4 ms·

`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 benchmar

`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.
    - jfoutz 9y ago
      I think I understand your opinion, but I'm asserting development time is wierd. Sometimes I need the bleeding edge. Sometimes I'm debugging the bleeding edge. If you're willing to stuff nightlys in artifactory, I'm willing to roll with the package manager. Realistically People aren't willing to own that process, so I grab a sane ish version, and go on with my life.
    - AsyncAwait 9y ago
      True, but there's not a simple, unified way to maintain packages across all major platforms that does not involve having your own package manager like Cargo.
      - flukus 9y ago
        No there isn't. That doesn't mean a rust platform has to be created that sits on top of the system.
        kbenson 9y ago
        Well, there is benefit to the platform, I think you've just misinterpreted it's use. Cargo is to Rust as cpan (the client) is to Perl, as pip is to Python, and as gem is to Ruby. All those other languages also have packages provided in many distros, but the developtment tool listed that downloads and installs relevant packages is also used when appropriate. For the regular, non-developer user that needs a module to support some program, that may be never. For the developer working in those languages that needs the newest version of the package, regardless of the back-patching policy of their distro, that may be often.
        flukus 9y ago
        > Cargo is to Rust as cpan (the client) is to Perl, as pip is to Python, and as gem is to Ruby. As I said, rust is meant to be a systems language, it shouldn't have an equivalent of cpan and, pip or gem because it needs to work with the system, not be yet another platform.
        kbenson 9y ago
        > rust is meant to be a systems language It's meant to useful as a systems language, so was designed with certain constraints in mind. It is whatever people want to make of it. There have been plenty of instances I've seen on HN alone of people mentioning use that isn't specifically tailored for a systems language. > it shouldn't have an equivalent of cpan and, pip or gem because it needs to work with the system, not be yet another platform. Those are entirely orthogonal issues. Cargo works with the system just as well as tar and make. They're just binaries. You could just as easily say that traditional source tarballs shouldn't be provided because people might download the source and use their compiler to build instead of using the distro package. This is a non-issue. The only people that will even have the choice are those that chose to install the compiler (whether it be a C compiler or Rust), and even then the vast majority that actually do so will probably end up having a good reason for doing so. Cargo is part of the build tool chain. Just because it can be used to distribute a package, and even while it probably will be used to distribute a package, that doesn't mean it's purpose is to do so, or that it's inappropriate that it exists. Any feature can be abused. You should not judge it by the abuse, but by its intended and common use.
