6 ms·

Node.js is one of the worst things to happen to the software industry in recent times, a whole generation of programmers are being taught the worst of all ways

by luriel 14y ago

Node.js is one of the worst things to happen to the software industry in recent times, a whole generation of programmers are being taught the worst of all ways of doing concurrency, in a system that doesn't scale either in performance or project size and with one of the languages most plagued by pitfalls ever created. JavaScript was already painful enough in the browser, why on earth anyone ever thought it was a good idea to use it on the server boggles the mind. We will be paying the price of this misguided hyped fad for decades to come. Of all the ways of doing concurrency, callbacks are by far the worst, Twisted was plagued by them and is the main reason why it failed, and that was with a much more sane and reasonable language like Python (stackless Python was a much better alternative and used a model similar to Go's CSP). And the sad thing is that there are much better alternatives around with much more sound models and environments, Erlang and Go are the two obvious examples, and that is for the highly specialized situations where you have great concurrency needs, for any other problem anything else will be much better than Node.js, even PHP.

dmpk2k 14y ago
I think your definition of "worst" needs recalibration; the hyperboles really aren't improving the level of discourse.
ShirsenduK 14y ago
"JavaScript was already painful enough in the browser" only because its in a browser where standards are inexistent.
- luriel 14y ago
  Yes, the lack of proper standards made it even worse, and yes, JavaScript has 'good parts', but JavaScript is still chockfull of wat: https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
  - dotborg 14y ago
    so it should be easier to use javascript on server side, no?
  - esrauch 14y ago
    That video is completely misleading due to a quirk of the repl treating {} as a block not an object, not really a language wart. Try it yourself: var a = [] + {}; var b = {} + []; Miraculously they are same (but only because the list is empty, string concat order matters obviously)! The only time that wat can ever happen is a case that would never exist in any actual code. The Dom is full of wat but I still havent seen any legitimate cases in js itself.
- Ygg2 14y ago
  No JavaScript in all honesty was painful because the way it was designed (it was made in ten days). Equality operator ('==') is a cause of MAJOR headache and so is the global scoping, the bizzaro addition operator, etc. See[1min 23s] https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
  - 1SaltwaterC 14y ago
    http://stackoverflow.com/a/9033306 http://stackoverflow.com/a/9033306 - this "wat" meme is getting old. At best, you people that keep posting this are automatically qualified as trolls. The fact is that probably none of you folks from the "wat" crowd didn't take the time to read the ECMA standard. I don't claim that the behavior is intuitive, or appropriate for some cases. But the lack of RTFM isn't excusable either. And yes, developing under node is not the same as developing for the browser where you need to use the lowest common denominator, which usually is IE6. I'd say that the issue is the "omg node.js" crowd that promoted it as the hammer for every issues that may pop out. It isn't. But this doesn't mean that it is completely useless.
    - Ygg2 14y ago
      Sorry, but please explain how is this issue somehow elevated by node when it is a part of language standard (ECMAScript standard linked in the article it posted)? Does V8 break ECMAScript? This is a gotcha of a language. It uses + operator that does something completely differently than what it usually does on almost any other language with similar syntax. It's the definition of counter-intuitive.
      - 1SaltwaterC 14y ago
        I said: > I don't claim that the behavior is intuitive, or appropriate for some cases. But the lack of RTFM isn't excusable either. You failed the read test. Twice. The first was the manual itself. > please explain how is this issue somehow elevated by node when it is a part of language standard You failed the read test. For the third time. Please indicate the part where I claim that node elevates the issue vs. standard ECMAScript behavior. I said something about the node vs browser runtimes. This is a totally different beast. > This is a gotcha of a language. It uses + operator that does something completely differently than what it usually does on almost any other language with similar syntax. It's the definition of counter-intuitive. The only gotcha is the coercion that some regard as dark magic vs statically typed languages vs the operators themselves. The "+" and "-" operators in JavaScript: "+" for summing Numbers or String concatenation, "-" for subtracting a Number from another Number (which basically makes it a strict arithmetic operator, you know, stuff for Numbers). Besides: - PHP uses the + and - as strictly arithmetic operators (it has the . operator for string concatenation), while summing up two strings equals int(0) since (int) 'foo' === 0: http://php.net/manual/en/language.operators.arithmetic.php http://php.net/manual/en/language.operators.arithmetic.php - C (and to some extent C++) uses the + and - as strictly arithmetic operators: invalid operands to binary + (have ‘char ’ and ‘char ’) - Java uses the + the same way as JavaScript: http://docs.oracle.com/javase/tutorial/java/nutsandbolts/opsummary.html http://docs.oracle.com/javase/tutorial/java/nutsandbolts/ops... What other language with "similar syntax"? D?
