News for hackers. Stuff that matters.
Re:The Way of the Gopher: Making the Switch from Node.js to ... by _ak on Sunday March 27, 2016 @03:54PM (#11371257)
...what? The point is that when any function in Go is blocking, it will obviously block the current flow of your own program until it returns. But it only ever blocks the flow of the current goroutine. Other goroutines will continue running just fine, and the runtime will schedule all the ready-to-run goroutines over the OS threads it has available, and that's nothing you need to take care of in your Go program. It essentially abstracts away what Node.js does in its event loop and the programmer does by manually splitting up the program into a series of function callbacks. Just use that knowledge to structure your program accordingly, and don't tried to badly reinvent futures.
Re:The Way of the Gopher: Making the Switch from Node.js to ... by kasey_junk on Sunday March 27, 2016 @04:22PM (#11371379)
How is that different than any language that supports parallel concurrency?

You can literally say that about every labguafe that has concurrency abstractions.

The whole point of the argument is that golangs abstractions just push the callbacks (or blocking sync) to the application layer.