3 ms·

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. As annoying as callbacks can be, they do fit the model basic GUI model very well: user clicks on something, the system calls the corresponding funciton. And indeed I see a lot of that sort of thing in the README. Does that mean goroutines will fade into the background in Gallium?

aikah 10y ago
> 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.
- sime2009 10y ago
  > 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. Node also has a full set of 'normal' synchronous I/O operations (although they were added later after the async stuff).
- Klathmon 10y ago
  A bit of a nitpick, technically you can hide if a function call is async or not by `await`ing it. It will act the same when it's sync vs async. It would be a horrible idea to await everything, but it would work.
coldtea 10y ago
>As annoying as callbacks can be, they do fit the model basic GUI model very well: user clicks on something, the system calls the corresponding funciton. Those are callbacks for event-driven programming. But there's nothing about them that makes it a great abstraction for asynchronous tasks in general, and even less so for concurrency tasks. They are a low level abstraction that should be used as an implementation detail.
zamalek 10y ago
> Go has hordes of green threads "goroutines" To clarify, they do not fall into the the strictest definition of green threads[1]. > [2]: As of Go 1.5, the default value of GOMAXPROCS is the number of CPUs (whatever your operating system considers to be a CPU) visible to the program at startup. Prior to 1.5, the default value was '1' but could be changed. > GUI model [...] Does that mean goroutines will fade into the background in Gallium? The main concern at the moment seems to be wrapping the underlying APIs. However, I see channels being used for great effect further down the line: var ui chan uiFunc = // ... button1Click := make(chan ClickEvent) go func() { for evt := range button1Click { ui <- func() { textBox1.setText("Button clicked!") } } }() button1.onClick(button1Click) I presume this also applies to interacting with the V8 ABI, seeing as JS is inherently single-threaded. [1]: https://golang.org/pkg/runtime/#GOMAXPROCS https://golang.org/pkg/runtime/#GOMAXPROCS [2]: http://dave.cheney.net/tag/gomaxprocs http://dave.cheney.net/tag/gomaxprocs

aikah 10y ago

> 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.

sime2009 10y ago
> 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. Node also has a full set of 'normal' synchronous I/O operations (although they were added later after the async stuff).
Klathmon 10y ago
A bit of a nitpick, technically you can hide if a function call is async or not by `await`ing it. It will act the same when it's sync vs async. It would be a horrible idea to await everything, but it would work.

coldtea 10y ago

>As annoying as callbacks can be, they do fit the model basic GUI model very well: user clicks on something, the system calls the corresponding funciton. Those are callbacks for event-driven programming. But there's nothing about them that makes it a great abstraction for asynchronous tasks in general, and even less so for concurrency tasks. They are a low level abstraction that should be used as an implementation detail.

zamalek 10y ago

> Go has hordes of green threads "goroutines" To clarify, they do not fall into the the strictest definition of green threads[1]. > [2]: As of Go 1.5, the default value of GOMAXPROCS is the number of CPUs (whatever your operating system considers to be a CPU) visible to the program at startup. Prior to 1.5, the default value was '1' but could be changed. > GUI model [...] Does that mean goroutines will fade into the background in Gallium? The main concern at the moment seems to be wrapping the underlying APIs. However, I see channels being used for great effect further down the line: var ui chan uiFunc = // ... button1Click := make(chan ClickEvent) go func() { for evt := range button1Click { ui <- func() { textBox1.setText("Button clicked!") } } }() button1.onClick(button1Click) I presume this also applies to interacting with the V8 ABI, seeing as JS is inherently single-threaded. [1]: https://golang.org/pkg/runtime/#GOMAXPROCS https://golang.org/pkg/runtime/#GOMAXPROCS [2]: http://dave.cheney.net/tag/gomaxprocs http://dave.cheney.net/tag/gomaxprocs