... wait a moment. Those 'wait groups' in Golang, is that literally just their equivalent of async-callback-counting in JS?! A practice which has been obsolete for like a decade by now?
I really struggle to take this language seriously...
And in particular, because it doesn't *look* like it's that hard
@joepie91 after offering fearless concurrency, we've finally discovered what fearful concurrency looks like
@joepie91 the design philosophy of go seems to be about being "simple" by ignoring any programming language design advancement after the year 2000 or so. hence the whole generics comedy and the error handling meme.
@operand I haven't been very loud about this despite being familiar with the issue, because I also know that issues with languages often get exaggerated for ideological reasons, and I didn't want to be complaining about it loudly without understanding things better first.
But no, it seems that it really actually *is* this bad...
@joepie91 There's an infamous quote by Rob Pike:
> The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
https://learn.microsoft.com/en-us/shows/lang-next-2014/from-parallel-to-concurrent (20:30 in this video)
You're right that people often exaggerate these things for ideological reasons but for Go the designers of the language make their design ideology refreshingly clear: a language that makes developers at Google maximally replaceable!
@joepie91 Now to be fair the language does also seem like a pretty good fit for the kind of data plumbing which is often necessary and which one might imagine a lot of programming at Google is. But I'm not really sure how much of that is the austere language design per se.
I've written a bit of Go (a while ago, before generics) and the language was fine, but the reasons why it doesn't have any of these modern features still seem deeply deeply silly to me.
(Coincidentally to your original post, that was at a summer job where the owner of the company wanted to try out Go, and my project convinced them to use Go as their standard language going forward. Personal bias, but for their usecase it probably was an improvement over Node)
@joepie91 no, a wait group is a basic primitive in low level concurrency.
@joepie91 (yes, they come with footguns if you don't use them correctly, they are a low level tool)
@bananas Yes, so are async callback counters. And just like those aren't used anymore because the vast majority of people shouldn't be working at that low a level and it's really hard to get right...
@joepie91 yes, but go has mistaken itself for a systems language where such structures are the norm.
@joepie91 Fun fact: Go has a convention to cancel long running operations through the channel of a context.Context. One catch: It does not interact with most of the stuff in sync standard library. Y'know, stuff that would be useful to be able to cancel?
This practice has been obsoleted, by the way, because people consistently kept fucking them up because it turns out that process synchronization is Very Hard To Get Right