6 ms·

V8 is a world class compiler. Compared to ruby, Python, Erlang, php and that ilk it is lightning quick. (Pypy is a good match for it but it's not main street

V8 is a world class compiler. Compared to ruby, Python, Erlang, php and that ilk it is lightning quick. (Pypy is a good match for it but it's not main street and you can't just use any module.) in terms of performance and popularity, v8/node stand pretty much alone as far as dynamic non-compiled environments. JavaScript has a lighter weight feel than Java and the jvm stack. Single threaded with a top notch event reactor. You can write just a few lines in node and have a web server serving some json. There are a ton of JavaScript coders. There is something to be said for having a common technology throughout your stack and you ui is almost certainly in js. It's easy to get something simple going quickly, there are tons of libraries and you're going to need to write go, Java or .net to out perform it. The big downsides, imho, v8 is designed for client side stuff. Both it and dart vm are limited to relatively small memory footprints (think 1GB) which just isn't good for some workloads and problems. Likewise a lot of server tasks can make good use of real threads, you're out of luck with node, you can have child processes and send messages but if they have to share big amounts of data the marshaling becomes a bit of a bottleneck. If you work is database crud, or light weight, or horizontally scalable, or able to be modeled as streams then node isn't that bad. Js feels kind of limited in how certain things are modeled, there isn't much data hiding or abstraction; the extreme simplicity almost creates more complexity for some things. There are lots of different opinions on basic code behavior, some node modules do work on import, some need explicit initialization, some alter prototypes and it's a concept that seems to be lost on many js devs; I've burnt hours debugging something because someone reordered the imports and it screwed init logic. And you'll completely screw yourself if you don't stay up to date with your depends, things change fast and sometimes they change a lot. Both node and dart vm seem really well equipped for tooling type things that are usually done in bash, Python or perl but that doesn't seem to be as popular. It's definitely not for everything but it's worth a look. It is really popular.

lasfter 9y ago
I see some merits. I am not sure I buy using JavaScript based on performance/dev speed ratio though. Lua is even faster, lighter weight and has clean, logical semantics. I guess I'm just trying to decide if having a large talent pool and tons of modules is good enough.
- cookiecaper 9y ago
  I would watch it with that "large talent pool". As is typical in the language du jour, there are tons of worthless imposters going around selling Node.js skills. However, it's even worse in the case of JavaScript because since it uses the "same language", some people assume that light front-end scripting qualifies as real backend development experience. "Tons of modules" is also a misnomer, because a much larger than normal portion of these are low-quality, small, and/or poorly maintained. Just the way it goes in the age of GitHub, where everyone wants a badge of honor in their repo list.
  - porker 9y ago
    > there are tons of worthless imposters going around selling Node.js skills. However, it's even worse in the case of JavaScript because since it uses the "same language", some people assume that light front-end scripting qualifies as real backend development experience. Seconded. I'm working for a company building an Ionic app, and they hired two junior programmers with "angular experience" (both of whom had built angular apps before) to be the developers on the project. I'd used KnockoutJS but never ES6, Angular (1 or 2), TypeScript, written a mobile app, plus the RxJS concept was new to me, as was thinking asynchronously (I told them I wasn't a good fit for the project). Yet while the developers have struggled to do their work and the schedule has slipped, I've been able to pick up the concepts, write half the app and solve the juniors' problems despite my unfamiliarity with it all. Glad to see nearly 20 years' experience programming makes a difference, even though none of it was with today's "hot" technologies.
    - mgkimsal 9y ago
      similar experience with ionic. yeah, I don't know 'angular' (well, didn't) but have still been able to be very productive very quickly (20+ years as well). and... the 'impostor' thing... quite true. easier for these people to slip in to larger companies, I think, but it's a problem all around. I would expect someone with 20+ years of experience to be able to help juniors troubleshoot in any language/stack, though, whether they expect it or not. :)