- bluejekyll 9y ago
  Cargo is a development and build tool, and it's quite possibly the best I've ever used. I don't know of any specific reason it's "fuck the package manager". Cargo does it's own dependency management, so I assume you mean to say that because of this, it makes it difficult to integrate into standard methods package managers use. After reading some of the email threads with OpenBSD, I do get the sense that it's complex in that situation, but isn't that because of Ports? And Ports' expectations? Most things in Ports are C, right? I haven't worked with Ports in a long time, so I don't know it very well. If you're pre-building something and pushing a package for say dpkg or rpm, I don't see a problem. If you're packaging source, then you'll need have the rust tools installed on the host to do that, which seems obvious. After that, I can see some debate about blessing versions of crates in the Rust ecosystem for use in the OS' package manager, but this starts to blur the lines between what the OS is guaranteeing and what is the responsibility of the build tool. Should an OS want to bless crates, cargo does have an override for crates.io: http://doc.crates.io/config.html http://doc.crates.io/config.html see the 'registry' section. I believe the other options in that configuration would also be things that the package manager on the OS would want to specify as well. I haven't done any of this myself, but would be interested in trying to help figure it out if you have specific concerns.
  - pjmlp 9y ago
    My main pet peeve with cargo is lack of support for binary crates. Compiling the whole world, including dependencies is big waste of time. I already tried to play around with workspaces to see if at least crates only get compiled once. With other AOT compiled languages I use, zero third party dependencies are compiled from scratch.
    - bluejekyll 9y ago
      Yeah, I agree with this. This confused me when I first started using the language. I do think there could be some better options for caching or downloading precompiled packages, but I also think this has partly helped with the development effort in Rust as well. That being said, a system wide cached package repo could work, but it also has issues (looking at you Maven) so it would be interesting to figure out how to get it "right" when dealing with source packages. This old issue discusses a bunch of this: https://github.com/rust-lang/cargo/issues/610 https://github.com/rust-lang/cargo/issues/610 I couldn't find another in a brief search. Edit: I should add that it does harken back a bit to my Gentoo days, where recompiling the world for that 10-15% architecture boost was a lot of fun, but also a waste of time in general ;)

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.
  - jfoutz 9y ago
    I think I understand your opinion, but I'm asserting development time is wierd. Sometimes I need the bleeding edge. Sometimes I'm debugging the bleeding edge. If you're willing to stuff nightlys in artifactory, I'm willing to roll with the package manager. Realistically People aren't willing to own that process, so I grab a sane ish version, and go on with my life.
  - AsyncAwait 9y ago
    True, but there's not a simple, unified way to maintain packages across all major platforms that does not involve having your own package manager like Cargo.
    - flukus 9y ago
      No there isn't. That doesn't mean a rust platform has to be created that sits on top of the system.
      - kbenson 9y ago
        Well, there is benefit to the platform, I think you've just misinterpreted it's use. Cargo is to Rust as cpan (the client) is to Perl, as pip is to Python, and as gem is to Ruby. All those other languages also have packages provided in many distros, but the developtment tool listed that downloads and installs relevant packages is also used when appropriate. For the regular, non-developer user that needs a module to support some program, that may be never. For the developer working in those languages that needs the newest version of the package, regardless of the back-patching policy of their distro, that may be often.
        flukus 9y ago
        > Cargo is to Rust as cpan (the client) is to Perl, as pip is to Python, and as gem is to Ruby. As I said, rust is meant to be a systems language, it shouldn't have an equivalent of cpan and, pip or gem because it needs to work with the system, not be yet another platform.
        kbenson 9y ago
        > rust is meant to be a systems language It's meant to useful as a systems language, so was designed with certain constraints in mind. It is whatever people want to make of it. There have been plenty of instances I've seen on HN alone of people mentioning use that isn't specifically tailored for a systems language. > it shouldn't have an equivalent of cpan and, pip or gem because it needs to work with the system, not be yet another platform. Those are entirely orthogonal issues. Cargo works with the system just as well as tar and make. They're just binaries. You could just as easily say that traditional source tarballs shouldn't be provided because people might download the source and use their compiler to build instead of using the distro package. This is a non-issue. The only people that will even have the choice are those that chose to install the compiler (whether it be a C compiler or Rust), and even then the vast majority that actually do so will probably end up having a good reason for doing so. Cargo is part of the build tool chain. Just because it can be used to distribute a package, and even while it probably will be used to distribute a package, that doesn't mean it's purpose is to do so, or that it's inappropriate that it exists. Any feature can be abused. You should not judge it by the abuse, but by its intended and common use.
bluejekyll 9y ago
Cargo is a development and build tool, and it's quite possibly the best I've ever used. I don't know of any specific reason it's "fuck the package manager". Cargo does it's own dependency management, so I assume you mean to say that because of this, it makes it difficult to integrate into standard methods package managers use. After reading some of the email threads with OpenBSD, I do get the sense that it's complex in that situation, but isn't that because of Ports? And Ports' expectations? Most things in Ports are C, right? I haven't worked with Ports in a long time, so I don't know it very well. If you're pre-building something and pushing a package for say dpkg or rpm, I don't see a problem. If you're packaging source, then you'll need have the rust tools installed on the host to do that, which seems obvious. After that, I can see some debate about blessing versions of crates in the Rust ecosystem for use in the OS' package manager, but this starts to blur the lines between what the OS is guaranteeing and what is the responsibility of the build tool. Should an OS want to bless crates, cargo does have an override for crates.io: http://doc.crates.io/config.html http://doc.crates.io/config.html see the 'registry' section. I believe the other options in that configuration would also be things that the package manager on the OS would want to specify as well. I haven't done any of this myself, but would be interested in trying to help figure it out if you have specific concerns.
- pjmlp 9y ago
  My main pet peeve with cargo is lack of support for binary crates. Compiling the whole world, including dependencies is big waste of time. I already tried to play around with workspaces to see if at least crates only get compiled once. With other AOT compiled languages I use, zero third party dependencies are compiled from scratch.
  - bluejekyll 9y ago
    Yeah, I agree with this. This confused me when I first started using the language. I do think there could be some better options for caching or downloading precompiled packages, but I also think this has partly helped with the development effort in Rust as well. That being said, a system wide cached package repo could work, but it also has issues (looking at you Maven) so it would be interesting to figure out how to get it "right" when dealing with source packages. This old issue discusses a bunch of this: https://github.com/rust-lang/cargo/issues/610 https://github.com/rust-lang/cargo/issues/610 I couldn't find another in a brief search. Edit: I should add that it does harken back a bit to my Gentoo days, where recompiling the world for that 10-15% architecture boost was a lot of fun, but also a waste of time in general ;)