3 ms·

What the hell are you on about? Saying in it inherited them, just proves you probably didn't use either. While compilation times are longer than say Go, they

by Ygg2 5y ago

What the hell are you on about? Saying in it inherited them, just proves you probably didn't use either. While compilation times are longer than say Go, they definitely never felt too long, compared to say Java. But your comment around errors takes the cake. Like maybe, if you use some combination of macros expansion and traits it could get confused. But Rust errors are on par with Elm. They show the line, they show what went wrong and how to fix. This is a far cry from C++, where using even a bit of templates, results in unintelligible mess.

brabel 5y ago
> they definitely never felt too long, compared to say Java. Woah... now I am the one who have to ask: what the hell are you on about?? I work on Rust and Java projects, if you exclude running tests, Java compiles very very fast compared to pretty much any language... Rust is a lot slower to compile even on the much smaller projects I've worked on... in this post, a very small project (I think it's like 16,000 LoC, it's mentioned in the beginning) was taking over a minute even on hot builds... To get a build to take this long in Java you would need to have several million LoC! Even if you don't use something like Gradle to cache compilation units and just compile everything from scratch with javac.
- dmitriid 5y ago
  > Java compiles very very fast compared to pretty much any language In my experience C# compiles faster, but I still agree with you on all points.
  - yawaramin 5y ago
    Not surprising, considering the chief architect of C# is the guy famous for making Turbo Pascal.
  - emn13 5y ago
    Build times have regressed considerably the past few releases (at least for me). Not that I'm complaining about the tradeoffs, the new features are generally worth it. Whats most annoying is that it's often hard to tell which features are expensive until you've already wasted a bunch of time introducing em. But I've got to say I'm super jealous of the level of introspection the rust compiler allows here. I'd definitely be willing to change a few C# coding patterns in code bases I maintain to benefit build times, but as is, that's a really painful trial and error process. And sometimes you get lucky finding the root cause, but if you don't... well, it's not a great experience.
