Hacker News new | past | comments | ask | show | jobs | submit login

By that logic Erlang should be winning, but it's really just "worse is better" at work.



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.


>I would contend Go does around 50% of what Erlang does. Node.js does around 10% of what Erlang does.

Not there are lots of reasons for choosing a platform, but if we are talking about performance:

A well written Go app tends to perform better as well: http://www.techempower.com/benchmarks/#section=data-r8&hw=i7...

Here it is with Java added back in too: http://www.techempower.com/benchmarks/#section=data-r8&hw=i7... . What is interesting here is any node entry only comes it at better than 10th place in one benchmark.

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:

https://news.ycombinator.com/item?id=7397653

So for them, node.js is "good enough".

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.

From PG's "Beating the Averages"


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?


A counterpoint: http://basho.com/erlang-at-basho-five-years-later/

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: