[deleted]
Ask HN: Is NodeJS stable enough to build the next Twitter?
41–50 of 60 posts
Re: Ask HN: Is NodeJS stable enough to build the next Twitter?
#42For Twitter scale you will need a cluster of node.js servers with redis (or some other thing) handling the cluster. Yours will then be more of a cluster management issue. This is our experience at our just launched startup (link: http://www.tesla.im).
Re: Ask HN: Is NodeJS stable enough to build the next Twitter?
#43Stable enough? Sure, for a given definition of "enough".
The advantages to using Python instead of NodeJS are going to be less about stability and more about maintainability and ecosystem.
Re: Ask HN: Is NodeJS stable enough to build the next Twitter?
#44I run http://jsonip.com . It's a single node process running on a VPS. It supports more than 10 million requests a day and barely stresses the system. Granted that its a relatively simple app, but it's raw node.js. I can easily scale it in a few simple ways like adding a caching layer and/or load balance a few extra servers. Haven't needed to yet.
I doubt there's a language out there that couldn't do 100qps of this complexity on a single modern core. It doesn't really say anything positive about Node
Why do people always take a figure like this and assume a near linear distribution?
I do agree with the sentiment of your point though but I'd be interested to know what the parent handles at peak
Re: Ask HN: Is NodeJS stable enough to build the next Twitter?
#45Node.js itself is fine. The real problem with node.js is the libraries. Just don't use them. A huge portion of existing libraries is full of hidden bugs, shortcomings, race conditions, edge cases, security issues, unscalable, or unmaintainable (and unmaintained). This is exacerbated by the fact that npm makes it really easy to publish a library. Many small buggy libraries. Core modules are too low level (e.g. http),…
It isn't hard to find out which libraries are maintained and which ones aren't. Maintained libraries are of fairly good quality. This isn't very different from other languages, except that there is significantly more activity around node.
Promises not being in core is a good thing. Eventually many of those use cases will switch to using ES6 generators.
If you want to scale node, you would use multiple processes.
Your DNS example is a corner case. There are discussions around it, and such issues impact all frameworks.
As for security issues, unscalable, unmaintainable etc, those are too generic in nature to comment. I can say this though; node is in production at some of the largest companies in the world and they are talking about it too.
Re: Ask HN: Is NodeJS stable enough to build the next Twitter?
#46Earlier quoted context omitted.
I'm using 0.10 in production and haven't had any bugs... what bugs are you referring to? Also domains are in 0.8
Is yours a large or small app? Do you use streaming/piping/remote services? Regarding bugs, there are too many to list, just see the tracker and spend some time browsing through them https://github.com/joyent/node/issues?direction=desc&pag... I'm fairly sure you can find pretty much anything. I'm considering removing all the npm modules from my project and go raw, since most of the obscure bugs are in the ecosystem a…
It is large, but doesn't use any streaming or piping. As for remote services, just a bunch of remote APIs, and they work fine.
With the changes to streams in 0.10, I can understand it having some issues. That slipped my mind... but I don't do much streaming so I just assumed it worked.
Re: Ask HN: Is NodeJS stable enough to build the next Twitter?
#47Premature optimisation is the root of all evil. If you're building something that will be as big as Twitter, the programming language will be the least of your problems. Figuring out how to scale all of the connected system horizontally, independently, will be more important than whether you chose Node or C# or Java or Python.
It does make a difference and choosing good tools and architecture early can make a hell of a difference because today's code become's tomorrow's legacy code. It's also very rare for a complete rewrite to happen, especially into a new language/framework. Look at Facebook; their codebase is still in PHP even if it's transcompiled to C++.
This also isn't a case of premature optimization at all, this is just about making good choices that will persist with the project for a long time. Premature optimization used to mean unnecessarily writing assembly or borderline obfuscated C in the name of performance, which led to programs being difficult to comprehend, hence it being the root of all evil. Today this has been perverted to mean "hey, buddy, if you think about performance you're optimizing prematurely!"
Re: Ask HN: Is NodeJS stable enough to build the next Twitter?
#48Premature optimisation is the root of all evil. If you're building something that will be as big as Twitter, the programming language will be the least of your problems. Figuring out how to scale all of the connected system horizontally, independently, will be more important than whether you chose Node or C# or Java or Python.
It does make a difference and choosing good tools and architecture early can make a hell of a difference because today's code become's tomorrow's legacy code. It's also very rare for a complete rewrite to happen, especially into a new language/framework. Look at Facebook; their codebase is still in PHP even if it's transcompiled to C++. This also isn't a case of premature optimization at all, this is just about makin…
Let's say your automating squirrel cloning. The quickest anyone can do this at the moment is 24 hours. Your solution takes 12 hours using SquirrelClonr. Somebody in the pub reckons he could produce a Squirrel Clone-o-matic which does it in 1 hour, but it would take 6 months to build.
Do you launch today with SquirrelClonr, or delay launch by 6 months to switch to the Squirrel Clone-o-matic? Since it's possible to increase the speed by 12 times, surely you should switch to the Clone-o-matic, right?
It depends on your customers. If you can be profitable by selling squirrels cloned in 12 hours, why wait when waiting could allow a competitor to monopolise the squirrel-cloning market. Plus, if you find out that nobody wants cloned squirrels, however long they take to produce, you've saved six months.
So premature optimisation (in this sense) means "thinking about performance of what you're trying to build before you've even established whether or not you should be building it". If you have no customers, it doesn't matter how quickly your code runs.
Re: Ask HN: Is NodeJS stable enough to build the next Twitter?
#49Earlier quoted context omitted.
It does make a difference and choosing good tools and architecture early can make a hell of a difference because today's code become's tomorrow's legacy code. It's also very rare for a complete rewrite to happen, especially into a new language/framework. Look at Facebook; their codebase is still in PHP even if it's transcompiled to C++. This also isn't a case of premature optimization at all, this is just about makin…
Let's say your automating squirrel cloning. The quickest anyone can do this at the moment is 24 hours. Your solution takes 12 hours using SquirrelClonr. Somebody in the pub reckons he could produce a Squirrel Clone-o-matic which does it in 1 hour, but it would take 6 months to build. Do you launch today with SquirrelClonr, or delay launch by 6 months to switch to the Squirrel Clone-o-matic? Since it's possible to inc…
Premature optimization doesn't mean anything of the kind.
The difference is it doesn't take much more to write something with Node than it does Python or anything else, and thinking about good architecture (particularly database architecture) is prudent. I said it before, but it's worth repeating: today's code become's tomorrow's legacy code, and certain early architectural decisions can make a hell of a difference later.
Your argument is like saying you're going to build a house but don't know if anyone will want to live in it, so instead of doing it properly you're going to use anything to build it regardless of how suitable, and regardless of how well the construction will stand up against the weather. If someone chooses to live in it, well, crumbling is a great problem to have because you got there first. If you're going to say this analogy is stretched (I'd disagree), think about it in terms of security. Writing decently secure software takes a little bit more mental overhead. Is it worth it to write a secure application from the ground up in spite of not knowing whether users will adopt the service? (The answer is always yes.)
Also, first mover advantage is a myth. There are plenty of examples of the first, or early mover, being toppled by someone who came along later.
Premature optimization means creating code that's difficult to comprehend without justification in the name of performance, not thinking about which language/framework/vm is going to yield a decent performance profile overall.
Re: Ask HN: Is NodeJS stable enough to build the next Twitter?
#50Earlier quoted context omitted.
Let's say your automating squirrel cloning. The quickest anyone can do this at the moment is 24 hours. Your solution takes 12 hours using SquirrelClonr. Somebody in the pub reckons he could produce a Squirrel Clone-o-matic which does it in 1 hour, but it would take 6 months to build. Do you launch today with SquirrelClonr, or delay launch by 6 months to switch to the Squirrel Clone-o-matic? Since it's possible to inc…
Premature optimization doesn't mean anything of the kind. The difference is it doesn't take much more to write something with Node than it does Python or anything else, and thinking about good architecture (particularly database architecture) is prudent. I said it before, but it's worth repeating: today's code become's tomorrow's legacy code, and certain early architectural decisions can make a hell of a difference l…
> Your argument is like saying you're going to build a house but don't know if anyone will want to live in it
The first houses in a complex are usually sold before being built, on the basis of a prototype - be it blueprints, 3D walkthrough, or a show-home. If they can't sell those houses, they don't build the rest. It's the cheapest way of establishing whether there's a market for the properties they intend to sell, and it's much cheaper than finding out there's no market having built 50 of them.
> "today's code become's tomorrow's legacy code"
Worry about it tomorrow. It's a nice problem to have as it means you're still in business. Most businesses started today won't be.
Until you've established that your product is going to have customers, the performance is irrelevant.
My favourite example is the fake 'Buy now' button. You don't need to build the payment process until you know people want to pay, and you definitely don't need to worry about how quickly it runs.
If people want it, they'll pay even if it's slow. If people don't want it, why are you building it? Nobody buys a product just because it's quick (unless performance is the central feature.)