4 ms·

Congratulations on the release! `cdylib` targets should prove very helpful for embedding, and compilation from a recent stable version will make it much easier

Congratulations on the release! `cdylib` targets should prove very helpful for embedding, and compilation from a recent stable version will make it much easier to package.

snuxoll 10y ago
The bootstrap problem is exactly why rust isn't in the Fedora repos right now, so I am very excited about this. Also, dylib will likely end up being preferred for distribution packaging (especially Fedora which HEAVILY discourages static linking, though there's no longer a strict no-static linking policy).
- evmar 10y ago
  It's too bad that Rust went to all this language design effort to allow inlining (including when passing a closure to a function, which is really impressive!) only to have distros undo it for some policy that ends up harming their users more than it helps.
  - snuxoll 10y ago
    Static linking has benefits, but from a distribution standpoint it makes handling security updates (which people expect to be done correctly and in a timely manner) a HUGE pain in the ass. You want to go statically link your internal rust binary that you are pushing out to hundreds or thousands of nodes and you need the extra performance? Go for it, you can handle rebuilding it every time there is a security update (and last I checked dylib's allow both static and dynamic linking against them, so you have that option). But if you want to include your binary in a distribution package repository it really should be dynamically linked, tracking what dependencies everything has and forcing rebuilds and updates for EVERY SINGLE BINARY that uses them is wasteful and a pain to manage.
    - slimsag 10y ago
      This draft document[1] suggests that Fedora will use the "rebuild all packages" option for packaging Go programs, since it's unlikely to support dynamic linking in the traditional fashion any time soon. [1] https://fedoraproject.org/wiki/PackagingDrafts/Go#Security_in_Go_Language_Packages https://fedoraproject.org/wiki/PackagingDrafts/Go#Security_i...
      - lisivka 10y ago
        I hate Go for exactly that reason.
      - snuxoll 10y ago
        Not much of a choice for Go, but Rust does give the option for dynamic linking so I suspect the Fedora project will take advantage of it. There is no tooling in Koji to support mass rebuilds when dependencies are updated like this, which is why in rawhide when you are about to make an soname bump you are supposed to notify anyone who depends on the package of the change so they can bump the release of their packages afterwards. I can't say anything about the build tooling other releases use (I only have real experience with Koji and a limited look at OpenSUSE's OBS), but I don't think (m)any support "rebuild all that depends on this package" without manual intervention. It's really a crappy situation to be put in by language designers who value their use case over all else, and while, again, I think static linking can have a place it really doesn't belong in distribution repositories if it can be helped.
    - evmar 10y ago
      Computers are good at tracking dependencies. It seems silly particularly in this case because Rust is harder to use than a garbage-collected high-level language exactly because it is trying to squeeze out these last optimizations, and then we turn those optimizations off because it's... what, too hard to automate rebuilding some binaries? It's as if they mandated you write your apps in Python because they didn't want to spend time compiling C apps.
      - goodplay 10y ago
        While statically linking most certainly has its use-cases (as the parent comment pointed out), it unjustifiably presents challenges that would not otherwise occur. To elaborate on the parent's example: a particularly bad bug in a library depended on by a set of programs might not cause much of problem if you build and deploy this software yourself. However, it would be a more significant endeavor on both the distribution's part (recompile, repackage, sign-off, and release every program in the set), and on the user's part who has to download the large binaries each time a dependency is updated rather than a small library. This problem is further exacerbated by the npm-like dependency graphs rust programs tend to end up with. Take servo as an extreme example of what these graphs might look like: https://web.archive.org/web/20160703132700/https://dirkjan.ochtman.nl/files/servo-graph.svg https://web.archive.org/web/20160703132700/https://dirkjan.o... Furthermore, I don't see how dynamic linking prevents the compiler from optimizing the resulting binaries. C libraries have been dynamically linked for decades without issue.
        snuxoll 10y ago
        You forgot an important step: recompile, repackage, TEST, sign-off, and release every program in the set. Updates in Fedora sit in updates-testing for a week unless the package gets enough karma from users testing the package, there's a fast track for certain security updates but having to push dozens of packages that depend on a library through this is a giant pain and causes a huge headache. With dynamic libraries we can just update the library, get it through the testing phase (and if necessary fast track a single update) and move on with life. As far as the GP's point about optimization, rustc can inline a lot of code from linked crates if you are compiling statically, which in tight loops can be a very useful performance optimization due to not needing to spend cycles on setting up a new stack frame and calling the function. However, like you say, applications written in C/C++ have used dynamic linking for ages and it is usually quite rare to need optimizations this deep - if YOU need them for your application please feel free, but in general dynamic linking should still be preferred.
