3 ms·

Sorry, I think we might be talking across each other. I am saying from the perspective of someone who is already using a full Node.js environment, adding Rust m

by strken 2y ago

Sorry, I think we might be talking across each other. I am saying from the perspective of someone who is already using a full Node.js environment, adding Rust must necessarily increase complexity. I am taking this perspective because in the article we're talking about, the examples are exclusively JavaScript tooling like Rollup, Prettier, and ESLint, where the only people using those tools are JavaScript developers who are already running node. I have absolutely no interest in getting into a pissing match about whose language and ecosystem is better, and I in fact agree that the Rust tooling is less complicated than JS to start with. Nevertheless, the article is not about choosing either JS or Rust, it's about rewriting tools for working with JS in Rust, which necessarily makes you learn Rust on top of JS if you want to modify them.

ndriscoll 2y ago
That's true of any tools, and most tools that a developer uses (e.g. `grep`) are written in C, C++, or more recently Rust. Or if they want to understand the details of how some part of JS actually works, they'll need to delve into C++. So that requirement already exists.
- strken 2y ago
  In theory, yes; in practice, the native libraries and tools that most JS developers used to use were stable, widely used, and well tested. Think pg, hash functions, POSIX basics like cp if they didn't need to build on windows, V8 and node, or the OS itself. Practically speaking, the native libpq is less likely to break than its wrapper, which is in turn less likely to break than a newfangled npm package with relatively few users and low test coverage. I've dipped into V8 to understand a bug...exactly once. Even then, I didn't have to build it, which is good because building node and V8 from source used to take hours and probably still does. It's just a more stable piece of software, because Google has a very strong incentive to keep it that way. The thing is, there is no requirement to ever touch lower level languages in order to work as a JS developer. I would hazard a guess that most JavaScript developers don't. If you need to touch C++ in order to do certain things, then most JS developers will choose not to do them. Expanding the number of tools that can't be fixed by most of their own users has downsides.

by strken 2y ago

ndriscoll 2y ago

That's true of any tools, and most tools that a developer uses (e.g. `grep`) are written in C, C++, or more recently Rust. Or if they want to understand the details of how some part of JS actually works, they'll need to delve into C++. So that requirement already exists.

strken 2y ago
In theory, yes; in practice, the native libraries and tools that most JS developers used to use were stable, widely used, and well tested. Think pg, hash functions, POSIX basics like cp if they didn't need to build on windows, V8 and node, or the OS itself. Practically speaking, the native libpq is less likely to break than its wrapper, which is in turn less likely to break than a newfangled npm package with relatively few users and low test coverage. I've dipped into V8 to understand a bug...exactly once. Even then, I didn't have to build it, which is good because building node and V8 from source used to take hours and probably still does. It's just a more stable piece of software, because Google has a very strong incentive to keep it that way. The thing is, there is no requirement to ever touch lower level languages in order to work as a JS developer. I would hazard a guess that most JavaScript developers don't. If you need to touch C++ in order to do certain things, then most JS developers will choose not to do them. Expanding the number of tools that can't be fixed by most of their own users has downsides.