3 ms·

> Maybe, maybe not, but there's no denying that faster feels nicer. Given finite developer time, spending it on improved optimization and code generation would

> Maybe, maybe not, but there's no denying that faster feels nicer. Given finite developer time, spending it on improved optimization and code generation would have a much larger effect on my development. Even if builds took twice as long.

hu3 1y ago
Can't agree. Iteration speed is magical when really fast. I'm much more productive when I can see the results within 1 or 2 seconds.
- timschmidt 1y ago
  > I'm much more productive when I can see the results within 1 or 2 seconds. That's my experience today with all my Rust projects. Even though people decry the language for long compile times. As I said, hot builds, which is every build while I'm hacking, are exactly that fast already. Even on the large projects. Even on my 4 year old laptop. On a hot build, build time is dominated by linking, not compilation. And even halving a 1s hot build will not result in any noticeable change for me.
  - ahartmetz 1y ago
    Linking? There are two relatively simple improvements: using a faster linker and not using static helper libraries (dependency crates...) in debug builds. I understand that Rust has basically no useful support for deploying shared libraries, but they could still be useful to get faster debug builds. Well, I've never tried it, but it works well in C++. Dynamically linked binaries typically take a few milliseconds longer to start, but also take seconds less to link.
    - timschmidt 1y ago
      > I understand that Rust has basically no useful support for deploying shared libraries Rust has excellent support for shared libraries. Historically they have involved downcasting to C types using the C ABI, but now there are more options like: https://lib.rs/crates/stabby https://lib.rs/crates/stabby https://lib.rs/crates/abi_stable https://lib.rs/crates/abi_stable and https://github.com/rust-lang/rfcs/pull/3470 https://github.com/rust-lang/rfcs/pull/3470
- pjmlp 1y ago
  Same here, Rust currently isn't the best tooling for UI or game development.

hu3 1y ago

Can't agree. Iteration speed is magical when really fast. I'm much more productive when I can see the results within 1 or 2 seconds.

timschmidt 1y ago
> I'm much more productive when I can see the results within 1 or 2 seconds. That's my experience today with all my Rust projects. Even though people decry the language for long compile times. As I said, hot builds, which is every build while I'm hacking, are exactly that fast already. Even on the large projects. Even on my 4 year old laptop. On a hot build, build time is dominated by linking, not compilation. And even halving a 1s hot build will not result in any noticeable change for me.
- ahartmetz 1y ago
  Linking? There are two relatively simple improvements: using a faster linker and not using static helper libraries (dependency crates...) in debug builds. I understand that Rust has basically no useful support for deploying shared libraries, but they could still be useful to get faster debug builds. Well, I've never tried it, but it works well in C++. Dynamically linked binaries typically take a few milliseconds longer to start, but also take seconds less to link.
  - timschmidt 1y ago
    > I understand that Rust has basically no useful support for deploying shared libraries Rust has excellent support for shared libraries. Historically they have involved downcasting to C types using the C ABI, but now there are more options like: https://lib.rs/crates/stabby https://lib.rs/crates/stabby https://lib.rs/crates/abi_stable https://lib.rs/crates/abi_stable and https://github.com/rust-lang/rfcs/pull/3470 https://github.com/rust-lang/rfcs/pull/3470
pjmlp 1y ago
Same here, Rust currently isn't the best tooling for UI or game development.