4 ms·

Absolutely, the compile times are the biggest drawback IMO. Everywhere I've been that built large systems in Rust eventually ends up spending a good amount of d

Absolutely, the compile times are the biggest drawback IMO. Everywhere I've been that built large systems in Rust eventually ends up spending a good amount of dev time trying to get CI/CD pipeline times to something sane. Besides developer productivity it can be an issue when you need a critical fix to go out quickly and your pipelines take 60+ minutes.

deleted 1y ago
[deleted]
lilyball 1y ago
Don't use a single monolithic crate. Break your project up into multiple crates. Not only does this help with compile time (the individual crate compiles can be parallelized), it also tends to help with API design as well.
- mixmastamyk 1y ago
  It compiles different files separately, right? With some exceptions for core data structures, it seems that if you only modified a few files in a large project the total compilation time would be quick no matter how slow the compiler was.
  - conradludgate 1y ago
    Sorta. The "compilation unit" is a single crate, but rustc is now also parallel, and LLVM can also be configured to run in parallel IIRC. Rust compile times have been improving over time as the compiler gets incrementally rewritten and optimised.
- Seattle3503 1y ago
  Every project I've worked on used a workspace with many crates. Generally that only gets you so far on large projects.
nicoburns 1y ago
If you have the money to throw at it, you can get a long way optimising CI pipelines just by throwing faster hardware at it. The sort of server you could rent for ~$150/month might easily be ~5x faster than your typical Github Actions hosted runner.
- Seattle3503 1y ago
  Yes, this is often the best "low-hanging fruit" option, but it can get expensive. It depends how you value your developer time.
- hobofan 1y ago
  Besides faster hardware, one of the main features (and drawbacks) you get with self-hosted runners is the option to break through build isolation, and have performant caches between builds. With many other build systems I'd be hesitant to do that, but since Cargo is very good about what to rebuild for incremental builds, keeping the cache around is a huge speed boost.
sethammons 1y ago
We have 60 minutes deploy pipelines and are in python. Just mentioning that since, in theory, we are not penalized for long compile times. Fast ability to quickly test and get feedback is mana from the gods in software development. Organizations should keep it right below customer satisfaction and growth as a driving metric.

deleted 1y ago

[deleted]

lilyball 1y ago

Don't use a single monolithic crate. Break your project up into multiple crates. Not only does this help with compile time (the individual crate compiles can be parallelized), it also tends to help with API design as well.

mixmastamyk 1y ago
It compiles different files separately, right? With some exceptions for core data structures, it seems that if you only modified a few files in a large project the total compilation time would be quick no matter how slow the compiler was.
- conradludgate 1y ago
  Sorta. The "compilation unit" is a single crate, but rustc is now also parallel, and LLVM can also be configured to run in parallel IIRC. Rust compile times have been improving over time as the compiler gets incrementally rewritten and optimised.
Seattle3503 1y ago
Every project I've worked on used a workspace with many crates. Generally that only gets you so far on large projects.

nicoburns 1y ago

If you have the money to throw at it, you can get a long way optimising CI pipelines just by throwing faster hardware at it. The sort of server you could rent for ~$150/month might easily be ~5x faster than your typical Github Actions hosted runner.

Seattle3503 1y ago
Yes, this is often the best "low-hanging fruit" option, but it can get expensive. It depends how you value your developer time.
hobofan 1y ago
Besides faster hardware, one of the main features (and drawbacks) you get with self-hosted runners is the option to break through build isolation, and have performant caches between builds. With many other build systems I'd be hesitant to do that, but since Cargo is very good about what to rebuild for incremental builds, keeping the cache around is a huge speed boost.

sethammons 1y ago

We have 60 minutes deploy pipelines and are in python. Just mentioning that since, in theory, we are not penalized for long compile times. Fast ability to quickly test and get feedback is mana from the gods in software development. Organizations should keep it right below customer satisfaction and growth as a driving metric.