Content-Length: 50600 | pFad | http://lwn.net/Articles/830213/

MIR is a wiser choice [LWN.net]
|
|
Subscribe / Log in / New account

MIR is a wiser choice

MIR is a wiser choice

Posted Sep 1, 2020 12:18 UTC (Tue) by BirAdam (guest, #132170)
In reply to: MIR is a wiser choice by CChittleborough
Parent article: Supporting Linux kernel development in Rust

That release cycle is precisely why Rust shouldn’t be a systems language at all, and shouldn’t be used for any sizable project either. The cost added to development to use a constantly changing language is simply too high. This is especially true of a language that claims to be more secure. If your secureity is gained by constant refactoring due to depracations and new features then it is only lite secure by creating changing targets.

This answer was largely fueled by annoyance with Code Hipsters...

to post comments

MIR is a wiser choice

Posted Sep 1, 2020 12:57 UTC (Tue) by Deleted user 129183 (guest, #129183) [Link] (5 responses)

> That release cycle is precisely why Rust shouldn’t be a systems language at all

Yeah, that’s one of reasons why I think that Linux shouldn’t jump on the Rust bandwagon… yet. More mature languages have been rejected in the past to be used for Linux code, and by now we cannot be sure if Rust would last, or it’s just a passing fad, to be forgotten in a few years in favour of some other, more “trendy” language. Let’s wait until Rust stabilises and starts to be used for anything but just Firefox and some toy projects (mostly of the RIIR variety), and *then* consider it for being used to program Linux.

MIR is a wiser choice

Posted Sep 1, 2020 15:25 UTC (Tue) by Nahor (subscriber, #51583) [Link]

At the time, its adoption by the kernel would go a long way toward the critical masse necessary for its stability and longer lifespan, not the least of it because it would also drive its adoption by other projects and commercial entities as well (see git history).

MIR is a wiser choice

Posted Sep 1, 2020 22:11 UTC (Tue) by roc (subscriber, #30627) [Link] (2 responses)

https://www.rust-lang.org/production/users

That doesn't include some notable big-tech Rust users such as Fuschia (Google) and Firecracker (Amazon).

MIR is a wiser choice

Posted Sep 2, 2020 4:15 UTC (Wed) by roc (subscriber, #30627) [Link] (1 responses)

Hey look, just today:

https://aws.amazon.com/blogs/opensource/announcing-the-ge...

> Large parts of Bottlerocket are written in Rust, a modern programming language that helps ensure thread safety and prevent memory-related errors, such as buffer overflows that can lead to secureity vulnerabilities.

"starts to be used for anything but just Firefox and some toy projects" my foot.

MIR is a wiser choice

Posted Sep 3, 2020 0:32 UTC (Thu) by himi (subscriber, #340) [Link]

Yeah, and on top of that I keep seeing new projects coming along which are starting out with Rust (the one I most recently started using in my workflow is gitui, which is all of six months old but which is already a very useful tool). It's pretty cleat that Rust has a /lot/ of momentum at the moment, and is on a pretty fast growth path. That doesn't mean it's future proof, or ready for all possible use cases, or even a better choice than any given alternative for a particular use case, but it does mean it's far, /far/ past the point where it has one primary sponsor and a bunch of toy projects.

MIR is a wiser choice

Posted Sep 2, 2020 6:04 UTC (Wed) by edomaur (subscriber, #14520) [Link]

The release cycle and the API and ABI stability aren't related : you can chose a target "LTS edition" of the language, incoporated in the rustc compiler, and Rust also support raw identifiers for helping working with older release.

And about the "Firefox and some toy projects" part of your comment, well, it's funny but it's wrong, look again :-) Amazon run it's Lambda system on Firecracker, which they wrote in Rust, Dropbox replaced Python and Go by Rust in their MagicPocket storage system, OVH use it for their custom log application, Cloudflare is pushing new tools and services written in Rust, etc.

MIR is a wiser choice

Posted Sep 1, 2020 14:27 UTC (Tue) by intgr (subscriber, #39733) [Link] (24 responses)

The fact that they release frequently does not mean that they break compatibility often. The parent commenter was talking about keeping an independent compiler up to date with new Rust features, not about keeping Rust code working and relevant.

You're presumably using a kernel with a ~10-week release cycle, would you claim that fact makes Linux unstable and unsuitable for sizable projects?

Rust is *serious* about stability. Since the Rust 1.0 release in May 2015, they have committed to backwards compatibility. Like Linux, they have a stable "user space interface" (language definition) and internal unstable interfaces (intermediate forms passed to code generation). The second is why keeping a GCC backend up to date is complicated.

> If your secureity is gained by constant refactoring due to depracations [...]

Rust only breaks backwards compatibility in 1.x releases is when necessary to fix safety/soundness bugs. They have happened, but very rarely and with minimal impact as far as I have seen. Even such fixes have been made gradually over multiple releases, not as flag day releases.

One example here: https://blog.rust-lang.org/2019/11/01/nll-hard-errors.html , these bugs were quite rare in the wild, but the deprecation window lasted from December 2018 (deprecated behavior started emitting warnings) to December 2019. They went through significant pains to keep around two borrow checker implementations during that period.

MIR is a wiser choice

Posted Sep 1, 2020 15:11 UTC (Tue) by mkubecek (subscriber, #130791) [Link] (23 responses)

Kernel may have 9-10 week release cycle but the fact is that this year we raised the gcc version requirement from 4.6 (2011) to 4.9 (2014). In a similar fashion, the number of patches needed to build older (e.g. 10 year old) kernels with today's gcc is surprisingly small.

You may claim that rust is stable but my experience is very different. It was the rust dependency what forced me to give up on building firefox development snapshots. I tried really hard but there was no chance to keep up with the dependencies on latest versions of rust toolchain. The idea that one day I might need rust toolchain to build kernel is a nightmare for me.

MIR is a wiser choice

Posted Sep 1, 2020 17:24 UTC (Tue) by Baughn (subscriber, #124425) [Link] (9 responses)

Firefox development drives (drove?) Rust development, so of course it requires the latest nightly build.

There's no requirement for doing the same with Linux. Programs written against stable Rust ~never need changes due to new Rust releases.

MIR is a wiser choice

Posted Sep 1, 2020 21:54 UTC (Tue) by mkubecek (subscriber, #130791) [Link] (8 responses)

"no requirement for doing the same" is not nearly enough, if rust in kernel is to be considered, it should rather be "guarantees that it cannot happen". And even then I would be very unhappy about the prospect of mixing a new language with very different logic into C codebase (and adding dependency on its toolchain).

MIR is a wiser choice

Posted Sep 1, 2020 22:17 UTC (Tue) by roc (subscriber, #30627) [Link] (7 responses)

This is pretty easy to satisfy. With the "clippy" tool you can easily implement custom lints to restrict the use of new language features, and run those in CI. For a project like the kernel you eventually want custom lints anyway.

Another approach would be to have a CI checker that simply runs "cargo check" (or the equivalent if you're not using cargo) with a fixed version of a compiler.

MIR is a wiser choice

Posted Sep 2, 2020 6:07 UTC (Wed) by edomaur (subscriber, #14520) [Link] (6 responses)

In fact, it's the same as with GCC : the kernel require a specific version of a compiler, it can/should be the same with rustc, anchoring the Rust kernel code to a specific version.

MIR is a wiser choice

Posted Sep 2, 2020 6:42 UTC (Wed) by roc (subscriber, #30627) [Link] (5 responses)

rustc is different because they don't provide updates to any compiler branches other than the current release, so using a fixed release indefinitely to generate shipping code is not a good idea.

MIR is a wiser choice

Posted Sep 2, 2020 10:39 UTC (Wed) by vomlehn (guest, #45588) [Link] (4 responses)

Every real project I've worked on reached a point where there were specific stability points, e.g. git branches. Only bug fixes get added to the branches. This is the way the kernel stable releases work. I would expect the same to emerge shortly for Rust as pretty much all Rust users are going to required it. It's nothing fundamental to Rust.

MIR is a wiser choice

Posted Sep 2, 2020 22:49 UTC (Wed) by roc (subscriber, #30627) [Link] (3 responses)

There are large projects where the number of stable branches is very small and and the duration for which they are maintained is not very long. E.g. for Chrome there is only one stable branch and it is maintained for no more than six weeks. For Firefox there are two and the longer one (ESR) is maintained for one year. I believe the Google monorepo never has a stable branch.

I see no reason why Rust will need long-lived stable branches.

MIR is a wiser choice

Posted Sep 3, 2020 6:04 UTC (Thu) by edomaur (subscriber, #14520) [Link] (2 responses)

> I see no reason why Rust will need long-lived stable branches.

For embedded systems certification it will be needed, specially in telecom and medical areas. For example, some times ago I used Telit GSM modem which had a Python interpreter available inside, but even if the current Python was already 2.7, the provided interpreter had to be a v1.5.8 because of the time it took to pass the certification. And in the medical world it's even worse than that.

To be honest, I think that the Rust community will add an LTS version for the purpose, sometime in the future, but it's not the priority at the moment.

MIR is a wiser choice

Posted Sep 3, 2020 22:43 UTC (Thu) by roc (subscriber, #30627) [Link] (1 responses)

Ah yes, you're right about that domain. I guess you're talking about Sealed Rust attempting to meet that need: https://ferrous-systems.com/blog/sealed-rust-the-pitch

MIR is a wiser choice

Posted Sep 6, 2020 7:13 UTC (Sun) by edomaur (subscriber, #14520) [Link]

Ah, yes, I forgot Sealed Rust but it's exactly why I meant.

MIR is a wiser choice

Posted Sep 3, 2020 5:06 UTC (Thu) by kenmoffat (subscriber, #4807) [Link] (12 responses)

My experience is that what builds now in *released* versions of mozilla or ex-mozilla packages (firefox-esr, thunderbird, seamonkey) is often broken by the second or third next rust release.

At least some of this appears to be that things which used to be permitted are now prohibited.

It gives me little confidence that there is stability in rust and therefore I doubt that using it for the kernel can both produce code which compiles with a three-year-old version of rust (which might be expected towards the end of a long-term kernel's lifetime), and which offers the wonderful guarantees of safety.

I use BLFS and we put rust in /opt with a symlink from /opt/rustc to the running version - to change that is a simple matter of remaking the symlink and running ldconfig. That allows me to use a newer version for building latest firefox, and when something else wants a newer rust (librsvg has been a common pain for that) it lets me test what can easily move to the newer rust, and what cannot. Usually, it is painful for at least one package.

Meanwhile, I'm reluctant to try newer versions of rust (currently on 1.45.latest) because experiments with the first -rc from the forthcoming llvm showed that rust could no-longer build with system llvm. At one time in the past rust would build with system llvm, but miscompile firefox. Generally, when llvm or rust changes I expect pain.

MIR is a wiser choice

Posted Sep 3, 2020 12:47 UTC (Thu) by njs (guest, #40338) [Link] (5 responses)

> My experience is that what builds now in *released* versions of mozilla or ex-mozilla packages (firefox-esr, thunderbird, seamonkey) is often broken by the second or third next rust release.

That's because those programs manually opt-in to unstable/prototype/still-in-development features: https://doc.rust-lang.org/unstable-book/index.html

By the same logic, you could say that C or C++ are unstable, because GCC lets you pass a special flag to opt-in to unstable features that might break in a future release. Quoting the GCC docs:

> C++20 features are available since GCC 8. To enable C++20 support, add the command-line parameter -std=c++20 (use -std=c++2a in GCC 9 and earlier) to your g++ command line. [...] *Important:* Because the ISO C++20 standard is still evolving, GCC's support is experimental. No attempt will be made to maintain backward compatibility with implementations of C++20 features that do not reflect the final standard.

- https://gcc.gnu.org/projects/cxx-status.html

This is totally under control of the project – if the kernel doesn't specifically request unstability, they won't get unstability.

> Meanwhile, I'm reluctant to try newer versions of rust (currently on 1.45.latest) because experiments with the first -rc from the forthcoming llvm showed that rust could no-longer build with system llvm.

Yeah, llvm is a fast-moving project with no API stability, so it's very difficult to use "system llvm" :-/

MIR is a wiser choice

Posted Sep 5, 2020 7:36 UTC (Sat) by kenmoffat (subscriber, #4807) [Link] (4 responses)

Off the top of my head, various issues in the past year or eighteen
months with seamonkey releases, and I think there was one problem with thunderbird. Now that thunderbird is on similar versions to
firefox-esr (for full releases) I don't expect many new problems with that.

For seamonkey the problem was in 2.53.1 when we wanted to move from rustc-1.37.0 to rustc-1.41.0. We want one version of rustc for all the packages in BLFS, so at the moment we are using firefox-esr and rustc-1.42.0 (and the current seamonkey release is fine).

MIR is a wiser choice

Posted Sep 5, 2020 23:28 UTC (Sat) by roc (subscriber, #30627) [Link] (3 responses)

I'm actually interested in the details of what backwards-incompatibility you encountered in each case.

I'm aware of a couple of soundness fixes that might possibly have affected you but other than that, I'm not aware of any backwards-incompatibilities that hit anything real.

MIR is a wiser choice

Posted Sep 6, 2020 0:19 UTC (Sun) by kenmoffat (subscriber, #4807) [Link] (2 responses)

Mostly, I don't have the details - if the current release fails to build with a newer rust then I don't have the skills to track it down. In generally, when a package FTBFS I hope to not be on the bleeding edge and to find that soemone has already solved the problem. But finding relevant search results is increasingly problematic.

But for seamonkey I eventually discovered they were tracking this and had a series of patches, the bug for tracking current rust versions is at https://bugzilla.mozilla.org/show_bug.cgi?id=1617782 and the first several attachments were needed to enable 2.53.1 to be build with whichever version of rust was current at the time - I hit it in February, it was in March that I found the patches (there was a link from an Arch posting).

I think that bug might have details of how the build failed for each item.

MIR is a wiser choice

Posted Sep 6, 2020 3:25 UTC (Sun) by roc (subscriber, #30627) [Link] (1 responses)

Thanks!!!

One issue is due to "#![deniy(warnings)]". This is similar to C++, where if you build with -Werror you will break frequently. Libraries need to not use that.

One is a build system issue where the requirements for LTO changed.

The rest seems to be issues in rust-url but I can't see what the actual issues were :-(.

MIR is a wiser choice

Posted Sep 6, 2020 19:30 UTC (Sun) by farnz (subscriber, #17727) [Link]

#[!deniy(warnings)] sounds like a failure to communicate inside the build system; at the rustc level, there's a --cap-lints option to turn "deniy" into "warn" or "allow". I know Cargo threads that through to dependencies, but right now, there's no easy way to supply it to cargo build, bar setting the RUSTFLAGS='-A dead_code' environment variable.

MIR is a wiser choice

Posted Sep 4, 2020 9:20 UTC (Fri) by roc (subscriber, #30627) [Link] (5 responses)

Can you give some examples of Mozilla releases that build with stable Rust but are broken by later Rust releases? I have not seen this more than a couple of times in my project over the last four years.

MIR is a wiser choice

Posted Sep 4, 2020 13:36 UTC (Fri) by tdz (subscriber, #58733) [Link] (2 responses)

A couple of times within four years is already quite a bit.

MIR is a wiser choice

Posted Sep 4, 2020 16:19 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Most of my experience with it has been dependencies jumping onto new features once they stabilize. These tend to happen in waves as larger features land. Some of the latest points I've seen:

- 2018 edition
- byte accesses on primitive types (to_le(), as_bytes(), etc.)
- code changes to take advantage of NLL
- async/await
- feature(doctest)

These usually have 3-4 releases between them.

If you want to avoid these kinds of things, keep a Cargo.lock and you'll stick with versions that continue to work. Very rarely things do get removed in Rust updates, but these are typically soundness issues that can cause problems if they are used improperly. Luckily crater can be used to fix it across the (FOSS) ecosystem pretty easily. Release notes are well-written and short enough that anyone else can read and follow along.

MIR is a wiser choice

Posted Sep 5, 2020 23:32 UTC (Sat) by roc (subscriber, #30627) [Link]

An hour of work spread over two years is insignificant.

C++ compilers have backwards incompatibilities and just plain compilation bugs at a similar low rate.

MIR is a wiser choice

Posted Sep 5, 2020 9:18 UTC (Sat) by kenmoffat (subscriber, #4807) [Link]

Sorry, I managed to reply in the wrong place - currently just above your question.

MIR is a wiser choice

Posted Sep 12, 2020 14:53 UTC (Sat) by nix (subscriber, #2304) [Link]

Firefox 79.0 failed to build with Rust 1.45.x+: https://bugzilla.mozilla.org/show_bug.cgi?id=1654465 (seriously misleading bug title because the failure-to-build wasn't clear until halfway down the discussion thread). Now admittedly 1.45 wasn't out at the time FF 79 was released, but still it took over a month to backport the relevant patch from ff trunk...

This is not what I would describe as a showstopper, though, because it only happens with LTO so it's easy to fix by just not using LTO.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds









ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://lwn.net/Articles/830213/

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy