4 ms·

Thanks for your elaborate comment. It is interesting to read and insightful. I just have comments for select sections: >> I don't consider it important to be a

by madez 9y ago

Thanks for your elaborate comment. It is interesting to read and insightful. I just have comments for select sections: >> I don't consider it important to be able to compile Rust to JavaScript > We share this opinion, but compiling to WebAssembly is a whole different ballgame. If I understand correctly, WebAssembly is essentially the same as JavaScript, and therefore something I'd like to avoid. I do not want random executable code from websites, that my browser then automatically executes. I don't think sandboxing is a solution, because it's an inherently impossible problem. Externally controlled and unaccaunted executable code is _always_ bad. Instead, let's fix some restricted non-turing complete markup language, like HTML, and stay with that. It's an optimal solution. Maybe, probably, I'm missing something here, but JavaScript and WebAssembly seem to be things that are not in the interest of users. >> There are scenarios where rustup and cargo are not acceptable. Is this on the radar? > It's hard to say without knowing more details of what exactly you mean; distros are already packaging Rust and libraries, for example. In general though, this is a thing we've put a ton of effort to in the past, and I expect to have even more in the future. Cargo and Rustup seem to be in competition to the existing package management systems. Why not integrate rust and the libraries into the existing packagement systems, like so many other software projects do? How is Cargo and rustup better than Apt? Also, Apt is perfectly usable without internet. One can download the entire Debian archive to a hard drive and use it without any external connections. How would I do that with Cargo and Rustup? This is just one point. There are so many scenarios Apt already has solutions for, that Cargo and Rustup probably didn't even consider yet. Anyhow, clearly this issue is noted and even already worked on. That's more I could ask for. Another thing I forgot to mention is IDE support. I read that Rust is now supposedly supported in Gnome Builder, but I see no option to create a Rust project. This is not the responsibility of the Rust team, and it's just an anecdote, but it affects Rust and it's usage and growth.

steveklabnik 9y ago
You're welcome! And thanks for your posts too. > WebAssembly is essentially the same as JavaScript In some senses, but not others. Regardless of personal feelings though, WebAssembly isn't just happening, it's already happened. And also regardless of personal feelings, many people in the Rust world seem to be very excited about WebAssembly; see https://mgattozzi.com/rust-wasm https://mgattozzi.com/rust-wasm for example. (I personally am very interested, but if the community was against it, would accept that. It seems like the majority, at this time, is pretty pro.) > How is Cargo and rustup better than Apt? There's a multitude of ways to tackle this problem, but I'll give you the biggest one: I'm a Windows user these days. Apt is 100% useless to me. This problem is the same even on Linuxes, while I do use Debian, I used to use Arch: Apt would be 100% useless to me. > Apt is perfectly usable without internet. Cargo is perfectly usable without internet. It's a hard requirement of projects like Firefox, and the various distros that are shipping Rust today. Now, we want to make it even easier to use without internet, so there's work to be done, but the fundamentals already exist and are used in production systems today. > Another thing I forgot to mention is IDE support. Yeah, this is super huge, agreed. We've been working on various things, but obviously it depends on what IDE you use, and there's a long tail there. We'll get there!
- madez 9y ago
  > You're welcome! And thanks for your posts too. Thanks :-) > And also regardless of personal feelings, many people in the Rust world seem to be very excited about WebAssembly WebAssembly and JavaScript are used to create locked-in software to deliver uncopyable experiences, to ultimately exercise power over other people. Clearly, there will be people interested in this, because the power can be used to generate profit. Ethically, I think it must not be supported. It goes frontally against the idea and intent of free software. I think this problem is glaring, and I'm interested in your view about this very aspect. > How is Cargo and rustup better than Apt? I didn't mean to restrict this to Apt. Many projects and programming languages are available on multiple platforms, all while playing nice with the existing package management systems. Apt is not special in this regard, and was just used as an example.
  - steveklabnik 9y ago
    > I'm interested in your view about this very aspect. I'm conflicted. I personally waver between "stallman is always right" and "free software misses the point" near constantly, myself. With regards to WebAssembly, it's also complicated. You can argue that JavaScript is basically in the same place, and so for me, it's kind of a moot point. That is, there's no requirement for JavaScript to be free software today either. In practice, obfuscated/minified JS and WebAssembly are basically the same, with the exception that the tooling for de-{obfuscating,compiling} JS is currently more robust and mature since it's been around a lot longer. TL;DR: I don't think that WebAssembly really changes the game here, for good or for bad. > I didn't mean to restrict this to Apt Quite fair! And as I alluded to above, it's not just the thing that I posted. This is quite long but I have little time, so I'm gonna be brief. https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527 https://medium.com/@sdboyer/so-you-want-to-write-a-package-m... basically is, IMO, the gold standard for talking about these things. However, I think the distinction of OS/system package manager vs Language package manager is important. Basically, Cargo and Apt (I'll follow your lead here with using Apt as a standin) have very different goals, and very different constants. This is because they're doing two very different jobs. Specifically, system package managers are about providing a unified set of packages to end-users. Language package managers are for developers to build applications. With Cargo, we've very strongly stayed away from giving it any sort of "system package manager" features, because that's not what we're trying to do. However, at some point, a developer delivers an application to an end user, and so I agree strongly that Cargo should play well with Apt. It cannot, however, be replaced by Apt. To that end, I think tools like https://crates.io/crates/debcargo https://crates.io/crates/debcargo are the path forward, and in fact that tool is (in my understanding) being used by Debian to manage this bridge. I would love to have a simple Cargo command to generate a compatible system package for any of these systems. It's a long tail thing though, so it's gonna take some time. Anyway, yeah, that's the root of it. There's tons of other details too. 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. > Many projects and programming languages are available on multiple platforms, all while playing nice with the existing package management systems What's the gold standard example for you, exempting C and C++?
