Back in the second century BC, Cato the Elder ended his speeches with the phrase 'Carthago delenda est,' which is to say, 'Carthage must be destroyed.' It didn't matter what the ostensible topic of the speech was: above all, Carthage must be destroyed.
My opinion towards JavaScript is much like Cato's towards Carthage: it must be rooted out, eliminated and destroyed entirely. I don't know if I'd go quite so far as to say that the fundamental challenge of mass computing is the final destruction of JavaScript — but I want to say it, even though it's false.
JavaScript is a pox, a disaster, a shame. It is the most embarrassingly bad thing to become popular in computing since Windows 3.1. Its one virtue (that it's on every client device) is outshone by its plethora of flaws in much the same way that a matchstick is outshone by the sun, the stars and the primordial energy of the Big Bang added together.
JavaScript is the XML, the Yugo, the Therac-25 of programming languages. The sheer amount of human effort which has been expended working around its fundamental flaws instead of advancing the development of mankind is astounding. The fact that people would take this paragon of wasted opportunity and use it on the server side, where there are so many better alternatives (to a first approximation, every other programming language ever used), is utterly appalling.
JavaScript delenda est.
We can all go around commenting on every single thread about how our chosen terrible thing is terrible, and then every thread looks exactly the same and it gets really boring. Or we can all restrain ourselves to only talking about how terrible our chosen terrible thing is, in threads that are about that thing.
Well, as long as you're having fun!
It's kind of like people who knock Perl: it's made specifically for text parsing, nothing more, and too many people use it for much more. Since it's not meant for more complex things, it fails, understandably.
I think what the comment was trying to point out is that oftentimes there are things on Hacker News that are written in JS that shouldn't be: systems programs, emulators, shells, etc. This is not the fault of the ecosystem itself, but rather the misunderstanding of the authors about the viable use cases of the tool that they're using (node.js).
crickets
"... with JAVASCRIPT!"
thunderous applause and/or retweets
In bash.
C is definitely the wrong choice for a complex data-structure processing piece of software like a text editor.
Even though vanilla JS is madness, it gives you a very nice base to build on - namely closures and a GC, which make languages like Clojure or Purescript possible.
Still, for an editor I'd prefer pure Javascript over C every time.
But really, a text editor is something C is quite well suited to. Javascript wouldn't bring much to the table, and you'd have to jump through hoops for something like mmap.
Just to be clear, I'm not advocating the usage of Javascript here, rather I'm trying to make the point that C is a really really primitive language and programming in it, rather than in a higher-level language (any higher-level language) is almost always a waste of time.
(Drivers and memory / performance-constrained code being an exception.)
Btw, there's a mmap module or library for any major programming language out there (checked for Js, Python, Ruby, Haskell, even Clojure.)
Other things like the syntax highlighting are implemented in Lua which is high level but still has low resource usage.
And yes part of the choice is also philosophical. I consider an editor a core system tool which should have minimal dependencies.
[1] https://github.com/martanne/vis/blob/02c6df7cd4bca89506cf1d0...
On the other hand, look at array.c. Or buffer.c. Or map.c. Or all the manual linked list management stuff. Or all the other logic that would be so much simpler with a more functional language. I mean, sure - there's an unique feeling to being so close to the metal, and that's fine, but if you want to build something new reinventing the wheel for the millionth time is a waste of time.
edit: there are compiled higher-level languages too (i.e. Haskell). If you want minimal dependencies, it doesn't really matter how the binary got built.
Anyway this was just an example. I agree that higher level languages (including functional ones) have their own merit. If I would start again today I might consider Rust. But again the LLVM dependency seems kind of scary.
Again for me an ideal base system is built upon a kernel, libc (musl), C compiler (cparser/libfirm), coreutils (sbase/ubase, toybox, busybox), editor (vis) etc. Writing a C compiler is non-trivial, but doable. Creating a C++ compiler on the other hand ...
A self contained (including terminfo entries etc), statically linked vis binary weights in at around ~800K. This allows usage in resource constrained sytems, I don't think the same would be possible using e.g. Haskell.
As someone who spends much of their time inside a editor, I would say that this is pretty important to me.
[0] http://stackoverflow.com/questions/17308956/differences-betw...
Perl 1 and 2 I think really were specifically for test processing, but it is neither widely regarded as a text processing language by its users, nor would someone learning the language notice that it's particularly geared toward text processing. Perl is hated on because it's a language that turned the dynamic up to eleven and embraces multiple ways of doi g something which causes ecosystem fragmentation, and because perl 5 predates a lot of now-widespread conveniences.
Node, for example, is a high-performing and fast-starting interpreter for a dynamic language with a base runtime that includes good tools for building network servers, system utilities, etc. There are many, many uses for which it's just great.
So when you say that Node is "awful" for anything except "web development" it's just inviting disagreement. Why make this kind of strong value judgment about a general purpose tool?
It's easy to understand what the comment was trying to point out, because there are similar comments in ~80% of HN discussions. That's the issue.
Perhaps the new ECMAScript standard will help. I have my doubts (but as with any statement about the future it is hard to say with any certainty what will happen). The Node rot runs deeper than the usual Javascript nonsense.
If it feels like Javascript is being unjustly maligned: (a), it isn't; (b), wait for the next gnarly buffer overflow exploit to come along and you'll see that people despise C just as much.
With JavaScript, many people are just vitriolic about it. I try to offer counterpoints because I'm a small part of this ecosystem, and I'm thankful for the work people put into open source tools, libraries, etc.
I also happen to think JavaScript is a pretty neat language... like, one of my favorites, despite its shortcomings.
By the way, I don't know of any languages without serious shortcomings... funny, that...