Rust’s compile times are crippling and its type system is easily one of the most rigid of all type systems (lifetimes are part of the type!). The latter is one of Rust’s main selling points because it allows encoding business rules into affine types, but that’s very very far from flexible especially when compared to Typescript (or Python or Haskell and their many ways of polymorphism). Traits add an orthogonal axis of flexibility but they’re still limited by lifetimes (see async_trait and generic associated types and specialization).
“Flexible” means the range from gradual typing (‘any’) to Turing complete conditional types that can do stuff like string parsing (for better or for worse). Structural typing vs instanceof and so on.
There’s really no comparison between Typescript’s type system and Rust’s. It’s worth noting though that Typescript is a bolted on typesystem that has explicitly traded soundness for flexibility. That’s the real tradeoff between Rust and TS IMHO. Rust is sound and expressive but not flexible, while Typescript is expressive and flexible but not sound.
> “Flexible” means the range from gradual typing (‘any’) to Turing complete conditional types that can do stuff like string parsing (for better or for worse).
So the flexibility means one gets to pretend they are doing typing, but in reality they get to sprinkle the code with void casts, because expressing ideas is apparently hard? For better or worse, that is probably the main pillar Rust is designed on.
Also, some prominent projects migrated away from TypeScript to JSDoc type comments due to the transpile times in TypeScript. The type checking task takes the more time the more complex the type-level expressions are. Haskell can also take a long time to compile if you turn on a few extensions and move toward dependent types.
Rust compiles fast if your translation units don’t need too much macro expansion. You add something like Diesel, and you can call for the lunch break.
It’s also worth mentioning Scala with Scala Native and maybe Kotlin with Kotlin/Native. OpenJDK Project Panama FFM now gives a better FFI experiences than JNI.
> Rust’s compile times are crippling
It's kind of a meme here on HN but while Rust compilation times are indeed higher than I wished they were, calling them “crippling” is a massive exaggeration.
My daily driver is a mid-range desktop computer from 2018 and I regularly code on a laptop from 2012, and even then it's completely manageable: cargo check is nigh instant on both, incremental compilation in debug mode is more than fast enough and even incremental rebuild in release mode and full debug builds are OK-ish (especially since they don't happen as often as the other above). There's only full builds in release mode that are arguably slow in the 2012 laptop (though on the project where it's the biggest problem, the majority of the time is spent compiling a C++ dependency), but then again it's a very obsolete piece of hardware and this isn't supposed to happen more than every six week when you update your compiler toolchain.
I welcome you to try to work on a cxx-qt project to understand what crippling compile times look like.
I’m not memeing here, I’ve struggled with this issue on a variety of different projects since I first started using Rust seven years ago.
Everything about cxx-qt is wrong. The Rust ecosystem deserves better. Not QML. Not any markup-like things like Slint. No immediate mode. And definitely not GTK. So much wasted potential.
So... what do you think GUI on rust should look like?
This really depends on what you are working on. As an example, compiling the protobuf stuff can get insanely slow for some reason.
For any larger project I would recommend working with a cargo workspace to compile as little as possible on each check/test/run/build.
Then you can build a DAG of crates and stick e.g. the Protobuf stuff in its own separate corner where it only needs to be recompiled on full rebuilds or when you work on it.
Feels a bit shitty to have to resort to managing crates instead of modules simply due to the compile times, but it is what it is.
https://doc.rust-lang.org/cargo/reference/workspaces.html
Yeah, second that. This is just release management best practice.
And it makes total sense to me, it’s a way of organizing your dependency graph by the lifetimes of your components.
This will also simplify testing, development, and audit. You won’t need to recompile autogen schemas as often as the business logic implementation anyway. Depending on artifacts pushed through a release pipeline is even more reliable. You can QA everything in guaranteed isolation while keeping it conveniently a workspace monorepo.
If only someone had a way of automating this! Say perhaps using some kind of digital computer...
I wish rustc could automatically build a DAG of “smallest group of modules with cyclic references” and use that as a compilation unit, but that's unfortunately not the case so far and it won't until someone steps up to build such a system.
On compile time for Typescript: when projects have large unioned or conditional types, Typescript's compilation time isn't all that fast, and sometimes even slower than Rust, more often when Rust will be compiling incrementally (I write both Rust and Typescript extensively).
Worse, typescript may even run out of it's allocated memory sometimes.
Yeah
Go feels like C with training wheels.
Rust feels like riding a bike where one leg pedals the front wheel and another one pedals the back wheel, and you have one handlebar for each wheel as well and a very smart alarm system but it is very clunky to ride (and they tell you it's "flexible")
Pretty normal bike for those who used to C++ bikes before.
Yes, you pedal the C++ bike by squeezing the brake handles and brake by pedaling backwards
I feel like if Python’s lack of typing is going to be considered a drawback, then the solution needs to be true typing. Rust’s strict typing is an advantage, not a drawback.