4 ms·
That's right, concurrency model does not break anything but still there are multiple concerns : 1) async/await are not supported in ES5, so after translating c
by sAbakumoff 9y ago
That's right, concurrency model does not break anything but still there are multiple concerns :
1) async/await are not supported in ES5, so after translating code from Go to JS I would also need to babelize it!
2) parallelism is not preserved
3) maybe it's just me, but in fat client apps it's all about event handling and data flow, co-rotines are not very useful there. But in Golang it's the most powerful feature ever(IMHO)
- jrs95 9y ago1) I don't think it actually uses async/await as it explicitly targets ES3. It's probably just using callbacks or something. 2) Parallelism isn't guaranteed by goroutines anyways, and this is targeted towards building new apps more than it is reusing existing Go code, so it shouldn't really be that much of an issue. Most web apps/SPAs have no need for parallelism.
- sAbakumoff 9y ago1) It does not really matter that you think because the author said the following: "Actually to my surprise, goroutines and channels can be modeled quite well in Javascript! Right now the compiler uses async/await but for 1.0, I think it's possible to compile it down to ES3."
- randomdata 9y ago> in fat client apps it's all about event handling and data flow, co-rotines are not very useful there. I would suggest that coroutines can solve event handling problems quite nicely. This is not exactly a novel idea either. There are toolkits in the wild that are designed to work exactly like that. From what I understand, there hasn't been any serious exploration of building UIs in Go, but I think its native coroutine/channel support has the potential to provide some interesting ways to handle events that are generally shied away from in languages where coroutines are not as easily used.