Earlier quoted context omitted.
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…
> 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 d…
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.