Hacker News Reader

> But if they change a few lines in the actual project and compile again it would be near instant.

If it’s a big project and the lines you are changing are in something that is being used many other places then the rebuild will still take a little while. (30 seconds or a minute, or more, depending on the size of the project.)

Likewise, if you work on things in different branches you may need to wait more when you switch branch and work on something there.

Also if you switch between Rust versions you need to wait a while when you rebuild your project.

I love Rust, and I welcome everything that is being done to bring the compile times down further!

> (30 seconds or a minute, or more, depending on the size of the project.)

I'm working on a largeish modern java project using gradle, and this sounds great... Every time I start my server it takes 40 seconds just for gradle to find out that all the sub projects are up to date, nothing has been changed and no compilation is necessary...

Yeah, even Maven seems much faster than Gradle, even on a clean build.

Neither are especially fast though.

I am not discouraging efforts to make compile times faster. However, I also see a lot of things that would really make Rust soar not being worked on, like syntax quality of life reworks that get complex under the hood being dropped, partially complete features with half baked PRs, IDE tooling and debugging support, interface-types and much of the momentum behind wasm, async traits and the sorely lacking async_std, etc. It seems like every time I dive into something moderately complex I start hitting compiler caveats with links to issues that have been open for 5 years and a bunch of comments like "what's the status of this can we please get this merged?". It can ever so slightly give one the impression that the rust community has decided that the language is mature and the only thing missing is faster compile times.

> "what's the status of this can we please get this merged?"

Having written Rust professionally for a number of years, this didn't happen too much. Where it did it was stuff like "yeah you need to Box the thing today", which... did not matter, we just did that and moved on.

> It can ever so slightly give one the impression that the rust community has decided that the language is mature and the only thing missing is faster compile times.

That is generally my feeling about Rust. There are a few areas where I'd like to see things get wrapped up (async traits, which are being actively worked on) but otherwise everything feels like a bonus. In terms of things that made Rust difficult to use, yeah, compile times were probably the number one.

There are a few more fundemental missing pieces for me:

- It's impossible to describe a type that "implements trait A and may or may not implement trait B"

- It's impossible to be generic over a trait (not a type that implements a trait, the trait itself)

> It's impossible to describe a type that "implements trait A and may or may not implement trait B"

How is this different from just describing a type that only "implements trait A" ?

It would allow you to call a function to check for trait B and downcast to "implements trait A and B" in the case that it does implement the trait.

I’m still learning the language but couldn’t you use an enum containing two types to accomplish the same thing?

You can if you know all of the possible types in advance. But if you want to expose this as an interface from a library that allows users to provide their own custom implementation then you need to use traits.

It seems like a way to ask "Can this thing implement X and if so how?" from say the Any trait would be what you want here, I have no idea how hard that would be to deliver but I also don't see how the previous trait thing is relevant, like, why do we need to say up front that maybe we will care whether trait B is implemented?

> - It's impossible to describe a type that "implements trait A and may or may not implement trait B"

So, specialization? Or something else? I haven't found a need for specialization. I remember when I came from C++ I had a hard time adjusting to "no specialization, no variadics" but idk I haven't missed it in years.

> - It's impossible to be generic over a trait (not a type that implements a trait, the trait itself)

Not sure I understand.

> So, specialization?

Basically yes. But that works with dynamic dispatch (trait objects) as well as static dispatch (generics).

> Not sure I understand.

A specific pattern I'd like to be able to represent is:

    trait AlgorithmAInputData {
      ...
    }

    trait AlgorithmA {
      trait InputData = AlgorithmAInputData;
      ...
    }

    trait DataStorage<trait AlgorithmA> {
      type InputData : Algorithm::InputData;
      
      fn get_input_data() -> InputData;

    }

    fn compute_algorithm_a<Storage: DataStorage<AlgorithmA>>() {
      ...
    }

I mean this is what you have to do to access variables from an async block:

    let block = || {
        let my_a = a.clone();
        let my_b = b.clone();
        let my_c = c.clone();
        async move {
            // use my_a, my_b, my_c
            let value = ...

            Ok<success::Type, error::Type>(value)
        }
    }

And you can't use `if let ... && let ...` (two lets for one if) because it doesn't desugar correctly.

