4 ms·

but why? Go's model is perfect. They're not real threads, it's basically very similar to Node, except that you can write code without a mess of callbacks and it

but why? Go's model is perfect. They're not real threads, it's basically very similar to Node, except that you can write code without a mess of callbacks and it's easier to reason about...

stouset 9y ago
Go's model doesn't even statically prevent data races (as Rust's does). You might think Go's model is good, but it's a far cry from perfect. Although I'll be happy to point out why Go's model isn't even good. Go's lack of ability to perform meaningful abstraction combined with the low level of its concurrency primitives means you end up having to copy/paste and slightly tweak dozens of lines of flow-control logic every time you use them. This[1] is an excellent critique of Go's concurrency model. [1]: https://gist.github.com/kachayev/21e7fe149bc5ae0bd878#so-what-about-patterns https://gist.github.com/kachayev/21e7fe149bc5ae0bd878#so-wha...
a13n 9y ago
async await though
- paulddraper 9y ago
  And no shared-memory CPU parallelism.
  - a13n 9y ago
    No threading bugs though.
owaislone 9y ago
Not just that. It can use multiple OS threads and multiplex the goroutines on actual threads so programs can actually leverage multiple cores.
brightball 9y ago
Nothing's perfect. Go's is Erlang's with a shared memory model. That creates a lot of trade offs and limitations. In some places, it's a perk. In others, it's not. No such thing as perfect, only trade offs.
int_19h 9y ago
Go's model breaks down as soon as you have to invoke into non-Go code, because the latter has no idea about goroutines. This is a general problem with all "green thread" abstractions - they are not OS level, or if they are (as e.g. fibers are on Win32), nobody cares to use them. Promises, on the other hand, can be mapped to a straightforward callback-oriented C API, thus allowing a fully async execution stack end-to-end across different languages. You can even go one step further and define a uniform API for all such callbacks, as WinRT did.

but why? Go's model is perfect. They're not real threads, it's basically very similar to Node, except that you can write code without a mess of callbacks and it's easier to reason about...

stouset 9y ago

Go's model doesn't even statically prevent data races (as Rust's does). You might think Go's model is good, but it's a far cry from perfect. Although I'll be happy to point out why Go's model isn't even good. Go's lack of ability to perform meaningful abstraction combined with the low level of its concurrency primitives means you end up having to copy/paste and slightly tweak dozens of lines of flow-control logic every time you use them. This[1] is an excellent critique of Go's concurrency model. [1]: https://gist.github.com/kachayev/21e7fe149bc5ae0bd878#so-what-about-patterns https://gist.github.com/kachayev/21e7fe149bc5ae0bd878#so-wha...

a13n 9y ago

async await though

paulddraper 9y ago
And no shared-memory CPU parallelism.
- a13n 9y ago
  No threading bugs though.

owaislone 9y ago

Not just that. It can use multiple OS threads and multiplex the goroutines on actual threads so programs can actually leverage multiple cores.

brightball 9y ago

Nothing's perfect. Go's is Erlang's with a shared memory model. That creates a lot of trade offs and limitations. In some places, it's a perk. In others, it's not. No such thing as perfect, only trade offs.

int_19h 9y ago

Go's model breaks down as soon as you have to invoke into non-Go code, because the latter has no idea about goroutines. This is a general problem with all "green thread" abstractions - they are not OS level, or if they are (as e.g. fibers are on Win32), nobody cares to use them. Promises, on the other hand, can be mapped to a straightforward callback-oriented C API, thus allowing a fully async execution stack end-to-end across different languages. You can even go one step further and define a uniform API for all such callbacks, as WinRT did.