AlexeyBrin 9y ago
> Cargo and Rustup seem to be in competition to the existing package management systems. Why not integrate rust and the libraries into the existing packagement systems, like so many other software projects do? How is Cargo and rustup better than Apt? > Also, Apt is perfectly usable without internet. One can download the entire Debian archive to a hard drive and use it without any external connections. How would I do that with Cargo and Rustup? This is just one point. There are so many scenarios Apt already has solutions for, that Cargo and Rustup probably didn't even consider yet. You can't simply ignore 98% of the users of other operating systems just because it happens for you today to use a Debian based system. The fact that Rust has an OS independent package manager is a huge plus for Rust adoption.
- madez 9y ago
  I didn't mean to exclude other systems by naming Apt, it was rather meant as an example. The non-Debian based systems, and even the non-Linux based systems are important. I agree that an OS independent package manager is a plus for Rust adoption. I also think it cannot replace the OS package managers, and therefore Rust should also play nice with them, and integrate as much as possible.
  - verletx64 9y ago
    Well, now you've got to have people covering those integrations with apt, pacman, homebrew, etc. And instead of this work benefiting everyone, it just kind of benefits some people. Not saying that means you ignore the idea, but especially an early stage language is going to prioritise trying to answer questions that improve life for the majority of its users, and things that are most demanded by interested, but for some reason dissuaded potential users.
bennofs 9y ago
> Why not integrate rust and the libraries into the existing packagement systems, like so many other software projects do? This makes me curious: can you tell me some examples of other software projects which are not written in C that integrate libraries into existing package management systems? Personally, I feel like `apt` could almost be called a C/C++ package manager at this point. It does have some packages written in other languages, but most languages still have their own package manager for development. For example: * Python: has pip and virtualenv, packaging with apt is difficult due to incompatible version requirements * Ruby: not personally using ruby much, but seems like most apps are installed via bundler or gem and not packaged * Haskell: Small binary compatibility of libraries make traditional packages difficult (even dependencies of dependencies need to match for compatibility) * Java: I don't even know how java libraries would work with apt * PHP: I have never used a PHP package installed through the package manager Granted, I may be missing something here, but the majority of the packages in apt repository seem to be C/C++, maybe some perl or python which are "made to work" simply because too many things depend on them.
- madez 9y ago
  Debian and Python seem to play nice with each other. > As such, with hundreds of Python modules and multiple versions of Python supported, Debian is the largest "integrated Python distribution". (https://wiki.debian.org/Python https://wiki.debian.org/Python) Even if other languages don't play as nice as possible, or even foul, that doesn't mean it's not important for Rust to play nice.
wasted_intel 9y ago
Coming from a Ruby background, keeping your language versions independent from your OS package manager is really useful. There are situations where having different versions running alongside one-another is really handy, or not having to wait for your distro to include support for the version you require. Agreed that it looks like re-inventing the wheel from the outside; rest assured, it's useful!
burntsushi 9y ago
> Maybe, probably, I'm missing something here, but JavaScript and WebAssembly seem to be things that are not in the interest of users. The Rust project does not have a goal to destroy every single piece of technology that could be construed as user hostile. The reality is that if you want to write a widely used browser application, you need to use Javascript, and probably soon, optionally WebAssembly. Rust is well positioned to take advantage of that. (This is not an argument against the claim that Javascript/WebAssembly are user hostile. I have no real interest in discussing that, and frankly, there is no obvious conclusion to draw there. Instead, I'm pointing out a category error.)

