[stymaar]

> But you have to compile Rust code to run it. You can run TypeScript code without type-checking it. That’s a massive difference in the development workflow.

And yet I'm waiting for TSC every day while almost never thinking about rustc…

> The new TSC, supposedly 10x faster, will be very pleasant to have but not as much of a game-changer as you might expect.

It will be very nice, but I don't expect it to be a game changer, tsc isn't fast but it's fast enough to get the work done, the annoyance is there but it's objectively minimal. Anything else is pointless internet language war.

> A 10x faster Rust compiler would be incredible.

For development? Not really, not for me at least. Against the endless rants about rustc's performance on HN, absolutely.

[msdz]

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

[iainmerrick]

"Compiling" is vague here; for TS I think you need to distinguish bundling from type-checking.

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.

[stymaar]

Exactly: tsc was “slow enough to be painful” in the context of the 2.5Mloc codebase of VScode.

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.

[DoesntMatter22]

Small apps in college are much different than huge apps in the real world

[stymaar]

Most people complaining about Rust being slow have never worked on anything close to a production app written in Rust.

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

[leecommamichael]

Speaking as someone who has also given courses at university teaching a programming language (Swift,) the students also do not know how fast computers are and that when their brand new super-computer lags and hitches for full seconds while coding it's pretty much "working as expected" to them. I haven't written Rust in a few years, but I remember it being remarkably similar to Swift both in API design ergonomics and compiler quality. I am open to this having changed, and I can appreciate @stymaar's frustration if it has done so drastically.