4 ms·

> All I can say is that the reaction to Cargo from Rust programmers is overwhelmingly, almost universally positive You can prove anything when you introduce a

by flukus 9y ago

> All I can say is that the reaction to Cargo from Rust programmers is overwhelmingly, almost universally positive You can prove anything when you introduce a sampling bias that large. > Not solving builds and package management is not a realistic option for a language in 2017. Package management was solved decades ago, my OS manages the packages and a lean and mean system is the result. The rust solution results in massive binary sizes for simple command line tools. This is fine if there goal is to replace java, but not if they want to replace c.

pcwalton 9y ago
> You can prove anything when you introduce a sampling bias that large. I'm confident that programmers don't want to be writing Makefiles. We don't have to take formal surveys to observe the obvious trend away from raw "make" that has been occurring for decades. Besides, if Rust programmers really had a problem with Cargo, they would tell us. Programmers don't suffer in silence. > Package management was solved decades ago, my OS manages the packages and a lean and mean system is the result. I'm glad you like your package manager. Most programmers, including me, don't want to have to deal with it when the goal is simply to put a Rust project together. Besides, we ship desktop software on Windows: we cannot tell our users "sorry, you need to install Ubuntu". > The rust solution results in massive binary sizes for simple command line tools. This is fine if there goal is to replace java, but not if they want to replace c. The Rust solution is customizable. You can use dynamic libraries if you like, and earlier prerelease versions of Rust did in fact do that. Dynamic libraries are a single rustc flag away. The feedback we got was that people preferred the convenience of a single standalone binary to the complexity of dynamic linking managed by the OS.
- flukus 9y ago
  > I'm glad you like your package manager. Most programmers, including me, don't want to have to deal with it when the goal is simply to put a Rust project together. This is the same attitude that makes electron so attractive. As a user, I don't care what makes your life easier as a developer, I care that I'm getting a more bloated and less secure result. This is an awful attitude that's creeped into software development lately. > Besides, we ship desktop software on Windows: we cannot tell our users "sorry, you need to install Ubuntu". So bundle them on windows, bloated installers are the norm their already. You're probably going to have to include an auto updater and a lot of other stuff that windows doesn't provide as well. Not having to deal with that stuff is part of why I use ubuntu in the first place. > The Rust solution is customizable. You can use dynamic libraries if you like, and earlier prerelease versions of Rust did in fact do that. Dynamic libraries are a single rustc flag away. Until there is a stable ABI that isn't a solution because you have to distribute those libraries with the app.
  - burntsushi 9y ago
    > As a user, I don't care what makes your life easier as a developer You should. The easier my life is, the faster I can fix bugs and put out new releases.
    - flukus 9y ago
      I'm dealing with the result of this attitude on my phone right now. The end result is I can't even install your app because I'm out of space on my phone. I'm out of space because every other app maker favored developer productivity over being conservative with users resources. It's a tragedy of the commons.
      - deleted 9y ago
        [deleted]
      - burntsushi 9y ago
        Seems like you are shifting the goal posts. If I'm building something to run on resource constrained devices, then it makes sense to value use of resources more highly! But otherwise, most of your comments just seem to repeat the same old dynamic vs static linking debate that had been hashed out already for decades. There is no one right answer. Trade offs abound. People who expect a stable ABI from Rust such that normal Rust libraries can be dynamically linked like you would C libraries would do well to adjust their expectations. It isn't happening any time soon.
        flukus 9y ago
        > most of your comments just seem to repeat the same old dynamic vs static linking debate that had been hashed out already for decades. There is no one right answer. Trade offs abound. Rust doesn't let me make that trade off, it's made the decision for me. > People who expect a stable ABI from Rust such that normal Rust libraries can be dynamically linked like you would C libraries would do well to adjust their expectations. It isn't happening any time soon. I think it's the rustaceans that need to adjust their expectations, as long as this holds rust won't be a real systems language, it stands a better chance of unseating java than c.
steveklabnik 9y ago
Many existing Rust users were extremely skeptical when Cargo was announced, many said they'd stick with Makefiles. In the end, they didn't. > Package management was solved decades ago If it was, there wouldn't be new package managers popping up all the time; it's a non-trivial problem. They're not created for no reason. > The rust solution results in massive binary sizes for simple command line tools. This isn't exactly true, or rather, you're comparing two different things. https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.html https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab... has the details.
- pcwalton 9y ago
  That's a great point: we effectively tried the "just use Makefiles" solution already. It failed.