chmln 9y ago
> Both it and dart vm are limited to relatively small memory footprints (think 1GB) which just isn't good for some workloads and problems. This hasn't been true for a while now. node --max-old-space-size=8192 server.js See also http://prestonparry.com/articles/IncreaseNodeJSMemorySize/ http://prestonparry.com/articles/IncreaseNodeJSMemorySize/
- TheCondor 9y ago
  How about using 64gb?
alleycat 9y ago
- Node wasn't designed for CPU intensive work, it's primarily for IO based work, which it frankly excels at, in terms of speed and scalability. - To get around the 1GB cap use Buffers, they are outside the v8 heap.
digitalzombie 9y ago
> 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.
josteink 9y ago
> V8 is a world class compiler. Compared to ruby, Python, Erlang, php and that ilk it is lightning quick. Not to nitpick details, but V8 is a runtime, not a compiler. A compiler checks your code and tells you if it contains errors before you run it. V8 does not.
- beaconstudios 9y ago
  V8 is a JIT compiler, which incorporates a runtime and a compiler.
  - josteink 9y ago
    > V8 is a JIT compiler, which incorporates a runtime and a compiler. So it's a compiler which incorporates a compiler? Compilerception much? Seriously though: Can I tell V8 to compile my JS and tell me any errors found before I deploy it to production and runtime? Yes or no? Just because V8 internally JIT-compiles the JS-code to something eventually executable which the machine can run doesn't change the fact that it's interpreter and execution-engine (also known as a "runtime") for Javascript code. Just like Python and all those other platforms you listed as not being "compilers" (in which case you're absolutely right).
    - beaconstudios 9y ago
      > So it's a compiler which incorporates a compiler? Compilerception much? No, what I meant is that the concept of a JIT compiler incorporates both a runtime and a compiler. > Seriously though: Can I tell V8 to compile my JS and tell me any errors found before I deploy it to production and runtime? Yes or no? That's not the job of a compiler. It's a feature of compilation, but a compiler does not by definition have to compile your code before deployment. What would you be compiling the JS to? If you're wanting to check your syntax, your IDE should be able to do that, or you can use a compile-to-JS language like TypeScript. Yes, it's dumb I know - that's one of the many reasons I use TypeScript. > Just because V8 internally JIT-compiles the JS-code to something eventually executable which the machine can run doesn't change the fact that it's interpreter and execution-engine (also known as a "runtime") for Javascript code. You seem to be hung up on the idea of a compiler as something that checks your code is correct. It isn't - that functionality is incidental to the compiler's job, because it can't translate invalid syntax into whatever destination language it compiles to. > Just like Python and all those other platforms you listed as not being "compilers" (in which case you're absolutely right). I did no such thing. That was someone else. Any language which internally uses a bytecode representation is a JIT compiler, including Python, Java, and PHP. You could argue I'm being nitpicky, given that pretty much all performant interpreted languages use a bytecode representation - it's true in a sense, but I'm just trying to highlight that you seem to have a misunderstanding of what a compiler's job is.
rusk 9y ago
"if you don't stay up to date with your depends, things change fast and sometimes they change a lot." This, was actually one of the things I liked most about Node.js - npm allows a developer to specify all dependencies (`pacakage.json`), versioned, similarly to maven but not as clunky. I was able to get up to speed project very quickly and easily using just `npm install`. I had one or two versioning issues to iron out, but the advice it provides about what is broken and where was very helpful.
- cookiecaper 9y ago
  Not sure what your other experience is, but most dynamic languages have simple package management platforms similar to npm. As you note, Java has Maven/Ant and C# has NuGet, both of which are substantially more "enterprisey". It'd be interesting to hear a fair, modern comparison between npm, ruby-gems, LuaRocks, pip/PyPI/cheeseshop, and the other big ones I'm sure I'm forgetting. The JavaScript community has had a lot of competitors on this front, particularly for frontend asset management, but it does finally seem to stabilizing a little bit. It took forever.
  - rusk 9y ago
    A "Battle of the dependency managers" if you will .. sounds great! I mentioned NPM in particular in the context of this being a node.js discussion. I've seen a few comparable tools in my time but IMHO NPM may be one of the cleanest, considering this as a feature of node.js - it does add to its attractiveness as a development environment. Yeah it took the JS community ages to sort this out, but in NPM there seems to be an answer.
