5 ms·

While rust certainly does a lot of things right, it is still a moving target with a relatively high velocity. There is a python library that recently switched

While rust certainly does a lot of things right, it is still a moving target with a relatively high velocity. There is a python library that recently switched to rust (partially) and now cannot be build on several platforms. This also means that very long-lived platforms will probably be forced to upgrade that library every half year or so in line with the development of rust. I'd say such an initiative needs a long-term supported version of rust, similar to C99 or so. And this does not even account for cargo. I know you don't have to use cargo, but is that practical? How are we going to maintain stable software for, say, ten years or more? Do we have anyone committed to providing a stable rust environment for these cases? Especially considering that rust has no ABI for dynamic libraries. Oh and by the way: We need a way to bootstrap rust as well. The current distribution downloads binaries of the last one to build itself. And it ships with a vendored version of llvm. So in conclusion: I really like the rust language. But I am concerned that it is still way too immature and to "hip" for long-running, stable projects.

wizzwizz4 6y ago
We have a way to bootstrap Rust: https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc
sammorrowdrums 6y ago
Was this an encryption library by any chance? Generating pgp keys to yubikey with an offline master involved having a system with rust toolchain in order to build a Python lib I required for a Yubikey utility. I could have got around it, but it took me by surprise that a Python dep required it. Not being negative or criticising the fact, just first time I had observed it.
- gpm 6y ago
  It was, "cryptography".
cp9 6y ago
> There is a python library that recently switched to rust (partially) and now cannot be build on several platforms. there comes a point where we can't let dependencies on Amiga or DEC Alpha (companies/platforms that haven't existed in literal decades) hold the rest of us back. If someone wants to port rust/llvm to those platforms more power to them, but the rest of us don't need to suffer. The only platform that actually matters that was negatively effected by that change is musl/alpine because there aren't musl wheels available and you have to build the rust part from source.
- notacoward 6y ago
  > dependencies on Amiga or DEC Alpha What about embedded platforms, which tend to remain relevant (i.e. present in large numbers out in the real world) much longer than desktop or server platforms? Don't they matter? Don't they need updates, including for security, as much as any other?
  - bowyakka 6y ago
    Is it not a bit of a paradox that said embedded platforms matter enormously right up to, but not including the point of having toolchains ported to them and maintained? And yes while gcc can be built to produce binaries for an alpha it's not producing any bugs right?
    - saagarjha 6y ago
      The interests of people writing new language toolchains sadly does not seem to extend to supporting older platforms. This doesn't mean that they are not important, it just means that that they are not important to the people writing the new language toolchains.
      - wmf 6y ago
        It's not a matter of interest; if an embedded platform matters they should be willing to pay someone to port Rust.
gpm 6y ago
> This also means that very long-lived platforms will probably be forced to upgrade that library every half year or so in line with the development of rust. As a security library... you really ought to be updating it every half year of so. This has nothing to do with rust though. Rust maintains full backwards compatibility, so even if you upgrade the compiler (which is unlikely on long lived platforms) and not the library nothing breaks. Nor is it necessarily the case that upgrading the library will require updating rust (though this isn't what you appear to be complaining about). Not only is it a build time dependency (that you don't even need to install if you are on common platforms which ave prebuilt binaries), but they are explicitly testing against a particular fixed old version of rust as well as recent ones: https://github.com/pyca/cryptography/blob/main/.github/workflows/ci.yml#L145 https://github.com/pyca/cryptography/blob/main/.github/workf... > I'd say such an initiative needs a long-term supported version of rust, similar to C99 or so. This describes every version of rust since 1.0. Rust is fully backwards compatible, unlike new C standards. > Do we have anyone committed to providing a stable rust environment for these cases? Yes, the entire rust team... > Especially considering that rust has no ABI for dynamic libraries. This is... rather irrelevant? Technically it does have support for the C abi for dynamic libraries though.
- choeger 6y ago
  I think you should reconsider the actual problem, if you do not understand it. The fact that rustc is backwards compatible is great, sure. But it does not solve the problem of distributors. Say you have libfoo-1.0 that uses rust and cargo 1.2 . A distributor that now releases their linux version and wants to ship libfoo-1.0 must consider the requirements for supporting it. This support usually outlives the upstream support. If libfoo-1.0 uses C, for instance, it is highly likely that a distributor can backport any security-relevant changes from libfoo-1.1, 1.2, and later into 1.0. In the case of rust there are two uncertainties creeping in: One is the highly dynamic nature of cargo dependencies. libfoo might depend on a myriad of crates transitively and rust simply is too young to provide any experience in how long they will be available or supported. And no, it is generally not a good idea to update to new feature releases for security updates. This is something that stable distributions explicitly try to avoid. So our distributor now must consider if changes in libfoo-1.2 pulled in changes via cargo that cannot be easily backported because they are feature releases or have a dependency on a newer version of rust. The second problem is the compiler itself. Any change in libfoo-1.2 might require a newer version of rust. It is great that they want to be backwards compatible but now our distributor must consider upgrading a substantial piece of software during the support period (and testing the backwards compatibility, of course) just to backport a security fix. Please don't get me wrong, I really like rust and I think these problems can be solved. But I also like stable software and all these languages with their package repositories seem to simply ignore everything that's older than one or two years. If rust wants to become a new C, which I would very much like, it needs to demonstrate a certain stability.
