4 ms·

> Compared to ruby, Python, Erlang, php and that ilk it is lightning quick. Ain't nobody is going to compare performance against Erlang for numerical number cr

> Compared to ruby, Python, Erlang, php and that ilk it is lightning quick. Ain't nobody is going to compare performance against Erlang for numerical number crunch. It was never built for that. It's not even a fair comparison. It's like comparing a race car against a hybrid prius and saying the race car suck at mpg. They're built for different purposes. Ilk implies as if Erlang is some crap flavor flav tech. It is not. Erlang was made for concurrency. NodeJS was made to solve for concurrency too. And Erlang beats NodeJS hands down in concurrency. The actor model is a much better model to do concurrency and preemptive scheduling is amazing. It's easier to mentally think about actor and the code isolation in each processes makes it much more cleaner, object oriented, quoted by Alan Kay himself. NodeJS chose some existing language to do concurrency where as Erlang was created from the ground up to do concurrency. Hence the reason why it's VM is so amazing on top of the fact that concurrency constructs are first class and primitives.

greenleafjacob 9y ago
Erlang/OTP as a system blows away anything in node camp, and is only really approached (but not eclipsed by) by the JVM. Supervision trees in particular I have seen poorly reimplemented over and over in Go, Java, Python, and so on. It really feels like a well polished system.
foldr 9y ago
>It was never built for that. It's not even a fair comparison. No, but it means I can write relatively computationally intensive server side code in JavaScript rather than having to switch to C and use an FFI. It's always nice to have decent performance, even if it's irrelevant most of the time for web programming. Erlang is great but its ecosystem is tiny compared to Node's, and as a programming language it's at least as quirky as JavaScript.
- srpablo 9y ago
  > Erlang is great but its ecosystem is tiny compared to Node's, and as a programming language it's at least as quirky as JavaScript. I disagree with this; while the syntax is unusual for many, its semantics are extremely simple and clear. I don't think it has anything quite like: * JavaScript having `null` and `undefined`. * JavaScript lacking have proper integers. * JavaScript strings being UTF-16, so things like "".length don't work. * Scoping of 'this'. * The unmanageable automatic typecast rules * Semicolon insertion. * JavaScript `with (x) {` (maybe a cheap shot since it's so uncommon, but we are talking about language design). Main quirks I can think of for Erlang are when people trip up over "strings", <<"binaries">>, and iolists. But I'd love to hear where others run into proper semantic quirks.
  - foldr 9y ago
    Does it have a non-hacky way of handling record types yet?
    - srpablo 9y ago
      It has maps now! This chapter speaks of them being fully supported in future versions, which have since arrived. http://learnyousomeerlang.com/maps http://learnyousomeerlang.com/maps And even records are hardly a quirk like the ones I listed for JavaScript: as long as you remember that they're just syntax around tuples, you're hardly ever surprised by what they do. You'll never get a runtime behavior you didn't expect.
      - foldr 9y ago
        That is definitely an improvement, although the document you linked to suggests that the old-style records would still be used for some purposes. If the language already has tuples there's really no reason why it shouldn't just have tuples with a fixed set of named fields. The quirks of JavaScript that you mention never bother me at all in practice (and yes, bringing up 'with' is a very cheap shot, and Erlang's string handling is pretty wacky too), but I remember that not having real record types was a serious pain point.
deleted 9y ago
[deleted]
jbreckmckye 9y ago
The only difference, of course, is that nobody uses Erlang.

greenleafjacob 9y ago

Erlang/OTP as a system blows away anything in node camp, and is only really approached (but not eclipsed by) by the JVM. Supervision trees in particular I have seen poorly reimplemented over and over in Go, Java, Python, and so on. It really feels like a well polished system.

foldr 9y ago

>It was never built for that. It's not even a fair comparison. No, but it means I can write relatively computationally intensive server side code in JavaScript rather than having to switch to C and use an FFI. It's always nice to have decent performance, even if it's irrelevant most of the time for web programming. Erlang is great but its ecosystem is tiny compared to Node's, and as a programming language it's at least as quirky as JavaScript.

srpablo 9y ago
> Erlang is great but its ecosystem is tiny compared to Node's, and as a programming language it's at least as quirky as JavaScript. I disagree with this; while the syntax is unusual for many, its semantics are extremely simple and clear. I don't think it has anything quite like: * JavaScript having `null` and `undefined`. * JavaScript lacking have proper integers. * JavaScript strings being UTF-16, so things like "".length don't work. * Scoping of 'this'. * The unmanageable automatic typecast rules * Semicolon insertion. * JavaScript `with (x) {` (maybe a cheap shot since it's so uncommon, but we are talking about language design). Main quirks I can think of for Erlang are when people trip up over "strings", <<"binaries">>, and iolists. But I'd love to hear where others run into proper semantic quirks.
- foldr 9y ago
  Does it have a non-hacky way of handling record types yet?
  - srpablo 9y ago
    It has maps now! This chapter speaks of them being fully supported in future versions, which have since arrived. http://learnyousomeerlang.com/maps http://learnyousomeerlang.com/maps And even records are hardly a quirk like the ones I listed for JavaScript: as long as you remember that they're just syntax around tuples, you're hardly ever surprised by what they do. You'll never get a runtime behavior you didn't expect.
    - foldr 9y ago
      That is definitely an improvement, although the document you linked to suggests that the old-style records would still be used for some purposes. If the language already has tuples there's really no reason why it shouldn't just have tuples with a fixed set of named fields. The quirks of JavaScript that you mention never bother me at all in practice (and yes, bringing up 'with' is a very cheap shot, and Erlang's string handling is pretty wacky too), but I remember that not having real record types was a serious pain point.

deleted 9y ago

[deleted]

jbreckmckye 9y ago

The only difference, of course, is that nobody uses Erlang.