- flukus 9y ago
  > If it was, there wouldn't be new package managers popping up all the time; it's a non-trivial problem. They're not created for no reason. Notice how all those package managers are for platforms or create platforms in their own right. Rust is meant to be a systems language, that means it's platform is the OS and it doesn't get to be a world unto itself like java. > This isn't exactly true, or rather, you're comparing two different things. https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab.. https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab.... has the details. So if you jump through a million hoops, limit yourself to c libraries you can produce small executables. At that point it's more complicated than just writing an app in c in the first place. I'm not interested in what it can technically do though, I'm interested in what is practically happening. In practice most rust programmers seem to be writing apps for the cargo platform. In practice rust developers are producing huge executables. In practice rust has no stable ABI so all rust libraries get statically compiled. In practice this is incompatible with the LGPL. In practice a security vulnerability means every app using the library has to be recompiled to be secure.
  - kibwen 9y ago
    > Rust is meant to be a systems language, that means it's platform is the OS and it doesn't get to be a world unto itself like java. Rust is meant to be a cross-platform systems language, and sadly there does not exist a cross-platform package manager. Until one exists (and I'm not holding my breath here), every language which intends to be cross-platform will continue inventing its own package management.

by flukus 9y ago

pcwalton 9y ago

> You can prove anything when you introduce a sampling bias that large. I'm confident that programmers don't want to be writing Makefiles. We don't have to take formal surveys to observe the obvious trend away from raw "make" that has been occurring for decades. Besides, if Rust programmers really had a problem with Cargo, they would tell us. Programmers don't suffer in silence. > Package management was solved decades ago, my OS manages the packages and a lean and mean system is the result. I'm glad you like your package manager. Most programmers, including me, don't want to have to deal with it when the goal is simply to put a Rust project together. Besides, we ship desktop software on Windows: we cannot tell our users "sorry, you need to install Ubuntu". > The rust solution results in massive binary sizes for simple command line tools. This is fine if there goal is to replace java, but not if they want to replace c. The Rust solution is customizable. You can use dynamic libraries if you like, and earlier prerelease versions of Rust did in fact do that. Dynamic libraries are a single rustc flag away. The feedback we got was that people preferred the convenience of a single standalone binary to the complexity of dynamic linking managed by the OS.

flukus 9y ago
> I'm glad you like your package manager. Most programmers, including me, don't want to have to deal with it when the goal is simply to put a Rust project together. This is the same attitude that makes electron so attractive. As a user, I don't care what makes your life easier as a developer, I care that I'm getting a more bloated and less secure result. This is an awful attitude that's creeped into software development lately. > Besides, we ship desktop software on Windows: we cannot tell our users "sorry, you need to install Ubuntu". So bundle them on windows, bloated installers are the norm their already. You're probably going to have to include an auto updater and a lot of other stuff that windows doesn't provide as well. Not having to deal with that stuff is part of why I use ubuntu in the first place. > The Rust solution is customizable. You can use dynamic libraries if you like, and earlier prerelease versions of Rust did in fact do that. Dynamic libraries are a single rustc flag away. Until there is a stable ABI that isn't a solution because you have to distribute those libraries with the app.
- burntsushi 9y ago
  > As a user, I don't care what makes your life easier as a developer You should. The easier my life is, the faster I can fix bugs and put out new releases.
  - flukus 9y ago
    I'm dealing with the result of this attitude on my phone right now. The end result is I can't even install your app because I'm out of space on my phone. I'm out of space because every other app maker favored developer productivity over being conservative with users resources. It's a tragedy of the commons.
    - deleted 9y ago
      [deleted]
    - burntsushi 9y ago
      Seems like you are shifting the goal posts. If I'm building something to run on resource constrained devices, then it makes sense to value use of resources more highly! But otherwise, most of your comments just seem to repeat the same old dynamic vs static linking debate that had been hashed out already for decades. There is no one right answer. Trade offs abound. People who expect a stable ABI from Rust such that normal Rust libraries can be dynamically linked like you would C libraries would do well to adjust their expectations. It isn't happening any time soon.
      - flukus 9y ago
        > most of your comments just seem to repeat the same old dynamic vs static linking debate that had been hashed out already for decades. There is no one right answer. Trade offs abound. Rust doesn't let me make that trade off, it's made the decision for me. > People who expect a stable ABI from Rust such that normal Rust libraries can be dynamically linked like you would C libraries would do well to adjust their expectations. It isn't happening any time soon. I think it's the rustaceans that need to adjust their expectations, as long as this holds rust won't be a real systems language, it stands a better chance of unseating java than c.

steveklabnik 9y ago

Many existing Rust users were extremely skeptical when Cargo was announced, many said they'd stick with Makefiles. In the end, they didn't. > Package management was solved decades ago If it was, there wouldn't be new package managers popping up all the time; it's a non-trivial problem. They're not created for no reason. > The rust solution results in massive binary sizes for simple command line tools. This isn't exactly true, or rather, you're comparing two different things. https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.html https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab... has the details.

pcwalton 9y ago
That's a great point: we effectively tried the "just use Makefiles" solution already. It failed.
flukus 9y ago
> If it was, there wouldn't be new package managers popping up all the time; it's a non-trivial problem. They're not created for no reason. Notice how all those package managers are for platforms or create platforms in their own right. Rust is meant to be a systems language, that means it's platform is the OS and it doesn't get to be a world unto itself like java. > This isn't exactly true, or rather, you're comparing two different things. https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab.. https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab.... has the details. So if you jump through a million hoops, limit yourself to c libraries you can produce small executables. At that point it's more complicated than just writing an app in c in the first place. I'm not interested in what it can technically do though, I'm interested in what is practically happening. In practice most rust programmers seem to be writing apps for the cargo platform. In practice rust developers are producing huge executables. In practice rust has no stable ABI so all rust libraries get statically compiled. In practice this is incompatible with the LGPL. In practice a security vulnerability means every app using the library has to be recompiled to be secure.
- kibwen 9y ago
  > Rust is meant to be a systems language, that means it's platform is the OS and it doesn't get to be a world unto itself like java. Rust is meant to be a cross-platform systems language, and sadly there does not exist a cross-platform package manager. Until one exists (and I'm not holding my breath here), every language which intends to be cross-platform will continue inventing its own package management.