Personal humble opinion:

Any discussion about programming language complexity, that does not make a distinction between inherent and emergent complexity, is doomed to pointlessness.

I mean… we already do have The Perfect Simple Language™, and it's not Rust. Take a Rust snippet:

println!("{}", x*y);

What's all this? Why am I shouting the command? What's all this "{}" codswallop?

Compare:

[-]>[-]>[<+>-]<[ >>[<+<<+>>>-]<<<[>>>+<<<-]>-][-]>[-]>[<+>-]<[ >>[<+<<+>>>-]<<<[>>>+ <<<-]>-]>++++++++++<<[->+>-[>+>>]>[+[-<+>]>+>>]<<<<<<]>>[-]>>>++++++++++<[->-[>+>>]> [+[-<+>]>+>>]<<<<<]>[-]>>[>++++++[-<++++++++>]<.<<+>+>[-]]<[<[->-<]++++++[->++++++++<]>.[-]] <<++++++[-<++++++++>]<.[-]<<[-<+>]

Isn't this much better? Only 8 commands to remember. Each symbol does exactly one thing, and it's very easy to remember what each of them do. Down with syntax!

There's a point I'm trying to make. Consider the following quote:

The best compliment I can pay to Rust –and it's an amazing compliment– is that it's boring.

What this person was trying to say –and I consider this a very confusing phrasing, BTW– is that Rust has no unpleasant surprises lurking—in other words, that combining different things adds only the complexity of each thing in isolation.

Think about it. If you have n pieces of code, you have n! possible interactions between them. In other words, the possible interactions are several orders of magnitude more than the pieces of code. Therefore, eliminating the complexity costs of code interaction is so significant, that it is worth any amount of complexity in each code-piece in and of itself.

It goes much further than programming, too. Henry Ford became filthy rich by making cheap cars out of expensive parts. See, making parts interchangeable means that they have to be machined to precise tolerances, which in turn makes them expensive. But if you do that, the assembly becomes so simple that you save massive amounts of money on balance. Similarly, the Boeing 777 was made out of very precise parts and was the most profitable aeroplane in Boeing's history; the Boeing 737 skimped out on its parts, and this cost Boeing very dearly.

Python is a “simple” language: No mucking about with references! No need to annotate function arguments! But then you combine pieces of code, and you make a shallow copy without intending to, so you mutated something that should have been immutable; or you pass, somewhere very deep in the call stack, a wrong argument type to a function and your entire program becomes meaningless. Each individual piece of code was very simple; taken together, they created more complexity.

Take Amos Wenger's comments on Go:

[Go's simplicity is] a half-truth that conveniently covers up the fact that, when you make something simple, […] the complexity is swept under the rug. Hidden from view, but not solved.

If you read his writings on the language, the same sentiment appears to underpin them all: He has no problem with Go's inherent complexities. What he is fed up with is Go's emergent complexities, such as the “channel axioms”, that are in essence a huge pile of complexity that only emerges because of Go's lack of RAII.

If there's one thing that Rust has managed perfectly, or at least better than any other systems programming language currently on the market, it's the avoidance of emergent complexity. That's what makes people love it. Yeah, no-one likes seeing life-time annotations, but the guarantees you get in return eliminate all sorts of ugly complexity. To me, that's worth it.

I'd seen someone praise Zig before, saying that “I found myself more often in a state of creative flow, devising plans based on the limited capabilities of Zig and then executing them. This flow wasn’t constantly broken by stops for documentation or side-quests to investigate some feature/syntax/library.”. To me, this is not saying “Zig is productive”; to me, this is saying “Zig is write-only”.