6 ms·

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 la

by flukus 10y 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 10y ago
So do you enjoy packaging code for every single OS, in its own specific way?
- flukus 10y 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 10y 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 10y 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 10y ago
  No there isn't. That doesn't mean a rust platform has to be created that sits on top of the system.
  - kbenson 10y 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 10y 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 10y 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.

by flukus 10y ago

pjmlp 10y ago

So do you enjoy packaging code for every single OS, in its own specific way?

flukus 10y 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 10y 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 10y 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 10y ago
No there isn't. That doesn't mean a rust platform has to be created that sits on top of the system.
- kbenson 10y 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 10y 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 10y 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.