- moosingin3space 10y ago
  Do you think it would be reasonable to package rustup in the Fedora repos? I ask because for a development machine, it makes more sense to be able to install multiple toolchains in parallel.
  - snuxoll 10y ago
    In the repos directly? No, probably not. rbenv and pyenv aren't in the repos either, I'm not aware of any specific policy against it but it introduces some hesitance to provide software in the repos that can be used to then install software that may conflict with software managed by the package manager itself. rubygems, setuptools/pip and cargo as examples only typically handle installation of libraries and are generally "well behaved" citizens that put files in specific locations and don't install or manage new versions of the underlying language runtime, meanwhile rbenv/pyenv/rustup can mess with your path and potentially cause conflicts that could end up with people filing bugs that are closed "not our problem, we support this one specific environment that's in the repos". Someone is welcome to try, feel free to open a thread on the fedora-devel mailing list and see what anyone else thinks. But even if rustup doesn't make it into the official repos I don't see why someone couldn't put it up on COPR.
    - tmzt 10y ago
      Could rustup use PackageKit/yum/dnf to do this on Fedora? It would be really nice to be able to point to one command in the documentation that would work whether installed directly by the developer or provided by a distro. Debian specifically provides it's own alternatives system to handle symlinks in a global manner, but nothing for directory-specific ones. I'm not sure about Fedora. With `rustup` replacing `multirust`, it would be useful to point to a common command that in turn would call the distro-provided facility for global links. Also, congratulations on 1.10! Looking forward to servo.apk in the coming weeks as well.
  - snuxoll 10y ago
    As an addendum, there's nothing preventing anyone from packaging multiple versions of Rust assuming it properly supports it (for example installing to /usr/bin as rustc1.10, then we can symlink /usr/bin/rustc to the most recent one) - and if Rust releases a 2.0 at some point it is likely that there will be multiple versions available for a release or two while programs are modified to be compatible with the newer release. However, as Rust is fairly commited to semver I don't see much use in this UNTIL there is a new major release.

Congratulations on the release! `cdylib` targets should prove very helpful for embedding, and compilation from a recent stable version will make it much easier to package.

snuxoll 10y ago

The bootstrap problem is exactly why rust isn't in the Fedora repos right now, so I am very excited about this. Also, dylib will likely end up being preferred for distribution packaging (especially Fedora which HEAVILY discourages static linking, though there's no longer a strict no-static linking policy).

