upvote

points

by Capricorn24814 hours ago |
comments
upvoteby pjmlp3 hours ago|
next
[-]
Haskell, Standard ML and OCaml have the tools for faster development workflows, or going for lunch while producing an optimised build.

It is a matter of priorities.

reply
upvoteby christophilus4 hours ago|
prev|
next
[-]
But there's not really a great reason for the long build times. There are plenty of languages that compile very fast. The Rust borrowchecker isn't the source of the bulk of the slowness. It seems to be a combination of language design (e.g. they didn't design it for fast compile times from the start), and implementation decisions. It does seem like there's room for a Rust-like language with Go-like tooling, standard lib, and a focus on development speed.
reply
upvoteby pcwalton3 hours 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.
reply
upvoteby rikarendsmp1 hours ago|
parent|
[-]
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.
reply
upvoteby treyd2 hours 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).

reply
upvoteby nu11ptr2 hours ago|
parent|
prev|
[-]
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.

reply
upvoteby Twirrim4 minutes ago|
parent|
[-]
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
reply
upvoteby faresahmed4 hours ago|
prev|
[-]
I beg to differ. It's not that Rust is completely different from Lisp. PL writers get so caught up with their 'killer feature' which in the case of Rust is the borrow checker, that they completely abandon the other 50% which is the environment.

If we stopped treating the compiler as a one-shot program, we could theoretically shorten this edit-build-test loop by 99%.

reply
upvoteby Ar-Curunir1 hours ago|
parent|
next
[-]
rustc is not really a one-shot program! Incremental computation is a big part of rustc !
reply
upvoteby LoganDark4 hours ago|
parent|
prev|
[-]
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).
reply
upvoteby wahern4 hours ago|
parent|
[-]
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.
reply