The author stated below that co-routines are translated to async/await. for me it seems to be completely different concepts because golang co-rotines allow to execute the code in parallel which async/await can't do.
Given that the Go runtime will put any number of goroutines on any number of threads, it seems like being limited to one thread in a JS environment shouldn't break anything. The concurrency model works regardless of the number of underlying threads.
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)
> 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.
1) 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.
1) 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."
I suspect "works" is strong - if there's no preemption, it's very easy to hit a deadlock. Consider a program that e.g. mines bitcoin on one goroutine and displays UI on the other. On any normal platform, the UI goroutine would get scheduled on a thread at least occasionally, but if you only have one thread to go around and no preemption, the mining task could just keep mining forever.
How are the two threads communicating? Via a channel? Why can't you schedule when a value is pushed onto a channel? Why do you need preemption in this situation?
The first task is writing to the second when it's done with a computation, but not bothering to check input from the second while it's in the middle of a computation.
Well, this works as long as you're using a separate goroutine and the Go runtime creates more than one thread, right? My claim is that a Go runtime that only creates one thread (which is effectively what Joy is) will not work the way you expect in this case.
Or, more specifically, that if you have N goroutines that consist of infinite loops of pure computation (or really, anything that doesn't involve receiving from a channel), and at least one other goroutine that's receiving from a channel, your runtime needs to generate at least N+1 OS threads or your last goroutine will never get scheduled.
That isn't any different from anything else in the browser though. It's not going to lock up anymore than async JS code would during CPU intensive operations. Which generally don't need to be done in browsers anyways.
I don't know too much about Go, but I think that background computations can be converted to web workers. Looks like Joy doesn't do it right now, but again, it doesn't seem fundamentally impossible.
(Also, it wouldn't surprise me if the majority of goroutines in practice were I/O heavy and not computationally heavy.)
