Each has their benefits:

Python wins in AI and syntax niceties. Loses on perf and library migration. uv (written in rust) saved the whole ecosystem from dying in my opinion.

Typescript wins because web integration, much better type system, ok perf, and gigantic npm ecosystem. Also loses on library migration and perf and large container sizes.

Go wins on compile speed, perf, standard library l, module system, and go fmt + never breaking compatibility being a massive LLM advantage. Main con is not being rust :)

Rust wins on perf, safety, syntax, wasm / sandboxing. think worse on module system and compile speed vs Go.

Java/Kotlan/C# are in enterprise land and probably the runtime approach is flawed for the ai eras.

C++ is strangely relevant because choosing c++ is easier than before. I tried writing a shared library in rust and then trivially converted it to c++ when I wanted

Zig is up and coming but also has an unknown future. Seems like a great language, but if bun switches to rust it might be set back a bit.

This is true for a usual approach, but the whole reason I’m writing the CRDT is to avoid these tombstones! Anyway, a long story short, I did eventually convince Claude I was right, but to do it I basically had to write a structural proof to show clear ordering and forward progression in all cases. And even then compaction tends to reset it. There are a lot of subtleties these systems don’t quite have yet.

Start with Claude Code if you haven't tried it yet as it can edit your files directly and has some pretty fantastic skills/plugins that are quite interesting. (Copilot is quite a bit far behind unfortunately.)

Also, I think the missed the first note UI could feel a little nicer. Something about the popup/hiding the music takes you out of the flow. Possibly just a subtitle would be enough with an encouraging message. There is a big difference between failing to do the whole pattern and failing the first note so definitely worth refining the feedback here.

Additionally, it is even more powerful when used with go modules. Make every script call a single function in the shared “scripts” module and they will all be callable from anywhere symmetrically. This will ensure all scripts build even if they aren’t run all the time. It also means any script can call scripts.DeployService(…) and they don’t care what dir they are in, or who calls it. The arguments make it clear what paths/configuration is needed for each script.

My hope is they will see these repeated pain points and find something that fits the error/result/enum issues people have. (Generics will be harder, I think)

For example, for the fall over regions (from the article) you could make a pulumi function that parameterizes only the n things that are different per fall over env and guarantee / verify the scripts are nearly identical. Of course, many people use modules / terragrunt for similar reasons, but it ends up being quite powerful.

I’ve found you have to use Claude Code to do something small. And as you do it iterate on the CLAUDE.md input prompt to refine what it does by default. As it doesn't do it your way, change it to see if you can fix how it works. The agent is then equivalent to calling chatgpt / sonnet 1000 times a hour. So these refinements (skills in the post are a meta approach) are all about how to tune the workflow to be more accurate for your project and fit your mental model. So as you tune the md file you’ll start to feel what is possible and understand agent capabilities much better.

So short story you have to try it, but long story its the iteration of the meta prompt approach that teaches you whats possible.