And error handling and backtraces are a beautiful mess. Your signatures look like `Result<..., Box<dyn std::error::Error>>` unless you use `anyhow::Result` but then half the stuff implements std::error::Error but not Into<anyhow::Error> and you can't add the silly trait impl because of language limitations so you have to map_err everywhere.

It's not just "oh throw a box around it and you're good". It's ideas that were introduced to the language when there was lots of steam ultimately not making it to a fully polished state (maybe Moz layoffs are partly to blame IDK). Anyway I love Rust and we use it in production and have been for years, but I think there's still quite a bit to polish.

I just want to reiterate how ridiculous the async block example is. You have to add a wrapper block that captures the variables and clones them because there is no way to specify how you want variables to be captured and what works in a normal block does not work in an async block. Then, because of some other language/compiler limitations, the return type of the block can't be inferred so you have to specify it manually even when you use the block in a context where it ought be inferred trivially. All this adds up to the existence of the block syntax being more complicated than just defining a function to do the same thing (when blocks are supposed to be a convenience so that you don't need a bunch of function with context pointers taking pointers to other functions everywhere like you do in C). Which you'd happily do but wait, you're trying to curry a function for a specific use case where you pass it to an async iterator function, so the signature is fixed and you have to use a block to curry because rust doesn't support that either. So you end up with the above just to say "run this piece of code concurrently for each element in a list.

> I mean this is what you have to do to access variables from an async block:

I am clearly missing some context because that code is needlessly complex. Are you just trying to show that you have to clone values that you hold a reference to if you want to move them? Because yes, you do. But your example also needlessly borrows them in the outer closure.

It’s not needless. I explained it a bit in my previous comment but it’s not worth diving into in this forum. To get an idea, consider scenarios along the lines of transforming a list of data in parallel using an async collection/iterator where all the futures are spawned and joined within the local scope of a single function. Hit me up in the Rust Discord if you want to chat about it and go into more details. Otherwise all I can really say is that I have encountered a few scenarios where this is necessary but shouldn’t be with improvements to the compiler.

> It can ever so slightly give one the impression that the rust community has decided that the language is mature and the only thing missing is faster compile times.

Is not the case, is that the features are now good enough and compile times is the one major, big, sore point.

So, if you compare Rust to X you can make a very good case until you hit:

"... wait, Rust is THAT SLOW TO COMPILE?"

":(. Yes"

For the branch-switching usecase you might get some milage out of sccache [1]. For local storage it's just one binary and two lines of configuration to have a cache around rustc, so it's worth testing out.

1: https://github.com/mozilla/sccache

