Skeptical of rewriting JavaScript tools in "faster" languages

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.

I also though rewrites of JS projects were only in part motivated by perf gain. Sure they were the most advertised benefits of the rewritten tools, as that communicates a benefit for the users of those tools.

> I find Rust allows me to feel far, far more confident in tooling specifically because of its type system.

Usually the JS projects become really hard to work on the growing up. Good JS needs a lot of discipline on the team of devs working on it: it get messy easily and refactoring becomes very hard. Type systems help with that. TypeScript helps, but only so much... Going with a languages that both has a sound type system (like Rust) and allows lots of perf improvements (like Rust) becomes an attractive option.

> The desire for stronger duck typing is confusing to me, but to each their own

I really like duck typing when I'm working on small programs - under 10,000 lines of code. Don't make me worry about stupid details like that, you know what I mean so just do the $%^#@ thing I want and get out of my way.

When I work with large programs (more than 50k lines of code - I work with some programs with more than 10 million lines and I know of several other projects that are much larger - and there is reason to believe many other large programs exist where those who work on them are not allowed to talk about them) I'm glad for the discipline that strong typing forces on me. You quickly reach a point in code where types save you from far more problems than their annoyance costs.

I just skimmed the article but the author had a statement about JS being "working class" in that it didn't enforce types and that he dislikes TS for that reason. Rust is completely anathema to that attitude, you have to make a LOT of decisions up front. People who don't see the value in a compiler are never going to like working in Rust. The author is completely satisfied with optimizing hacks in the toolchain.

> you know what I mean just do the $%^#@ thing I want

Yeah, it's just that about 10k LoC, as I've also noticed, you don't actually know what you yourself mean! It's probably because such amount of code is almost never written in one sitting, so you end up forgetting that e.g. you've switched, for this particular fields, from a stack of strings to just a single string (you manage the stacking elsewhere) and now your foo[-1] gives you hilarious results.

"Skeptical" doesn't mean completely against their usage. From the author in the comment section:

> “Embarrassingly parallel” tasks definitely make a lot of sense to do in Rust.

>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.

Types in the end are contacts you make with yourself, enforced by the compiler.

A weak type system gives you the freedom to trick yourself.

I don't feel it's a feature.

I noticed that, and I was left kind of confused. My experience might be limited, but operating on thousands of files and performing multiple reads or writes on them over and over seems exactly like the type of thing a lot of JS tooling does, so I’m not really sure where the author decides that JS is no longer the right fit. I don’t see why that doesn’t dispel skepticism right off of the bat.

A language that goes from prototype-quality (duck typing, dynamic, and interpreted) to strict static compile checks would be nice.

I can’t think of any in the mainstream, however.

Isn't that TypeScript or more generically "type hints" in other languages? If all you care about is that your program is valid for some gradually increasing subset of your code at compile time then these work great.

i don't do javascript, but I know from experience adding const to c++ is impossible I expect the similar for types

I was envisioning a system or some other compiled language, but you’re right. I overlooked Typescript and it indeed comes close.