jahewson 14y ago
> the worst of all ways of doing concurrency That would be threads.
- chrisbroadfoot 14y ago
  You can't do concurrency with threads. I think you're confusing concurrency with parallelism.
  - tomjen3 14y ago
    And I think you are wrong. From wikipedia: >In computer science, concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other. The computations may be executing on multiple cores in the same chip, preemptively time-shared threads on the same processor, or executed on physically separated processors. A number of mathematical models have been developed for general concurrent computation including Petri nets, process calculi, the Parallel Random Access Machine model, the Actor model and the Reo Coordination Language. You can certainly build the actor model on the backs of threads.
    - deleted 14y ago
      [deleted]
    - deleted 14y ago
      [deleted]
  - johnleppings 14y ago
    @shit_hn_says Why not? A thread allows for two parts of the program to be running concurrently. Whether or not they run in parallel is orthogonal. Why don't you think they allow for concurrency? A few citations to back myself up: Concurrent Haskell is all about adding threads to Haskell: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html http://www.haskell.org/ghc/docs/latest/html/libraries/base/C.... The Java tutorials on concurrency all use threads: http://docs.oracle.com/javase/tutorial/essential/concurrency/ http://docs.oracle.com/javase/tutorial/essential/concurrency.... The Scheme manual uses threads for concurrency: http://sisc-scheme.org/manual/html/ch06.html http://sisc-scheme.org/manual/html/ch06.html. The Oz language also uses threads for concurrency: http://www.mozart-oz.org/home/doc/tutorial/node8.html http://www.mozart-oz.org/home/doc/tutorial/node8.html. So who's wrong here? The world leading academics behind Haskell, Scheme and Oz? The industrialists and pragmatists behind Java? Or little old you? The reality is that threads were created only to allow for concurrency. They were then re-used to allow for parallelism when we had multi-processors and then multi-cores. Edit: does this guy work at Google? Unbelieveable.
jlouis 14y ago
I agree that the Node.js model of concurrency is one of the weakest models out there. CPS is for the compiler writer, not for the programmer. The underlying problem is that sequential languages do bad when you "bolt on" concurrency to them - unless said language is expressive enough to make it bearable (Haskell and some MLs come to mind). For all other language, you are just frankensteining your system. The reactor-model, of which Twisted, Node.js and a couple of like systems are built around has one advantage: It is fairly easy to get going. It is by far the simplest model you can get bolted onto a system with relative ease. The crux of the problem is that we have a lot of sequentially oriented programmers who suddenly need to do full concurrency. This is the first attempt. To a professional Erlang programmer like me, it does look rather odd that one would hail a reactor model as being anything decent to work with. There are other concurrent calculi out there, which may be better than what Erlang provides, but none of them worries about callbacks in the style of Node. I have a hunch the kid must be dragged screaming into the concurrency shop.
- hasenj 14y ago
  > The underlying problem is that sequential languages do bad when you "bolt on" concurrency to them - unless said language is expressive enough to make it bearable Really? I'm not familiar with Erlang, but have you tried Go? Concurrency fits seamlessly into the language.
  - jlouis 14y ago
    Go is not sequential, but concurrent. It has built-in primitives for handling concurrency, witness the `go` keyword. It also has special syntax for doing selective receive over channels, which in turn means that the concurrency of that language is definitely not "bolted on" in the sense I meant. Perhaps you are confusing my definition of "sequential" with yours. I tend to use "sequential" as the opposite of "concurrent" like I have another, orthogonal, axis for "serial"/"parallel". So you can be serial/concurrent (Node.js is close to this. So is a 4.4BSD OS without any SMP support). And you can be sequential/parallel (GPUs is my preferred example).

