Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I definitely support this sentiment w/r/t the single threaded mindset of node and their async all the things approach. The only question with Go is if we guarantee sync libs, then where is the good async example code? I agree libraries should be synchronous, but does it really hurt to not have some best practices "how to do it async" in the docs? or should it be... in the code?

Kind of a meta question, but an interesting one.



The "good asynchronous" code in Golang is straight-line code that would be called "synchronous" in Node.

Part of the problem is that even as an attempt at a "non-synchronous" interface, this seems clumsy. It demand-creates new channels for requests. That doesn't seem right.


Whats wrong with "demand-creating" channels? The Go stdlib does it within their network library https://golang.org/src/net/singleflight.go#L67


Because you can't select on an arbitrary collection of channels.

It might make sense for a library to return a new channel for something you do once, or once per goroutine.

It doesn't make sense to use returned channels as a basis for async dispatch.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: