Hacker News Reader

Maybe I'm not understanding it correctly, but on the point about "it's ok to block", does that mean Go will continue to serve other requests normally, but at the point of the blocking code, it automatically has a "callback" to the next command? (effectively saving the programmer the pain of having to write code in callback fashion)

Having no prior experience with Go, I found the rest of the article informative!

View on HN

Yeah, Go has a concept called Goroutines which are like lightweight threads. The system multiplexes Goroutines onto system threads. This means if one Goroutine blocks while waiting on IO, the Go scheduler will automatically select another Goroutine to run while the first Goroutine waits on IO.

Writing your code in blocking style is just easier to follow than the callbacks used in Node and other asynchronous event servers.

My point was that you make a goroutine and within that goroutine you do stuff sequentially and you block if you need to.

Reply on news.ycombinator.com