by luriel 14y ago

dmpk2k 14y ago

I think your definition of "worst" needs recalibration; the hyperboles really aren't improving the level of discourse.

ShirsenduK 14y ago

"JavaScript was already painful enough in the browser" only because its in a browser where standards are inexistent.

luriel 14y ago
Yes, the lack of proper standards made it even worse, and yes, JavaScript has 'good parts', but JavaScript is still chockfull of wat: https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
- dotborg 14y ago
  so it should be easier to use javascript on server side, no?
- esrauch 14y ago
  That video is completely misleading due to a quirk of the repl treating {} as a block not an object, not really a language wart. Try it yourself: var a = [] + {}; var b = {} + []; Miraculously they are same (but only because the list is empty, string concat order matters obviously)! The only time that wat can ever happen is a case that would never exist in any actual code. The Dom is full of wat but I still havent seen any legitimate cases in js itself.
Ygg2 14y ago
No JavaScript in all honesty was painful because the way it was designed (it was made in ten days). Equality operator ('==') is a cause of MAJOR headache and so is the global scoping, the bizzaro addition operator, etc. See[1min 23s] https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
- 1SaltwaterC 14y ago
  http://stackoverflow.com/a/9033306 http://stackoverflow.com/a/9033306 - this "wat" meme is getting old. At best, you people that keep posting this are automatically qualified as trolls. The fact is that probably none of you folks from the "wat" crowd didn't take the time to read the ECMA standard. I don't claim that the behavior is intuitive, or appropriate for some cases. But the lack of RTFM isn't excusable either. And yes, developing under node is not the same as developing for the browser where you need to use the lowest common denominator, which usually is IE6. I'd say that the issue is the "omg node.js" crowd that promoted it as the hammer for every issues that may pop out. It isn't. But this doesn't mean that it is completely useless.
  - Ygg2 14y ago
    Sorry, but please explain how is this issue somehow elevated by node when it is a part of language standard (ECMAScript standard linked in the article it posted)? Does V8 break ECMAScript? This is a gotcha of a language. It uses + operator that does something completely differently than what it usually does on almost any other language with similar syntax. It's the definition of counter-intuitive.
    - 1SaltwaterC 14y ago
      I said: > I don't claim that the behavior is intuitive, or appropriate for some cases. But the lack of RTFM isn't excusable either. You failed the read test. Twice. The first was the manual itself. > please explain how is this issue somehow elevated by node when it is a part of language standard You failed the read test. For the third time. Please indicate the part where I claim that node elevates the issue vs. standard ECMAScript behavior. I said something about the node vs browser runtimes. This is a totally different beast. > This is a gotcha of a language. It uses + operator that does something completely differently than what it usually does on almost any other language with similar syntax. It's the definition of counter-intuitive. The only gotcha is the coercion that some regard as dark magic vs statically typed languages vs the operators themselves. The "+" and "-" operators in JavaScript: "+" for summing Numbers or String concatenation, "-" for subtracting a Number from another Number (which basically makes it a strict arithmetic operator, you know, stuff for Numbers). Besides: - PHP uses the + and - as strictly arithmetic operators (it has the . operator for string concatenation), while summing up two strings equals int(0) since (int) 'foo' === 0: http://php.net/manual/en/language.operators.arithmetic.php http://php.net/manual/en/language.operators.arithmetic.php - C (and to some extent C++) uses the + and - as strictly arithmetic operators: invalid operands to binary + (have ‘char ’ and ‘char ’) - Java uses the + the same way as JavaScript: http://docs.oracle.com/javase/tutorial/java/nutsandbolts/opsummary.html http://docs.oracle.com/javase/tutorial/java/nutsandbolts/ops... What other language with "similar syntax"? D?

