4 ms·

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

by 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.

by jfoutz 9y ago

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.