evmar 10y ago
It's too bad that Rust went to all this language design effort to allow inlining (including when passing a closure to a function, which is really impressive!) only to have distros undo it for some policy that ends up harming their users more than it helps.
- snuxoll 10y ago
  Static linking has benefits, but from a distribution standpoint it makes handling security updates (which people expect to be done correctly and in a timely manner) a HUGE pain in the ass. You want to go statically link your internal rust binary that you are pushing out to hundreds or thousands of nodes and you need the extra performance? Go for it, you can handle rebuilding it every time there is a security update (and last I checked dylib's allow both static and dynamic linking against them, so you have that option). But if you want to include your binary in a distribution package repository it really should be dynamically linked, tracking what dependencies everything has and forcing rebuilds and updates for EVERY SINGLE BINARY that uses them is wasteful and a pain to manage.
  - slimsag 10y ago
    This draft document[1] suggests that Fedora will use the "rebuild all packages" option for packaging Go programs, since it's unlikely to support dynamic linking in the traditional fashion any time soon. [1] https://fedoraproject.org/wiki/PackagingDrafts/Go#Security_in_Go_Language_Packages https://fedoraproject.org/wiki/PackagingDrafts/Go#Security_i...
    - lisivka 10y ago
      I hate Go for exactly that reason.
    - snuxoll 10y ago
      Not much of a choice for Go, but Rust does give the option for dynamic linking so I suspect the Fedora project will take advantage of it. There is no tooling in Koji to support mass rebuilds when dependencies are updated like this, which is why in rawhide when you are about to make an soname bump you are supposed to notify anyone who depends on the package of the change so they can bump the release of their packages afterwards. I can't say anything about the build tooling other releases use (I only have real experience with Koji and a limited look at OpenSUSE's OBS), but I don't think (m)any support "rebuild all that depends on this package" without manual intervention. It's really a crappy situation to be put in by language designers who value their use case over all else, and while, again, I think static linking can have a place it really doesn't belong in distribution repositories if it can be helped.
  - evmar 10y ago
    Computers are good at tracking dependencies. It seems silly particularly in this case because Rust is harder to use than a garbage-collected high-level language exactly because it is trying to squeeze out these last optimizations, and then we turn those optimizations off because it's... what, too hard to automate rebuilding some binaries? It's as if they mandated you write your apps in Python because they didn't want to spend time compiling C apps.
    - goodplay 10y ago
      While statically linking most certainly has its use-cases (as the parent comment pointed out), it unjustifiably presents challenges that would not otherwise occur. To elaborate on the parent's example: a particularly bad bug in a library depended on by a set of programs might not cause much of problem if you build and deploy this software yourself. However, it would be a more significant endeavor on both the distribution's part (recompile, repackage, sign-off, and release every program in the set), and on the user's part who has to download the large binaries each time a dependency is updated rather than a small library. This problem is further exacerbated by the npm-like dependency graphs rust programs tend to end up with. Take servo as an extreme example of what these graphs might look like: https://web.archive.org/web/20160703132700/https://dirkjan.ochtman.nl/files/servo-graph.svg https://web.archive.org/web/20160703132700/https://dirkjan.o... Furthermore, I don't see how dynamic linking prevents the compiler from optimizing the resulting binaries. C libraries have been dynamically linked for decades without issue.
      - snuxoll 10y ago
        You forgot an important step: recompile, repackage, TEST, sign-off, and release every program in the set. Updates in Fedora sit in updates-testing for a week unless the package gets enough karma from users testing the package, there's a fast track for certain security updates but having to push dozens of packages that depend on a library through this is a giant pain and causes a huge headache. With dynamic libraries we can just update the library, get it through the testing phase (and if necessary fast track a single update) and move on with life. As far as the GP's point about optimization, rustc can inline a lot of code from linked crates if you are compiling statically, which in tight loops can be a very useful performance optimization due to not needing to spend cycles on setting up a new stack frame and calling the function. However, like you say, applications written in C/C++ have used dynamic linking for ages and it is usually quite rare to need optimizations this deep - if YOU need them for your application please feel free, but in general dynamic linking should still be preferred.
moosingin3space 10y ago
Do you think it would be reasonable to package rustup in the Fedora repos? I ask because for a development machine, it makes more sense to be able to install multiple toolchains in parallel.
- snuxoll 10y ago
  In the repos directly? No, probably not. rbenv and pyenv aren't in the repos either, I'm not aware of any specific policy against it but it introduces some hesitance to provide software in the repos that can be used to then install software that may conflict with software managed by the package manager itself. rubygems, setuptools/pip and cargo as examples only typically handle installation of libraries and are generally "well behaved" citizens that put files in specific locations and don't install or manage new versions of the underlying language runtime, meanwhile rbenv/pyenv/rustup can mess with your path and potentially cause conflicts that could end up with people filing bugs that are closed "not our problem, we support this one specific environment that's in the repos". Someone is welcome to try, feel free to open a thread on the fedora-devel mailing list and see what anyone else thinks. But even if rustup doesn't make it into the official repos I don't see why someone couldn't put it up on COPR.
  - tmzt 10y ago
    Could rustup use PackageKit/yum/dnf to do this on Fedora? It would be really nice to be able to point to one command in the documentation that would work whether installed directly by the developer or provided by a distro. Debian specifically provides it's own alternatives system to handle symlinks in a global manner, but nothing for directory-specific ones. I'm not sure about Fedora. With `rustup` replacing `multirust`, it would be useful to point to a common command that in turn would call the distro-provided facility for global links. Also, congratulations on 1.10! Looking forward to servo.apk in the coming weeks as well.
- snuxoll 10y ago
  As an addendum, there's nothing preventing anyone from packaging multiple versions of Rust assuming it properly supports it (for example installing to /usr/bin as rustc1.10, then we can symlink /usr/bin/rustc to the most recent one) - and if Rust releases a 2.0 at some point it is likely that there will be multiple versions available for a release or two while programs are modified to be compatible with the newer release. However, as Rust is fairly commited to semver I don't see much use in this UNTIL there is a new major release.