←back to thread

Skeptical of rewriting JavaScript tools in "faster" languages

(nolanlawson.com)
160 points todsacerdoti | 1 comments | 20 Oct 24 21:25 UTC | HN request time: 0s | source
Show context
steve_adams_86 ◴[21 Oct 24 08:23 UTC] No.41901887[source]▶
I’ve written quite a bit of tooling in JS, and I genuinely enjoy the language, but I feel like Rust and Go are a godsend for these types of tools. I will sometimes prototype with TypeScript, but if something requires massive concurrency and parallelism, it’s unlikely I’ll stick with it.

I wonder if the author would feel differently if they spent more time writing in more languages on tooling like this. My life got a lot easier when I stopped trying to write TypeScript everywhere and leveraged other languages for their strengths where it made sense. I really wanted to stick to one language I felt most capable with, but seeing how much easier it could be made me change my mind in an instant.

The desire for stronger duck typing is confusing to me, but to each their own. I find Rust allows me to feel far, far more confident in tooling specifically because of its type system. I love that about it. I wish Go’s was a bit more sane, but there are tons of people who disagree with me.

replies(5): >>41902484 #>>41904308 #>>41904349 #>>41904569 #>>41905026 #
1. romwell ◴[21 Oct 24 15:09 UTC] No.41905026[source]▶
>The desire for stronger duck typing

That's what C++ templates always have been, and got way, way tighter with concepts circa C++23.

Rust's traits are also strong duck typing if you squint a little.

The idea in both cases is simple: write the algorithm first, figure outwhat can go into it later — which allows you to write the code as if all the parts have the types you need.

But then, have the compiler examine the ducks before the program runs, and if something doesn't quack, the compiler will.