jahewson 14y ago

> the worst of all ways of doing concurrency That would be threads.

chrisbroadfoot 14y ago
You can't do concurrency with threads. I think you're confusing concurrency with parallelism.
- tomjen3 14y ago
  And I think you are wrong. From wikipedia: >In computer science, concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other. The computations may be executing on multiple cores in the same chip, preemptively time-shared threads on the same processor, or executed on physically separated processors. A number of mathematical models have been developed for general concurrent computation including Petri nets, process calculi, the Parallel Random Access Machine model, the Actor model and the Reo Coordination Language. You can certainly build the actor model on the backs of threads.
  - deleted 14y ago
    [deleted]
  - deleted 14y ago
    [deleted]
- johnleppings 14y ago
  @shit_hn_says Why not? A thread allows for two parts of the program to be running concurrently. Whether or not they run in parallel is orthogonal. Why don't you think they allow for concurrency? A few citations to back myself up: Concurrent Haskell is all about adding threads to Haskell: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html http://www.haskell.org/ghc/docs/latest/html/libraries/base/C.... The Java tutorials on concurrency all use threads: http://docs.oracle.com/javase/tutorial/essential/concurrency/ http://docs.oracle.com/javase/tutorial/essential/concurrency.... The Scheme manual uses threads for concurrency: http://sisc-scheme.org/manual/html/ch06.html http://sisc-scheme.org/manual/html/ch06.html. The Oz language also uses threads for concurrency: http://www.mozart-oz.org/home/doc/tutorial/node8.html http://www.mozart-oz.org/home/doc/tutorial/node8.html. So who's wrong here? The world leading academics behind Haskell, Scheme and Oz? The industrialists and pragmatists behind Java? Or little old you? The reality is that threads were created only to allow for concurrency. They were then re-used to allow for parallelism when we had multi-processors and then multi-cores. Edit: does this guy work at Google? Unbelieveable.

jlouis 14y ago

I agree that the Node.js model of concurrency is one of the weakest models out there. CPS is for the compiler writer, not for the programmer. The underlying problem is that sequential languages do bad when you "bolt on" concurrency to them - unless said language is expressive enough to make it bearable (Haskell and some MLs come to mind). For all other language, you are just frankensteining your system. The reactor-model, of which Twisted, Node.js and a couple of like systems are built around has one advantage: It is fairly easy to get going. It is by far the simplest model you can get bolted onto a system with relative ease. The crux of the problem is that we have a lot of sequentially oriented programmers who suddenly need to do full concurrency. This is the first attempt. To a professional Erlang programmer like me, it does look rather odd that one would hail a reactor model as being anything decent to work with. There are other concurrent calculi out there, which may be better than what Erlang provides, but none of them worries about callbacks in the style of Node. I have a hunch the kid must be dragged screaming into the concurrency shop.

hasenj 14y ago
> The underlying problem is that sequential languages do bad when you "bolt on" concurrency to them - unless said language is expressive enough to make it bearable Really? I'm not familiar with Erlang, but have you tried Go? Concurrency fits seamlessly into the language.
- jlouis 14y ago
  Go is not sequential, but concurrent. It has built-in primitives for handling concurrency, witness the `go` keyword. It also has special syntax for doing selective receive over channels, which in turn means that the concurrency of that language is definitely not "bolted on" in the sense I meant. Perhaps you are confusing my definition of "sequential" with yours. I tend to use "sequential" as the opposite of "concurrent" like I have another, orthogonal, axis for "serial"/"parallel". So you can be serial/concurrent (Node.js is close to this. So is a 4.4BSD OS without any SMP support). And you can be sequential/parallel (GPUs is my preferred example).