←back to thread

Skeptical of rewriting JavaScript tools in "faster" languages

(nolanlawson.com)
160 points todsacerdoti | 3 comments | 20 Oct 24 21:25 UTC | HN request time: 0s | source
Show context
sksxihve ◴[20 Oct 24 22:16 UTC] No.41898942[source]▶
> Whereas if it’s written in a native language, I’d need to check out the source code and compile it myself – a big barrier to entry.

Is it though? Rust/Zig/Go programs are pretty much all incredibly easy to checkout and compile, it's one of the big selling points of those languages. And at the end of the day how often are javascript developers fixing the tooling they use even when it's written in javascript?

I've always felt learning new languages give me not only new tools to use but shapes the way I think about solving problems.

replies(3): >>41898974 #>>41900897 #>>41901026 #
strken ◴[21 Oct 24 05:51 UTC] No.41901026[source]▶
It's definitely more of a pain to figure out rustup than to use the Node.js environment that's already installed. As noted in the article, you can quite literally go edit the source of your NPM packages without downloading or compiling a single thing.

Minor speedbumps like installing Rust don't stop me now, and probably don't stop you either, but they might have at the start of my career. You have to think about the marginal developers here: how many people are able to debug the simple thing who would be unable or unwilling to do it for the complicated thing? As you note, it's already quite rare to fix up one's tooling, so we can't afford to lose too many potential contributors.

I like learning new languages too, but not to the extent that I'd choose to debug my toolchain in Zig while under time pressure. This is something I've actually done before, most notably for FontCustom, which was a lovably janky Ruby tool for generating font icons popular about a decade ago.

replies(1): >>41901170 #
kstrauser ◴[21 Oct 24 06:19 UTC] No.41901170[source]▶
That’s not objectively true at all. I learned to use Rust long before I ever touched a Node setup, and the first time I wanted to run a JS app it took me a lot longer to figure out how to do it than it did to type `cargo run foo`.

Neither is easier than the other. Whichever one you already know will be easier for you, and that’s it.

replies(1): >>41901332 #
1. strken ◴[21 Oct 24 06:45 UTC] No.41901332[source]▶
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.

replies(1): >>41905323 #
2. ndriscoll ◴[21 Oct 24 15:38 UTC] No.41905323[source]▶
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.
replies(1): >>41908249 #
3. strken ◴[21 Oct 24 20:32 UTC] No.41908249[source]▶
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.