I think that's a valid perspective. But there are many of us who don't find Go harder to read than those languages (well, maybe not C++). I think we must recognise that to some extent simplicity is subjective. What is easy to one person isn't necessarily easy to another and vice-versa.
Personally, I think in abstractions. So a language that represents those directly is much easier for me to reason about than one that makes me constantly translate those low-level procedural code and back again.
Re:Go 1.18
by philosopher1234 on Tuesday March 15, 2022 @02:53PM
(#30689402)
Perhaps the trouble is when you encounter other peoples abstractions, or when you return to abstractions you’ve long since discarded :)
The key abstractions that I want access to are standard ones like "map", "filter", "reduce", and data structures like "Option", "Result", "Future, "ConcurrentHashMap".
Then logically brainfuck should be much easier to read with only the 8 or so “keywords” it has.
Complexity can not generally be decomposed into smaller parts.
I suspect that this is like arguing that if the Latin alphabet is more practical than the Chinese script, we should just jump straight to binary symbols. The fact that binary symbols would make writing impractical again doesn't negate the fact that the Latin alphabet is more practical than the Chinese script.
I can't say the same for Java / C#, Rust / C++ etc ...