acdha 9y ago
> V8 is a world class compiler. Compared to ruby, Python, Erlang, php and that ilk it is lightning quick. I've heard that a lot but advocacy always seems to be based on artificial benchmarks. Most server apps are I/O bound and the ones which aren't tend to bottleneck in native code – i.e. a gzip implementation would run faster in V8 than python, ruby, etc. but since they're just calling a C library, it's a question of whether V8 is faster than GCC/Clang. One area where this is more interesting is async support, but the argument then is that it's easier to write async code in JS than other languages and reasonable people disagree on that point. I'm not saying that V8 isn't an impressive bit of work, just that most of the advocacy I've seen has reminded me of the JVM hype cycle before most people learned that a JIT mattered a lot less than their architectural choices.

lasfter 9y ago

I see some merits. I am not sure I buy using JavaScript based on performance/dev speed ratio though. Lua is even faster, lighter weight and has clean, logical semantics. I guess I'm just trying to decide if having a large talent pool and tons of modules is good enough.

cookiecaper 9y ago
I would watch it with that "large talent pool". As is typical in the language du jour, there are tons of worthless imposters going around selling Node.js skills. However, it's even worse in the case of JavaScript because since it uses the "same language", some people assume that light front-end scripting qualifies as real backend development experience. "Tons of modules" is also a misnomer, because a much larger than normal portion of these are low-quality, small, and/or poorly maintained. Just the way it goes in the age of GitHub, where everyone wants a badge of honor in their repo list.
- porker 9y ago
  > there are tons of worthless imposters going around selling Node.js skills. However, it's even worse in the case of JavaScript because since it uses the "same language", some people assume that light front-end scripting qualifies as real backend development experience. Seconded. I'm working for a company building an Ionic app, and they hired two junior programmers with "angular experience" (both of whom had built angular apps before) to be the developers on the project. I'd used KnockoutJS but never ES6, Angular (1 or 2), TypeScript, written a mobile app, plus the RxJS concept was new to me, as was thinking asynchronously (I told them I wasn't a good fit for the project). Yet while the developers have struggled to do their work and the schedule has slipped, I've been able to pick up the concepts, write half the app and solve the juniors' problems despite my unfamiliarity with it all. Glad to see nearly 20 years' experience programming makes a difference, even though none of it was with today's "hot" technologies.
  - mgkimsal 9y ago
    similar experience with ionic. yeah, I don't know 'angular' (well, didn't) but have still been able to be very productive very quickly (20+ years as well). and... the 'impostor' thing... quite true. easier for these people to slip in to larger companies, I think, but it's a problem all around. I would expect someone with 20+ years of experience to be able to help juniors troubleshoot in any language/stack, though, whether they expect it or not. :)

chmln 9y ago

> Both it and dart vm are limited to relatively small memory footprints (think 1GB) which just isn't good for some workloads and problems. This hasn't been true for a while now. node --max-old-space-size=8192 server.js See also http://prestonparry.com/articles/IncreaseNodeJSMemorySize/ http://prestonparry.com/articles/IncreaseNodeJSMemorySize/

TheCondor 9y ago
How about using 64gb?

alleycat 9y ago

- Node wasn't designed for CPU intensive work, it's primarily for IO based work, which it frankly excels at, in terms of speed and scalability. - To get around the 1GB cap use Buffers, they are outside the v8 heap.

digitalzombie 9y ago

> 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.

josteink 9y ago

> V8 is a world class compiler. Compared to ruby, Python, Erlang, php and that ilk it is lightning quick. Not to nitpick details, but V8 is a runtime, not a compiler. A compiler checks your code and tells you if it contains errors before you run it. V8 does not.

