4 ms·

I'm sure most of us can assume reasons why collecting data with node.js might be "wrong," but it would be more helpful to the conversation if you would spell ou

I'm sure most of us can assume reasons why collecting data with node.js might be "wrong," but it would be more helpful to the conversation if you would spell out specific reasons why using node.js for this use case is not optimal, instead of just commenting with a single emoji.

otterley 11y ago
Because it's just not necessary, and meanwhile most experienced SREs and performance engineers are imperative programmers. We don't see the benefits of using JavaScript on our servers, and that's rather putting it mildly. Also JavaScript doesn't have a 64-bit integer type, which is absolutely necessary to properly support large counters. There are workarounds but the fact that you need one is ridiculous. Many of us believe that the only reason one would want to use JavaScript is because you're doing browser programming and therefore you have no other choice.
- NietTim 11y ago
  Non of what you just said was an actual argument against node.js though. All you said was "Well, we don't like it" Why don't you like it? What's wrong with it? What would be better?
  - jjnoakes 11y ago
    > All you said was "Well, we don't like it" That's not what I see.
  - otterley 11y ago
    It's not about Node per se; it's about JavaScript. System telemetry collectors don't benefit much from languages built around event loops. Many of us already know C, Bourne Shell and Python and probably another scripting language and all of those can get telemetry data off systems and into an event bus or metrics aggregator quickly enough. Adding JavaScript adds complexity without giving us significant new functionality. Now the data collector (gathering metrics from many senders for aggregation and storage) is a different story. I've seen them written in JavaScript but the 64-bit counter difficulties would rule it out for me were I to implement one again.
  - crdoconnor 11y ago
    It's a weakly typed language and it exhibits all kinds of bizarre not-very-well-thought out behaviors. c.f. the disaster with npm a few days ago. These problems are particularly pernicious for large scale apps - which this isn't, currently, but probably aspires to be one day. Any strongly typed language would be better (python, go, ruby, etc.).
    - geofft 11y ago
      Can you explain how the npm incident is related to typing? I am an advocate of strong typing and love seeing it be the answer to all sorts of problems (e.g. concurrency), but I'm not understanding the connection here.
      - crdoconnor 11y ago
        That wasn't related to js's weak typing and I didn't say that it was, but it's indicative of the types of other problems that will occur.
- illumin8 11y ago
  I've seen plenty of server-based applications written in node.js. Just because javascript used to be pigeon-holed into front-end doesn't mean it can't perform well on server applications. A good example of a node.js app that is purely server side is Hubot, a chat bot created at Github and widely used in Slack, HipChat, IRC, etc. I'm sure there are thousands of others out there, and I don't believe being written in Javascript gives them any fundamental disadvantage to server applications written in Python, Java, C++, or any other language.
  - pritambaral 11y ago
    For systems programming though? Running on a server is not the only similarity you should be looking at.
  - otterley 11y ago
    "If you have a hammer, everything starts to look like your thumb." JavaScript is reasonably suited to servers written around event loops like Hubot. But as a general purpose programming language I think it's reasonable to argue that it's pretty bad compared to alternatives like Erlang and Go in the space it's used in. Also debugging is a pain in the ass because stack traces aren't useful at all. (That's not limited to JS but it does make my life harder.) In any event, we're talking about a telemetry collector, which is generally a trivial piece of code that simply doesn't need whatever benefits JS purports to provide.
deleted 11y ago
[deleted]
pritambaral 11y ago
Not parent, but IMHO requiring nodejs is heavy for something as simple as data collection. I wouldn't mind if plugins (sufficiently complex ones) can be written in nodejs, but requiring nodejs is too much. I'd prefer something like Lua (and C, of course), or even Python (which is installed on most systems anyway, but still too heavy).

otterley 11y ago

Because it's just not necessary, and meanwhile most experienced SREs and performance engineers are imperative programmers. We don't see the benefits of using JavaScript on our servers, and that's rather putting it mildly. Also JavaScript doesn't have a 64-bit integer type, which is absolutely necessary to properly support large counters. There are workarounds but the fact that you need one is ridiculous. Many of us believe that the only reason one would want to use JavaScript is because you're doing browser programming and therefore you have no other choice.

NietTim 11y ago
Non of what you just said was an actual argument against node.js though. All you said was "Well, we don't like it" Why don't you like it? What's wrong with it? What would be better?
- jjnoakes 11y ago
  > All you said was "Well, we don't like it" That's not what I see.
- otterley 11y ago
  It's not about Node per se; it's about JavaScript. System telemetry collectors don't benefit much from languages built around event loops. Many of us already know C, Bourne Shell and Python and probably another scripting language and all of those can get telemetry data off systems and into an event bus or metrics aggregator quickly enough. Adding JavaScript adds complexity without giving us significant new functionality. Now the data collector (gathering metrics from many senders for aggregation and storage) is a different story. I've seen them written in JavaScript but the 64-bit counter difficulties would rule it out for me were I to implement one again.
- crdoconnor 11y ago
  It's a weakly typed language and it exhibits all kinds of bizarre not-very-well-thought out behaviors. c.f. the disaster with npm a few days ago. These problems are particularly pernicious for large scale apps - which this isn't, currently, but probably aspires to be one day. Any strongly typed language would be better (python, go, ruby, etc.).
  - geofft 11y ago
    Can you explain how the npm incident is related to typing? I am an advocate of strong typing and love seeing it be the answer to all sorts of problems (e.g. concurrency), but I'm not understanding the connection here.
    - crdoconnor 11y ago
      That wasn't related to js's weak typing and I didn't say that it was, but it's indicative of the types of other problems that will occur.
illumin8 11y ago
I've seen plenty of server-based applications written in node.js. Just because javascript used to be pigeon-holed into front-end doesn't mean it can't perform well on server applications. A good example of a node.js app that is purely server side is Hubot, a chat bot created at Github and widely used in Slack, HipChat, IRC, etc. I'm sure there are thousands of others out there, and I don't believe being written in Javascript gives them any fundamental disadvantage to server applications written in Python, Java, C++, or any other language.
- pritambaral 11y ago
  For systems programming though? Running on a server is not the only similarity you should be looking at.
- otterley 11y ago
  "If you have a hammer, everything starts to look like your thumb." JavaScript is reasonably suited to servers written around event loops like Hubot. But as a general purpose programming language I think it's reasonable to argue that it's pretty bad compared to alternatives like Erlang and Go in the space it's used in. Also debugging is a pain in the ass because stack traces aren't useful at all. (That's not limited to JS but it does make my life harder.) In any event, we're talking about a telemetry collector, which is generally a trivial piece of code that simply doesn't need whatever benefits JS purports to provide.

deleted 11y ago

[deleted]

pritambaral 11y ago

Not parent, but IMHO requiring nodejs is heavy for something as simple as data collection. I wouldn't mind if plugins (sufficiently complex ones) can be written in nodejs, but requiring nodejs is too much. I'd prefer something like Lua (and C, of course), or even Python (which is installed on most systems anyway, but still too heavy).