> tsc isn't fast but it's fast enough to get the work done, the annoyance is there but it's objectively minimal.
For our small codebases, maybe. The tsc-in-Go announcement had VS Code compilation go from >120 seconds to ten.
For our small codebases, maybe. The tsc-in-Go announcement had VS Code compilation go from >120 seconds to ten.
If you're talking about bundling the entire app, 120 seconds down to 10 seconds is a great saving, but other bundlers can do it much faster already. Most people don't bother using TSC to bundle their code. I can understand why Microsoft might insist on using it, but it's not typical.
For type-checking the entire app, I would see that as akin to running all the unit tests. 120 -> 10 seconds is excellent, but not something that should be a constant bottleneck in your development workflow.
I can definitely see that 10x improvement being crucial on large teams (and/or LLM swarms) where the speed of the CI queue becomes a bottleneck.
But it's not too slow for most people.
Likewise, Rust may be slow enough to be painful for some big projects that need to often rebuild from-scratch in release mode, but that niche is definitely much smaller than the size of the “rust compiles too slowly” crowd on HN.
I gave Rust classes in university a few years back, and literally none of my students complained about slow build times. At this point it's much more of an internet meme than an actual pain point for most devs.
By the way, for most apps, rhe difference from an app we'd write in class is not as nearly as big as you'd expect: most of the code lies within dependencies anyway, and you need roughly the same amount of them in both cases.
Of course there are exceptions, apps that are tens of millions of LoCs exist, but it's not the majority.
(And they tend to be naturally split in multiple crates, which is the default workaround if a rust project takes too much time to compile).