5 ms·
Say I'm a Python developer and I'm looking to write services that are fast. Would I likely be better off going down the route of node.js, Go, Haskell, Erlang? I
by antihero 14y ago
Say I'm a Python developer and I'm looking to write services that are fast. Would I likely be better off going down the route of node.js, Go, Haskell, Erlang? I mean they are all fantastic languages and I've dabbled in most of them but from what I've read, Go seems to be the best one to use if you don't want to shake your world up, but if you do, Haskell or Erlang are nice new paradigms to dive into. Is this true?
- pilgrim689 14y agoErlang has decades of use in fast, robust, large telecommunication systems. Haskell promises more robustness than any other platform as well as performance sometimes comparable to C. Its downside is just that steep learning curve though. So if you want speed, I'd go for those two out of your list. Go and node.js are still infants in the game, so I don't think there is enough serious software out there built with these to properly judge their effective speeds.
- codygman 14y agoI agree that Erlang is probably the best example of proven to be robust due to use in large telecommunication systems. I would also agree that Go and Node.js are still infants in the game, but I'd argue that there is enough software out there to judge Go's effective speeds. - Google is using it internally, where speed is an absolute requirement - Vitess, recently open sourced (and used internally by youtube) would definitely have to be fast for the task youtube is using it for. (http://code.google.com/p/vitess/ http://code.google.com/p/vitess/) - Desktop window manager in Go that is very fast even on lower spec machines: https://github.com/BurntSushi/wingo https://github.com/BurntSushi/wingo Just my two cents. I would absolutely stay away from node.js if you are in an environment where people touching the code aren't easily accessible, since it's very easy to write javascript that only you understand. The other languages seem to punish it a bit more, while at times it feels as if javascript embraces it.
- marekmroz 14y agoHave you tried writing services in Python and running on gunicorn or gevent?
- jondot 14y agoFirst, you need to define 'fast'. Whats your workload and usecase? Why is python slow for you?
- rdtsc 14y agoI recommend Erlang. But you have to be careful what you mean by "fast". There is serially fast. As in fast if you have a single client but that might not be "fast" when you have 10000 clients anymore. Erlang will make sure your system stays responsive under load. Any of those languages will probably do that but I feel that Erlang is the one with most tooling and most practical experience behind its back. Also, don't give up on Python. Python is an excellent language and when you don't need 5 nines or reliability or crazy scalability, a Python gevent or tornado based server might just do the job.
- codygman 14y agoThe problem is the threading solutions for python fill bolted on, and kind of break the whole "pythonic" feel of everything. Of course this is purely subjective, but for me it feels like I'm "going against the grain" and falling out of the domain space of problems the language was meant for. That, and Go seems to be close enough to python with those advantages built in that it becomes an easy choice for me. Combine that with the fact that my problems are mostly solved easily with the inbuilt libraries, and it's a clear solution. I mean, look at the docs for gevent. In the docs one of the first things they teach is monkey patching: http://www.gevent.org/intro.html#monkey-patching http://www.gevent.org/intro.html#monkey-patching
- rdtsc 14y ago> The problem is the threading solutions for python fill bolted on, and kind of break the whole "pythonic" feel of everything. See I find a lot Twisted, and yield based concurrency frameworks not being Pythonic enough. Threads are just functions that run concurrently. In the case of green threads it is really just as simple as spawn(func) to start a new green thread running function func(). Take a look at these eventlet examples, they are pretty elegant: http://eventlet.net/doc/examples.html http://eventlet.net/doc/examples.html Yes there is monkey patching. However, that happens once per program at the very top. That is a small price to pay for the ability to use all the Python libraries out there. Speaking of libraries. That is one good thing about Python. And probably the reason to stick to it -- the large library ecosystem. Of course it depends on the system you are designing but a large enough system will usually need some other libraries (parsing a protocol, using a work queue etc). Go and Erlang also have plenty, but not nearly the level and breadth that Python has.
- Peaker 14y agoOf that list, I'd recommend Haskell and Erlang. Haskell in particular is especially interesting if speed is of concern. Haskell manages to combine the conciseness and elegance of good Python code with static safety not found in other mainstream languages. Speed-wise, it ranges from OK to great, depending on how skilled you are at optimizing Haskell. The tools for optimizing Haskell code are pretty great, though.
- cmccabe 14y agoGo for go. Go is actually fast, not just fast in theory or fast when speed isn't important, or whatever other weasel words you care to choose. Goroutines and channels give you the scalability advantages of async programming, without leaving behind readable code. Deployment is super simple because it produces a compiled binary. Go has a solid foundation, including things like real support for integers, real support for threads, a runtime that was really developed for servers, and a well-thought-out type system. Some people have compared it to static duck typiing.
- codygman 14y agoI would recommend Go since you'll be able to parse Go easier and it was a language designed for fast web services. That, and I've had experience writing web services with Go that have proven to be fast, reliable, easy to extend, and easy to maintain. Not to mention, dead simple and clear to people who don't even know Go.