beaconstudios 9y ago
V8 is a JIT compiler, which incorporates a runtime and a compiler.
- josteink 9y ago
  > V8 is a JIT compiler, which incorporates a runtime and a compiler. So it's a compiler which incorporates a compiler? Compilerception much? Seriously though: Can I tell V8 to compile my JS and tell me any errors found before I deploy it to production and runtime? Yes or no? Just because V8 internally JIT-compiles the JS-code to something eventually executable which the machine can run doesn't change the fact that it's interpreter and execution-engine (also known as a "runtime") for Javascript code. Just like Python and all those other platforms you listed as not being "compilers" (in which case you're absolutely right).
  - beaconstudios 9y ago
    > So it's a compiler which incorporates a compiler? Compilerception much? No, what I meant is that the concept of a JIT compiler incorporates both a runtime and a compiler. > Seriously though: Can I tell V8 to compile my JS and tell me any errors found before I deploy it to production and runtime? Yes or no? That's not the job of a compiler. It's a feature of compilation, but a compiler does not by definition have to compile your code before deployment. What would you be compiling the JS to? If you're wanting to check your syntax, your IDE should be able to do that, or you can use a compile-to-JS language like TypeScript. Yes, it's dumb I know - that's one of the many reasons I use TypeScript. > Just because V8 internally JIT-compiles the JS-code to something eventually executable which the machine can run doesn't change the fact that it's interpreter and execution-engine (also known as a "runtime") for Javascript code. You seem to be hung up on the idea of a compiler as something that checks your code is correct. It isn't - that functionality is incidental to the compiler's job, because it can't translate invalid syntax into whatever destination language it compiles to. > Just like Python and all those other platforms you listed as not being "compilers" (in which case you're absolutely right). I did no such thing. That was someone else. Any language which internally uses a bytecode representation is a JIT compiler, including Python, Java, and PHP. You could argue I'm being nitpicky, given that pretty much all performant interpreted languages use a bytecode representation - it's true in a sense, but I'm just trying to highlight that you seem to have a misunderstanding of what a compiler's job is.

rusk 9y ago

"if you don't stay up to date with your depends, things change fast and sometimes they change a lot." This, was actually one of the things I liked most about Node.js - npm allows a developer to specify all dependencies (`pacakage.json`), versioned, similarly to maven but not as clunky. I was able to get up to speed project very quickly and easily using just `npm install`. I had one or two versioning issues to iron out, but the advice it provides about what is broken and where was very helpful.

cookiecaper 9y ago
Not sure what your other experience is, but most dynamic languages have simple package management platforms similar to npm. As you note, Java has Maven/Ant and C# has NuGet, both of which are substantially more "enterprisey". It'd be interesting to hear a fair, modern comparison between npm, ruby-gems, LuaRocks, pip/PyPI/cheeseshop, and the other big ones I'm sure I'm forgetting. The JavaScript community has had a lot of competitors on this front, particularly for frontend asset management, but it does finally seem to stabilizing a little bit. It took forever.
- rusk 9y ago
  A "Battle of the dependency managers" if you will .. sounds great! I mentioned NPM in particular in the context of this being a node.js discussion. I've seen a few comparable tools in my time but IMHO NPM may be one of the cleanest, considering this as a feature of node.js - it does add to its attractiveness as a development environment. Yeah it took the JS community ages to sort this out, but in NPM there seems to be an answer.

acdha 9y ago

> V8 is a world class compiler. Compared to ruby, Python, Erlang, php and that ilk it is lightning quick. I've heard that a lot but advocacy always seems to be based on artificial benchmarks. Most server apps are I/O bound and the ones which aren't tend to bottleneck in native code – i.e. a gzip implementation would run faster in V8 than python, ruby, etc. but since they're just calling a C library, it's a question of whether V8 is faster than GCC/Clang. One area where this is more interesting is async support, but the argument then is that it's easier to write async code in JS than other languages and reasonable people disagree on that point. I'm not saying that V8 isn't an impressive bit of work, just that most of the advocacy I've seen has reminded me of the JVM hype cycle before most people learned that a JIT mattered a lot less than their architectural choices.