pid_0 6y ago
>There is a python library that recently switched to rust (partially) and now cannot be build on several platforms. Progress should not be held back for the rest of us because a few will get left behind. If you are running something so old that LLVM doesn't support it, upgrade. It's 2021.
- varajelle 6y ago
  LLVM does not support every proprietary embedded device. And even if it did, rust support does not come for free. (One must add support for the target ABI and other stuff)
- saagarjha 6y ago
  I guarantee you that there is a device in your house that Rust does not target.
adamnemecek 6y ago
At some point, they had to switch from Python 2 to Python 3 no?

wizzwizz4 6y ago

We have a way to bootstrap Rust: https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc

sammorrowdrums 6y ago

Was this an encryption library by any chance? Generating pgp keys to yubikey with an offline master involved having a system with rust toolchain in order to build a Python lib I required for a Yubikey utility. I could have got around it, but it took me by surprise that a Python dep required it. Not being negative or criticising the fact, just first time I had observed it.

gpm 6y ago
It was, "cryptography".

cp9 6y ago

> There is a python library that recently switched to rust (partially) and now cannot be build on several platforms. there comes a point where we can't let dependencies on Amiga or DEC Alpha (companies/platforms that haven't existed in literal decades) hold the rest of us back. If someone wants to port rust/llvm to those platforms more power to them, but the rest of us don't need to suffer. The only platform that actually matters that was negatively effected by that change is musl/alpine because there aren't musl wheels available and you have to build the rust part from source.

notacoward 6y ago
> dependencies on Amiga or DEC Alpha What about embedded platforms, which tend to remain relevant (i.e. present in large numbers out in the real world) much longer than desktop or server platforms? Don't they matter? Don't they need updates, including for security, as much as any other?
- bowyakka 6y ago
  Is it not a bit of a paradox that said embedded platforms matter enormously right up to, but not including the point of having toolchains ported to them and maintained? And yes while gcc can be built to produce binaries for an alpha it's not producing any bugs right?
  - saagarjha 6y ago
    The interests of people writing new language toolchains sadly does not seem to extend to supporting older platforms. This doesn't mean that they are not important, it just means that that they are not important to the people writing the new language toolchains.
    - wmf 6y ago
      It's not a matter of interest; if an embedded platform matters they should be willing to pay someone to port Rust.

gpm 6y ago

> This also means that very long-lived platforms will probably be forced to upgrade that library every half year or so in line with the development of rust. As a security library... you really ought to be updating it every half year of so. This has nothing to do with rust though. Rust maintains full backwards compatibility, so even if you upgrade the compiler (which is unlikely on long lived platforms) and not the library nothing breaks. Nor is it necessarily the case that upgrading the library will require updating rust (though this isn't what you appear to be complaining about). Not only is it a build time dependency (that you don't even need to install if you are on common platforms which ave prebuilt binaries), but they are explicitly testing against a particular fixed old version of rust as well as recent ones: https://github.com/pyca/cryptography/blob/main/.github/workflows/ci.yml#L145 https://github.com/pyca/cryptography/blob/main/.github/workf... > I'd say such an initiative needs a long-term supported version of rust, similar to C99 or so. This describes every version of rust since 1.0. Rust is fully backwards compatible, unlike new C standards. > Do we have anyone committed to providing a stable rust environment for these cases? Yes, the entire rust team... > Especially considering that rust has no ABI for dynamic libraries. This is... rather irrelevant? Technically it does have support for the C abi for dynamic libraries though.

choeger 6y ago
I think you should reconsider the actual problem, if you do not understand it. The fact that rustc is backwards compatible is great, sure. But it does not solve the problem of distributors. Say you have libfoo-1.0 that uses rust and cargo 1.2 . A distributor that now releases their linux version and wants to ship libfoo-1.0 must consider the requirements for supporting it. This support usually outlives the upstream support. If libfoo-1.0 uses C, for instance, it is highly likely that a distributor can backport any security-relevant changes from libfoo-1.1, 1.2, and later into 1.0. In the case of rust there are two uncertainties creeping in: One is the highly dynamic nature of cargo dependencies. libfoo might depend on a myriad of crates transitively and rust simply is too young to provide any experience in how long they will be available or supported. And no, it is generally not a good idea to update to new feature releases for security updates. This is something that stable distributions explicitly try to avoid. So our distributor now must consider if changes in libfoo-1.2 pulled in changes via cargo that cannot be easily backported because they are feature releases or have a dependency on a newer version of rust. The second problem is the compiler itself. Any change in libfoo-1.2 might require a newer version of rust. It is great that they want to be backwards compatible but now our distributor must consider upgrading a substantial piece of software during the support period (and testing the backwards compatibility, of course) just to backport a security fix. Please don't get me wrong, I really like rust and I think these problems can be solved. But I also like stable software and all these languages with their package repositories seem to simply ignore everything that's older than one or two years. If rust wants to become a new C, which I would very much like, it needs to demonstrate a certain stability.

pid_0 6y ago

>There is a python library that recently switched to rust (partially) and now cannot be build on several platforms. Progress should not be held back for the rest of us because a few will get left behind. If you are running something so old that LLVM doesn't support it, upgrade. It's 2021.

varajelle 6y ago
LLVM does not support every proprietary embedded device. And even if it did, rust support does not come for free. (One must add support for the target ABI and other stuff)
saagarjha 6y ago
I guarantee you that there is a device in your house that Rust does not target.

adamnemecek 6y ago

At some point, they had to switch from Python 2 to Python 3 no?