3 ms·
>Some that burn me a lot is support for future/promises This doesn't make sense in Go. Nothing is asynchronous in Go, everything is blocking. You use goroutine
by emersion 8y ago
>Some that burn me a lot is support for future/promises
This doesn't make sense in Go. Nothing is asynchronous in Go, everything is blocking. You use goroutines to execute multiple tasks at the same time. That's a big part of what makes Go simple: it's a lot easier to understand sequential code than spaghetti callbacks and promises (it's somewhat similar to async/await in the JavaScript world).
- kasey_junk 8y agoYet open up nearly any large golang codebase and you’ll find a channel being used to return a single answer response in the future.
- emersion 8y agoWhat's wrong with that? Go has channels thus it doesn't need futures/promises.
- kasey_junk 8y agoSome problems are more simply modeled as futures/promises than csp. Go’s unsophisticated type system makes it difficult to write a good standard generic data structure library such as a future/promise library. That leads to people either writing a poor replacement, not using that style, or losing type safety. This is precisely what you would predict upon learning golang doesn’t have user defined genetics & ive had it bite me more than once in real projects.
- heavenlyblue 8y agoYeah, and that's why Go code is a spaghetti of communicating via channels, rather than callbacks.
- emersion 8y agoEach code in each goroutine is synchronous. That's what makes it simpler than callbacks.
- weberc2 8y agoCallbacks are prolific in Go; not sure where you're getting this from...
- johnydepp 8y agoGo channels are very handy and magnitude of less spaghetti than futures. And goroutines have good performance. I think people are used to futures etc, that's why the new concept feels strange. I think the goroutines and channels are the biggest features which compensates for generics.