3 ms·

I'll try to keep it brief this time. > TL;DR: I don't think that WebAssembly really changes the game here, for good or for bad. It's a step in the wrong direc

by madez 9y ago

I'll try to keep it brief this time. > TL;DR: I don't think that WebAssembly really changes the game here, for good or for bad. It's a step in the wrong direction. Working on WebAssembly is not as bad as it could be because there already is JavaScript, but instead of working on WebAssembly, I think we should bury JavaScript. > Package management is a very hard thing. Maybe someday I'll write a blog post about all of this at length, when I have the time. Fair enough. Looking forward to it. > What's the gold standard example for you, exempting C and C++? Maybe Python on Debian. But why shouldn't C be the benchmark? And why compare to another language instead of what's desireable?

steveklabnik 9y ago
> Maybe Python on Debian. Cool, thanks. I'll look into it. I'm more familiar with Ruby and Debian which has a... storied history :) > But why shouldn't C be the benchmark? In some sense, it shouldn't, I'm in agreement that in some sense, we should talk about what's desireable. However, there's a reason that it's significant: apt is designed around C. Its compilation model, everything. So of course C works with apt very well; I'd hope so! But non-C languages have a much larger hurdle. In terms of Rust's integration into a system, it'd face challenges similar to non-C than to C.
- madez 9y ago
  > apt is designed around C It would be nice to have a list of what each of Apt, Pacman and Portage needed to change to accommodate Rusts needs. Thanks for your comments!
  - burntsushi 9y ago
    Arch is already packaging Rust applications. One of mine is in the community repo. People are working on debs, but it's slow going: https://github.com/BurntSushi/ripgrep/issues/10 https://github.com/BurntSushi/ripgrep/issues/10
  - steveklabnik 9y ago
    There's also another split, honestly. Anyone can make an Apt package, but getting your apt package into Debian is another story. There's friction in both sides. Most of them are related to (very sensible when talking about C) distro policies. It's as much cultural as it is technical. Someday I might write some of this up, but honestly, I deeply appreciate the work that the humans who build OS packages do, and don't really want to add more friction to the pile, or appear to be denigrating their work. It's more likely to just be an "argue on the internet" situation than actually cause any change that'd be helpful. To be clear, again, this stuff already works. It's about the difference between "easy" and "possible".

by madez 9y ago

steveklabnik 9y ago

> Maybe Python on Debian. Cool, thanks. I'll look into it. I'm more familiar with Ruby and Debian which has a... storied history :) > But why shouldn't C be the benchmark? In some sense, it shouldn't, I'm in agreement that in some sense, we should talk about what's desireable. However, there's a reason that it's significant: apt is designed around C. Its compilation model, everything. So of course C works with apt very well; I'd hope so! But non-C languages have a much larger hurdle. In terms of Rust's integration into a system, it'd face challenges similar to non-C than to C.

madez 9y ago
> apt is designed around C It would be nice to have a list of what each of Apt, Pacman and Portage needed to change to accommodate Rusts needs. Thanks for your comments!
- burntsushi 9y ago
  Arch is already packaging Rust applications. One of mine is in the community repo. People are working on debs, but it's slow going: https://github.com/BurntSushi/ripgrep/issues/10 https://github.com/BurntSushi/ripgrep/issues/10
- steveklabnik 9y ago
  There's also another split, honestly. Anyone can make an Apt package, but getting your apt package into Debian is another story. There's friction in both sides. Most of them are related to (very sensible when talking about C) distro policies. It's as much cultural as it is technical. Someday I might write some of this up, but honestly, I deeply appreciate the work that the humans who build OS packages do, and don't really want to add more friction to the pile, or appear to be denigrating their work. It's more likely to just be an "argue on the internet" situation than actually cause any change that'd be helpful. To be clear, again, this stuff already works. It's about the difference between "easy" and "possible".