Well now it's true. I think people said it earlier because they didn't really care about the slop. I do care, and so I would have totally agreed with you 3 months ago. But since Astra they made a huge leap (way beyond what the benchmarks show). Kind of annoying because I'd like to use them for personal projects but they're really expensive. I tried some of the cheaper models and they're still in slop land.

In a way this is all great because vibe coding actually works for real now. Tools that I've wanted for years I can now make in a few days of prompting. But also... society is not ready for this. And I would like to have a job. Still, sticking your head in the sand isn't going to help.

Git has a mutable map whose keys are strings, and whose values are content-addressed objects. The keys are conventionally formatted as file system paths

I used to think this too, but I think it's more accurate to say the keys are filesystem paths. Try creating branches foo and foo/bar. That would be fine if the keys were strings. I vaguely recall there was some effort to make that actually work, but it doesn't today.

Do you understand why is it origin master in one command, and origin/master in the other? I didn’t, until a few weeks ago!

I mean I understood that it was because Git has a terrible CLI, and... that is ultimately still the reason. There's no fundamental reason it couldn't have been consistent. It just isn't.

I don't think your Wayland comparison is great. There are already solutions to app isolation that make X a weak link, e.g. Android or Qubes. Whereas there's basically no future where SHA1 in Git is the weakest link.

Also security was only one reason for Wayland.

For code at least. Makes sense. For maths I think radians are more elegant but you don't have to worry about speed or precision there.

You can (and should!) do exactly the same with "traditional" GitHub Actions style YAML.

Avoid putting commands in the YAML - put those in separate scripts and call them from the YAML. The YAML should only be used for things that can't be done from scripts (e.g. job matrices, uploading artifacts, reporting status etc.)

I totally agree about story points being bollocks. Their supposed justification is that you can measure velocity by seeing how many story points you do per month, but that only works if there's no feedback from velocity to story point estimation which is obviously not the case.

So in practice they just become a stupid proxy for time. "1 story point is an hour right?"

The Fibonacci thing makes some sense to me though - it is a way of suggesting that bigger estimates are less accurate.

Of course it would be much better if you could actually put an accuracy directly into Jira or whatever (e.g. 10-30 hours), but that would apparently be way too complicated. You could also get that data fairly nicely from planning poker (which I also think is pretty good, but you throw away all the information about uncertainty that you just spent ages discovering!)

There are definitely some cases where memory safety isn't especially important:

• Single player games
• Apps that don't process external data (e.g. a simple calculator).
• Lots of things running on microcontrollers, where the form of input could never possibly cause any security issues. E.g. a motor controller or a basic syringe pump or a (non-smart) washing machine or something.
• Tests, e.g. I've considered writing RISC-V tests in Zig. They're traditionally written in C or assembly.

In cases like those, memory unsafety mainly leads to non-security bugs and annoying debugging sessions. But I wouldn't say it's as much of a deal breaker compared to e.g. writing a video codec or font renderer or web browser or DNS server or whatever.

I still think Rust is a better choice than Zig in most cases anyway, even ignoring memory safety. But in these cases it's at least a defensible choice.

To be fair the days when a game was "released" and that was that are also pretty much long gone. Big studios now rely on being able to patch bugs after release.

Wow. I wonder why nobody saw this before then? Op's code doesn't look unusual.

A human engineer will get those passively at no cost to the company.

Some human engineers. I still regularly have to explain Git to people that never bothered to learn.

Also I think you are forgetting that AI is still improving and getting cheaper. Not super quickly, but even if it is too expensive now, is that still going to be true in 10 years? I doubt it.

Surely you wouldn’t argue that Rust or C++ would be a more appropriate alternative in that kind of role because they’re statically typed.

Not C++. Rust hopefully, when cargo script is stabilised!

Until then I strongly prefer Deno (which is also statically typed) for ad-hoc scripting. Python is surprisingly bad for that use case despite it being super popular for it because:

1. There's no way to use third party dependencies reliably from a single-file scripts. You're limited to the standard library, or setting up a whole pyproject.toml, venv and so on.
2. You can't import files by relative file path like you can in Deno, Zig, and Rust (sort of; it's slightly hacky). That leads to people doing hacks to PYTHONPATH or importlib which completely breaks all tooling.

Wow yeah that looks awful. Great reviews though.