The author makes a point about getting high-quality node developers. That is primarily for two reasons.
1) Early adopters generally tend to do well, whatever the language may be.
2) And more importantly, the asynchrony in nodejs is not easy. Writing maintainable JS is harder than writing Python or Java. So if someone has been through that grind, chances are they could be good developers.
Being able to do everything with a single language is kind of a big deal for many companies; the only thing holding back JS of the messy nature of callbacks (and promises, yuck). I would expect real adoption of JS to begin when ES6 features (generators, classes, etc) become available.
It is probably more of different tensions competing: if node.js will provide 80% of what Erlang can do, but is a lot more obvious, is the same language of the web development, is hyped, and so forth, there is no chance for Erlang to compete.
A stranger / corner language to win must provide a lot more than another more accessible technology.
EDIT: it does not help that other popular backend technologies suck so hard performance-wise, since I can't see how javascript is better than, for example, Ruby, as a language (but the contrary).
I would contend Go does around 50% of what Erlang does. Node.js does around 10% of what Erlang does.
You are right that both Go and Node.js has a lot of mass and a lot of acceleration right now. But Erlang has inertia in the projects where it does well and it will probably not affect typical Erlang systems much if Node.js or Go grows large. To this extent, Erlang is a too different beast.
Most people's slow Java applications are slow due to architecture/ecosystem, Java itself is pretty fast. That being said, I still prefer Go due to its elegant simplicity, easy concurrency, lack of runtime dependencies and better memory usage. Go's selective choice of which OO features to support also helps discourage some of the Java architectural bloat.
> I would contend Go does around 50% of what Erlang does. Node.js does around 10% of what Erlang does.
You're probably more or less correct, but turn things around: from the point of view of the Node.js user, Node does pretty much everything they need, and Erlang does "extra, cool stuff" that, however, they can live without; or think they can.
They can do fast, dynamic web sites with web sockets with relatively low overhead, and that's really what they are after.
This is related to disruptive innovation being discussed elsewhere:
You are I'm sure correct that people who need Erlang won't see Node encroach on their turf, but it's something of a missed opportunity for Erlang just the same.
Exactly that. People sediment to the most accessible technology that allows to, more or less, do the work they are after. If Erlang was the only way to solve a given problem in a decent way, people would switch to it, as, for example, people switched to Git eventually: it was different, more complex to use in some way, but it really was so much better at solving a given problem that everybody moved.
Btw when we talk about Erlang, to me, is not just a matter of the language itself. How accessible, small, easy to run, the runtime of a language appears to be make for a big difference as well.
>You're probably more or less correct, but turn things around: from the point of view of the Node.js user, Node does pretty much everything they need, and Erlang does "extra, cool stuff" that, however, they can live without
They're blub programmers
>As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.
Yeah, well I know plenty of "blub" programmers who somehow manage to quickly deliver high quality work, who have high profile public projects with their name on them, and make six digit salaries where the first digit is not a "1".
And I know plenty of hipster programmers forever chasing the new language du jour who deliver little but useless abandoned libraries on github. Check out this half working haskell ORM I'm already getting sick of, oh and there's no tests
And I work next to a company that foolishly decided to write their API using scala (don't you know rails doesn't scale) and is now reduced to spending 3 months training new devs because they can't hire to save their lives.
So yeah, tell me about "blub" programmers again. I'll tell you, these "blub" programmers make the friggin' world go round. You like PG's essay but riddle me this - how many lisp startups has YC funded?
Basho uses Erlang, despite not really being able to hire erlang devs (just need to hire and train, for the most part, its a small community), because they feel it gives them a competitive advantage, and even attracts more talented developers.
I'm not arguing that you can't or shouldn't get shit done w/ node.js/Go/PHP/Java/C#/whatever works, just that its ignorant to say "Haskell/Lisp/Erlang/OCaml/Whatever has lots of weird shit I don't need".
It's funny that you call these languages the "language de jour" when Haskell, Lisp, and Erlang are all like 20+ years old.
Well, Basho made an eyes-open decision to go with erlang, after making a thorough analysis of their needs, and well aware they were balancing benefits vs costs. I would say they made a good decision. That's not really the kind of mentality I was railing against, though.
What I can't stand is this kind of condescending smugness - "oh, you're still using X? You're a 'blub' programmer!" as if the only conceivable reason for their choice is that they're lazy, stupid, unmotivated, or all three. Well maybe it's because they like that language, they're productive in it, it's mainstream and hireable, and they don't have any unusual requirements!
I get what PG was trying to say in his essay, but I don't think he expressed it very well. Programmers should try to choose the most productive possible tools, of course. But he's made it rather too easy to simply dismiss anyone who hasn't ended up choosing the most hardcore language possible as "blub programmers", rather than acknowledging they possibly made an informed, pragmatic choice. Engineering is about tradeoffs and throwing around these labels does not improve the discussion.
In my opinion PG over-emphasised the role of lisp in that essay. He conflated the ability to use such a language, ie that he and his colleagues are smart guys, with the language itself. They likely would still have succeeded with perl, TCL, even python was around then. And by doing so, he taught the wrong lesson.
Anyway, I think we agree more than not. And "du jour" actually means "of the day" - not necessarily age. Your point is taken, though.
If we are talking from the point of view of "features" of the language, probably yes, but in the get-things-done area things tend to be a lot more malleable, and once you have a single process that performs concurrency with mutable global state you can hack a lot on top of it.
I get the feeling that what Node helps with is concurrency, although being fairly fast helps too.
Ruby on Rails does not really have a good concurrency story for something like web sockets.
Although Rails is still what I would use for bootstrapping something where you're trying to find product/market fit and you are not absolutely sure that you need to squeeze out lots of performance from the get-go. Even if I knew I needed web sockets, I'd probably farm those out to a specific server to handle just those, most likely in Erlang.
That's a good point, but there was nothing in Javascript that was exceptionally better at event driven programming compared to other languages: probably the reverse actually, because of the lack of constructs to carry state.
Regarding the "same language of web development", it seems to be a major selling point for nodejs. What worries me is that frontend development is different from backend development, and it's different from kernel development. If you imagine there is a single language capable of being applied in all these layers, do people really think the _mindsets_ and practices adopted aren't different? Like, oh there are millions of web developers using this language, what a marvelous resource to tap into to, let's ask them to write backend code!
The difference is that most backend developers I know also know javascript. I think at fewer developers only work on the back end and on the front end Javascript has already won, the war's over. So there are more backend devs that know JS than any other language.
"Being able to do everything with a single language is kind of a big deal for many companies;"
Its a shame that so far JavaScript seems to be the only language you can use on the client and server. I come from a Perl background and every time I try to do something in JS it seems like a kludge.
I don't have experience with ClojureScript yet, but CoffeeScript is trivial to debug since the source and the compiled JavaScript are structurally very similar.
On top of that Python has a solid set of libraries for it. In my experience with JavaScript (admittedly a lot more limited than with Python or Perl), the library support is far poorer. Angular is one of the most popular frameworks out there and the documentation is terrible. Compare that to any major framework in Python or Perl and you will see the difference.
IIRC, JS was designed and initially implemented by a single programmer in about 10 days.
It's far better than could reasonably be expected given that, but it still sucks. Some of the things that immediately come to mind WRT not being well thought out are bad number handling, lack of modules, and possibly the number of warnings needed about how "this" behaves.
> I would expect real adoption of JS to begin when ES6 features (generators, classes, etc) become available.
The adoption of server-side JS implementations (node particularly) is already "real" I think - the growth in its popularity seems to be very quick compared to other platforms when you consider how short a time has passed since node was first made available.
I agree that one of the things constraining that growth is the ease with which a nightmare of callbacks gets created, which can be a problem for later maintenance/improvement, and some of the newer language features will help that - but I think many will avoid using those features until they are commonly available client side too (there are many out there still using relatively old browsers, and a lot of projects don't have the luxury of being able to ignore them).
I think a major thing that is making those consider node hold back a little is the very thing that has made it successful: the rapid growth and evolution which is still on-going. I suspect that there are many experimenting with it but waiting until things settles down (which the core no doubt will for a while soon) before committing to using it for major projects.
> but I think many will avoid using those features until they are commonly available client side too
Why would you do that? If you have a few more advanced features on the server side that doesn't run on the client why wouldn't a team take advantage of them just for server-side code. Maybe the fear is server-side code ends up getting run on the client, but I feel like the separation would be pretty obvious that should be easy to avoid. Node.js allows you use the same language on the frontend and backend but it's not like people are justing moving code around between the two without regard for what context it's running in.
Actually, there's a couple of up-and-coming node.js frameworks which do encourage using much of the same code on client and server. Some of the ReactJS stacks do, for example.
The thing is, it turns out that what people want is proper separation of frontend and backend, not separation of client and server. Outside of single-page apps, there's a fair bit of "generate this page for me" stuff required as a baseline, but also a lot of places where if it's possible, rendering (and animating) on the client-side provides a better experience. GitHub's repository browsing is an example, as is Twitter's entire site, as is Google's Instant Search.
So running the same view logic on the server and client is a good thing, as it results in not having to write it once for each environment. The controller glue for tying it to the model changes, but that can easily be switched out per environment without changing the view's code, and is often generic enough that it can be implemented at least in part by a library.
> Early adopters generally tend to do well, whatever the language may be.
One look at the Rails early adopters should tell you that this is false. Almost every major high-throughput architecture that was initially based on Rails had to completely reimplemented.
Rails is appropriate for proving ideas and rapid development of complete apps. It's also suitable for implementing small, loosely-coupled SOA-style apps integrated with a larger system, or for basic low-traffic apps.
It's not appropriate for huge commerce or infrastructure-style services.
A lot of developers jumped on it when it was a new technology because it offered lots of benefits - in particular, the whole convention-over-configuration thing and lots of happy developers. They weren't wrong for that. Now that we're trying to build bigger and bigger things on the web, and moving into SOA with APIs for mobile apps etc., something other than Rails is a good choice.
Those early adopters did well, and modern early adopters will do well too.
I don't think OP meant "do well" as in "code or architect" well, but they "do well for themselves" (make more money, play with newer toys, don't have to clean up others' messes as much, etc).
"Early adopters generally tend to do well, whatever the language may be."
It is because early adopters tend to work either on special kind of problems the new language is especially suited for or because they tend to work on rather small projects. Those small projects would do well in almost any circumstances.
New technologies tend to be buggy, quirky and tend not to stay around. Rarely someone picks them up for things that are supposed to be maintained in the long term.
> I would expect real adoption of JS to begin when ES6 features (generators, classes, etc) become available.
JS adoption is 101% on the client side already, and this force will be merged with server side responsibilities.
You can't blame the JS way of doing things if you wan't to brute force other languages approaches. You need to code JS with JS mind model, otherwise, you will be seriously frustraded.
Why is everyone saying callbacks are naturally messy? When I first started node.js I realised I had a pyramid in my screen (6 callbacks in one another). I then googled "callback hell", and found some nice techniques not requiring promises or any other fancy library to write my code nicely.
The messiness isn't in the code; the messiness is in the execution model itself. However nice you may think your code is now, compared to the "pyramid", it's nothing on how nice it is when you write it in a language that has "asynchronousness" at its core, like Go.
Thank you. I actually already apply all this practices on my code, maybe that why i never understood this callback hell that people keep talking about, maybe haven't done big js projects yet to experience it.
Being able to do everything with a single language is kind of a big deal for many companies
I'm not sure the common language thing has ever been that significant of a factor in node's success, or even in the uptake by developers. I mean it appears in advocacy as a bullet point, but by itself it just isn't that compelling. Especially given that so many developers do so much to distance themselves from JavaScript proper (TypeScript, CoffeeScript, etc). The actual problem space on both the client and the server tends to be dominated by non-JavaScript related issues (e.g. the DOM, state, etc).
Node offered good performance, a decent model for asynchronous implementations (in an era when the PHP / .NET model was entirely synchronous. Every .NET advocate could point out some method of emulating what node does, but it was awkward and not at all idiomatic), and possibly more important than everything else it presented a platform that was a ground zero -- to get into it and start a project using best practices took an afternoon of learning, versus established platforms like .NET and Java where cargo culting and pseudo-best practices made even the most trivial of implementation a monumental task if you wanted to avoid raising the ire of others.
Since then other platforms have largely caught up. Even moreso, the way we develop apps have changed -- the server side isn't a presentation layer, but instead is often merely a service layer. For that purpose some other technologies are often a better fit. Personally I've mostly transitioned to using Go on the service side, as the glorious glue that hooks information together.
1) Early adopters generally tend to do well, whatever the language may be.
2) And more importantly, the asynchrony in nodejs is not easy. Writing maintainable JS is harder than writing Python or Java. So if someone has been through that grind, chances are they could be good developers.
Being able to do everything with a single language is kind of a big deal for many companies; the only thing holding back JS of the messy nature of callbacks (and promises, yuck). I would expect real adoption of JS to begin when ES6 features (generators, classes, etc) become available.