3 ms·
It seems like the lesson here is that basically any language (Python, Ruby, ...) will perform about the same with non-blocking I/O. Does this mean that Erlang
by socratic 15y ago
It seems like the lesson here is that basically any language (Python, Ruby, ...) will perform about the same with non-blocking I/O.
Does this mean that Erlang and node.js are mostly compelling because of the prevalence of async versions of common libraries? Or are they not that compelling in web contexts in the first place?
- ankrgyl 15y agoThat's exactly the point we wanted to convey. Erlang and node are great, but we know Python really well and were able to write a performant server with the tools we're familiar with.
- MetaCosm 15y agoYou failed. I blame title and tone.
- cageface 15y agoErlang is compelling because it's been built from the ground up to support reliable distributed computing and heavily battle tested in incredibly high-volume applications. Non-blocking I/O is just the plumbing in a far more sophisticated machine.
- helwr 15y agoSophistication is often the ultimate enemy. H. Thoreau once said "In proportion as he simplifies his life, the laws of the universe will appear less complex.." (Walden, Princeton University Press, 1971, p.323-324)
- cageface 15y agoI'm a big believer in KISS. If you don't have the problems Erlang was designed to solve, Erlang is probably not a good choice. Rolling your own amateur version of Erlang on top of evented Python or Javascript is probably also not a good move though.
- SoftwareMaven 15y agoI think you are confusing sophistication and complexity. Part of the sophistication of Erlang is how it simplifies the complexities of concurrent programming and, more importantly, the handling of failures in concurrent programming.
- nirvana 15y agoComplexity, is the enemy. The most sophisticated solutions are often very simple, because they were written from a sophisticated perspective, not a naive perspective. erlang has stood the test of time, and produced great results because, really, it is very simple. It just comes from a sophisticated perspective.
- megaman821 15y agoA lot of the languages will probably perform similar on non-blocking I/O because they are all leveraging epoll (or select or kqueue) underneath it all. There is great variation however, on how the green threads are exposed. Node.js has callbacks, Python has yields, and Erlang has messages. Some of these approaches are easy to reason about and maintain than others. I always found Haskell's take on parallelism interesting, and maybe it is faster. In Haskell you create a unit of work called a 'spark'. You can have billions of these, they get mapped to lightweight Haskell threads (powered by epoll) and those get mapped onto OS threads.
- monopede 15y agoI understand that this is meant just as an experience report, but I have to say this article didn't convince me in any way that this rewrite was a good idea. Obvious questions: 1. How does the performance of the new system compare to the old system? 2. What exactly were those maintenance issues with the Erlang server? Did just no-one in your team find the time to learn Erlang well enough? I know Erlang isn't the prettiest of languages, but async I/O isn't the only advantage of Erlang. A battle-tested concurrent runtime and built-in support for fault-tolerance are two obvious examples.
- MetaCosm 15y agoBut, but, so pretty and elegant! quick_sort([]) -> []; quick_sort([H | T]) -> quick_sort([X || X <- T, X < H]) ++ [H] ++ quick_sort([X || X <- T, X >= H]).