Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We switched to Node.js: the good and the not so good

blog.superfeedr.com

Post reply on HN
Print view View original

91–100 of 106 posts

Re: We switched to Node.js: the good and the not so good

#91

Post by codygman »

rdtsc wrote: post #78
antihero wrote: post #52

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?

I 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…

The 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

Re: We switched to Node.js: the good and the not so good

#92

Post by codygman »

antihero wrote: post #52

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?

I 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.

Re: We switched to Node.js: the good and the not so good

#93

Post by codygman »

pooriaazimi wrote: post #33
dagw wrote: post #18

Earlier quoted context omitted.

As much as I love CoffeeScript, it's not a substitution for learning JavaScript. CoffeeScript is basically just JavaScript with a prettier syntax and if you don't understand JavaScript you won't understand CoffeeScript.

Very true. I love CoffeeScript very, very much. It's my favorite language - I like it even better than ruby, if you believe me! I like using indentation instead of stupid 'end's that only God knows are ending a loop or a def or something else, I like the use of ... instead of * (for splats), and a few other things. But, as much as I like CS and hate ( really hate) JS, I have to agree with you wholeheartedly. You must…

If you like how CoffeeScript is tab delimited, you might also enjoy python.

Re: We switched to Node.js: the good and the not so good

#94

Post by codygman »

pilgrim689 wrote: post #57
antihero wrote: post #52

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?

Erlang 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 thes…

I 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/)

- Desktop window manager in Go that is very fast even on lower spec machines: 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.

Re: We switched to Node.js: the good and the not so good

#95

Post by gbog »

nkohari wrote: post #60
gbog wrote: post #32

Earlier quoted context omitted.

You have better ways to ask for explanations. Not the OP but I can give some reasons for Javascript and Node.js to not be the best option for a rewrite if the goal is longterm maintainability: - js / node.js is very young, it might fade out of fashion, and in 10 years it is not impossible that good coders in js will be hard to find. - Readability and simplicity are prominent in this context, and js has a syntax that…

Technology and business requirements move too fast to worry about writing software that will be around 10 years from now. Choosing the best technology for your particular use case, that will also allow your software to evolve over time, is much more important than trying to predict the future. Also, I've gotta say, you completely undermined all 3 points of your argument by saying you'd choose Go.

> Technology and business requirements move too fast to worry about writing software that will be around 10 years from now

This is a common belief but I do not think it applies very well in most cases. If you write the last pic sharing thing, maybe you can dismiss worries, but if you build the next Google, entreprise or scientific software, or even something like Github, you should hope your baby to be well and alive in 10 years, and choose your tech stack accordingly. I guess.

Re: We switched to Node.js: the good and the not so good

#96

Post by partomniscient »

pkorzeniewski wrote: post #30
PommeDeTerre wrote: post #22

Earlier quoted context omitted.

Coming from Objective-C first, which is generally a rather sensible language, I think you'll be surprised at how stupid, unnecessary and inexcusable many of JavaScript's problems are. People who only have a PHP background, for instance, have become accustomed to such stupidity. They think it's "normal", solely because they don't really know any better. Those coming from C, C++, Java, C#, Ruby, Python or most other la…

It's not that JavaScript is a bad language, it's just easy to write bad code in JavaScript. I don't get it why most people coming from languages you mentioned like to bash JS so much, I used most of these languages in the past or use them currently (mainly Java and Python) and I like JavaScript the most. The problem is most people just don't want to learn JS, they write shitty code because it's easier and than compla…

>It's not that JavaScript is a bad language, it's just easy to write bad code in JavaScript.

In my mind, that alone makes JavaScript a bad language.

Re: We switched to Node.js: the good and the not so good

#97

Post by DoubleCluster »

Peaker wrote: post #76
DoubleCluster wrote: post #2

> It terms of performance, we also have seen a significant (about 25%) bump in terms of feeds processed by second per server. They rewrote the entire codebase and obtained for just a 25% gain? It doesn't sound like they are very happy to be coding in javascript now either. Everyone: please don't rewrite your code, it's almost never worth it. The one exception is rewriting a core part of an algorithm in C for speed (t…

My experience is the exact opposite. Trying to make do with horrible code for long periods of time, suffering through bugs in every change... Until we finally rewrite it. I've never regretted a rewrite, and it has always ended up significantly better than the original (possibly because the horror threshold for rewriting is high, so that's not saying much).

In my experience it's quite doable (with a good IDE) to refactor the working but messy code into something maintainable. It might take the same amount of time as a rewrite but you'll still have all the features and corner cases covered. Usually refactoring will be much faster though.

Re: We switched to Node.js: the good and the not so good

#98

Post by Peaker »

DoubleCluster wrote: post #97
Peaker wrote: post #76

Earlier quoted context omitted.

My experience is the exact opposite. Trying to make do with horrible code for long periods of time, suffering through bugs in every change... Until we finally rewrite it. I've never regretted a rewrite, and it has always ended up significantly better than the original (possibly because the horror threshold for rewriting is high, so that's not saying much).

In my experience it's quite doable (with a good IDE) to refactor the working but messy code into something maintainable. It might take the same amount of time as a rewrite but you'll still have all the features and corner cases covered. Usually refactoring will be much faster though.

I disagree. Incremental changes are not always capable of reaching point B from point A.

A large, extremely messy code-base can make even trivial changes unsafe, let alone large changes.

The effort required not only to figure out what point B is, but also how to safely reach it from point A is immense. Much much harder than a rewrite.

However, it is a very good idea to meticulously read the bad old code and write down a list of things it handles -- to make sure none of it is missed in the rewrite.

Re: We switched to Node.js: the good and the not so good

#99

Post by rdtsc »

codygman wrote: post #91
rdtsc wrote: post #78

Earlier quoted context omitted.

I 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…

The 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 t…

> 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

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.

Re: We switched to Node.js: the good and the not so good

#100

Post by nkohari »

gbog wrote: post #95
nkohari wrote: post #60

Earlier quoted context omitted.

Technology and business requirements move too fast to worry about writing software that will be around 10 years from now. Choosing the best technology for your particular use case, that will also allow your software to evolve over time, is much more important than trying to predict the future. Also, I've gotta say, you completely undermined all 3 points of your argument by saying you'd choose Go.

> Technology and business requirements move too fast to worry about writing software that will be around 10 years from now This is a common belief but I do not think it applies very well in most cases. If you write the last pic sharing thing, maybe you can dismiss worries, but if you build the next Google, entreprise or scientific software, or even something like Github, you should hope your baby to be well and alive…

Google in 2002 was nothing like Google in 2012. The only thing the same is the name. The entire software industry has changed at least twice in the last decade or so. If more than 10% of the original code that powered Google is still in production, I would be absolutely shocked.

Remember how Twitter was originally written in Rails, and then it collapsed under its own weight when they tried to scale it? Their business requirements changed, so they rewrote the parts that needed to be rewritten. On the flip side, if they had originally set out to try to build the system that now powers Twitter, not only would they likely have built the wrong thing entirely, they never would have launched.

Software services are evolutionary. You have to always be willing to burn pieces of it down and rewrite them as conditions change around you.

Post reply on HN