8 ms·

Is this based on benchmarks? I don't have any, but I can do a clean compile of 8000 java classes (> 2 million lines) in 3 minutes on my underpowered Mac mini.

Is this based on benchmarks? I don't have any, but I can do a clean compile of 8000 java classes (> 2 million lines) in 3 minutes on my underpowered Mac mini. I wouldn't expect Rust would ever be as fast to compile, even if it weren't a younger language, because Rust is doing compile time optimization that Java defers until runtime. And that's ok: there may be times what Java does is better, but there are also times it's worse.

vvanders 9y ago
Mostly gut feeling :). To be fair my javac comparison with with Gradle + Android Studio layered on top so it may be a bit slanted in favor of Cargo/Rust. That said I've never seen a Java build environment that I'd call 'snappy'.
- fnord123 9y ago
  Maven takes a long long time to start up, but once it's ready, javac is pretty quick. Some Rust projects are very quick to build; but some are astonishingly slow to build. e.g. lalrpop is unusably slow (~15mins to build on 2014 Macbook Air). I think the place here performance breaks down is liberal use of generic types in functions. e.g. AsPath<T> and AsRef<T>, etc.) where the compiler creates the function for all the different types and then tries to collapse them again later on. So one rules of thumb is to only use those in the public APIs and convert the type so it can be passed around without generics internally within a module. Or maybe that's just me trying to do some `cargo cult` heuristics (haha! puns!)
  - wtetzner 9y ago
    > Or maybe that's just me trying to do some `cargo cult` heuristics (haha! puns!) I always thought `cargo new` should have been called `cargo cult`.
- pjmlp 9y ago
  So better try again with straight javac, Ant and Maven. Gradle sucks big time, why do you think Google still does talks letting angry Android developers that Gradle + Android Studio will some day be as fast as Ant + Eclipse? http://androidbackstage.blogspot.de/2017/04/episode-64-gradleweiss.html http://androidbackstage.blogspot.de/2017/04/episode-64-gradl... https://www.youtube.com/watch?v=BKRK4SvMtRk https://www.youtube.com/watch?v=BKRK4SvMtRk The Android Gradle plugin being slow as molasses is a typical discussion theme at Google IO since it was introduced. Being partially written in Groovy also doesn't help.
  - lenkite 9y ago
    Take a look at the Kobalt build system http://beust.com/kobalt/home/index.html http://beust.com/kobalt/home/index.html
bluejekyll 9y ago
`cargo check` is pretty darn fast, and that's pretty much all you need while developing. I'd say it's generally 50% faster than a standard compile (not benchmarking, just a gut feeling). On top of that `cargo watch 'test'`, runs fine on a 100kloc project, way better than my personal experience with Java. Now, when Rust compiles all dependencies from the ground up it is really slow, but that's only generally one time during development or after updating dependencies. For me, the compile times are fine, and the end product generally doesn't need as much debugging as an interpreted language that requires no compilation at all, or has minimal validation, prior to running.
- flukus 9y ago
  That assumes you're using cargo and it's "fuck the package manager" approach.
  - jfoutz 9y ago
    But that's how languages do it. CPAN was my first experience with it. At development time, I need weird libraries.i hope they're ready by release time. Package managers are awesome, but sometimes, fuck them.
    - flukus 9y ago
      Higher level languages get away with it because they are platforms in their own right, rust is meant to be a systems level language. I expect a systems level language to work with the system, not against it.
      - pjmlp 9y ago
        So do you enjoy packaging code for every single OS, in its own specific way?
        flukus 9y ago
        Of course I don't, but I don't think it's an important aspect in any case. I think the user experience is more important than the developer experience. Using shared libraries that are likely already in memory provides a better user experience because it's faster, more stable, more secure and uses less memory. The cargo approach will end up with windows/node level bloat where every app bundles half an OS.

vvanders 9y ago

Mostly gut feeling :). To be fair my javac comparison with with Gradle + Android Studio layered on top so it may be a bit slanted in favor of Cargo/Rust. That said I've never seen a Java build environment that I'd call 'snappy'.

fnord123 9y ago
Maven takes a long long time to start up, but once it's ready, javac is pretty quick. Some Rust projects are very quick to build; but some are astonishingly slow to build. e.g. lalrpop is unusably slow (~15mins to build on 2014 Macbook Air). I think the place here performance breaks down is liberal use of generic types in functions. e.g. AsPath<T> and AsRef<T>, etc.) where the compiler creates the function for all the different types and then tries to collapse them again later on. So one rules of thumb is to only use those in the public APIs and convert the type so it can be passed around without generics internally within a module. Or maybe that's just me trying to do some `cargo cult` heuristics (haha! puns!)
- wtetzner 9y ago
  > Or maybe that's just me trying to do some `cargo cult` heuristics (haha! puns!) I always thought `cargo new` should have been called `cargo cult`.
pjmlp 9y ago
So better try again with straight javac, Ant and Maven. Gradle sucks big time, why do you think Google still does talks letting angry Android developers that Gradle + Android Studio will some day be as fast as Ant + Eclipse? http://androidbackstage.blogspot.de/2017/04/episode-64-gradleweiss.html http://androidbackstage.blogspot.de/2017/04/episode-64-gradl... https://www.youtube.com/watch?v=BKRK4SvMtRk https://www.youtube.com/watch?v=BKRK4SvMtRk The Android Gradle plugin being slow as molasses is a typical discussion theme at Google IO since it was introduced. Being partially written in Groovy also doesn't help.
- lenkite 9y ago
  Take a look at the Kobalt build system http://beust.com/kobalt/home/index.html http://beust.com/kobalt/home/index.html

bluejekyll 9y ago

`cargo check` is pretty darn fast, and that's pretty much all you need while developing. I'd say it's generally 50% faster than a standard compile (not benchmarking, just a gut feeling). On top of that `cargo watch 'test'`, runs fine on a 100kloc project, way better than my personal experience with Java. Now, when Rust compiles all dependencies from the ground up it is really slow, but that's only generally one time during development or after updating dependencies. For me, the compile times are fine, and the end product generally doesn't need as much debugging as an interpreted language that requires no compilation at all, or has minimal validation, prior to running.

flukus 9y ago
That assumes you're using cargo and it's "fuck the package manager" approach.
- jfoutz 9y ago
  But that's how languages do it. CPAN was my first experience with it. At development time, I need weird libraries.i hope they're ready by release time. Package managers are awesome, but sometimes, fuck them.
  - flukus 9y ago
    Higher level languages get away with it because they are platforms in their own right, rust is meant to be a systems level language. I expect a systems level language to work with the system, not against it.
    - pjmlp 9y ago
      So do you enjoy packaging code for every single OS, in its own specific way?
      - flukus 9y ago
        Of course I don't, but I don't think it's an important aspect in any case. I think the user experience is more important than the developer experience. Using shared libraries that are likely already in memory provides a better user experience because it's faster, more stable, more secure and uses less memory. The cargo approach will end up with windows/node level bloat where every app bundles half an OS.