by madez 9y ago

steveklabnik 9y ago

You're welcome! And thanks for your posts too. > WebAssembly is essentially the same as JavaScript In some senses, but not others. Regardless of personal feelings though, WebAssembly isn't just happening, it's already happened. And also regardless of personal feelings, many people in the Rust world seem to be very excited about WebAssembly; see https://mgattozzi.com/rust-wasm https://mgattozzi.com/rust-wasm for example. (I personally am very interested, but if the community was against it, would accept that. It seems like the majority, at this time, is pretty pro.) > How is Cargo and rustup better than Apt? There's a multitude of ways to tackle this problem, but I'll give you the biggest one: I'm a Windows user these days. Apt is 100% useless to me. This problem is the same even on Linuxes, while I do use Debian, I used to use Arch: Apt would be 100% useless to me. > Apt is perfectly usable without internet. Cargo is perfectly usable without internet. It's a hard requirement of projects like Firefox, and the various distros that are shipping Rust today. Now, we want to make it even easier to use without internet, so there's work to be done, but the fundamentals already exist and are used in production systems today. > Another thing I forgot to mention is IDE support. Yeah, this is super huge, agreed. We've been working on various things, but obviously it depends on what IDE you use, and there's a long tail there. We'll get there!

madez 9y ago
> You're welcome! And thanks for your posts too. Thanks :-) > And also regardless of personal feelings, many people in the Rust world seem to be very excited about WebAssembly WebAssembly and JavaScript are used to create locked-in software to deliver uncopyable experiences, to ultimately exercise power over other people. Clearly, there will be people interested in this, because the power can be used to generate profit. Ethically, I think it must not be supported. It goes frontally against the idea and intent of free software. I think this problem is glaring, and I'm interested in your view about this very aspect. > How is Cargo and rustup better than Apt? I didn't mean to restrict this to Apt. Many projects and programming languages are available on multiple platforms, all while playing nice with the existing package management systems. Apt is not special in this regard, and was just used as an example.
- steveklabnik 9y ago
  > I'm interested in your view about this very aspect. I'm conflicted. I personally waver between "stallman is always right" and "free software misses the point" near constantly, myself. With regards to WebAssembly, it's also complicated. You can argue that JavaScript is basically in the same place, and so for me, it's kind of a moot point. That is, there's no requirement for JavaScript to be free software today either. In practice, obfuscated/minified JS and WebAssembly are basically the same, with the exception that the tooling for de-{obfuscating,compiling} JS is currently more robust and mature since it's been around a lot longer. TL;DR: I don't think that WebAssembly really changes the game here, for good or for bad. > I didn't mean to restrict this to Apt Quite fair! And as I alluded to above, it's not just the thing that I posted. This is quite long but I have little time, so I'm gonna be brief. https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527 https://medium.com/@sdboyer/so-you-want-to-write-a-package-m... basically is, IMO, the gold standard for talking about these things. However, I think the distinction of OS/system package manager vs Language package manager is important. Basically, Cargo and Apt (I'll follow your lead here with using Apt as a standin) have very different goals, and very different constants. This is because they're doing two very different jobs. Specifically, system package managers are about providing a unified set of packages to end-users. Language package managers are for developers to build applications. With Cargo, we've very strongly stayed away from giving it any sort of "system package manager" features, because that's not what we're trying to do. However, at some point, a developer delivers an application to an end user, and so I agree strongly that Cargo should play well with Apt. It cannot, however, be replaced by Apt. To that end, I think tools like https://crates.io/crates/debcargo https://crates.io/crates/debcargo are the path forward, and in fact that tool is (in my understanding) being used by Debian to manage this bridge. I would love to have a simple Cargo command to generate a compatible system package for any of these systems. It's a long tail thing though, so it's gonna take some time. Anyway, yeah, that's the root of it. There's tons of other details too. 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. > Many projects and programming languages are available on multiple platforms, all while playing nice with the existing package management systems What's the gold standard example for you, exempting C and C++?

