Python cryptography, Rust, and Gentoo [LWN.net]

Python cryptography, Rust, and Gentoo

Posted Feb 15, 2021 10:25 UTC (Mon) by laarmen (subscriber, #63948)
In reply to: Python cryptography, Rust, and Gentoo by ceplm
Parent article: Python cryptography, Rust, and Gentoo

I think it has to do with the fact that Rust has really good tooling to manage the toolchain from a developer PoV along with a good backward compatibility. Upgrading the rustc version is assumed to be a trivial step (rustup update and voilà), and if you're an application author you can provide binaries for most platforms, which means the upgrade doesn't concern those users as there is no need for them to upgrade their runtime.

In contrast, most other languages either have a runtime component, which makes upgrading painful for all users, and/or an upgrade process that was not trivial when the community around the language started forming its habits. I would assume you'll find a similar attitude in the Go ecosystem.

to post comments

Python cryptography, Rust, and Gentoo

Posted Feb 15, 2021 12:03 UTC (Mon) by ceplm (subscriber, #41334) [Link] (3 responses)

That’s what I call immature environment: if it works on my laptop, it’s perfect, ship it!

Without considering maintenance costs, long-time support, and or combining multiple Rust projects in one system (e.g., Linux/Mac OS X distributions).

Python cryptography, Rust, and Gentoo

Posted Feb 15, 2021 13:47 UTC (Mon) by laarmen (subscriber, #63948) [Link] (1 responses)

You're putting words in my mouth.

The fact that application developer using Rust don't particularly care about sticking to a lower version of Rust is indeed partly because the language is still evolving and gaining features, for instance async/await which was not available in the version of rustc originally shipped with Debian (the situation has since changed). But my point is that it also comes from the fact that it is *very* easy for a Rust developer using what is considered the standard way of developing in Rust to install and use multiple versions of a toolchain, and for most users *from their PoV* the version of Rust doesn't matter since either they compile from source and can thus be expected to use standard (for Rust) tooling, or they are using already-compiled binaries with no runtime dependency on the version of Rust.

Saying that maintenance costs, long-time support and combining multiple Rust projects in one system isn't considered by the Rust community is just plainly false. It's just a matter of perspective : they consider that rustc is just another build-time dependency and it's okay to require those that build to bump it, which in its face makes sense : you're already updating something in your system (the project itself), it shouldn't be a big bother to update something else.

I'm not saying this is the absolute right choice, as there clearly is a mismatch with how distros work, but things are not black and white.

Python cryptography, Rust, and Gentoo

Posted Feb 15, 2021 14:32 UTC (Mon) by ceplm (subscriber, #41334) [Link]

> You're putting words in my mouth.

I am not. I haven’t mean it as pretending to quote you, or I haven’t even claimed that you would support this statement, but that it seems to me that this attitude is too present in the Rust community.

> […] the language is still evolving and gaining features, for instance async/await which was not available in the version of rustc originally shipped with Debian (the situation has since changed).

Yes, in other words, the language is still too immature for the projects of the size of Linux distros and similar.

Python cryptography, Rust, and Gentoo

Posted Feb 15, 2021 15:28 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

> and or combining multiple Rust projects in one system (e.g., Linux/Mac OS X distributions).
It works just fine with multiple Rust projects and environments (see https://doc.rust-lang.org/edition-guide/rust-2018/rustup-... ). I have several Rust versions installed on my laptop side-by-side for tests and cross-compilation.

And the fact that you mention Windows/macOS is especially funny, because Rustup has native installers for them, making experimenting with them very easy.

And of course, Cargo makes sure that libraries don't interfere with each other, so each project gets its own dependency closure.