Yeah… I have 100k rep (almost exactly!) and I don’t use it any more. It doesn’t have the network effects, so even if there is a question that AI can’t answer (which does still happen despite what some people seem to think), I don’t go to Stackoverflow, I go somewhere else. A forum, GitHub repo discussions, even IRC once (OpenOCD still uses that for some weird reason - they were extremely helpful though).

It had a good run. RIP.

Seems like a good policy. Especially if they’re bottlenecked on review, which most large open source projects are.

Who doesn’t want to be able to get their work done easier? Nobody.

Err, people that don’t want to be made redundant? You haven’t been at all paying attention to the history of automation!

I don’t know why you think Python is fine but Typescript isn’t. With modern Python best practice (project.toml and uv) they have basically the same behaviour and caveats. Python is actually a little worse because most Python packages don’t use semver.

It’s not that it’s a bad idea, it’s more that it’s basically impossible at this point.

Bazel can’t use Cargo, CMake and so on for downloading & building packages because it is trying to do cross-language builds the right way - a single build graph that includes everything. No other third party package managers/build tools actually exposed their build graphs - only commands to perform builds, which are too coarse for Bazel.

To put it simply, its necessary if you are doing things at the scale of Bazel.

Python is one of the worst offenders here. I don’t think Python’s poor behaviour should excuse Lua’s.

But I can also see why Python is making breaking changes - a lot of Python is so bad it really makes sense to clean it up. I dunno if Lua is in that situation.

Anyway I think I would look to other languages like Go, Rust, Java, C++ which do a much better job. I don’t think Go or Rust have any backwards incompatibilities (at least very very few) and C++ has a small number but they’re for stuff that is truly ancient or almost completely unused. It’s totally possible if you care about it.

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.

What are you talking about? 500 applications is clearly way too many for them to be serious. You’re basically spamming at that point.

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.

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.