←back to thread

160 points todsacerdoti | 2 comments | | HN request time: 0.001s | source
Show context
steve_adams_86 ◴[] 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. Vinnl ◴[] No.41904569[source]
"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.

replies(1): >>41905767 #
2. steve_adams_86 ◴[] No.41905767[source]
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.