I use Go quite a bit, and I have the exact opposite experience from a lot of these testimonials.
Someone else mentioned go just works, they don't have to fight the tooling, or that they worked on a go program that works five years later (which language does this not apply to). ??? I've had quite a few problems with things like plugins for go deleting unused imports because I am in the habit of saving frequently. I resolved it, but I still had to fight with the tooling. Then there was the whole go mod situation.
Go code is a language that has succeeded in a niche market (It's magical to just spin up a web server that works out of the box with great performance. ) while also handicapping itself so that complex code is too difficult to write. So it doesn't get associated with the problems some other languages have. Java is a good language that people ruined with horrible enterprise culture.
I don't even really think that go is that painless to learn. The small size of average projects has led to some dire fault lines. The biggest one for me is that it's structural typing for interfaces isn't explicit. Often times I'll read some code that uses an interface, and I'll have a real hard time mentally mapping what uses that interface and how to write code. 90% of the time this isn't an issue because the projects are small enough that I can just keep the whole thing in my head, and I can make educated guesses, or I only need to remember a handful of common cases. This doesn't scale well. Yea, I know there's plugins for these things - and I use them, but I am not a fan of tying development to non-standalone tools.
Anyways, rant aside, looking forward to another 11 years of go.
Yeah, Java is better than most languages at this too. It’s still too early to say for sure, but Go feels better at this point. it has more to do with the libraries, dependencies, and ecosystem relative to Java.
I don’t even remember what I was using for Java 1.2. Maybe ant and struts? I doubt there’s a good path to update such things without a giant rewrite or refactor.
The simpler the language the better it is for complex code. Heavy abstractions won't help another reader of your code understand what's going on. In most cases it means it will take them much longer to understand.
Concise code with heavy abstraction can help eliminate errors, but it definitely doesn't make reading it easier. It also doesn't make solving problems any easier. Solving problems is all about algorithms and data structures, not the language you are using.
I suggest you try and implement some complex but well-defined algorithm, e.g. sha256, in some very, very simple language, say, brainfuck (which is very close to the original Turing machine language). Or, more realistically, in PDP11 assembly, which is beautifully transparent and uniform.
You might then notice that there is some kind of sweet spot in complexity: fewer features and footguns than, say, C++, but more features and abstractions than machine code.
SHA256 is a fixed circuit. It's a particularly weird thing to implement. Other than it being a bit long, it's not complex to implement, even on a calculator.
If you want an example of something moderately complex but well defined, go implement a min-heap or some other basic algorithm.
Rich Hickey[] has a nice talk "Simple made easy", where he differentiates between exes, the simple-complex axis and the easy-hard axis. By his definitions, you can kind of strive for easiness but get complexity, and if you aim for simplicity it may be hard. His point is, that you'd much prefer simple-hard over something 'easy' that leads to incidental complexity.
I feel like Go isn't so much aiming for simlicity but actually for easiness in that line of thought, and thus its only a matter of time until complexity is encoded within the Go code.
Now, aiming for simplicity is not easy, at times definitely hard but it can lead to actual simplicity.
[] obligatory note that while I like this talk I don't agree with all of his utterances.
Code that requires codegen or some verbose structure to express some constraint or idea that could be expressed in a sentence or two or a simple oneliner with the right abstraction can actually be harder to read because of the miles of boilerplate you have dive through.
Ex doing string processing in python vs golang. In golang or java even it's far more lines of code and far harder to understand.
Someone else mentioned go just works, they don't have to fight the tooling, or that they worked on a go program that works five years later (which language does this not apply to). ??? I've had quite a few problems with things like plugins for go deleting unused imports because I am in the habit of saving frequently. I resolved it, but I still had to fight with the tooling. Then there was the whole go mod situation.
Go code is a language that has succeeded in a niche market (It's magical to just spin up a web server that works out of the box with great performance. ) while also handicapping itself so that complex code is too difficult to write. So it doesn't get associated with the problems some other languages have. Java is a good language that people ruined with horrible enterprise culture.
I don't even really think that go is that painless to learn. The small size of average projects has led to some dire fault lines. The biggest one for me is that it's structural typing for interfaces isn't explicit. Often times I'll read some code that uses an interface, and I'll have a real hard time mentally mapping what uses that interface and how to write code. 90% of the time this isn't an issue because the projects are small enough that I can just keep the whole thing in my head, and I can make educated guesses, or I only need to remember a handful of common cases. This doesn't scale well. Yea, I know there's plugins for these things - and I use them, but I am not a fan of tying development to non-standalone tools.
Anyways, rant aside, looking forward to another 11 years of go.