Hacker News Reader

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

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.

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

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

Does it have a non-hacky way of handling record types yet?

It has maps now! This chapter speaks of them being fully supported in future versions, which have since arrived. 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.

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.

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

> 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

How about using 64gb?

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

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.

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.

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

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

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

I've had some trouble finding explicit node backend jobs, as someone who'd consider themselves a relative specialist in it. Most places want a full stack developer well versed in common frontend frameworks and maybe a tiny bit of services on the backend. Most backend focused jobs (rightly, probably) focus on more traditional stacks or go. There's amazing things one can do very quickly with node exp (serverless/Faas services for one) but I've been struggling to find positions reliably.

Same, almost all JavaScript job postings are front end only. It's quite a shame.

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

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.

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.

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

V8 is a JIT compiler, which incorporates a runtime and a compiler.

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

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

"but a compiler does not by definition have to compile your code before deployment" Huh?

Not sure many experienced developers would agree with you a JIT Compiler is quite different to a real compiled language C Fortran Etc

a compiled language, yes. But the function of a compiler, between a compiled language and an interpreted language, remains the same. It translates code from one representation to another.

This is really simple. Do you use V8 to compile your code or to run it?

Just because V8 has a compiler, doesn't make it a compiler. Do you see the difference?

V8 compiles code into bytecode and runs that. This is really simple.

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.

V8 compiles to native code with the exception of low memory devices (512M or less), for which it has a (relatively recently introduced) bytecode compiler, so it uses an interpreter in that one case.

Syntax errors will be detected prior to runtime because the application will not be able to be compiled into whatever format it compiles down to (raw ASM, some IR, etc.). A fully AOT compiler will generally check more than a JIT compiler, but there is still compilation and it is still a "compiler" in a technical sense.

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"?

It is my understanding that V8 provides you with the capability to interpret your code and run it, while gcc produces a resulting binary which be run independently of gcc.

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.

Executables from gcc can't be run independent of a binary-compatible C runtime.

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]

[0] https://github.com/v8/v8/tree/master/src/compiler

There is no interpretation involved; V8 has an unoptimized base compiler for compiling JS to machine code one function at a time, and a pair of optimizing compilers that work based on runtime profiling. V8 also has a bytecode interpreter for low memory devices, but it'd mainly be used on very low end mobile devices.

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