> So Go and JS are similar in that they are designed for heavily asynchronous tasks. But they do it very differently: Go has hordes of green threads "goroutines

> So Go and JS are similar in that they are designed for heavily asynchronous tasks. But they do it very differently: Go has hordes of green threads "goroutines", JS has callbacks all the way down. concurrent tasks =/= asynchronous tasks. A big difference is that Go doesn't force you to write asynchronous code for I/O operations, JS engines like nodejs do and it's a pain in the ass. Go only says : "If you want to write concurrent code you can do that", while NodeJS or browsers say :"Any I/O operation needs to be asynchronous and explicit". If I call an API in Go, I don't have to care whether the computation will be executed in the same thread or not, or in 10 different threads, provided concurrency is encapsulated the right way. There is no amount of async/yield/promise that can mask any I/O operation with Nodejs on the other hand. > As annoying as callbacks can be, they do fit the model basic GUI model very well: This is a design decision. Gallium could have used channels instead of callbacks.