|
|
|
|
|
|
by dahauns
3313 days ago
|
|
|
While it gives good insight to the problem of sync vs async functions, I've come to find its conclusions problematic (and it rather blatantly ignores Chesterton's fence), especially with "Java did it right, but they have started to do it badly now", and especially "Go has eliminated the distinction between synchronous and asynchronous code".
Ouch. You are going to think that - until your hit first deadlock or race condition. While implementation quality of the "colored function" concept varies greatly (and JS async/await is not a good example IMO - look at C# for one that doesn't neccesarily suffer the "async all the way up" problem, for example), there are reasons it's so prevalent. Async is fundamentally different, and more importantly: In the end, it's all about the data. That's why the most important part of goroutines is the channel/send/receive(EDIT: And especially select, of course. :)) implementation. And that's why the simple "go func" syntax itself or whether it's different from normal function is a bit of a red herring, since the implementation and data access/communication inside the function will likely be different. |
|
|
I love Go, it's my language of choice. There's a clear difference between calling a function sync or async. It's nice that we can choose to do either at will.
Oh, except that if it's an async call we have to use channels to communicate with it. Which is cool, but it's a different mechanism than if it's a sync call.
It's exactly the same as the red/blue rant about JS. If it's async you have to hand it a channel to talk to you on. If it's sync you can just wait for it to return. Async/Await same same but different.
Yes, the language does some nice stuff under the covers about pausing goroutines, but it only does that if you have multiple goroutines. If you code everything without using goroutines (and channels) then it's not concurrent and won't do the nice stuff. It'll pause for i/o just like any other language.