The bots can also write Rust instead of C++, doing away with the arcane nonsense accumulated by that legacy language. SCNR.

Bot-assisted Rust could be amazing; there's some ports already happening which wouldn't have otherwise. Maybe Rewrite-it-in-Rust can actually be a real thing and not just a meme. But it does put a big burden on implementors to understand what they're generating, and now it's in an unfamiliar language to boot.

Bureaucracy gives you leverage against slop. Review seriously, but limit the time that you spend. This will stall the slop. When the culprit complains, tell your boss "I spend X hours per week on reviews. If you need more throughput, the PRs quality needs to improve."

Writing and reading design documentation can be slower than pair programming. On the other hand, info about code design also belongs into inline documentation or commit messages (in this order of preference), so the effort might not be wasted.

I don't think so. There can be a lot of shared context within the team which can make prose shorter than writing code. And written words last longer than verbal exchange.

It's not just documentation. Everything that makes programming easier is now suddenly valued, because wasting tokens is obviously worse than wasting your employees' time.

Employees get paid either way, so weirdly that makes it less motivating. Costs aren't lower if you put more work into writing a good spec.

When you're paying piecework style, suddenly the work needed to write a good spec has a bottom-line payoff.

The list of tools that Pythonheads present as a definite solution to their problems changes every year, yet the results are still far behind Rust/Scala/Kotlin/C#.

Surpassing DB's punctuality is the first large-scale example of the "Overtaking without catching up" East German slogan coming true.

The "fix everything" button is abolishing zoning laws, and its aggregate cost is negative. Aggregate cost is not the issue preventing problems from being solved.

> on top of a well designed language constructed over past language design experience

While I believe that Chris Lattner is a great compiler designer, his language design record has been less stellar. Swift bidirectional type inference for instance feels like it was implemented because they had a compiler algorithm that they wanted to use, rather than a genuine need, and is just a completely avoidable problem. Trying to make a HPC language that is also Python compatible was doomed from the start. Hopefully the damage from going into this direction will remain limited.

Mojo is NOT Python compatible (although they initially wanted it to be). So they got all downsides without the upsides.

They claim you can easily mix them so there is some degree of compatibility.

Every reasonable language has a Python interop story. All it takes is C FFI. But what Mojo promised early on was the eventuality of compiling a large amount of Python code if not entire wheels as Mojo.

I don't recall they promised that. They promised it'll be a superset, but Mojo introduces new keyword. Mojo could support all Python features today exactly as they're supported in Python and you wouldn't still be able to copy Python code into Mojo and compile it

"All downsides"? What do you mean?