4 ms·

It's not node.js that's horrible: it's great for what it does (web development). When taken out of that use case, it's awful, because it's simply not meant to d

It's not node.js that's horrible: it's great for what it does (web development). When taken out of that use case, it's awful, because it's simply not meant to do systems programming or to make local applications. 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).

eckza 11y ago
"Hey guys, look what I did!" crickets "... with JAVASCRIPT!" thunderous applause and/or retweets
- cardiffspaceman 11y ago
  I wrote a compiler for a toy functional (lazy) language. In bash.
pka 11y ago
That's because it's a waste of time to write a program in a primitive language like C when you don't end-of-the-world absolutely need performance/hard realtime guarantees; even then it's a better idea to only write the 5% performance-critical parts in C/asm and the rest in a saner high-level language. 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.
- adrusi 11y ago
  There are more concerns than performance. The choice of C here is a philosophical one. Vis seems to come from the same school of thought as the Suckless projects, where the unix design principles are worshipped. People who are interested in that kind of stuff are also usually fans of writing in C, simply because C is the most Unix of languages: Makefiles control the build, which allows trivial integration of external tools into the build process, function names match 1:1 with the labels in the produced object files, no name mangling, documentation comes in man pages. 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.
  - pka 11y ago
    I agree that often the choice of C is philosophical rather than technical, or we wouldn't see so much misuse of that language (and yes, I wouldn't count the build or package management system (or rather the non-existence thereof) or the documentation format as serious technical arguments for or against a language). 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.)
    - martanne 11y ago
      Some things are just more convenient/efficient to do in C. As an example the mark handling[1] used to represent cursors/selection relies on pointer arithmetic. 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/02c6df7cd4bca89506cf1d0e4a08bd719e8f17d3/text.c#L1543 https://github.com/martanne/vis/blob/02c6df7cd4bca89506cf1d0...
      - 11y ago
- digitaltoad 11y ago
  >end-of-the-world absolutely need performance/hard realtime guarantees As someone who spends much of their time inside a editor, I would say that this is pretty important to me.
  - pka 11y ago
    I meant hard realtime [0]. Your operating system is probably not hard realtime, which means that any editor you run isn't either. [0] http://stackoverflow.com/questions/17308956/differences-between-hard-real-time-soft-real-time-and-firm-real-time http://stackoverflow.com/questions/17308956/differences-betw...
adrusi 11y ago
> 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. 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.
mbrock 11y ago
I think that's still a lot of blanket judgments that programmers who can and have built other things with Node than web things, and with Perl than text monging tools, have to disagree with. 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?
burkaman 11y ago
"I think what the comment was trying to point out" 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.
jdc0589 11y ago
I still like node for writing utility CLIs as well, which I find myself doing A LOT these days. To be totally fair, that's mainly because of the excellent feature rich CLI modules out there (yargs, commander, etc...); but, I've found I want my CLI utilities to be in an interpreted language, and node just fits the bill pretty well for that.
- creshal 11y ago
  But why? It's a deployment nightmare to keep node updated on servers and laptops and desktops that will never, ever use node to server server-side JS, why do I need it and NPM and the whole upgrade nightmare it implies to run a random CLI utility?

eckza 11y ago

"Hey guys, look what I did!" crickets "... with JAVASCRIPT!" thunderous applause and/or retweets

cardiffspaceman 11y ago
I wrote a compiler for a toy functional (lazy) language. In bash.

pka 11y ago

That's because it's a waste of time to write a program in a primitive language like C when you don't end-of-the-world absolutely need performance/hard realtime guarantees; even then it's a better idea to only write the 5% performance-critical parts in C/asm and the rest in a saner high-level language. 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.

adrusi 11y ago
There are more concerns than performance. The choice of C here is a philosophical one. Vis seems to come from the same school of thought as the Suckless projects, where the unix design principles are worshipped. People who are interested in that kind of stuff are also usually fans of writing in C, simply because C is the most Unix of languages: Makefiles control the build, which allows trivial integration of external tools into the build process, function names match 1:1 with the labels in the produced object files, no name mangling, documentation comes in man pages. 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.
- pka 11y ago
  I agree that often the choice of C is philosophical rather than technical, or we wouldn't see so much misuse of that language (and yes, I wouldn't count the build or package management system (or rather the non-existence thereof) or the documentation format as serious technical arguments for or against a language). 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.)
  - martanne 11y ago
    Some things are just more convenient/efficient to do in C. As an example the mark handling[1] used to represent cursors/selection relies on pointer arithmetic. 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/02c6df7cd4bca89506cf1d0e4a08bd719e8f17d3/text.c#L1543 https://github.com/martanne/vis/blob/02c6df7cd4bca89506cf1d0...
    - 11y ago
digitaltoad 11y ago
>end-of-the-world absolutely need performance/hard realtime guarantees As someone who spends much of their time inside a editor, I would say that this is pretty important to me.
- pka 11y ago
  I meant hard realtime [0]. Your operating system is probably not hard realtime, which means that any editor you run isn't either. [0] http://stackoverflow.com/questions/17308956/differences-between-hard-real-time-soft-real-time-and-firm-real-time http://stackoverflow.com/questions/17308956/differences-betw...

adrusi 11y ago

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

mbrock 11y ago

I think that's still a lot of blanket judgments that programmers who can and have built other things with Node than web things, and with Perl than text monging tools, have to disagree with. 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?

burkaman 11y ago

"I think what the comment was trying to point out" 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.

jdc0589 11y ago

I still like node for writing utility CLIs as well, which I find myself doing A LOT these days. To be totally fair, that's mainly because of the excellent feature rich CLI modules out there (yargs, commander, etc...); but, I've found I want my CLI utilities to be in an interpreted language, and node just fits the bill pretty well for that.

creshal 11y ago
But why? It's a deployment nightmare to keep node updated on servers and laptops and desktops that will never, ever use node to server server-side JS, why do I need it and NPM and the whole upgrade nightmare it implies to run a random CLI utility?