3 ms·

> 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 tak

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

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.