For context I worked with Go extensively for about 5 years. I tried very hard to like it because I have immense respect for folks on the core team.
I even wrote some pretty good code in it.
However a few things became very clear to me over time.
1. Go is -not- a general purpose language. It lacks expressiveness necessary for this purpose which leads to overly hard to follow and refactor business logic, repetitive and error-prone (hah) error handling. Poor/inconsistent null handling. Highly variable quality standard library (some stuff is amazing like it's HTTP and TLS stacks). This leads it to be very good at one thing and one thing only, network servers, preferably operating at the protocol level. I think if you want to write a custom DNS, TFTP, or other simple network protocol and you cbf using Rust then Go is a great choice.
2. Go is easily picked up but very hard to master and the reward for mastery is much lower than languages that have similar learning curves. I would say I got very close to mastery but gave up short of the goal. Some things that come to mind here are handling of channels especially in select statements is much more nuanced than most would imagine, hell channels in general are -very- subtle. Subtle is never a word I want to hear when talking about a tech that I'm expected to support and mentor juniors to use.
3. Go leads to masses of very poor quality code that becomes extremely expensive to refactor, in large part due to language design decisions. However it's also a follow on effect of the above point but that applies equally to Python, JS, Ruby etc. What makes Go unique in this regard is that it is already a very verbose language but goes further to have a poor module system and structural typing system that makes code inflexible.
4. The ecosystem lacks high quality frameworks ala Spring that can be used to build applications in such a way that knowledge of structure and style are portable across codebases/companies/etc. Go (like JS) favours a smaller composable library approach which lends itself much better to highly experienced developers than beginners that really do need the help because they are yet to develop good taste. Unfortunately Go mainly caters to beginners so this is a fundamental impedance mismatch between the ecosystem and the users.
5. It actively repels experienced engineers. This is probably the controversial point but it holds true among my social group which I would consider to all be A++ engineers both in intellectual capacity but also real world effectiveness (i.e these guys build the stuff you rely on every day).
Why is this so? Well it boils down to that bit about mastery no being rewarding. Even in Java which is admittedly probably the most boring language on the planet there is a very rewarding payout for sticking with the language for a decade and getting exceedingly good at it, you have all the primitives at your fingertips, real threads, powerful reflection, metaprogramming and runtime introspection. What does Go offer? M:N coroutine model, pretty basic profiling capabilities, really shitty (and slow) reflection, runtime with almost no knobs to apply workload specific optimisations, etc. In short for all that time investment to fully peak out you are only marginally better than the next mediocre dev. TLDR: The ceiling is low, you end up surrounded my mediocrity, it's hard to effect change in large codebases as a result, Java/.NET/other langs don't suffer anywhere near as badly as such Go is avoided.
I could go on but these are the main points.
Also I could just be jaded old and grumpy but whatever, this is how I feel about it and everyone is free to be wrong on the Internet.
> Also I could just be jaded old and grumpy but whatever, this is how I feel about it and everyone is free to be wrong on the Internet.
No -- this is interesting. I also think point 3 and 5 probably informed and explain the new generics design, which seems intended to reward perseverance.
I didn't find channels difficult, but then I have some Occam, CSP and PVM experience, and some message-passing parallel language design experience too (albeit all academically, including 27 years ago in my final degree assignment)
I do think you are right there and that generics will have a significant (and likley highly positive) impact on Go.
Much of the code I wrote in large applications amounted to writing application specific data-structures that had no business being application specific. However due to Go restricting generic capability to language level features and reflection being far too slow it lead to a lot of it sadly. One of the reasons I love the JVM ecosystem so much is access to the `java.collections` library which is definitely 1st class among standard libraries.
I haven't kept up with Go development but I hope they are going to revamp the stdlib with generics powered structures etc. Seeing people use the stdlib linkedlist implementation always caused me to start questioning my life decisions.
As for channels I think basic usage is straight forward. Where things become complicated is differences between buffered vs unbuffered channels and how combining those in select statements etc makes for some interesting interactions. Which is what I find egregious, something that looks and feels simple until it's not.
That's one of my gripes with the language too. Due to the lack of generics, Go programmers just use pointers to indicate nullability - not exactly the right approach. Thankfully, it's still an improvement over Java, as non-nullable pass-by-value semantics are the default, so if you want a pointer you have to explicitly define one.
I have my fingers crossed that once generics land, the ecosystem switches over to some sort of an Option type.
> have a poor module system
I'm curious, what's poor about it?
> runtime with almost no knobs to apply workload specific optimisations, etc
The approach Go takes is that the GC should "just work" for all workloads. Obviously, this will never be 100% optimal for any given workload, but you know... tradeoffs.
That said, the knobs you're looking for do exist, but they are in the language itself. Unlike Java, Go makes writing GC-friendly code easy.
> Even in Java [...] you have all the primitives at your fingertips, real threads, powerful reflection, metaprogramming and runtime introspection.
Aren't "real threads" strictly worse than green threads?
> powerful reflection, metaprogramming
Those are misfeatures, especially metaprogramming.
I even wrote some pretty good code in it.
However a few things became very clear to me over time.
1. Go is -not- a general purpose language. It lacks expressiveness necessary for this purpose which leads to overly hard to follow and refactor business logic, repetitive and error-prone (hah) error handling. Poor/inconsistent null handling. Highly variable quality standard library (some stuff is amazing like it's HTTP and TLS stacks). This leads it to be very good at one thing and one thing only, network servers, preferably operating at the protocol level. I think if you want to write a custom DNS, TFTP, or other simple network protocol and you cbf using Rust then Go is a great choice.
2. Go is easily picked up but very hard to master and the reward for mastery is much lower than languages that have similar learning curves. I would say I got very close to mastery but gave up short of the goal. Some things that come to mind here are handling of channels especially in select statements is much more nuanced than most would imagine, hell channels in general are -very- subtle. Subtle is never a word I want to hear when talking about a tech that I'm expected to support and mentor juniors to use.
3. Go leads to masses of very poor quality code that becomes extremely expensive to refactor, in large part due to language design decisions. However it's also a follow on effect of the above point but that applies equally to Python, JS, Ruby etc. What makes Go unique in this regard is that it is already a very verbose language but goes further to have a poor module system and structural typing system that makes code inflexible.
4. The ecosystem lacks high quality frameworks ala Spring that can be used to build applications in such a way that knowledge of structure and style are portable across codebases/companies/etc. Go (like JS) favours a smaller composable library approach which lends itself much better to highly experienced developers than beginners that really do need the help because they are yet to develop good taste. Unfortunately Go mainly caters to beginners so this is a fundamental impedance mismatch between the ecosystem and the users.
5. It actively repels experienced engineers. This is probably the controversial point but it holds true among my social group which I would consider to all be A++ engineers both in intellectual capacity but also real world effectiveness (i.e these guys build the stuff you rely on every day). Why is this so? Well it boils down to that bit about mastery no being rewarding. Even in Java which is admittedly probably the most boring language on the planet there is a very rewarding payout for sticking with the language for a decade and getting exceedingly good at it, you have all the primitives at your fingertips, real threads, powerful reflection, metaprogramming and runtime introspection. What does Go offer? M:N coroutine model, pretty basic profiling capabilities, really shitty (and slow) reflection, runtime with almost no knobs to apply workload specific optimisations, etc. In short for all that time investment to fully peak out you are only marginally better than the next mediocre dev. TLDR: The ceiling is low, you end up surrounded my mediocrity, it's hard to effect change in large codebases as a result, Java/.NET/other langs don't suffer anywhere near as badly as such Go is avoided.
I could go on but these are the main points.
Also I could just be jaded old and grumpy but whatever, this is how I feel about it and everyone is free to be wrong on the Internet.