Hacker News Reader

Comment by j2labs | Hacker News Reader

That's a small use case compared to the whole language. The statement you disagree with is more true than your anecdote about one library. On top of that, all the network I/O is automatically nonblocking.

View on HN

His point is that it probably doesn't matter for performance whether you're building in Python or Go, since neither language can make the kernel handle socket buffers and network events faster. I/O-bound programs in either language will have poll/select/epoll/whatever at the top of their profile.

The main point is that for CPU bound tasks, other than those that use Numpy, the performance is still a dog with Python.

I threw in the comment about nonblocking I/O niceties as icing on the cake, but since we're on the topic it's worth mentioning that a language with these features built in is superior to one where it is either a tricky library or a monkey patch, referring to Twisted, Tornado, Gevent and Eventlet.

What? No it isn't. Go's concurrency support is fundamentally different than Python's idiomatic approach (event libraries). It's an apples/oranges comparison. If one approach is more performant than the other, I'd bet on the event library, since evented programs are more or less scheduled purely by I/O.

I like Go. I've been writing in it for a couple of weeks now and will continue to. But don't oversell it.

I'm pretty sure i/o bound go routines will use the very same kernel eventing mechanism. I looked into this recently, and you have to explicitly tell it to use more than one thread with http://golang.org/pkg/runtime/#GOMAXPROCS

Exactly.

In both goroutines and events, blocking IO will be parked waiting on a select (or similar device). In both, they implicitly context switch while blocking, meaning that processing ready IO might have to wait for other stuff to reach a scheduling point. Unlike events, goroutines can be processed on more than one underlying OS thread at once.

Advantage: goroutines.

It certainly is. Just look at the insanity of the nonblocking I/O experience in Python. It's confusing, divided, and results in duplicated work all the way down to the database driver level.

I'm not overselling it. I'm someone who's built an entire web framework around gevent and knows that having this functionality in the library is a massive weakness of Python.

In Python, we have monkey patching vs. an entirely new driver vs. just using blocking calls.

In Go, we just have nonblocking I/O because that's how it works.

Well, scipy/numpy is quite relevant in the Python ecosystem; it's not something you can ignore when talking about the language. Like Rails to Ruby, numpy is quite a big feature of Python.

Reply on news.ycombinator.com