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

Python cryptography, Rust, and Gentoo

Posted Feb 11, 2021 19:52 UTC (Thu) by rgmoore (✭ supporter ✭, #75)
In reply to: Python cryptography, Rust, and Gentoo by glaubitz
Parent article: Python cryptography, Rust, and Gentoo

Sure, but the problem is that this hasn't happened yet and one of the main reasons is the fact that the language is moving so fast that alternative implementations have trouble keeping up.

I don't think it's as much a matter of alternative implementations having trouble keeping up as it is Rust not yet having reached critical mass to justify an alternative implementation. C and C++ have enough users to justify multiple FOSS implementations and multiple independent proprietary ones. Rust doesn't have that kind of user base yet.

My impression is that the perception of Rust as changing rapidly is driven by the way the compiler is developed. The developers have often used features new to release N when writing release N+1, so anyone who wants to bootstrap from another language will have to build every version of the compiler to get to the current version. That leads to the perception that the language as a whole is developing at a breakneck pace, even though it has a good history of preserving backward compatibility.

to post comments

Python cryptography, Rust, and Gentoo

Posted Feb 11, 2021 19:57 UTC (Thu) by glaubitz (subscriber, #96452) [Link] (4 responses)

> That leads to the perception that the language as a whole is developing at a breakneck pace, even though it has a good history of preserving backward compatibility.

It may have backward compatibility, but the main problem is that many upstream projects adopt new language feature rather quickly which means that distributions with longer release cycles such as Debian, RHEL or SLE will have to backport new versions of the Rust compiler when updating packages like Firefox.

I have not observed this particular problem with C/C++ code while maintaining packages for an LTS distribution.

Python cryptography, Rust, and Gentoo

Posted Feb 11, 2021 21:01 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (3 responses)

Eh, the "core" libraries that "everyone" depends on tends to keep the MSRV (minimum suitable Rust version) pretty low, or at least documented. Sure, things get bumped occasionally, not that even that pace is suitable for LTS distro cadences, but it isn't a mad rush to use the latest-and-greatest for the entire ecosystem.

Python cryptography, Rust, and Gentoo

Posted Feb 12, 2021 4:54 UTC (Fri) by plugwash (subscriber, #29694) [Link] (2 responses)

The reality in Debian is that due to the huge number of security holes that web browsers acrete and the fact that even the LTS release cycles of firefox are much shorter than those of a stable release they are practically forced to upgrade to new release series of firefox within a stable release.

Before firefox/thunderbird started using rust, this wasn't a huge problem, the firefox package could be updated largely independently of everything else. Nowadays though, a new release series of firefox basically means a new release of rustc.

And that breaks things. Sure the rustc developers have defined a stable subset, but a bunch of crates depend on less stable features. Some of this through the officially endorsed "feature gates" mechanism, others through a certain flag that is not supposed to be used by user code but is anyway that lets you use "nightly" features on a stable compiler.

Python cryptography, Rust, and Gentoo

Posted Feb 12, 2021 13:52 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (1 responses)

> Some of this through the officially endorsed "feature gates" mechanism, others through a certain flag that is not supposed to be used by user code but is anyway that lets you use "nightly" features on a stable compiler.

Feature gates can only be opened on a nightly compiler. The stable compiler does not let you use them (unless you masquerade as the stdlib with some internal flags, but then you're in a "you get to keep both pieces" situation anyways).

What you're probably actually seeing is the crates using the newer language/stdlib features of *stable* rust releases.

Python cryptography, Rust, and Gentoo

Posted Feb 15, 2021 8:56 UTC (Mon) by glaubitz (subscriber, #96452) [Link]

> What you're probably actually seeing is the crates using the newer language/stdlib features of *stable* rust releases.

I'm pretty sure I have seen crates that required Rust nightly in the past.

Building rustfmt is one of such cases: https://github.com/rust-lang/rustfmt#installing-from-source

Python cryptography, Rust, and Gentoo

Posted Feb 11, 2021 21:29 UTC (Thu) by josh (subscriber, #17465) [Link]

> Rust not yet having reached critical mass to justify an alternative implementation

Rust is permissively licensed, which removes much of the motivation for any alternative implementation.

And personally, I'm hopeful that mrustc will meet any regulatory or similar requirements for "alternative implementation", so that we don't need another one for that reason either.

I hope that we go as long as possible *without* an alternative implementation, to avoid fragmenting the ecosystem by expecting crate authors to use the subset of Rust provided by that implementation.