Yes but that tracks issues of all severities and with all of GitHub’s services of which there are a great many. Also “days since incident” is a terrible metric because it doesn’t capture how long the incidents last.

For example the latest incident is that copilot had degraded performance with Fable due to an Anthropic issue. It only last 18 minutes, only affected part of a part of their service, and it wasn’t even their fault!

That’s very different to “all of GitHub is down for 7 hours”.

So yes. I am not sure GitHub is worse.

Ah yeah looks like the latest 19.1 release from June.

But it also seems to suggest it’s only a UI change. Is is possible to do stacked MRs across forks? Does it not still suffer from the flaw GitHub has (or had, hopefully) - you create one MR, myfork:feature_0 -> upstream:master. That’s fine, but then you want to create the second MR targeting the first MR, myfork:feature_1 -> ???:feature_0, only you can’t. feature_0 doesn’t exist in the upstream and there’s no point creating an MR targeting your own fork.

I’m not sure it actually is. At best it is too early to tell.

I haven’t used it yet but assuming they did it right, yes you can merge the PRs sequentially.

Do you mean GitHub? Last I checked Gitlab doesn’t support stacked PRs.

Me too, but obviously there is a point at which I would say “this language isn’t so great that I’m willing to tolerate these compile times”.

Yes they do. I don’t think it’s totally unreasonable. Slow compile time is a big productivity drain. But it’s not as bad as people often make out for Rust - in large part because compilation speed has at least doubled since Rust 1.0, but its reputation is still based on the 1.0 compile times.

And some specific projects do have substantially bad compile times. When your incremental compilation time is 20 seconds where in other languages it’s instant… That’s notably worse.

But I don’t think it should be a deal breaker. C++ has dealt with similarly bad compile times for decades and people don’t like it but it’s never been enough for most of them to switch to another language.

500-600 applications!? Sounds like you are putting low effort into sending a lot of applications rather than high effort into a few.

I am now pursuing opportunities to return to paid work on the Rust compiler. Wish me luck!

Someone (Rust Foundation?) pay this man! Compilation speed is one of the few weaknesses of Rust and even though I think that in 95% of cases it’s actually not that bad and people are just looking for an excuse to not use Rust, it would be great to remove that excuse. (And faster compilation is always nicer anyway!)

Vibe port the Zig compiler to Rust? 😄

Ah I see. That definitely depends on what it is and who your target audience is. I would say you can be quite technically proficient in Windows without being very familiar with the command line because a) the Windows command line sucks (even Powershell is kind of awful), and b) there are so many great GUI tools available, you almost never need to resort to the command line.

So yeah, just depends where you want to draw the line and what it is that you’re making.

Excellent presentation skills! He’s heard of the hero’s tale.

Depends on the windows user. But I dunno why you wouldn’t offer it for Windows. You kind of have to go out of your way these days to make supporting Windows difficult, e.g. using OCaml or Perl or Bash or something.

I’ve never seen a good answer to this question. Snapshot testing sucks. A 0.3% threshold can totally be too low for benign changes and too high to detect real bugs.

Manual testing is probably the best option if you can afford it, but it’s time consuming and tedious.

I’m sure there are people working on AI for this. I wouldn’t be too surprised if that’s the best option but I haven’t looked into any of that. Also you really want it to be deterministic and I’m not sure how you do that with AI easily.

I think your intent sounds reasonable. I expect other people have done this, they probably just didn’t wrap it up in a nice crate.

Also no idea why I was downvoted. Maybe because I mentioned the forbidden word.

This is cool. Back when I worked on Typescript the one type-aware lint you really needed was to prevent boolean coercion. I did get it working but the configuration effort required to get ESLint to have all the right plugins and settings was insane.

If you find yourself reaching for this feature it probably means your Bash script has reached the level of complexity where you should absolutely not be using Bash. Use a real programming language instead.

Indeed, but animating bulleted lists is like the most common thing people do in presentation. The fact that they didn’t notice it… It’s like if your compiler miscompiles printf.

A fairly recent version IIRC. May have been a one time bug but it was a pretty hilariously bad one. At the very least it shows poor quality control.

I think the use of the term junior and senior is a bit confusing because it conflates age and skill. I would say most people use it to talk about skill, because we’re talking job titles here.

While age and skill are certainly linked, I have known several junior engineers well over 50 (don’t hire these people!), and also some extremely skilled engineers in their very early 20s. The latter hadn’t yet earned the “senior” job title but that’s just because they didn’t know they deserved it yet.

So yeah I do think junior (skill) programmers are pretty screwed - AI is already at least on par with the junior skill level people I’ve worked with. But I don’t think that means young people are screwed, as long as you are good at your job.

For now anyway. Who knows how good AI will be in 5 years. We might all be out of a job.