Totally not the point of the article, and totally subjective I know, but to me the thing that jumps out is how much more readable the Go code is than the others.
This is the main reason that I use Go as my main language, and why many orgs are starting to adopt it: it's easy to read and jump into. I would argue, however, that it's very easy to create antipatterns and just general spaghetti code with Go. A language that's easy to be productive with != one that's also easy to maintain. Design and philosophy becomes very important with large codebases in the language.
source: consultant, seen some truly heinous Go monoliths.
There are definitely some ways to do bad designs in go, but i have the feeling it will be more immediately apparent what's wrong (or at least what part of the system needs rework). The reason being that there are no ways to obfsucate an awful design by wrapping it on mountains of generics programming and language sugar, making the whole thing a lot worse.
It's only my gut feeling, but does that match your experience ?
Definitely subjective. I don't find some parts very readable. E.g., this line took my a minute to parse:
append34 := func() func([]int) []int {
If I was going to rank the readability I would say:
1. Rust function bodies
2. Go code
3. Rust function signatures
4. C++ code
Which you could argue is me shifting the boundaries a bit, but sufficiently statically typed languages seem to develop two (or more) sublanguages. Global complexity definitely pushes Rust down peg.
I agree. However, my gut reaction was that the style of the go code was written differently than what I’d expect if asked to work off the rust version.
> Can you mention the difference that made Go code is more readable than C++ and Rust?
Probably not, and to be fair anyone else's preference is equally valid. I think largely what individuals consider most readable depends less on what's being read and assessed now, and more on what route a developer has taken to reach this point in their career.
If I'm honest it's more about unconscious familiarity with idioms and constructs than it is an isolated unbiased opinion.
And I'd probably also change my comment slightly to say that by "Go code" I really did mean the actual code doing the work; I find the tests far less appealing.
source: consultant, seen some truly heinous Go monoliths.