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.
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.
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.
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.
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.
This hasn't been true for a while now.
node --max-old-space-size=8192 server.js
See also http://prestonparry.com/articles/IncreaseNodeJSMemorySize/
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.
"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.
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.
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. :)
I can with one, and have cracked his management style too, so he's gone from being unproductive and the butt of office gossip to meeting schedules.
The other is new to this country, doesn't speak much English (e.g. not enough to ask questions) and understands little English too. At a loss for how to proceed...
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.
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.
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.
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.
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).
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.
Not sure many experienced developers would agree with you a JIT Compiler is quite different to a real compiled language C Fortran Etc
Just because V8 has a compiler, doesn't make it a compiler. Do you see the difference?
V8 is a JIT compiler. It both compiles code and runs it. For your original complaint about not being able to compile JS up front, you're talking about Ahead-Of-Time (AOT) compilation. You don't seem very familiar with the relevant terminology.
In fact, I just looked it up and apparently V8 compiles JS directly to machine code rather than bytecode: https://en.wikipedia.org/wiki/Chrome_V8.
And for the record, AOT languages also have "runtimes" provided by a platform. If someone combined gcc and glibc, would the combined product no longer be considered a "compiler"?
Can V8 be used to compile js to a artifact/binary which can later be executed independently of V8? If no, then it's not a compiler. It's as simple as that.
The difference is just that V8 includes the runtime and compiler in the same program. If they split it into v8c and v8lib without making any changes to the way that JavaScript is converted into something that your CPU processes, would it then be a "real compiler"?
Are mcs or javac real compilers? They both leave behind an "executable", but they require a separate runtime to be installed actually execute it. What about GCJ? What about anything that compiles down to LLVM IR and depends on LLVM to convert it to machine code? Is that not a real compiler either? Is CPython a compiler? It leaves junk on my disk in the form of pyc files.
I'm really curious why you insist that something isn't performing compilation if it doesn't write its output to disk. When is the process of compiling from one target into another not compilation?
Perhaps you're suggesting that only compilers that emit appropriate machine code are "real compilers". That's silly, but I could understand if that's what you mean.
However, I think you'll be disappointed to learn that V8 does directly emit machine code. [0]
- To get around the 1GB cap use Buffers, they are outside the v8 heap.
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.