> 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.
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)