3 ms·

> The argument to me is that Go advertises itself as being easy to write that concurrent glue code & then fails to provide basic abstractions around it. What‽

by wtbob 11y ago

> The argument to me is that Go advertises itself as being easy to write that concurrent glue code & then fails to provide basic abstractions around it. What‽ It provides channels, which are a really nice abstraction for concurrency. > Everything you mention about things being expressed in glue code would be easier if Golang provided a modern promises library & holds just as reasonably for other modern languages that do. Have you actually written any Go? Using channels in Go is much nicer than using callbacks. Callbacks basically force one to write one's code in continuation-passing style, while callbacks let one work about sync points only where you need.

kasey_junk 11y ago
> What‽ It provides channels, which are a really nice abstraction for concurrency. Channels are a concurrent safe queue, nothing more. They are not even particularly well implemented concurrent queues as they are highly contended. What go provides for abstractions around those queues are range and select. Range is a nice way to make simple concurrency cases look like traditional for loops (and is very rarely used in practice as simple concurrency cases are rare, at least for me). Select is a nice addition to the language, yet the edge cases around channels make it very difficult to reason about without keeping http://dave.cheney.net/2013/04/30/curious-channels http://dave.cheney.net/2013/04/30/curious-channels open. > Have you actually written any Go? Using channels in Go is much nicer than using callbacks. I have, for 2 years, full time. I have not used node. Have you ever used a language that supports concurrency besides Go? Go does not provide, as part of its concurrency abstractions, things that are deemed bare necessities by other languages such as timeouts, cancellation, supervision, lock free structures, etc. The entirety of the Golang concurrency story can be wrapped up with 3 things a) the culture of the language prefers message passing concurrency b) the scheduler is a very good example of when simplicity gets you great performance in the main cases c) select as a language keyword is interesting. By leaving the basics out you push all of that work to the application level, which is why I think the callbacks argument is a red herring. At the application level you are either going to encounter callbacks (as in the stdlib http handler) or blocking code (subject to races, deadlocks, etc).

by wtbob 11y ago

kasey_junk 11y ago

> What‽ It provides channels, which are a really nice abstraction for concurrency. Channels are a concurrent safe queue, nothing more. They are not even particularly well implemented concurrent queues as they are highly contended. What go provides for abstractions around those queues are range and select. Range is a nice way to make simple concurrency cases look like traditional for loops (and is very rarely used in practice as simple concurrency cases are rare, at least for me). Select is a nice addition to the language, yet the edge cases around channels make it very difficult to reason about without keeping http://dave.cheney.net/2013/04/30/curious-channels http://dave.cheney.net/2013/04/30/curious-channels open. > Have you actually written any Go? Using channels in Go is much nicer than using callbacks. I have, for 2 years, full time. I have not used node. Have you ever used a language that supports concurrency besides Go? Go does not provide, as part of its concurrency abstractions, things that are deemed bare necessities by other languages such as timeouts, cancellation, supervision, lock free structures, etc. The entirety of the Golang concurrency story can be wrapped up with 3 things a) the culture of the language prefers message passing concurrency b) the scheduler is a very good example of when simplicity gets you great performance in the main cases c) select as a language keyword is interesting. By leaving the basics out you push all of that work to the application level, which is why I think the callbacks argument is a red herring. At the application level you are either going to encounter callbacks (as in the stdlib http handler) or blocking code (subject to races, deadlocks, etc).