The love and hate of Node.js(mailinator.blogspot.com)
mailinator.blogspot.com
The love and hate of Node.js
http://mailinator.blogspot.com/2012/05/love-and-hate-of-nodejs.html
91 comments
For a lot of people - Node allows them to do a lot of things that was previously non-trivial in Ruby or Python land. ...for certain classes of problems, neither event machine nor twisted come close to Node and its ecosystem today.
This is the kind of stuff that causes the backlash. The JVM doesn't exist? Erlang doesn't exist? Why did the Node people insist on building a new ecosystem from scratch? Wouldn't it have been easier to build on something that was already mostly working (and already supported multicore)?
This is the kind of stuff that causes the backlash. The JVM doesn't exist? Erlang doesn't exist? Why did the Node people insist on building a new ecosystem from scratch? Wouldn't it have been easier to build on something that was already mostly working (and already supported multicore)?
Erlang may as well not exist for the vast majority of developers. I like Erlang, but a lot of people don't get it, and even more are completely unaware that it exists. Meanwhile, JavaScript is already one of the biggest languages on the Web. This is actually one of Node.js's intended strengths.
The JVM is really mature, but its primary language is one many people hate, so people would complain about choice of platform even if they had gone that way. You may as well ask why Ruby on Rails wasn't Java on Rails. The answer is that 37signals didn't like Java.
And V8 and JavaScript already existed when Node was created, so they were building in an existing ecosystem. Again, JavaScript was already one of the dominant languages on the Web. That's a big argument in its favor.
To my understanding, JavaScript had one more advantage that put it over the top: what didn't exist in its ecosystem — namely, a culture of synchronous development. This meant Node wasn't fighting against the idiomatic way to do things. JavaScript was already highly async, and since this was the whole idea behind Node, it made JavaScript a less-bad fit than most other languages. Other languages were considered, but the fact that libraries for those languages were largely synchronous was viewed as a downside.
The JVM is really mature, but its primary language is one many people hate, so people would complain about choice of platform even if they had gone that way. You may as well ask why Ruby on Rails wasn't Java on Rails. The answer is that 37signals didn't like Java.
And V8 and JavaScript already existed when Node was created, so they were building in an existing ecosystem. Again, JavaScript was already one of the dominant languages on the Web. That's a big argument in its favor.
To my understanding, JavaScript had one more advantage that put it over the top: what didn't exist in its ecosystem — namely, a culture of synchronous development. This meant Node wasn't fighting against the idiomatic way to do things. JavaScript was already highly async, and since this was the whole idea behind Node, it made JavaScript a less-bad fit than most other languages. Other languages were considered, but the fact that libraries for those languages were largely synchronous was viewed as a downside.
Since when did people do not like Java? And still it is the most widely used computer language? And how many people like Ruby, Python by the way? Hype is indeed stranger than reality.
You should choose languages and platforms that fit the task at hand. Every language is as good as the programmer who wields it as long as it suits the purpose. Hating a language is hardly the way to get things done. After learning and working on dozens of languages I am very language agnostic - a new language takes at most a week to get to moderate proficiency now. Make systems that work rather than bitching about your new pantyhose.
You should choose languages and platforms that fit the task at hand. Every language is as good as the programmer who wields it as long as it suits the purpose. Hating a language is hardly the way to get things done. After learning and working on dozens of languages I am very language agnostic - a new language takes at most a week to get to moderate proficiency now. Make systems that work rather than bitching about your new pantyhose.
I'll toss my two cents in.
Java is one of the few languages in existence that I actively avoid (Symbian's particular flavor of C++ is the other).
I've heard it best described as being a very "bureaucratic" language and I think that sums it up perfectly. Checked exception and the rigid language rules just make Java really painful to develop with.
For a long time folks went with Java by default. Usually tossing around something about how impressive the standard libraries are. That's an advantage that doesn't really hold today. Python and Ruby (in particular) have developed amazingly strong third party and standard libraries that allow you to accomplish almost anything, and do it with way less pain than Java insists on inflicting.
Amazing things have been accomplished with Java. Hell there are immensely talented programmers who prefer Java. I'm just not sure that's really that common anymore.
Java is one of the few languages in existence that I actively avoid (Symbian's particular flavor of C++ is the other).
I've heard it best described as being a very "bureaucratic" language and I think that sums it up perfectly. Checked exception and the rigid language rules just make Java really painful to develop with.
For a long time folks went with Java by default. Usually tossing around something about how impressive the standard libraries are. That's an advantage that doesn't really hold today. Python and Ruby (in particular) have developed amazingly strong third party and standard libraries that allow you to accomplish almost anything, and do it with way less pain than Java insists on inflicting.
Amazing things have been accomplished with Java. Hell there are immensely talented programmers who prefer Java. I'm just not sure that's really that common anymore.
Java is the most widely used computer language because it's the lingua franca of the enterprise. That doesn't reflect the programming community's love — it reflects the approval of big business executives. Some programmers genuinely love Java, but I'm pretty sure it's a much smaller number. In the startup scene, where technical founders pick the stack, Ruby is actually more widely used. Take a look at the HN Jobs category (linked at the top of the page) and count the number of Ruby web dev listings, then count the Java web dev listings.
(Cheat sheet in case you didn't feel like counting: There are zero listings for server-side Java. The only Java listings are for Android.)
You can argue that it shouldn't be this way, but that is how it is. A lot of people hate Java. Rails' whole initial marketing campaign was essentially "Java sucks — we do everything opposite of them."
(Cheat sheet in case you didn't feel like counting: There are zero listings for server-side Java. The only Java listings are for Android.)
You can argue that it shouldn't be this way, but that is how it is. A lot of people hate Java. Rails' whole initial marketing campaign was essentially "Java sucks — we do everything opposite of them."
And you think HN is the horizon of entire programming world? Hope that is a self fulfilling prophecy. If you believe HN, Ruby is taking over the world - but in reality, Ruby use is going down (http://www.tiobe.com/index.php/content/paperinfo/tpci/index....). If you really want to know which language is gaining popularity fast - it is a pretty old language called Objective-C! Recheck the reality distortion field.
And about love - I have a family to love - programming languages are tools - hardly objects to love or hate.
And about love - I have a family to love - programming languages are tools - hardly objects to love or hate.
You seem to be disagreeing very strongly with a bunch of things I didn't say. Let me clear up a few misconceptions:
1. I don't believe Ruby is taking over the world. Six years ago it was, but now it's fairly mature and stable. I do believe that Ruby is better-loved overall than Java. (Incidentally, you'll notice Java is dropping two orders of magnitude faster than Ruby on TIOBE's chart.)
2. I have been programming Objective-C since 2001 when OS X came out. I'm pretty familiar with it.
3. HN is not "the horizon of the entire programming world," but it is pretty well-embedded in the Silicon Valley startup scene, which is what I was discussing at the time. My point is this: Take a look at any area where passionate coders get to choose any technology stack they want and you will find Ruby is generally more popular than Java. If HN's job listing isn't convincing to you, let's take a look at another place where coders choose their own language — open source. On Github's ranking of most popular languages, Ruby is #2 and Java is #5.
4. I am not trying to convince you that you should love or hate any languages. I am saying that many people do, and their feelings towards these languages affect how they behave.
As a side note, I agree that programming languages are tools, but honestly, most artists and craftsmen I know do have favorite tools — a favorite violin, a favorite kind of film, etc. Heck, many people have a favorite chair. It's OK if you don't, but it's not that weird.
1. I don't believe Ruby is taking over the world. Six years ago it was, but now it's fairly mature and stable. I do believe that Ruby is better-loved overall than Java. (Incidentally, you'll notice Java is dropping two orders of magnitude faster than Ruby on TIOBE's chart.)
2. I have been programming Objective-C since 2001 when OS X came out. I'm pretty familiar with it.
3. HN is not "the horizon of the entire programming world," but it is pretty well-embedded in the Silicon Valley startup scene, which is what I was discussing at the time. My point is this: Take a look at any area where passionate coders get to choose any technology stack they want and you will find Ruby is generally more popular than Java. If HN's job listing isn't convincing to you, let's take a look at another place where coders choose their own language — open source. On Github's ranking of most popular languages, Ruby is #2 and Java is #5.
4. I am not trying to convince you that you should love or hate any languages. I am saying that many people do, and their feelings towards these languages affect how they behave.
As a side note, I agree that programming languages are tools, but honestly, most artists and craftsmen I know do have favorite tools — a favorite violin, a favorite kind of film, etc. Heck, many people have a favorite chair. It's OK if you don't, but it's not that weird.
I would believe it on the basis that every programmer I've talked to, from a couple of years after Java was introduced, until today, didn't really like Java. Things became very complex very fast for the language that gave birth to FactoryFactoryPattern.
[deleted]
I own tools that I love and tools that I hate.
I agree with your post, but wanted to pick up on one point:
Erlang may as well not exist for the vast majority of developers. I like Erlang, but a lot of people don't get it, and even more are completely unaware that it exists.
This was also true of Ruby pre 2005. I'm not an Erlang developer but it clearly has some natural advantages in the increasingly important world of parallelism and maybe it just needs its own "Rails" as a catalyst for its take off? (And by "its own Rails" I don't mean a Web framework but just a MacGuffin that lures people in to trying it.)
Erlang may as well not exist for the vast majority of developers. I like Erlang, but a lot of people don't get it, and even more are completely unaware that it exists.
This was also true of Ruby pre 2005. I'm not an Erlang developer but it clearly has some natural advantages in the increasingly important world of parallelism and maybe it just needs its own "Rails" as a catalyst for its take off? (And by "its own Rails" I don't mean a Web framework but just a MacGuffin that lures people in to trying it.)
Half of it was true for Ruby — many people were unaware. What they don't have in common is people's immediate reaction upon discovering the language.
Common first exposure to Ruby: "Oh, wow, that's cool. It looks pretty easy."
Common first exposure to Erlang: "Oh, wow, I didn't know you could code in Klingon."
I do agree, though, that Erlang could probably gain a lot more popularity if somebody introduced a framework that really showed what it could do. The most popular web framework right now (at least I think it's the most popular — there aren't any official polls or anything) is MochiWeb, which kindasorta doesn't have any documentation.
Common first exposure to Ruby: "Oh, wow, that's cool. It looks pretty easy."
Common first exposure to Erlang: "Oh, wow, I didn't know you could code in Klingon."
I do agree, though, that Erlang could probably gain a lot more popularity if somebody introduced a framework that really showed what it could do. The most popular web framework right now (at least I think it's the most popular — there aren't any official polls or anything) is MochiWeb, which kindasorta doesn't have any documentation.
MochiWeb is a web server, not a web framework. People use nitrogen(1) and webmachine(2) over it. Nitrogen is a pretty fully featured framework, and webmachine is a really light layer that bakes in http/REST semantics.
I pretty much exclusively use webmachine with ErlyDTL (an implementation of the Django templating system) on top.
There's also erlangweb, and a few others. Both nitrogen and webmachine are pretty well documented. I think it's still all of the periods and arrows that are scaring people off.
(1) http://nitrogenproject.com/ (2) http://wiki.basho.com/Webmachine.html
I pretty much exclusively use webmachine with ErlyDTL (an implementation of the Django templating system) on top.
There's also erlangweb, and a few others. Both nitrogen and webmachine are pretty well documented. I think it's still all of the periods and arrows that are scaring people off.
(1) http://nitrogenproject.com/ (2) http://wiki.basho.com/Webmachine.html
Given the visceral reactions to the syntax, perhaps Erlang could be boosted via a CoffeeScript-esque language that compiles down to it? No idea how practical that is with Erlang's idioms but CS helped some previously JS-shy folks get on board.
There already is one: Elixir (http://elixir-lang.org). It's created by Jose Valim, who (as you probably know) is also a member of the Rails core team. It's a very interesting language.
Ah, cool! I knew he'd gone off to build something new but hadn't realize it was Erlang based. Thanks.
A web framework built on top of Elixir would do it.
Why did the Node people insist on building a new ecosystem from scratch?
People don't sit and plan about creating ecosystems. Things happen. It's not like the Erlang or the Java community are not building anything (Akka is very impressive). I would rather appreciate the work that has gone behind Node. Hype or no hype, the sheer number of knowledgeable people associated with it lends credence to the fact that it's well suited for atleast some classes of problems.
People don't sit and plan about creating ecosystems. Things happen. It's not like the Erlang or the Java community are not building anything (Akka is very impressive). I would rather appreciate the work that has gone behind Node. Hype or no hype, the sheer number of knowledgeable people associated with it lends credence to the fact that it's well suited for atleast some classes of problems.
Well, to be fair they didn't invent a new language.
I am very happy with our Java-based infrastructure now, but it took two years to get there. The ecosystem is all over the place, is sometimes unwieldy (e.g. Maven) and huge chunks of it have withered and fallen off (e.g. EJB). This is healthy, but does not help developers choose what path won't lead to a dead-end. In our case it was a combination of something old (JDBC, Spring) and something new (Netty, Redis).
For Node it seems the big selling point is in having relatively few options to choose from after "Hello, World". This I think makes it seem nimble. Eventually it'll cruft up just like Java: There will be way too many ways to do everything, people will start arguing about it, and something perceived as "simpler" will take its place.
I am very happy with our Java-based infrastructure now, but it took two years to get there. The ecosystem is all over the place, is sometimes unwieldy (e.g. Maven) and huge chunks of it have withered and fallen off (e.g. EJB). This is healthy, but does not help developers choose what path won't lead to a dead-end. In our case it was a combination of something old (JDBC, Spring) and something new (Netty, Redis).
For Node it seems the big selling point is in having relatively few options to choose from after "Hello, World". This I think makes it seem nimble. Eventually it'll cruft up just like Java: There will be way too many ways to do everything, people will start arguing about it, and something perceived as "simpler" will take its place.
As someone who has extensive Java and JavaScript experience, the whole reason for the Java hate as a language is it's lack of closures. For any callback you have define a new interface explicitly then do a gnarly anonymous inner class. In JavaScript you can just plop in an anonymous function. As for the ecosystem, Node also wins with NPM for ease of installing third party libraries, but Java wins for more comprehensive libraries that are already battle tested. A lot of Node libraries do reinvent the wheel.
I don't even know what the standard way of installing a new library is in Java. There's Ivy, Maven, and Gradle. Out of all of them Gradle seems to be the best, but least used.
I don't even know what the standard way of installing a new library is in Java. There's Ivy, Maven, and Gradle. Out of all of them Gradle seems to be the best, but least used.
This might answer your question: http://www.youtube.com/watch?v=SAc0vQCC6UQ
TLDR: He didn't want to use an ecosystem that had existing blocking code. He wanted node to be pure in te sence that nothing was blocking. Starting on a clean slate enabled him to get everything pure non-blocking from the ground up. He admits that Js isn't the best language. But his rationale for not using an existing ecosystem (when it comes to IO) is not bad.
TLDR: He didn't want to use an ecosystem that had existing blocking code. He wanted node to be pure in te sence that nothing was blocking. Starting on a clean slate enabled him to get everything pure non-blocking from the ground up. He admits that Js isn't the best language. But his rationale for not using an existing ecosystem (when it comes to IO) is not bad.
A nice client-server library in an existing ecosystem would've helped the world more. Oh well.
I'm curious, why would you write that game in Node now, if you already know Erlang?
From my perspective, Erlang is a better fit than Node for all the problem domains that Node is good at. I understand using Node if you don't know Erlang, but do know JS, but if you're already skilled with Erlang...
From my perspective, Erlang is a better fit than Node for all the problem domains that Node is good at. I understand using Node if you don't know Erlang, but do know JS, but if you're already skilled with Erlang...
Erlang string/unicode handling amazes me! AFAIK no native support for strings.
I have zero experience with Erlang so want to ask: does this cause problems in practice? Especially, does all library code needing strings use the same Unicode representation?
http://www.erlang.org/doc/man/unicode.html
I have zero experience with Erlang so want to ask: does this cause problems in practice? Especially, does all library code needing strings use the same Unicode representation?
http://www.erlang.org/doc/man/unicode.html
Using Haskell for prototyping has its uses!...prototyping for the formal verification of an operating system, for example... :P [1]
[1] http://www.ssrg.nicta.com.au/publications/papers/Klein_EHACD...
[1] http://www.ssrg.nicta.com.au/publications/papers/Klein_EHACD...
> Someone said the other day that he/she uses Haskell for prototyping.
So...?
So...?
For a lot of people - Node allows them to do a lot of things that was previously non-trivial in Ruby or Python land. From comet based applications to using socket.io for real-time notifications. It's not that these things can't be done in other platforms.
One of the problems I have with the hype around Node is that people seem to gloss over the fact that asynchronous IO is only really dramatically more useful for the particular case of wanting to have a lot of connections that are open and idle most of the time. Many people, instead of saying “Node is great for comet because of asynchronous IO” say “Node scales really well because of asynchronous IO”, when in fact those 2 statements are very different.
One of the problems I have with the hype around Node is that people seem to gloss over the fact that asynchronous IO is only really dramatically more useful for the particular case of wanting to have a lot of connections that are open and idle most of the time. Many people, instead of saying “Node is great for comet because of asynchronous IO” say “Node scales really well because of asynchronous IO”, when in fact those 2 statements are very different.
Why is it that folks who point out that Facebook, Twitter, and Square all had to move to a "fast" language never seem to be able to point to any company (in the current generation) that achieved massive success by starting in a fast language? Having to transition to another language once you achieve success is a pretty solvable problem in comparison to actually creating a product successful enough that platform matters.
For that matter, neither Square nor Twitter have exactly "migrated" (I don't know about Facebook). They optimized hotspots -- a long and storied tradition. Even C programmers drop down into assembly.
Use different pieces for what they're best at.
For that matter, neither Square nor Twitter have exactly "migrated" (I don't know about Facebook). They optimized hotspots -- a long and storied tradition. Even C programmers drop down into assembly.
Use different pieces for what they're best at.
OKCupid. Started and continue to do most things in C++, though I believe they now also have some Node.js stuff in there too.
stackoverflow and the whole network was written in C# from the very start, and still is.
Facebook still writes features in php, they just compile to C++ to eke out performance (i dont work there). I'm not sure where he got the "fixed" quotation from, the word 'fix' is not mentioned at all in the fb post to which he linked.
> never seem to be able to point to any company (in the current generation) that achieved massive success by starting in a fast language?
Didn't Google start in C++?
Didn't Google start in C++?
Actually the first version was written in Java.
EDIT: Also, the original crawler was written in python. http://infolab.stanford.edu/~backrub/google.html
[deleted]
Google is not the current generation. In 1998, hardware was not fast enough to make dynamic languages feasible.
Weren't a lot of Web sites written in Perl in 1998? And there was the AOLServer/Tcl crowd, but we won't speak of that.
I'm not sure why that's controversial. Sure, Perl was quite popular in the CGI days, but at scale? I guess Yahoo has been using PHP for a long time. Certainly things like Ruby, and maybe Python, were not really feasible until we had faster hardware.
Optimizing what needs to be optimized by using different tools is exactly what the big companies should do.
> Even C programmers drop down into assembly.
C programmers usually only drop down to assembly to do something that can't be done in C
C programmers usually only drop down to assembly to do something that can't be done in C
This article is spot on. We'd all like to have magical properties like speed and scale instantly conferred on our code merely by using the right tool. The fact of the matter is that both of those properties require consistent correct decisions at the application level to be achieved.
Scale, for that matter has been totally conflated with speed by many in the Node.js. A single-core reactor is not inherently scale-out. You can, of course, build a scale out app on node.js, but there's nothing about using node (or any other tool) that magically makes your app scaleable.
Scale, for that matter has been totally conflated with speed by many in the Node.js. A single-core reactor is not inherently scale-out. You can, of course, build a scale out app on node.js, but there's nothing about using node (or any other tool) that magically makes your app scaleable.
Remember when App Engine came out?
> Google: "Run your app on our servers, and you'll scale really well, just like Google."
> Developers: "Sweet! Where do I sign up?"
> Developers: "Wait - my app is actually really slow."
> Google: "Duh! You have to write it exactly like we do to make it scale."
> Google: "Run your app on our servers, and you'll scale really well, just like Google."
> Developers: "Sweet! Where do I sign up?"
> Developers: "Wait - my app is actually really slow."
> Google: "Duh! You have to write it exactly like we do to make it scale."
I think question that could be asked is, how long can any one tool, used correctly, defer the need to scale?
For some services, Node.js may give you more time and capacity. For others, Ruby or Python might.
You might need a static website, and you can develop it and push out the 'compiled' HTML to your server. For all the scaley goodness Node.js or whatever may seem to offer, for that purpose it'd never compete with NginX running a static server with appropriate caching.
Up until that point becomes visible on the horizon, you're just wasting time (and money) on a problem you don't or, if you're unlucky, might never have.
For some services, Node.js may give you more time and capacity. For others, Ruby or Python might.
You might need a static website, and you can develop it and push out the 'compiled' HTML to your server. For all the scaley goodness Node.js or whatever may seem to offer, for that purpose it'd never compete with NginX running a static server with appropriate caching.
Up until that point becomes visible on the horizon, you're just wasting time (and money) on a problem you don't or, if you're unlucky, might never have.
how long can any one tool, used correctly, defer the need to scale?
Probably longer if the tool automatically supports multiple cores.
Probably longer if the tool automatically supports multiple cores.
[deleted]
The reason I don't want to write much in node.js is simply I don't like callbacks. It's an inversion of control, and not a necessary one. One can easily invert control back to direct style by using futures/promises. There are even node.js extensions that do various conversions back to direct style, but since the language doesn't endorse any particular one you can't use them across a whole app (unless you write everything yourself).
The stack of callbacks piling up is definitely not a great feature of node.js code. You can mitigate it by using declared functions instead of anonymous functions but that also becomes burdensome when all your callback function does is call something else that also requires a callback.
This will be an interesting problem for node developers to solve. I like the Go approach of using channels. Twisted uses deferreds and inline yields depending on your preference. There are some libraries out there that people have written for node.js that also help.
This will be an interesting problem for node developers to solve. I like the Go approach of using channels. Twisted uses deferreds and inline yields depending on your preference. There are some libraries out there that people have written for node.js that also help.
tame.js solves this to an extent by allowing await and defer calls in your JS code. Not native, of course.
I run a production node.js app and my experience hasn't been bad. My cofounder and I spent more time in the beginning (not much more time, mind you) learning how to deal with multiple outstanding async calls, a good application structure for express, etc. Now it's just as fast for us to go in and add a new API call that does this one query in node as it would be in another system.
The only technical problem I've seen that node is an easier solution is dealing with third party apis concurrently. It wouldn't be very straightforward to have a redis query, a mongo query, a facebook query, and a sendgrid query all open at the same time and managing the results when they all come in (and keeping program flow maintainable) in PHP, Python, Ruby, etc. Probably not a common problem or desired feature, though.
We're 100% Node on heroku with a custom buildpack, using a hosted Mongo service, some Node written cron jobs (which were pretty interesting to write), and redis and we serve 5 digits worth of hits every day at least, and I'm more than happy with performance. I never once look back and regret the decision to use node. I don't necessarily care about sharing code, having frontend developers do everything, etc like some node guys throw around naively, but I am looking forward to bringing somebody on that can grasp adding in a new API route, throw in a Mongoose find, and render a template with some variables. We have EJS templates serverside and clientside for that reason, and that could just as easily be done in PHP or Python.
However, I am enjoying working with node, the node community, and the interesting modules and stuff that are being released. I will say that there's a good bit more active "lets hack this up into a module and open source it over the weekend" kind of people in node than others at the moment.
The only technical problem I've seen that node is an easier solution is dealing with third party apis concurrently. It wouldn't be very straightforward to have a redis query, a mongo query, a facebook query, and a sendgrid query all open at the same time and managing the results when they all come in (and keeping program flow maintainable) in PHP, Python, Ruby, etc. Probably not a common problem or desired feature, though.
We're 100% Node on heroku with a custom buildpack, using a hosted Mongo service, some Node written cron jobs (which were pretty interesting to write), and redis and we serve 5 digits worth of hits every day at least, and I'm more than happy with performance. I never once look back and regret the decision to use node. I don't necessarily care about sharing code, having frontend developers do everything, etc like some node guys throw around naively, but I am looking forward to bringing somebody on that can grasp adding in a new API route, throw in a Mongoose find, and render a template with some variables. We have EJS templates serverside and clientside for that reason, and that could just as easily be done in PHP or Python.
However, I am enjoying working with node, the node community, and the interesting modules and stuff that are being released. I will say that there's a good bit more active "lets hack this up into a module and open source it over the weekend" kind of people in node than others at the moment.
> The only technical problem where I've seen node be a unique solution is dealing with third party apis concurrently.
Use a library like Async, it makes this really easy.
https://github.com/caolan/async
(assume redis, mongo, facebook, and callback are all functions)
async.parallel([ redis, mongo, facebook], callback);
callback is called when all of the others are complete. If you have dependencies, like facebook needs the output of redis and mongo then use async.auto which will automatically run things in parallel and in the order you need them.
Use a library like Async, it makes this really easy.
https://github.com/caolan/async
(assume redis, mongo, facebook, and callback are all functions)
async.parallel([ redis, mongo, facebook], callback);
callback is called when all of the others are complete. If you have dependencies, like facebook needs the output of redis and mongo then use async.auto which will automatically run things in parallel and in the order you need them.
Yes, what I was saying is that Node makes that really simple, and PHP, Python, Ruby, etc don't.
That's more of a side effect of having everything be asynchronous though.
This is really simple in Python using greenlet, stackless, or gevent.
Or threads. Simple, non-shared state threads are not that difficult to write, and for IO bound operations, they are not terribly inefficient.
I think part of the "problem" is that Node represents two different "radical" ideas together: first, using JavaScript on the server, and second, using evented/runloop programming. As such, the discussions become kind of confused. For example, not being someone too excited about Node myself, I still found this particular article kind of strange: I see no issue at all with using JavaScript on the server and in fact think that's the best part about Node. I am on the end of the spectrum where I don't even understand the point of discussing what language "deserves" to be on the server.
However, due to the hyper success of Node, we were left in this strange place where Node became the defacto JavaScript platform, and you can't really use JavaScript on the server/desktop without it (you can I guess, but don't expect anyone else to be able to use your code easily). As such, I think part of the reason you have people who want to use Node "for everything", is that a lot of them just actually want to use JavaScript "for everything", which is a less contentious issue in my opinion. In a world where you had "JavaScript on the server", and the optional "Node library" where you could do evented programming, vs. a different Rail/synchronous style library, you'd have something that looks a lot more like the other programming worlds.
I for example want to use JavaScript as my ideal scripting environment on the desktop, which is not that well suited for the asynchronous model of Node (just reading a bunch of files, operating on them, and then spitting out a new file can be kind of tedious with this model -- I'm not really waiting on anything or trying to hold a million open connections simultaneously). JavaScript itself I think competes just fine against Python and Ruby for these tasks, but again we can't really compare them in this abstract way, we have to compare JavaScript in the particular way it exists in Node, which brings along a lot of opinionated asynchronous APIs.
However, due to the hyper success of Node, we were left in this strange place where Node became the defacto JavaScript platform, and you can't really use JavaScript on the server/desktop without it (you can I guess, but don't expect anyone else to be able to use your code easily). As such, I think part of the reason you have people who want to use Node "for everything", is that a lot of them just actually want to use JavaScript "for everything", which is a less contentious issue in my opinion. In a world where you had "JavaScript on the server", and the optional "Node library" where you could do evented programming, vs. a different Rail/synchronous style library, you'd have something that looks a lot more like the other programming worlds.
I for example want to use JavaScript as my ideal scripting environment on the desktop, which is not that well suited for the asynchronous model of Node (just reading a bunch of files, operating on them, and then spitting out a new file can be kind of tedious with this model -- I'm not really waiting on anything or trying to hold a million open connections simultaneously). JavaScript itself I think competes just fine against Python and Ruby for these tasks, but again we can't really compare them in this abstract way, we have to compare JavaScript in the particular way it exists in Node, which brings along a lot of opinionated asynchronous APIs.
V8 isn't really designed to run multi-threaded code, which makes sense, since it's designed to run JavaScript code for the browser, and browser JS is single-threaded (except for Web Workers, which are isolated, and isolation requires a different style of code just like asynchronicity does). Here's one effort to add multithreading to V8: http://code.google.com/p/v8-juice/wiki/ThreadingInJS However, it has limitations because V8 isn't really intended to be used that way.
If you just want to write code in blocking style, you can use asyncblock with node.js: https://github.com/scriby/asyncblock
If you just want to write code in blocking style, you can use asyncblock with node.js: https://github.com/scriby/asyncblock
It seems odd to me that we had Javascript as pretty much the default server-side scripting language back in the Netscape days, then JS on the server pretty much disappeared as IIS and Apache took over, and now with Node Javascript on the server is "new".
We adopted server-side Javascript at Bloomberg to build all of the applications for the terminal starting in 2006 using a custom environment built around Spidermonkey. So Node isn't that new a concept around here :)
Javascript was popular-but-not-dominant as the server-side scripting language for 'classic' ASP (vbscript was also used), which died out a lot around 2002 with the release of .NET.
Node has synchronous file I/O APIs for the use case you mention.
I was going to use Node.js for a site I was building, but then I stepped back and realised going with Node.js (and MongoDB) meant I had absolutely no idea what I was doing.
I stepped back and used Python with Flask and SQLite as I had done before. There was nothing wrong with what I was familiar with. (An added bonus was I could actually reuse code from an older project using a similar architecture)
I stepped back and used Python with Flask and SQLite as I had done before. There was nothing wrong with what I was familiar with. (An added bonus was I could actually reuse code from an older project using a similar architecture)
I initially had the worry that I had no idea what I was doing with Node.js and MongoDB. Honestly I still don't know what I'm doing. I wanted to learn these technologies eventually so I figured why not fumble through the process of learning and failing now so I'll be better with later project?
Keep in mind that my project isn't time or language sensitive. It's a practice project that could go somewhere with more work, but I can take all the time I need. I highly recommend a project like this if you want to learn these or any other new technology, otherwise you can keep with what you're familiar with.
Keep in mind that my project isn't time or language sensitive. It's a practice project that could go somewhere with more work, but I can take all the time I need. I highly recommend a project like this if you want to learn these or any other new technology, otherwise you can keep with what you're familiar with.
I also consider language religion to be a red flag. The folks who wrote SICP said it better than I " Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn"
This makes the "READ SICP" meme rather ironic ;)
I've dabbled in node a bit and have an odd idea that Javascript is much like Python with C syntax and a bit of quirkiness. I've got a ~400 line program that parses a Debian packages file and lays out build dependencies - sadly I hadn't learned of germinate at the time.
And having to change languages to scale the website further because you've Made It can be a good problem to have...
I've dabbled in node a bit and have an odd idea that Javascript is much like Python with C syntax and a bit of quirkiness. I've got a ~400 line program that parses a Debian packages file and lays out build dependencies - sadly I hadn't learned of germinate at the time.
And having to change languages to scale the website further because you've Made It can be a good problem to have...
There is a subset of JavaScript that is Python-like with C-syntax. But at some point you're going to have to abandon that analogy and learn more idiomatic ways of working in JS.
This is a tangential point in the article but he mentions interviewing people and asking questions about arrays vs linked lists. I was wondering whether a lot of you are working on stuff that involves deep understanding of data structures, sorting algorithms, etc? I seem to see it in a lot of interview questions. Is that just a good topic to separate those with formal education from self-taught people, or are a lot of you really spending a lot of time working on those types of problems?
(To add to that, I should say that I did study data structures in college and know the answers to these questions, but I just personally never have to deal with that level of the code in my work.)
(To add to that, I should say that I did study data structures in college and know the answers to these questions, but I just personally never have to deal with that level of the code in my work.)
Knowing (in Python, for example) when to use a list, a tuple, a dict, a set or a deque makes a rather big difference, and is a skill I probably use almost every day at work.
See also this tweet from last night for a real-world application:
https://twitter.com/#!/djco/status/202490834472542210
See also this tweet from last night for a real-world application:
https://twitter.com/#!/djco/status/202490834472542210
Interesting. Thanks for that. Curious what kind of work that is - do you have real-time critical apps that you have to tweak milliseconds or watch RAM consumption carefully?
I sometimes feel like I could be lazy, but I just never seem to need to deal with that type of tuning due to the nature of my work which is business apps. Don't get me wrong, I do deal with performance tuning - but never at the data structure or algorithm level. I would say I spend time architecting to preventing huge data structures to begin with. Also SQL tuning, interface design and things that I have to deal with. The low-level stuff like sorting algorithms are just built into whatever language I'm using and they don't seem to be a bottleneck.
I sometimes feel like I could be lazy, but I just never seem to need to deal with that type of tuning due to the nature of my work which is business apps. Don't get me wrong, I do deal with performance tuning - but never at the data structure or algorithm level. I would say I spend time architecting to preventing huge data structures to begin with. Also SQL tuning, interface design and things that I have to deal with. The low-level stuff like sorting algorithms are just built into whatever language I'm using and they don't seem to be a bottleneck.
I'm co-founder at a hedge fund startup. Much of our code may not be extremely sensitive to small delays, but picking the right datastructures makes a big difference even on small workloads. And we do have some big simulations where performance definitely counts. But mostly, picking the right datastructure isn't that hard most of the time, and is a painless kind of optimization.
> I just never seem to need to deal with that type of tuning due to the nature of my work which is business apps.
and
> Also SQL tuning
Are at odds with each other. Although the terminology is different, you are in fact doing it if your SQL tuning includes things like adding an index and selecting the right kind of index for your workload (every database has different names, but the different kinds usually include hash, btree, and a couple of others).
and
> Also SQL tuning
Are at odds with each other. Although the terminology is different, you are in fact doing it if your SQL tuning includes things like adding an index and selecting the right kind of index for your workload (every database has different names, but the different kinds usually include hash, btree, and a couple of others).
I suppose that is true. Indexing is something I deal with but I guess I don't really think much about the underlying storage mechanics.
At my current job I do spend a lot of time caring about using the right data structures and algorithms to get decent performance. At my previous job, where performance was not as important, there were still places where this knowledge was required. For instance, we had something analogous to Google's instant search, where each keystroke in the search box would cause the results to change instantly. Implementing this incorrectly would have caused it to be very slow for the user.
I don't ask these questions to separate people with formal education from people without. People with formal education get these questions wrong quite often.
I don't ask these questions to separate people with formal education from people without. People with formal education get these questions wrong quite often.
The article misses the biggest advantage: writing browser & server code in the same language is a huge win. Libraries can be shared. It is easy to move functionality back and forth. You can have one implementation of input validation logic instead of two.
I would love to see a concrete, documented example of this code sharing between the server-side and client-side. I'm not interested in "context switching" but I am extremely interested in how to actually share code between the two environments; I believe this is part of the key to creating more accessible content.
Could you point me to something I could look at further?
Could you point me to something I could look at further?
You should check out the Browserify module by @substack. It packages even native nodejs code to work in the browser. Seriously just check it out, I can't do it justice: https://github.com/substack/node-browserify
But is that worth writing everything in an asynchronous pattern?
The author is not arguing whether there can be a server-side framework using a dynamic language like Javascript. Obviously there can, just like there is RoR, Django and others. His point is that the Node community came to such a point where they think Node is a silver bullet that can solve scalability issues just by itself.
My best guess is that Node gets such reaction due to the same reason Javascript does.
Anytime I stumble with a Node or Js or Rails guy the same question pops to mind. Why limit myself to one language or framework?
Anytime I stumble with a Node or Js or Rails guy the same question pops to mind. Why limit myself to one language or framework?
Node.js people: do you actually like Javascript?
Every language sucks to various degrees, but for what it's worth there are over 100 alternative languages that compile to javascript:
https://github.com/jashkenas/coffee-script/wiki/List-of-lang...
That's true, but not what I was asking. I can write a compiler from any language to any other language, so I'm not asking if you like other languages, I'm asking if you like Javascript.
I think a big part of this is just status quo bias. Also many programmers are suspicious of things that are convenient.
That article could easily be half as long
vibed.org
It doesn't strike me as ridiculous to make a server-side Javascript framework. I'm not interested in Node because from code examples I've seen, its programming model seems to make doing even simple things quite complex. I really like Javascript, though.
This makes me think of all the people who insist on using jQuery for exactly everything.
For a lot of people - Node allows them to do a lot of things that was previously non-trivial in Ruby or Python land. From comet based applications to using socket.io for real-time notifications. It's not that these things can't be done in other platforms. There have been plenty of Java COMET solutions. Heck, 3 years back I wrote my own multiplayer strategy game in Erlang/OTP. However today, if I were to write that game - I will do that in Node. Reactor pattern is nothing new - but if you work with Node you will realize that for certain classes of problems, neither event machine nor twisted come close to Node and its ecosystem today.
Yes, C++ servers could be faster and JS can be a terrible language to work with. But a lot of us don't care - we want to get work done and we use Node for stuff that it's good at. There are always going to be people using it for everything - but every community has its set of zealots. Someone said the other day that he/she uses Haskell for prototyping.