7 ms·

I find it interesting the article didn't mention compile times at all. Maybe since Oxide mostly works with embedded, they have few dependencies and their compil

I find it interesting the article didn't mention compile times at all. Maybe since Oxide mostly works with embedded, they have few dependencies and their compile times aren't very bad? I know my primary complaint after working with the language for about a year is that most projects take over a minute to build. Of course, it doesn't help that I keep moving onto larger projects xD but even small things like cargo-deadlinks and ripgrep take a while.

steveklabnik 6y ago
Funny story, I've actually been working on reducing our compile times lately. We had a conversation about this when I started the work, Brian just doesn't have a ton of sensitivity to this in general. I apparently have more :) There are details that matter, but on the codebase I work on, the current worst case (before the work I've been doing) means a compile takes a couple of minutes; more like two than five. I'm not sure how other codebases at the company are with regards to this, but I don't think they're super long. What I've been doing drops it to under thirty seconds in basically all cases. So yeah, it hasn't been a super pain for us specifically. We'll see as time goes on :)
- swsieber 6y ago
  Can you share approaches you've used to drop compile times? I'm wondering if there's anything beyond avoiding macros and generics.
  - steveklabnik 6y ago
    Honestly, it's stuff that's very specific to "writing a whole operating system in Rust," and so unlikely to be broadly useful. Basically, we were doing a lot of "spurious" re-builds of crates, because we were changing flags between compilations, and with some creativity, we didn't actually need to do that. If you're not building a bunch of things multiple different times in slightly different ways, it's not relevant. I will say that I recently discovered that putting a bunch of crates into a workspace is inherently slower than compiling them all separately, which is pretty surprising. I haven't dug into the exact reason yet, but it makes 4x the syscalls, so I'm assuming that it's checking every single dep of every single member and that has significant overlap. https://users.rust-lang.org/t/complex-build-advice/48779?u=steveklabnik https://users.rust-lang.org/t/complex-build-advice/48779?u=s... is probably closest to what I can currently say :)
    - boris 6y ago
      Quoting from the linked discussion: > The issue with Makefiles is that well, they're not portable. I'm on Windows, and 99% of this stuff Just Works really really nicely, but that means that "just use Make" isn't a real option. I love that Rust's tooling is so cross-platform, and this is just a final pain point. The problem is hard, but it's mostly about fiddly details. > I'm trying to figure out how good I can make this without throwing it all out and doing something else. If we never push Cargo's boundaries, it will never grow into being a good fit for these projects. The fundamental problem with Cargo is that it's not a general-purpose build system (like, say, make). It's a black box with a bunch of hooks for achieving certain common things that the black box itself doesn't handle. As a result, every time you step out of the "supported area", it will be yet another "final pain point" & "mostly about fiddly details". I agree make is not a good fit for a cross-platform project (nor is Meson, IMO, due to the Python dependency). But there are good (IMO) options in this area that meet your requirements (cross-platform, no external dependencies, etc). I can elaborate if you are interested.
      - steveklabnik 6y ago
        Sure, I'm always about hearing what works for folks. It is unlikely that we will switch away, but I'm always interested!
        boris 6y ago
        In your case it would be more like "adding" a make-like tool to tie all the steps together rather than "switching away" from anything. The tool I have in mind is buid2[1] (full disclosure: I work on the project). In this context you would be using it as a portable (and saner) make replacement (though we do have a Rust module in the works but that is geared more toward multi-language C/C++ and Rust builds). In fact, if you are interested, I am prepared to put my money where my mouth is and code up a demo/prototype for you (without any expectations that the result will be used). [1] https://build2.org https://build2.org
        steveklabnik 6y ago
- jynelson 6y ago
  > What I've been doing drops it to under thirty seconds in basically all cases. Is that for full builds or incremental? 30 seconds for a full build is reasonably fast (for rust, still feels slow IMO) but if that's incremental it sounds _painful_.
  - steveklabnik 6y ago
    Full builds, incremental is a few (like five or less) seconds.
reader_mode 6y ago
Out of curiosity - what hardware are you using ? I kept hearing this but recently started playing with it and haven't found it limiting probably because I haven't used it enough yet. Still I'm curious if this is a problem top of the line HW setup can alleviate.
- jynelson 6y ago
  This ended up too long for a post on hacker news: https://gist.github.com/jyn514/5476c7b6122a3cb18825e1b883c18a33 https://gist.github.com/jyn514/5476c7b6122a3cb18825e1b883c18... tl;dr if you have a lot of dependencies more cores help a lot. If not, you hit diminishing returns; top hardware _helps_ but it's still painful.
pitterpatter 6y ago
I recently updated some Rust code I wrote months ago (~April). In the 6 months since apparently its compile time went down from 6m30s to just around 4mins! I know there's been a focus on improving compile time and it's awesome to see in practise too.

steveklabnik 6y ago

Funny story, I've actually been working on reducing our compile times lately. We had a conversation about this when I started the work, Brian just doesn't have a ton of sensitivity to this in general. I apparently have more :) There are details that matter, but on the codebase I work on, the current worst case (before the work I've been doing) means a compile takes a couple of minutes; more like two than five. I'm not sure how other codebases at the company are with regards to this, but I don't think they're super long. What I've been doing drops it to under thirty seconds in basically all cases. So yeah, it hasn't been a super pain for us specifically. We'll see as time goes on :)

swsieber 6y ago
Can you share approaches you've used to drop compile times? I'm wondering if there's anything beyond avoiding macros and generics.
- steveklabnik 6y ago
  Honestly, it's stuff that's very specific to "writing a whole operating system in Rust," and so unlikely to be broadly useful. Basically, we were doing a lot of "spurious" re-builds of crates, because we were changing flags between compilations, and with some creativity, we didn't actually need to do that. If you're not building a bunch of things multiple different times in slightly different ways, it's not relevant. I will say that I recently discovered that putting a bunch of crates into a workspace is inherently slower than compiling them all separately, which is pretty surprising. I haven't dug into the exact reason yet, but it makes 4x the syscalls, so I'm assuming that it's checking every single dep of every single member and that has significant overlap. https://users.rust-lang.org/t/complex-build-advice/48779?u=steveklabnik https://users.rust-lang.org/t/complex-build-advice/48779?u=s... is probably closest to what I can currently say :)
  - boris 6y ago
    Quoting from the linked discussion: > The issue with Makefiles is that well, they're not portable. I'm on Windows, and 99% of this stuff Just Works really really nicely, but that means that "just use Make" isn't a real option. I love that Rust's tooling is so cross-platform, and this is just a final pain point. The problem is hard, but it's mostly about fiddly details. > I'm trying to figure out how good I can make this without throwing it all out and doing something else. If we never push Cargo's boundaries, it will never grow into being a good fit for these projects. The fundamental problem with Cargo is that it's not a general-purpose build system (like, say, make). It's a black box with a bunch of hooks for achieving certain common things that the black box itself doesn't handle. As a result, every time you step out of the "supported area", it will be yet another "final pain point" & "mostly about fiddly details". I agree make is not a good fit for a cross-platform project (nor is Meson, IMO, due to the Python dependency). But there are good (IMO) options in this area that meet your requirements (cross-platform, no external dependencies, etc). I can elaborate if you are interested.
    - steveklabnik 6y ago
      Sure, I'm always about hearing what works for folks. It is unlikely that we will switch away, but I'm always interested!
      - boris 6y ago
        In your case it would be more like "adding" a make-like tool to tie all the steps together rather than "switching away" from anything. The tool I have in mind is buid2[1] (full disclosure: I work on the project). In this context you would be using it as a portable (and saner) make replacement (though we do have a Rust module in the works but that is geared more toward multi-language C/C++ and Rust builds). In fact, if you are interested, I am prepared to put my money where my mouth is and code up a demo/prototype for you (without any expectations that the result will be used). [1] https://build2.org https://build2.org
        steveklabnik 6y ago
jynelson 6y ago
> What I've been doing drops it to under thirty seconds in basically all cases. Is that for full builds or incremental? 30 seconds for a full build is reasonably fast (for rust, still feels slow IMO) but if that's incremental it sounds _painful_.
- steveklabnik 6y ago
  Full builds, incremental is a few (like five or less) seconds.

reader_mode 6y ago

Out of curiosity - what hardware are you using ? I kept hearing this but recently started playing with it and haven't found it limiting probably because I haven't used it enough yet. Still I'm curious if this is a problem top of the line HW setup can alleviate.

jynelson 6y ago
This ended up too long for a post on hacker news: https://gist.github.com/jyn514/5476c7b6122a3cb18825e1b883c18a33 https://gist.github.com/jyn514/5476c7b6122a3cb18825e1b883c18... tl;dr if you have a lot of dependencies more cores help a lot. If not, you hit diminishing returns; top hardware _helps_ but it's still painful.

pitterpatter 6y ago

I recently updated some Rust code I wrote months ago (~April). In the 6 months since apparently its compile time went down from 6m30s to just around 4mins! I know there's been a focus on improving compile time and it's awesome to see in practise too.