3 ms·

Long live Node.js! As everyone has mentioned this seems to be a simple case where the rewrite is a completely different architecture, which could have been don

by erlich 11y ago

Long live Node.js! As everyone has mentioned this seems to be a simple case where the rewrite is a completely different architecture, which could have been done in Node.js. I'm interested in why this continues to happen. Seems like Node.js is a victim of its own simplicity. The baked-in non-blocking concepts of Node.js makes everyone feel like single-threaded is the only way to go, and think that Node.js is inherently flawed when it comes to parallelization. Because Go doesn't give you a simple and relatively scalable solution without even thinking about it like Node.js does, instead you have to choose what to parallelize and think about the problem more. With PM2 scaling Node.js over CPUs becomes incredibly trivial. Also, I think programmers naturally like rewrites/starting from scratch, and a new programming language provides an opportunity to rewrite everything (which the OP from this article and every other "switcher" article seem to do).

douche 11y ago
> Seems like Node.js is a victim of its own simplicity NodeJS is a victim of basing itself on a terrible scripting language that was thrown together to wire up basic event handlers to HTML buttons.
zongitsrinzler 11y ago
Recently I rewrote a medium sized Websocket app from Node to Go. Hoping for better performance and having heard a lot of good about Go. Since the application relies heavily on sharing resources between sockets I found out the hard way that concurrent programming in Go is not much easier than in Java. Sure, it has a better syntax and channels but compared to Node where you never have to think about things like these the complexity is way higher. Long live Node.js!
- 59nadir 11y ago
  > Since the application relies heavily on sharing resources between sockets... Which resources?
  - zongitsrinzler 11y ago
    Connections are grouped in various ways. A lot of maps, etc. You can't even use a regular int safely, need to use an atomic for that. I'm not bashing Go here, the memory usage is about 3x lower (which was the most important for me). And for a static language it's pretty cool.
    - 59nadir 11y ago
      Am I understanding you correctly when I assume that you mean you share data across threads?
zappo2938 11y ago
I've been learning Node.js for the past several months and building all my pet projects exclusively with it. A couple weeks ago I was offered a job, they knew I was mostly interested in JavaScript, but they dropped one on me in the interview. The condition of me being hired was I had to learn to Golang and would be developing in Go. I just felt like I was switching rafts midstream if I went that route so I had to say no. When it comes to deciding which is better, being able to find Node.js developers is a huge plus. Also, there is a lot more resources for Node.js which might make development faster in an industry where the first out the gate is often the winner.
- tonyedgecombe 11y ago
  Interesting, for me the language I use would be near the bottom of the list of priorities in a job search.
  - Vendan 11y ago
    True, though, TBH, if a programmer can't say "Sure, I can learn that", I don't want to work beside him.
fauigerzigerk 11y ago
>I'm interested in why this continues to happen. The psychology is easy to explain. The nodejs.org home page says "Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient". And the about page goes on to say "As an asynchronous event driven framework, Node.js is designed to build scalable network applications". But for that supposed efficiency and scalability you pay a price: You must structure your code according to a particular optimization technique instead of structuring it according to semantic coherence. You lose modularity and clarity to gain scalability. That's the deal. And then one day you realize that the whole thing doesn't scale as well as it could on a given hardware and it isn't very efficient unless you bring back some of the supposedly heavyweight architectural principles that you left behind. At that point doubts start to creep in: Did we use the right tool for the job? Did we turn our code base into callback spaghetti for nothing? And it's not that surprising that sometimes people opt not to keep paying the price in terms of code quality when they lose the supposed benefits they were paying that price for in the first place.

by erlich 11y ago

douche 11y ago

> Seems like Node.js is a victim of its own simplicity NodeJS is a victim of basing itself on a terrible scripting language that was thrown together to wire up basic event handlers to HTML buttons.

zongitsrinzler 11y ago

Recently I rewrote a medium sized Websocket app from Node to Go. Hoping for better performance and having heard a lot of good about Go. Since the application relies heavily on sharing resources between sockets I found out the hard way that concurrent programming in Go is not much easier than in Java. Sure, it has a better syntax and channels but compared to Node where you never have to think about things like these the complexity is way higher. Long live Node.js!

59nadir 11y ago
> Since the application relies heavily on sharing resources between sockets... Which resources?
- zongitsrinzler 11y ago
  Connections are grouped in various ways. A lot of maps, etc. You can't even use a regular int safely, need to use an atomic for that. I'm not bashing Go here, the memory usage is about 3x lower (which was the most important for me). And for a static language it's pretty cool.
  - 59nadir 11y ago
    Am I understanding you correctly when I assume that you mean you share data across threads?

zappo2938 11y ago

I've been learning Node.js for the past several months and building all my pet projects exclusively with it. A couple weeks ago I was offered a job, they knew I was mostly interested in JavaScript, but they dropped one on me in the interview. The condition of me being hired was I had to learn to Golang and would be developing in Go. I just felt like I was switching rafts midstream if I went that route so I had to say no. When it comes to deciding which is better, being able to find Node.js developers is a huge plus. Also, there is a lot more resources for Node.js which might make development faster in an industry where the first out the gate is often the winner.

tonyedgecombe 11y ago
Interesting, for me the language I use would be near the bottom of the list of priorities in a job search.
- Vendan 11y ago
  True, though, TBH, if a programmer can't say "Sure, I can learn that", I don't want to work beside him.

fauigerzigerk 11y ago

>I'm interested in why this continues to happen. The psychology is easy to explain. The nodejs.org home page says "Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient". And the about page goes on to say "As an asynchronous event driven framework, Node.js is designed to build scalable network applications". But for that supposed efficiency and scalability you pay a price: You must structure your code according to a particular optimization technique instead of structuring it according to semantic coherence. You lose modularity and clarity to gain scalability. That's the deal. And then one day you realize that the whole thing doesn't scale as well as it could on a given hardware and it isn't very efficient unless you bring back some of the supposedly heavyweight architectural principles that you left behind. At that point doubts start to creep in: Did we use the right tool for the job? Did we turn our code base into callback spaghetti for nothing? And it's not that surprising that sometimes people opt not to keep paying the price in terms of code quality when they lose the supposed benefits they were paying that price for in the first place.