| |
| ▲ | pcwalton a day ago | parent | next [-] | | It remains to be seen whether you can have a useful borrow checker on top of a simpler type system (at least, a type system that's significantly simpler so as to meaningfully reduce compile times). I have my doubts, personally. | | |
| ▲ | rikarendsmp a day ago | parent | next [-] | | Relax runs the borrow checker 'lazily' so it already starts your app whilst the borrow checker runs asynchronous. It's jokingly called 'gandalf' because I think It halts the JIT if it finds a problem. | |
| ▲ | brabel 14 hours ago | parent | prev [-] | | The Goose Programming Language demonstrates an alternative approach that is super simple while being as safe as Rust, or even more if you believe the claim that it doesn’t need unsafe in the language to do anything, unlike Rust. |
| |
| ▲ | treyd a day ago | parent | prev | next [-] | | The borrowchecker is not the source of the bulk of the language's slowness. It takes a fairly small fraction of the total time, I think I remember the number was 5%-15% depending on the project. The majority of time is spent between the trait solver and LLVM optimization passes. There is work being done to improve the trait solver and to produce more efficient LLIR code from the get-go (so LLVM has less to optimize). | | |
| ▲ | packetlost a day ago | parent | next [-] | | Also procmacros add quite a bit of overhead to builds | | |
| ▲ | norman784 10 hours ago | parent [-] | | Note that is so, because macros can have side effects, that was an oversight of Rust design, not having a way to have pure and impure procmacros (macro rules are pure) | | |
| ▲ | packetlost 10 hours ago | parent [-] | | It's also worse because the procmacros are themselves Rust and get compiled with the same parameters as the overall build, so if you're running a debug build the procmacros are running as debug binaries. |
|
| |
| ▲ | dboreham a day ago | parent | prev [-] | | You always know you're in trouble when you're profiling the compiler and you're just a user of that compiler... |
| |
| ▲ | antonvs 10 hours ago | parent | prev | next [-] | | > There are plenty of languages that compile very fast. Not that many in the same systems programming space. If you compare Rust build times to C++, the difference is not as great. Put another way, for people writing something like web services, Rust build times can seem terrible, given the available competition. But if you're writing the kind of code that you would typically reach for C++ for, you're likely to have a different perspective. | |
| ▲ | nu11ptr a day ago | parent | prev | next [-] | | The Rust compiler, while not extremely fast, is not extremely slow either. As an example, my toy compiler is 130K LoC of Rust and compiles in under 7 seconds on a cold build on my M5 Max. An incremental build is nearly instant. So then why is it that so many projects have a minute compile time with far fewer LoC? The answer: dependencies (My compiler has virtually none, intentionally) Rust has a very small stdlib, so you are forced to bring in dependency crates, and not just a few. Many programs have 50-100 or more, and they all have dependencies, and so on. Contrast with Go where it has a culture of few dependencies, and those project have few dependencies. Your Rust compiler is doing a lot more work for what appears to be the same program as in other langs, but ultimately is a lot more code (typically). To make matters worse, cargo does a decent job of parallelizing the builds, but it can only do so a) at the crate level b) only as much as the dependency graph allows. | | |
| ▲ | Twirrim a day ago | parent | next [-] | | I love the language, but I'm still not convinced by Rust's skinny stdlib approach. I appreciate not wanting to end up like python where they're having to remove stuff from the stdlib because it has too many batteries and bitrot is a problem, but there's surely a happy-medium somewhere along the line. I don't write much Go but it seems like it has a good balance when I do. It may be a bad example, but even in rust generating a random number involves pulling in 6ish crates └── rand v0.10.3
├── chacha20 v0.10.2
│ ├── cfg-if v1.0.5
│ └── rand_core v0.10.1
├── getrandom v0.4.3
│ ├── cfg-if v1.0.5
│ ├── libc v0.2.191
│ └── rand_core v0.10.1
└── rand_core v0.10.1
| | |
| ▲ | coderenegade a day ago | parent | next [-] | | The skinny stdlib is always a mistake imo, because if you don't provide it, somebody else will, and it's unlikely to be as nice to work with for your users as a standard library implementation. In the case of C++, for instance, this lead to the boost era. For all of Python's warts, it at least makes everyday structures and operations you might want to use fairly painless, and it keeps expression fairly standardized. Leave external libraries to build things that are actually interesting, rather than scaffolding and infrastructure that the language vendor is better off providing. | | |
| ▲ | imtringued 15 hours ago | parent [-] | | >The skinny stdlib is always a mistake imo, because if you don't provide it, somebody else will, and it's unlikely to be as nice to work with for your users as a standard library implementation. In the case of C++, for instance, this lead to the boost era. I disagree, skinny stdlib is an option that you intentionally leave open. You let the ecosystem around you explore good solutions first before you commit early or exhaust the air in the room for better ideas. | | |
| |
| ▲ | nu11ptr a day ago | parent | prev | next [-] | | Agreed. I would like to see an extended stdlib of sorts form perhaps taking inspiration from Go or Python. I think it is too late to shim it into the language itself, but it could be like an alternative stdlib of sorts (more like an addendum, not replacing what is already in stdlib). The bonus is it would be precompiled for all platforms so even if doing a cold compile, it just is linked. | |
| ▲ | cmrdporcupine a day ago | parent | prev [-] | | 100% this. Was playing with the odin language recently (https://odin-lang.org/) and was very pleased at what was included in the std lib while still being a good viable systems PL. And delightful fast compilation time. That said, I missed the borrow checker. | | |
| ▲ | pjmlp a day ago | parent [-] | | And a certain Object Pascal feel to it, while the provided library is not on the same vein as MacApp, Turbo Vision, or OWL. |
|
| |
| ▲ | mpweiher 17 hours ago | parent | prev | next [-] | | > The answer: dependencies Assuming for a second this is true. Why? We solved separate compilation a few decades ago. So if those dependencies are causing your compile times to spiral out of control, then something is wrong. For example unlearning separate compilation, as we seem to have done. | |
| ▲ | shikck200 21 hours ago | parent | prev [-] | | > M5 Max Fucking lol. I have an almost decade-old laptop and compile projects way faster. Ocaml and Go both compile 100K LOC projects under 1sec. | | |
| ▲ | pjmlp 19 hours ago | parent [-] | | That is what I always point out, not everyone on the planet can afford the kind of hardware that makes Rust builds usable, thus it is a potential loss of users that are then pushed into adopting languages that are friendlier in hardware requirements. And to make a point, the Turbo Pascal 5.5 compilation times, from 1989 marketing brochure > Fast! Compiles 34 000 lines of code per minute This was measured on a IBM PS/2 Model 60, a computer model from 1987, with a 80286 running at 10 MHz, limited by 640 KB, with luck one would expand it up to 1 MB and use HMA, in what concerns using it with MS-DOS. You can get the brochure at https://archive.org/details/bitsavers_borlandtur5.5Brochure1... So one would expect that at very least for debug builds in 2026, one would always have blazing fast build times. Which is why languages like OCaml, Go, Zig, D, Delphi and co, are not doing something spectacular, rather pretty much what should be the norm, and unfortunately got sidetracked somehow. |
|
| |
| ▲ | imtringued 15 hours ago | parent | prev [-] | | The build times are long because of dependencies and complex but optional features in Rust. People should stop abusing the language. Some of my Rust projects compile faster than the time it takes JVM applications to start. Obviously, once the tests are compiled, the test suite with hundreds of tests finishes in less than one second, meanwhile the JVM tests might take 30 seconds. | | |
|
| |
| ▲ | shikck200 21 hours ago | parent | next [-] | | Rust's killer features is not "the borrow checker". That idea was just stolen from Cyclone. Rust is basically a semi ml kind of language in the c++ space. I dont see many "killer features" in rust outside the saner type system. Its basically a better language for software you write in C at the cost of horrible compile times. | | |
| ▲ | brabel 14 hours ago | parent [-] | | The killer feature is definitely memory safety in a systems programming language. That was pretty much thought impossible before Rust came along, and even today there is essentially no competition offering both memory safety and C performance, which requires no GC really. |
| |
| ▲ | LoganDark a day ago | parent | prev | next [-] | | The borrow checker is an example of a certain kind of reasoning that Rust benefits from. There's a reason a Lisp can be inspected and rewritten as the process runs, and it's the same thing that makes Rust difficult to rewrite in the same way. Not sure the exact term for it, but it's very easy to have profound nonlocal effects, for example with TAIT (type alias impl trait). | | |
| ▲ | wahern a day ago | parent | next [-] | | The borrow checker doesn't rely on interprocedural analysis. The function prototype provides all the information needed to maintain lifetime invariants across functions, so given static typing already then interprocedural borrow checking is effectively zero cost at compile time. (Cf. Intraprocedural, non-lexical borrow checking.) So borrow checking is no impediment to dynamically replacing function definitions. And it would be less of a headache for intraprocedural REPL but-for non-lexical semantics. But in a REPL you could always use an interpreter for running a function currently being edited, then compile it down once complete. REPLs are a headache for languages like Rust because of static typing generally, generics, trait semantics, etc. | |
| ▲ | pjmlp 19 hours ago | parent | prev [-] | | The reason is tooling matters, you can also do the same in C++, tools do exist. |
| |
| ▲ | Ar-Curunir a day ago | parent | prev [-] | | rustc is not really a one-shot program! Incremental computation is a big part of rustc ! |
|