Practically all Rust crates make heavy use of monomorphized generics, so every use of them in a new project is bespoke and has to be compiled on the spot. This is very different from how Go or Node work. You could compile the non monomorphic portions of a Rust crate into a C-compatible system library (with a thin, header-like wrapper to translate across ABI's) but in practice it wouldn't amount to much.

Some popular proc-macros could be pre-compiled and distributed as WASM, and it would be impactful, since they tend to bottleneck the early parts of a project build. However I don't think that could be made entirely transparent, because right now there's a combinatorial explosion of possible syn features. For now I avoid depending on syn/quote if I can.

Incremental builds are what matter to me. On my 1240p if I change one file and build it takes ~11s to build. Changing one file and running tests takes ~3.5. That's all build time the tests run in <100ms.

The incremental build performance seems to be really dependent on single-thread performance. An incremental build on a 2014ish Haswell e5-2660v3 xeon takes ~30s.

> On my 1240p if I change one file and build it takes ~11s to build. Changing one file and running tests takes ~3.5

`cargo test` and default `cargo build` use the same profile, so presumably the first number is referring to `cargo build --release`. Release builds deliberately forego compilation speed in favor of optimization. In practice, most of my development involves `cargo check`, which is much faster than `cargo build`.

> so presumably the first number is referring to `cargo build --release`

Both numbers are for debug builds. I don't know why `cargo test` is faster but I appreciate it.

Incremental release builds with `cargo build --release` are even slower taking ~35s on the 1240p.

i suspect most of that time is link time. Possibly the linker in use is not very parallel, and so linking one big executable with cargo build takes longer than many smaller test executable whose linking can actually be made parallel?

Using mold might help in this case.

https://github.com/rui314/mold

https://github.com/rust-lang/rust/issues/94347

Honestly, it should be impossible; in the absence of some weird configuration, cargo test does strictly more work than cargo build. :P Can you reproduce it and file a bug?

I contributed to Rome tools [1] and the build takes more than 1 min. This makes write-build-test loop frustrating... Such frustrating that I am hesitating to start a project in Rust...

My machine is 7yo. People tell me to buy a new one just for compiling a Rust project... That's ecologically questionable.

[1] https://rome.tools/

I'd say if you got a newer system, the SSD speed of the new system would be at least 2x of the old one. That's got to help at least the linking step substantially.

It's a few things:

1. Clean builds can happen more often than some may think. CI/CD pipelines can end up with a lot of clean builds - especially if you use ephemeral instances (to save money), but even if you don't it's very likely.

Even locally it can happen sometimes. For example, we used Docker to run builds. For various reasons the cache could get blown. Also, sometimes weird systemy things happen and 'cargo clean' fixes it, but you have to recompile from scratch. This can take 10+ minutes on a decent sized codebase.

2. On a large codebase even small changes can lead to long recompile times, especially if you want to run tests - cargo check won't be enough, you need to build.

Both, because some times a little change implies compiling the world due to configuration changes.

Also it is quite irritating sometimes seeing the same crate being compiled multiple times as it gets referenced from other crates.

Ideally Rust could use a dumb compilation mode (or interpreter) for change-compile-debug cycles, and proper compilation for release, e.g. Haskell and OCaml offer such capabilities on their toolchains.

I primarily develop the Virgil compiler in interpreted mode (i.e. running the current source on the stable binary's interpreter). Loading and typechecking ~45kloc of compiler source takes 80ms, so it is effectively instantaneous.

Yeah it works great having toolchains that support all possible execution models.

But you aren't on our timeline and haven't opted into our bullshit.

HTML+Js projects used to be testable with the load of a web page and that community has opt-in to long build times.

Most people are so far away from flow-state that they can't even imagine another way of being.

Mhm, maybe twas a bad idea to start learning React with ReasonML. Being used to compiles in milliseconds made the collision with TS at $Job extra painful.

cargo run is a command you'd generally use to actually get something running I guess. This is not going to be incremental development in many cases which focus on unit tests I guess.

FWIW cold builds (i.e., in docker with no cache) of cargo are much slower than go, hanging for a long time on refreshing cargo.io indexes. I don't know exactly what that is doing but I have a feeling it is implemented in a monolithic way rather than on-demand. Rust has had plenty of time to make this better but it is still very slow for cold cargo builds, often spending minutes refreshing the crates index. But Go misses easy optimizations like creating strings from a byte slice.

So it is what it is - Go makes explicit promises of fast compile times. Thanks to that, build scripts in go are pretty fast. Any language that doesn't make that explicit might be slow to compile and might run fast - that's totally fine and I would rather have two languages optimized to each case than one mediocre language.

Refreshing the crates index has gotten quite slow because it currently downloads the entire index, regardless of which bits you need. There's a trial of a new protocol happening now, due for release in March, that should speed this up (https://blog.rust-lang.org/inside-rust/2023/01/30/cargo-spar...)

You don't even need a separate language, there's already a "fast" compiler for Rust based on cranelift which is used in debug builds by default.

Cranelift is not used for debug builds by default. I think that's probably a goal (although I'm not actually 100% sure about that just because I'm not dialed into what the compiler team is doing). Even the OP mentions this:

> We were able to benchmark bjorn3's cranelift codegen backend on full crates as well as on the build dependencies specifically (since they're also built for cargo check builds, and are always built without optimizations): there were no issues, and it performed impressively. It's well on its way to becoming a viable alternative to the LLVM backend for debug builds.

And the Cranelift codegen backend itself is also clear about it not being ready yet: https://github.com/bjorn3/rustc_codegen_cranelift

(To be clear, I am super excited about using Cranelift for debug builds. I just want to clarify that it isn't actually used by default yet.)

The more immediate goal of "distribute the cranelift backend as a rustup component" has been making good progress and seems like it might happen relatively soon https://github.com/bjorn3/rustc_codegen_cranelift/milestone/...

That's amazing. Thanks for that update. Can't wait.

Great news.