I have similar feelings. I’ve been coding a long time, and the longer I do it, the less sure I am about any of this stuff. The one thing I can say for sure, I find it relatively easy to jump into an arbitrary go code base and make sense of it. I can’t say this about languages with all the features people are clamoring for, and I’ve worked on large projects in Ruby, python, Java, scala, clojure, swift, JavaScript, typescript, and a few others.
I’m not sure exactly which qualities/features of Go make it so much easier to read, but I worry that change will lead to the Go losing what makes it unique and special.
Side note: clojure was oddly the second easiest for me to read.
Making sense of a small, detailed part of a codebase is meaningless. But too much detail will make it much harder to see the big picture, something that may be more apparent in more expressive languages.
On a deliberate hyperbole, reading assembly, each line is trivial, but it is very very hard to make sense of what does it do compared to a line of a high level language.
would be over a dozen lines of code in golang, with potentially one off functions everywhere. This only gets more obnoxious with larger code bases.
The problem is that even if golang added generics, they won't be composable. In their proposal, they proposed adding map/filter/etc functions in a separate package, not as functions on slices as a proper language would do. The same mistake they did with not having any functions on strings, but kept them in a separate package.
Also, they need to improve their anonymous function syntax.
foo("param1", func(a int, b string) bool { return len(b) < a }
is verbose, more advanced languages simply shorten it to
I’m not sure exactly which qualities/features of Go make it so much easier to read, but I worry that change will lead to the Go losing what makes it unique and special.
Side note: clojure was oddly the second easiest for me to read.