AlexeyBrin 9y ago

> Cargo and Rustup seem to be in competition to the existing package management systems. Why not integrate rust and the libraries into the existing packagement systems, like so many other software projects do? How is Cargo and rustup better than Apt? > Also, Apt is perfectly usable without internet. One can download the entire Debian archive to a hard drive and use it without any external connections. How would I do that with Cargo and Rustup? This is just one point. There are so many scenarios Apt already has solutions for, that Cargo and Rustup probably didn't even consider yet. You can't simply ignore 98% of the users of other operating systems just because it happens for you today to use a Debian based system. The fact that Rust has an OS independent package manager is a huge plus for Rust adoption.

madez 9y ago
I didn't mean to exclude other systems by naming Apt, it was rather meant as an example. The non-Debian based systems, and even the non-Linux based systems are important. I agree that an OS independent package manager is a plus for Rust adoption. I also think it cannot replace the OS package managers, and therefore Rust should also play nice with them, and integrate as much as possible.
- verletx64 9y ago
  Well, now you've got to have people covering those integrations with apt, pacman, homebrew, etc. And instead of this work benefiting everyone, it just kind of benefits some people. Not saying that means you ignore the idea, but especially an early stage language is going to prioritise trying to answer questions that improve life for the majority of its users, and things that are most demanded by interested, but for some reason dissuaded potential users.

bennofs 9y ago

> Why not integrate rust and the libraries into the existing packagement systems, like so many other software projects do? This makes me curious: can you tell me some examples of other software projects which are not written in C that integrate libraries into existing package management systems? Personally, I feel like `apt` could almost be called a C/C++ package manager at this point. It does have some packages written in other languages, but most languages still have their own package manager for development. For example: * Python: has pip and virtualenv, packaging with apt is difficult due to incompatible version requirements * Ruby: not personally using ruby much, but seems like most apps are installed via bundler or gem and not packaged * Haskell: Small binary compatibility of libraries make traditional packages difficult (even dependencies of dependencies need to match for compatibility) * Java: I don't even know how java libraries would work with apt * PHP: I have never used a PHP package installed through the package manager Granted, I may be missing something here, but the majority of the packages in apt repository seem to be C/C++, maybe some perl or python which are "made to work" simply because too many things depend on them.

madez 9y ago
Debian and Python seem to play nice with each other. > As such, with hundreds of Python modules and multiple versions of Python supported, Debian is the largest "integrated Python distribution". (https://wiki.debian.org/Python https://wiki.debian.org/Python) Even if other languages don't play as nice as possible, or even foul, that doesn't mean it's not important for Rust to play nice.

wasted_intel 9y ago

Coming from a Ruby background, keeping your language versions independent from your OS package manager is really useful. There are situations where having different versions running alongside one-another is really handy, or not having to wait for your distro to include support for the version you require. Agreed that it looks like re-inventing the wheel from the outside; rest assured, it's useful!

burntsushi 9y ago

> Maybe, probably, I'm missing something here, but JavaScript and WebAssembly seem to be things that are not in the interest of users. The Rust project does not have a goal to destroy every single piece of technology that could be construed as user hostile. The reality is that if you want to write a widely used browser application, you need to use Javascript, and probably soon, optionally WebAssembly. Rust is well positioned to take advantage of that. (This is not an argument against the claim that Javascript/WebAssembly are user hostile. I have no real interest in discussing that, and frankly, there is no obvious conclusion to draw there. Instead, I'm pointing out a category error.)