3 ms·

It’s really hard to read such posts. The tool is only as good as the contributor, that’s all there is. Great things were built in all languages and frameworks.

It’s really hard to read such posts. The tool is only as good as the contributor, that’s all there is. Great things were built in all languages and frameworks. For god sakes, stop blaming the tool by doing naive comparisons with other languages/framework. Nothing’s perfect, that’s a given, but these kinds of post smells so much like entitlement. You don’t need to trash your previous framework/language and discourage others. If you struggled using node don’t fool yourself that it was because of the tool and try to do the hard work of introspection and understand why you failed. Disclaimer: In case you think I’m bias toward node, I’m more of a python fast API guy, but I have tremendous respect toward NodeJS performance and async elegance (and even more when mixed with typescript)

harryf 6y ago
I get where you're coming from - the post meanders around some topics every programmer has to learn by hard experience, such as the value of being able to reason about code / systems and the importance of data structures. That said my feeling is Node gives you multiple pump action shotguns you can easily shoot yourself in the foot with. For example https://nodejs.org/en/docs/guides/dont-block-the-event-loop/ https://nodejs.org/en/docs/guides/dont-block-the-event-loop/ > One common way to block the Event Loop disastrously is by using a "vulnerable" regular expression. If you're leading an engineering team, just this should be giving you panic attacks every time you hire someone new into the team. What makes this worse is it's very hard to detect problems at scale, if you missed it in code reviews. If you have one "vulnerable regex" in your event loop that only exposes itself on certain request inputs, it means that only every now and again - when given "bad input" - it's going to block the event loop. But then how to you detect issue? It's likely going to manifest itself first in _other_ requests that got blocked taking an excessively long time to respond. From an operational point of view, that's a nightmare scenario. Every now and again you're going to see slow requests in your logs but when you dig into it you find no problems. And that's going to make you very uncertain on how you're doing when it comes to scaling up; instead of a gradual slow down across all requests, you're going to see erratic spikes and jams. ...which actually occurs to me it's not unlike how traffic jams occur - https://www.youtube.com/watch?v=azmcu1cn2vg https://www.youtube.com/watch?v=azmcu1cn2vg - https://traffic-simulation.de/ https://traffic-simulation.de/
- debrice 6y ago
  I understand all the things you're talking about, and I agree, you can block the main thread (and elixir does not use the OS processes so it's awesome...). I do disagree with the take on await/async but that's a different discussion. Is the article insightful? Mostly, yes. Did Node and JS have to be painted this way? probably not.

harryf 6y ago

I get where you're coming from - the post meanders around some topics every programmer has to learn by hard experience, such as the value of being able to reason about code / systems and the importance of data structures. That said my feeling is Node gives you multiple pump action shotguns you can easily shoot yourself in the foot with. For example https://nodejs.org/en/docs/guides/dont-block-the-event-loop/ https://nodejs.org/en/docs/guides/dont-block-the-event-loop/ > One common way to block the Event Loop disastrously is by using a "vulnerable" regular expression. If you're leading an engineering team, just this should be giving you panic attacks every time you hire someone new into the team. What makes this worse is it's very hard to detect problems at scale, if you missed it in code reviews. If you have one "vulnerable regex" in your event loop that only exposes itself on certain request inputs, it means that only every now and again - when given "bad input" - it's going to block the event loop. But then how to you detect issue? It's likely going to manifest itself first in _other_ requests that got blocked taking an excessively long time to respond. From an operational point of view, that's a nightmare scenario. Every now and again you're going to see slow requests in your logs but when you dig into it you find no problems. And that's going to make you very uncertain on how you're doing when it comes to scaling up; instead of a gradual slow down across all requests, you're going to see erratic spikes and jams. ...which actually occurs to me it's not unlike how traffic jams occur - https://www.youtube.com/watch?v=azmcu1cn2vg https://www.youtube.com/watch?v=azmcu1cn2vg - https://traffic-simulation.de/ https://traffic-simulation.de/

debrice 6y ago
I understand all the things you're talking about, and I agree, you can block the main thread (and elixir does not use the OS processes so it's awesome...). I do disagree with the take on await/async but that's a different discussion. Is the article insightful? Mostly, yes. Did Node and JS have to be painted this way? probably not.