- Ygg2 5y ago
  And I've worked on large Java projects. Things that have like 420+ dependencies (spring boot + some other requirements). I timed the maven clean compile. And it takes around 2min.
  - brabel 5y ago
    Maven is very slow. Gradle and Bazel avoid doing wasteful things like Maven does so generally are a lot faster... if you want to know the speed of compiling Java you should just run `javac`, assuming Maven speed is Java compilation speed is far from correct even if a lot of projects still use Maven to build Java projects.
    - lenkite 5y ago
      Use Maven Daemon. (https://github.com/apache/maven-mvnd https://github.com/apache/maven-mvnd) . With Maven Daemon, traditional maven builds get a spectacular boost factor that put them ahead of Gradle. (Haven't tried Bazel though)
- fasterthanlime 5y ago
  Seems like you really need to finish reading the article: hot builds take 3s by the time I find the regression that caused pathological compile times.
  - yawaramin 5y ago
    You mean, by the time you split up the project into a bunch of tiny crates and mention: > I don't love how the dependency graph looks After adding this complexity to the project, yes, some of the crates are building in ~3s, if they are the only ones that needed to be rebuilt. Meanwhile, in a Java project there is none of this artificial crate splitting. Sure, Java projects have other nonsense, but they don't force you to split up projects into tiny pieces to get decent compile times.
    - estebank 5y ago
      It's a tradeoff: if you make the file the language's compilation unit, then you can't have "circular imports" to allow end users divide their code in an ergonomic manner with fewer "arbitrary" restrictions. We can argue all year on whether Rust settled on the right side of that trade-off.
      - yawaramin 5y ago
        I'm just surprised that no one has (to my knowledge, anyway) tried this even experimentally. Wouldn't the potential build speed improvement be worth at least trying out the one-file-per-crate strategy?
tialaramex 5y ago
Rust's errors are definitely the best of any language I've used. That's one reason it's nice to write Rust after a day fighting with SQL Server for example which seems to still think in 2021 that "Syntax error" is a reasonable diagnostic message. As to "How to fix it" however if you have lifetime confusion the error reported by the borrow checker probably isn't going to suggest refactoring your code with a design that makes sense even though that's likely the correct solution. It would be cute if the Rust compiler said "I think you want a Boxed collection of strings here to use the algorithm you're attempting, change how this is represented in all the related structs too, here's how:" but that's unrealistic and, more importantly, no other language is doing a better job here. While Rust makes the errors themselves look easy, the right suggestion is context sensitive anyway. In my AoC solutions, unwrap() was the correct answer anywhere the problem is "I have an Option or a Result and I wish that I didn't". Because it's AoC if I'm wrong to be so cavalier I will eat a panic immediately, and I don't plan to maintain this stuff. In a real project I probably want to explicitly handle None and Error in some places, and pass on Errors in other places, even when I don't I should write an expect() in case I'm maintaining this years from now. More likely in lifetime confusion scenarios the equivalent C++ compiles but just has mysterious crashes or bugs and the equivalent Java has runtime Null reference errors, Concurrency errors, a truly enormous memory leak, data races, other mysterious mutation bugs, or all of the above. I'll take a compile time error from the borrow checker thanks.
- estebank 5y ago
  > It would be cute if the Rust compiler said "I think you want a Boxed collection of strings here to use the algorithm you're attempting, change how this is represented in all the related structs too, here's how:" but that's unrealistic I think we could provide such messages in some cases. :) For example, if you have an impl Trait return type and have multiple returned values of different types, we suggest using Box<dyn Trait> when valid. It's just a lot of work to get those in place. You're effectively implementing a language that does those things automatically, plus all the work to print out the actual diagnostic.

by Ygg2 5y ago

brabel 5y ago

> they definitely never felt too long, compared to say Java. Woah... now I am the one who have to ask: what the hell are you on about?? I work on Rust and Java projects, if you exclude running tests, Java compiles very very fast compared to pretty much any language... Rust is a lot slower to compile even on the much smaller projects I've worked on... in this post, a very small project (I think it's like 16,000 LoC, it's mentioned in the beginning) was taking over a minute even on hot builds... To get a build to take this long in Java you would need to have several million LoC! Even if you don't use something like Gradle to cache compilation units and just compile everything from scratch with javac.

dmitriid 5y ago
> Java compiles very very fast compared to pretty much any language In my experience C# compiles faster, but I still agree with you on all points.
- yawaramin 5y ago
  Not surprising, considering the chief architect of C# is the guy famous for making Turbo Pascal.
- emn13 5y ago
  Build times have regressed considerably the past few releases (at least for me). Not that I'm complaining about the tradeoffs, the new features are generally worth it. Whats most annoying is that it's often hard to tell which features are expensive until you've already wasted a bunch of time introducing em. But I've got to say I'm super jealous of the level of introspection the rust compiler allows here. I'd definitely be willing to change a few C# coding patterns in code bases I maintain to benefit build times, but as is, that's a really painful trial and error process. And sometimes you get lucky finding the root cause, but if you don't... well, it's not a great experience.
Ygg2 5y ago
And I've worked on large Java projects. Things that have like 420+ dependencies (spring boot + some other requirements). I timed the maven clean compile. And it takes around 2min.
- brabel 5y ago
  Maven is very slow. Gradle and Bazel avoid doing wasteful things like Maven does so generally are a lot faster... if you want to know the speed of compiling Java you should just run `javac`, assuming Maven speed is Java compilation speed is far from correct even if a lot of projects still use Maven to build Java projects.
  - lenkite 5y ago
    Use Maven Daemon. (https://github.com/apache/maven-mvnd https://github.com/apache/maven-mvnd) . With Maven Daemon, traditional maven builds get a spectacular boost factor that put them ahead of Gradle. (Haven't tried Bazel though)
fasterthanlime 5y ago
Seems like you really need to finish reading the article: hot builds take 3s by the time I find the regression that caused pathological compile times.
- yawaramin 5y ago
  You mean, by the time you split up the project into a bunch of tiny crates and mention: > I don't love how the dependency graph looks After adding this complexity to the project, yes, some of the crates are building in ~3s, if they are the only ones that needed to be rebuilt. Meanwhile, in a Java project there is none of this artificial crate splitting. Sure, Java projects have other nonsense, but they don't force you to split up projects into tiny pieces to get decent compile times.
  - estebank 5y ago
    It's a tradeoff: if you make the file the language's compilation unit, then you can't have "circular imports" to allow end users divide their code in an ergonomic manner with fewer "arbitrary" restrictions. We can argue all year on whether Rust settled on the right side of that trade-off.
    - yawaramin 5y ago
      I'm just surprised that no one has (to my knowledge, anyway) tried this even experimentally. Wouldn't the potential build speed improvement be worth at least trying out the one-file-per-crate strategy?

tialaramex 5y ago

Rust's errors are definitely the best of any language I've used. That's one reason it's nice to write Rust after a day fighting with SQL Server for example which seems to still think in 2021 that "Syntax error" is a reasonable diagnostic message. As to "How to fix it" however if you have lifetime confusion the error reported by the borrow checker probably isn't going to suggest refactoring your code with a design that makes sense even though that's likely the correct solution. It would be cute if the Rust compiler said "I think you want a Boxed collection of strings here to use the algorithm you're attempting, change how this is represented in all the related structs too, here's how:" but that's unrealistic and, more importantly, no other language is doing a better job here. While Rust makes the errors themselves look easy, the right suggestion is context sensitive anyway. In my AoC solutions, unwrap() was the correct answer anywhere the problem is "I have an Option or a Result and I wish that I didn't". Because it's AoC if I'm wrong to be so cavalier I will eat a panic immediately, and I don't plan to maintain this stuff. In a real project I probably want to explicitly handle None and Error in some places, and pass on Errors in other places, even when I don't I should write an expect() in case I'm maintaining this years from now. More likely in lifetime confusion scenarios the equivalent C++ compiles but just has mysterious crashes or bugs and the equivalent Java has runtime Null reference errors, Concurrency errors, a truly enormous memory leak, data races, other mysterious mutation bugs, or all of the above. I'll take a compile time error from the borrow checker thanks.

estebank 5y ago
> It would be cute if the Rust compiler said "I think you want a Boxed collection of strings here to use the algorithm you're attempting, change how this is represented in all the related structs too, here's how:" but that's unrealistic I think we could provide such messages in some cases. :) For example, if you have an impl Trait return type and have multiple returned values of different types, we suggest using Box<dyn Trait> when valid. It's just a lot of work to get those in place. You're effectively implementing a language that does those things automatically, plus all the work to print out the actual diagnostic.