LWN: Comments on "Rust is the future of systems programming, C is the new Assembly (Packt)"

Rust is the future of systems programming, C is the new Assembly (Packt)

ceplm — Wed, 11 Nov 2020 15:08:21 +0000

> I was under the impression that go-oo forked off during Sun's tenure, because it was GPL in name only ...

There was some disagreements about the build system, and some components (Sun OOo was perfectly open source but with CLA, which some contributors were not willing to sign, because also sold OOo under proprietary license). However, where CLA was signed, there were not that many problems, and for example Red Hat (especially Caolán McNamara and others) provided patches to Sun quite regularly. That all broke down when Oracle took over Sun, and one of the steps towards LibreOffice was when exactly Red Hat gave up on OOo and joined go-oo to create new foundation.

Irrelevance

jerrywrice@fabnexus.com — Wed, 28 Oct 2020 22:49:48 +0000

Regarding embedded systems Rust code with (FFI) c code makes sense, assuming there's a Rust compiler (back-end) for the target embedded HW platform.

Rust is the future of systems programming, C is the new Assembly (Packt)

jerrywrice@fabnexus.com — Wed, 28 Oct 2020 22:35:02 +0000

I see value in first generating a new Linux device driver as a test-bed for Rust's adoption as a kernel development language offers a low risk entry, and could well lead to identifying additional new low-level interface features that will improve Rust's usefulness and viability in similar low-level system use cases.

Rust is the future of systems programming, C is the new Assembly (Packt)

silvergate — Tue, 26 Nov 2019 15:47:50 +0000

Why not (re-) try to do something like UDI (http://www.projectudi.org/) in Rust? I don't know much about driver development, but an abstract driver framework looks interesting: You write the framework (API) once, drivers once and two (or more) implementations (one for linux and one for Redox)... and can use the same driver on linux and Redox. Another pro: this would curcument the unstable linux driver API problem, con: overhead, a lot of work (more?).

Relevance

moltonel — Sun, 08 Sep 2019 20:46:37 +0000

Currently the most production-ready rust GUI libs are binding to GTK and (to a lesser degree) Qt. These bindings work just as well as the equivalent bindings in other languages, but they are less palatable in Rust than in, for example, Python for a few reasons:

* You're bringing in a huge amount of code that is "unsafe" in Rust parlance. This isn't to say that GTK is full of bugs, but selecting a memory-safe language to run mostly memory-unsafe code is frustrating.
* Most GUI libs (GTK included) are based on the assumption that you can mutate any data that you have a handle on. This clashes with Rust's ownership model. It's not just about adding a mutex here and there, it's about going up and down the widget tree. It can of course be done, but it results in a very non-rust-like API. There's the same kind of tension when working with Wayland protocols for example.

So there are a lot of alternative GUIs in the Rust world at the moment. Some webrender-based (reminiscent of Electron but not as bad), some data-driven, some message-passing, some cross-platform, some ad-hoc... Plenty of usable stuff but nothing that's as stable and featureful as GTK/Qt yet. Time (a lot of it) will tell which ones will rise to prominence and perhaps even get used outside of Rust. At least, using a Rust API from C/C++ should be more straightforward than using a C/C++ API from Rust ;)

Relevance

ceplm — Sat, 07 Sep 2019 17:45:58 +0000

Hmm, thanks, that sounds like really excessive. With such requirements, they have to either write their own replacement for Gtk/Qt/something in Rust, and that wouldn’t happen for many years, or they will bind to something Electron, which is not any more safe than something like Gtk (actually, I would argue, it is less safe). I am really curious what will be the conclusion on this matter.

Relevance

micka — Sat, 07 Sep 2019 11:39:03 +0000

That serms to be the general opinion of the (or part of) the rust community https://areweguiyet.com/

They tend to pretty strict on the solutions they propose themselves and iterate at the 0.x semver level until completely satisfied.
The opinion is pretty much the same for the web, not that it prevent you for doing it anyway. It just means the current solution may not be the same ones as those next year, or that compatibility would be guaranteed.

Relevance

ceplm — Sat, 07 Sep 2019 08:20:51 +0000

> I didn't say that GUIs are the only thing that C++ is good for, rather that GUIs are something that Rust is currentlly comparatively bad at.

I don’t know, but I use neovim-gtk (https://github.com/daa84/neovim-gtk) daily and it seems to work just fine. What is supposed to be wrong with Rust and GUI?

Relevance

moltonel — Fri, 06 Sep 2019 20:17:05 +0000

I didn't say that GUIs are the only thing that C++ is good for, rather that GUIs are something that Rust is currentlly comparatively bad at. In contrast, Rust would have less trouble with the other areas you mentioned (there'll still be some library gaps, but small enough to be worth the effort).

Regarding places where you'd still choose C over C++ (ignoring programmer familiarity andvpre-existing environement), the original article summarize it as "low-level stuff like firmware and kernels", and I would extend that to small libs that need to expose a C ABI and small kernel utilities. YMMV of course.

The "use the language as it is meant to be" argument is a tired one, whose main flaw is that it relies on a mythical "good prigrammer".

C++, like C, isn't going to die any time soon. But the set of pojects where it's the best tool for the job is shrinking each year, even with the newer C++ versions. You may not feel like it's time to switch yet, but a growing number of people are. Rust is only one of the replacements, but it's the most serious one in the GC-free category.

Irrelevance

kragil — Thu, 05 Sep 2019 12:52:38 +0000

C++ is a complete and utter mess and needs to die a long slow death.

Everybody is working on replacing it. Even in games people work on language that are better suited for the job.
The future is Rust/Swift/Go/etc. My guess is that C will have a healthier life ahead than C++.

Rust is the future of systems programming, C is the new Assembly (Packt)

nix — Mon, 02 Sep 2019 10:00:57 +0000

The GPL does not actually carry any kind of requirement that external contributors' contributions be accepted, or even read. (Old GNU projects in the cathedral era were famously hard to get stuff into, and if they're not GPLed, nothing is.)

What saves this is exactly what you noted: the freedom to fork. If a project is both nonresponsive and has enough problems or enough frustrated developers, it'll fork -- and these days, it's so easy to set up the infrastructure for a fork that the number of frustrated developers is probably one and the definition of nonresponsive may well be "did not reply to patch yet because maintainer was away getting a coffee" :P

Rust is the future of systems programming, C is the new Assembly (Packt)

Wol — Mon, 02 Sep 2019 09:14:34 +0000

There's plenty of "proprietary" stuff that's GPL'd.

Tell me, how many contributions written by non-Sun staff actually made it into Sun OpenOffice?

I was under the impression that go-oo forked off during Sun's tenure, because it was GPL in name only ...

Cheers,
Wol

Rust is the future of systems programming, C is the new Assembly (Packt)

moltonel — Mon, 02 Sep 2019 09:13:26 +0000

The list I was working with is Alpha/PA-RISC/m68K/sh4,: roc argued that they weren't a priority, from which mirabilos concluded that the rust toolchain was a toy. So no offense to RISC-V, I'm not pushing it in the museum yet ;)

tl;dr: Rust is NFG. Try again in 2030.

flussence — Mon, 02 Sep 2019 01:37:18 +0000

Where can I get a copy of the point-scoring system you use for all that green ink?

Rust is the future of systems programming, C is the new Assembly (Packt)

flussence — Mon, 02 Sep 2019 01:28:38 +0000

The comment I replied to seems to be using a strange definition of “all”, then.

tl;dr: Rust is NFG. Try again in 2030.

roc — Sun, 01 Sep 2019 20:58:01 +0000

Superior trolling. Good work.

Rust is the future of systems programming, C is the new Assembly (Packt)

roc — Sun, 01 Sep 2019 20:54:49 +0000

Those are challenges worth highlighting. They need not be showstoppers. The details matter and they'll have to be addressed individually. E.g.

> * Sticking points are the heavy use of intrusive data-structures alongside kernel APIs, e.g. `offsetof`. Providing safety around that means that you cannot use some of the APIs directly.

Rust can express some uses of intrusive data structures safely (e.g. https://docs.rs/intrusive-collections/0.8.1/intrusive_col...) so it comes down whether the implicit lifetime constraints in play in each situation are expressible.

> * Many APIs use raw pointers all over. How do you ensure safety around these APIs? For example, for VFS - do you do something similar to FUSE but *inside* the kernel for some subsystems?

Similar issue: raw pointers themselves aren't the issue --- they can be cast to references --- the question is, can you assign valid and useful Rust lifetimes to those references? And that depends on the invariants of the specific API. But the common idioms of C code (e.g., "pointer parameter guaranteed to be valid for the duration of the call") are easily translated into Rust.

> * Some of the kernel APIs make heavy use of the C preprocessor.

They'll have to be translated by hand into inline, possibly generic Rust code, or possibly into Rust macros.

> * In debugging, kernel backtraces would need to deal with backtraces inside the kernel code, alongside backtraces for the C code. I'm guessing that kernel developers would like to see demanded symbols in kernel oops reports.

Should be OK if the build-the-kernel-with-LLVM people are already getting those backtraces. Rust demangling has recently been standardized and there's a library to do it.

> * How would kernel Rust code unwind in panic situations? (I'm guessing `fn drop` calls would be skipped).

Unwinding out to the nearest C code is an option, but probably you just want panic to call BUG().

> * Problem domain is similar to loading Rust-based DSOs in userspace, for frameworks that are not originally written in Rust (think about a GIMP plugin, for instance). Perhaps we should tackle that problem first?

This is being done. E.g. Federico did librsvg, people are writing GStreamer plugins in Rust. https://github.com/sdroege/gst-plugin-rs

Go is the future of system programming

roc — Sun, 01 Sep 2019 20:29:39 +0000

C++ fixes namespaces, parameterized types, and closures. Modules haven't shipped yet, and it doesn't have a modern package manager or sane error handling (C++ exceptions are so bad they're banned in perhaps the majority of C++ projects). And of course it removes almost nothing from C. So no, it doesn't "fix almost all of that".

Plus of course no-one is expecting C to "go extinct in the wild" anymore than mainframes have.

Go is the future of system programming

wahern — Sun, 01 Sep 2019 19:46:02 +0000

C++ fixes almost of that, which I guess explains why C is extinct in the wild.

tl;dr: Rust is NFG. Try again in 2030.

Cyberax — Sun, 01 Sep 2019 18:06:00 +0000

> This is not substantially different from the 1996 Java deal[3], only now it's a good thing that there's not going to eventually be a sufficiently smart just-in-time compiler and prescient garbage collector.
Whut? Rust by design has statically managed object lifetime, that's the reason for the whole borrow-checker thingie.

Please, do stop smoking whatever you're smoking.

tl;dr: Rust is NFG. Try again in 2030.

ksandstr — Sun, 01 Sep 2019 14:24:39 +0000

These conclusions are generally met with a variation of the motte-and-bailey argument, i.e. that Rust has an "unsafe" mode where all the manageable evils of C are permitted, albeit with back-to-front declaration syntax, semantically significant scoping[-1], an unhelpful type system, and a single compiler whose intermediate language is only equivalent to C but which supports fewer hardware targets. The advocate will then ignore these concerns, describing an ideal where existing code is supplanted with an incompatible language for which there are fewer skilled programmers, no semantics formalized to a standards-language level and then immobilized in stone every dozen years or so, no independent implementation from even hardware vendors, no fifty-year history, and no nigh-universal acceptance outside its niche as Mozilla's in-house language for browser implementation.

So it's not unreasonable to put that line of argument to rest just on the back of Rust's immaturity as a language, regardless of its supposedly groundbreaking special features (which don't exist inside "unsafe" blocks), and the discussion moved forward perhaps to its conclusion.

Rust is a huge crock. The reasons why it looks good to some are that contemporary C++ is also a crock (e.g. for attempting parity with Rust); and because its advocacybots[0] soak up all the flak that its features and lack thereof should rather face. Oh, and also security[1], and indistinct references to studies supposedly proving how people[2] just aren't good enough to handle sharp-cornered objects. This is not substantially different from the 1996 Java deal[3], only now it's a good thing that there's not going to eventually be a sufficiently smart just-in-time compiler and prescient garbage collector.

>(...) having Redox's kernel and Linux linked together, providing a single kernel binary, and drivers for Redox co-exist in the same space, gradually supplanting Linux drivers.

This is known as driver or subsystem porting, and it's commonly discussed in terms of having the younger system built up without reimplementing "the boring parts". In the context of Rust this takes on a rather millennarian tone where, instead of an eventual Redox 6.0 having hardware support (filesystem, device mapper, network stack, etc.) parity with Linux 12.34, the latter would have been rewritten to exclude non-Rust languages. A cultural revolution, if you will; certainly a great leap forward. Ensuring that definitely all the bathwater is gone so it won't be proven innocent of causing all our problems.

[-1] beyond identifier shadowing, which has a dedicated warning setting encouraged by common best practice.
[0] it's interesting to compare recent Rust advocacy with some from 2017; the arguments are the same and the conversations never move forward, akin to the hog having successfully dragged the farmer into a bout of mud-wrestling and wound up happy whether he wins or loses.
[1] in the sense of a small category of pointer bugs which can certainly look complete to the amateur who's never seen other use cases, let alone put them to practice himself; but not (say) AB-BA races, dangling keys, context violations such as misordered locking, and so forth.
[2] cheapest possible subcontractors, who can't but whose bugs aren't immediately apparent.
[3] in particular, MMUs still don't exist, and knee-jerkably deadly hazards still lurk even in data the program has itself generated.

Rust is the future of systems programming, C is the new Assembly (Packt)

da-x — Sun, 01 Sep 2019 07:19:21 +0000

I contemplated this for awhile. Some conclusions:

* While FFI is used mostly to wrap Rust APIs around libraries originally written in C/C++, where the state of the loaded C/C++ code is demarcated, doing the other way around is much more difficult because of the statefulness of the _surrounding_ C/C++ code.
* Sticking points are the heavy use of intrusive data-structures alongside kernel APIs, e.g. `offsetof`. Providing safety around that means that you cannot use some of the APIs directly.
* Many APIs use raw pointers all over. How do you ensure safety around these APIs? For example, for VFS - do you do something similar to FUSE but *inside* the kernel for some subsystems?
* Some of the kernel APIs make heavy use of the C preprocessor.
* In debugging, kernel backtraces would need to deal with backtraces inside the kernel code, alongside backtraces for the C code. I'm guessing that kernel developers would like to see demanded symbols in kernel oops reports.
* How would kernel Rust code unwind in panic situations? (I'm guessing `fn drop` calls would be skipped).
* Problem domain is similar to loading Rust-based DSOs in userspace, for frameworks that are not originally written in Rust (think about a GIMP plugin, for instance). Perhaps we should tackle that problem first?

Bottom line, I think that it would be quite hard to extract value from this, given how much of the APIs exposed by the kernel are engrossed in C-based complexity and unsafety assumptions. When I do imagine such framework, I see it would need a to provide a thick layer with a disparate set of APIs, if it ever wants to be viable and a fully idiomatic Rust.

Maybe it's just a crazy idea, but perhaps a different project can be realized, for example - having Redox's kernel and Linux linked together, providing a single kernel binary, and drivers for Redox co-exist in the same space, gradually supplanting Linux drivers.

Go is the future of system programming

Freeaqingme — Sat, 31 Aug 2019 13:27:24 +0000

I concur that for many applications Go could be an alternative to C. Think of (web) servers, etc.

Operating systems? Not so much. Go relies on its own runtime, that makes it difficult to integrate in to the low level stuff where it's essential to be in full control of your memory.

Relevance

jezuch — Sat, 31 Aug 2019 13:19:47 +0000

> C++20, out very soon, has major new modernizations, and C++23 will have more.

I haven't done C++ in years but from what I'm seeing, with all these new features mixed in with the old, it rapidly becomes a write-only language, while still being C++. It's been tremendously complex years ago already, and with all the new additions it's exponentially more so. So why not just start from scratch and design a new language that doesn't have all this legacy but has nice modern features? Like, you know, Rust? ;)

Rust is the future of systems programming, C is the new Assembly (Packt)

slankes — Sat, 31 Aug 2019 11:48:57 +0000

I would too lovely help also.

Rust is the future of systems programming, C is the new Assembly (Packt)

samlh — Sat, 31 Aug 2019 06:59:08 +0000

The GC of pypy is written in RPython, which is a language semantically closer to C than to python. :)

Rust is the future of systems programming, C is the new Assembly (Packt)

roc — Sat, 31 Aug 2019 00:03:18 +0000

That leads to absurd conclusions. So if I design my own ISA for use by ten of my friends, suddenly it's the responsibility of toolchains to support it?

Gcc regularly drops support for ISAs. https://www.phoronix.com/scan.php?page=news_item&px=G...
Is gcc a toy?

Unlike those museum architectures, Qualcomm's Hexagon is alive and well today and has shipped billions of units. LLVM has in-tree support for Hexagon, but gcc does not. How dare those gcc maintainers!

Rust is the future of systems programming, C is the new Assembly (Packt)

pizza — Fri, 30 Aug 2019 23:57:50 +0000

No, under Sun it became actual Free Software (GPL!) but after Oracle absorbed Sun it languished so badly that folks forked it (under the 'go-oo' moniker). That fork became LibreOffice, which predates Oracle dumping OpenOffice's carcass over to Apache.

Rust is the future of systems programming, C is the new Assembly (Packt)

Wol — Fri, 30 Aug 2019 23:36:58 +0000

Except that, for pretty much its entire life (until it was abandoned), Apache Open Office has been what I call "open source", namely a proprietary program with source available. It started as the proprietary StarOffice, then it become Sun Office which was very much under the thumb, no change when it became Oracle Office, and only when it was abandoned to Apache did it become anything like a FLOSS project.

At which point, IBM sank it.

Cheers,
Wol

Rust is the future of systems programming, C is the new Assembly (Packt)

Cyberax — Fri, 30 Aug 2019 20:18:02 +0000

RISC-V is supported by the mainline LLVM.

Rust is the future of systems programming, C is the new Assembly (Packt)

flussence — Fri, 30 Aug 2019 19:20:23 +0000

I think it's more likely that the hardware supported by the Apple Corporation Compiler will be a museum piece long before RISC-V is.

Rust is the future of systems programming, C is the new Assembly (Packt)

mathstuf — Fri, 30 Aug 2019 19:08:52 +0000

> cargo as build system is "nice and simple" and can handle a lot but falls short if complex builds are needed which can be done in C using the automake/autoconf, cmake, ... hell ...

What, really, do you need from a more complex build system? The majority of CMake's complexity comes from compiler and linker inconsistencies. Generated sources have solutions in Rust. Platform introspection can be done at the same time (and generate code for inclusion). Preprocessing to handle some intermediate language is fine too. I guess I'm missing what kinds of complexities are actually required that aren't possible with stock cargo.

One thing I know of is linker stuff (manifest files on Windows, custom ELF sections, library ID management on macOS, rpath/runpath shenanigans, linker scripts, packaging metadata, etc.). But, most of this can also be done as post-processing steps on the resulting artifacts anyways, so I don't think that is a fundamental lack in cargo itself.

Rust is the future of systems programming, C is the new Assembly (Packt)

mathstuf — Fri, 30 Aug 2019 19:05:02 +0000

> Rust has supported dynamic linking for as long as I can recall?
> It's simply not the default.

Well, it does, but you can only really use it for C ABI boundaries. A shared Rust library would also likely need recompiled/linked for updates due to a lack of ABI stability (in the sense of "updating the compiler can change this") of Rust calls and structure layouts.

Rust is the future of systems programming, C is the new Assembly (Packt)

moltonel — Fri, 30 Aug 2019 16:04:49 +0000

You seem to be using a strange definition of the word "most". All the platforms you mentioned are museum pieces by now, they are toys for hardware enthusiasts. If those enthusiast want to port a modern compiler to such old hardware, that's cool and fun and great. But it doesn't belong in the mainline.

Rust is the future of systems programming, C is the new Assembly (Packt)

josh — Fri, 30 Aug 2019 15:36:46 +0000

> 2. Many C language features have no corresponding Rust support. For example, it seems like impossible to construct a struct with bitfields.

That's one of the items on the FFI working group's list to work on.

Rust is the future of systems programming, C is the new Assembly (Packt)

mirabilos — Fri, 30 Aug 2019 13:04:58 +0000

No. Support belongs in-tree, and if a toolchain is not going to even try to support most platforms, it’s clearly suitable only as a toy, not as a replacement for something well-established.

Support for anything MUST be in-tree so it benefits from whole-tree changes automatically, shows up when a developer greps for “does anything use this function?”, etc.

Rust is the future of systems programming, C is the new Assembly (Packt)

lzh — Fri, 30 Aug 2019 12:53:17 +0000

In my simple and exprimental project (https://github.com/lizhuohua/linux-kernel-module-rust), I implemented a simple driver for the Ethernet controller used on raspberry pi 3, based on Geofft's amazing project (https://github.com/fishinabarrel/linux-kernel-module-rust). And I found that the performance impact is actually negligible. However, I found the following problems:

1. Linux kernel doesn't guarantee API/ABI stability, so it's hard to design a universal Rust interface. At least it is almost impossible to make it work on all versions of Linux.
2. Many C language features have no corresponding Rust support. For example, it seems like impossible to construct a struct with bitfields.
But yes, I believe Rust is a promising language for kernel programming. Let's join forces to make this happen!

Rust is the future of systems programming, C is the new Assembly (Packt)

pizza — Fri, 30 Aug 2019 12:22:18 +0000

> Even the most pathological F/OSS project is lightyears beyond the depressing suckage in the proprietary world.

I wrote this, then I remembered Apache OpenOffice, which transcends to Dilbert-esque levels of suckage.

Rust is the future of systems programming, C is the new Assembly (Packt)

pizza — Fri, 30 Aug 2019 12:10:34 +0000

"helping" or "forking" only applies when upstream allows you to have (and do something with) the source code.

Even the most pathological F/OSS project is lightyears beyond the depressing suckage in the proprietary world.

Rust is the future of systems programming, C is the new Assembly (Packt)

pizza — Fri, 30 Aug 2019 11:58:57 +0000

For a given application, sure, the _technical_ effort to keep your bundled Rust dependencies (naively) updated is lower than with a "classic" C project. (Putting aside the fact that it takes extra effort to bundle C libraries to begin with, so in a very true sense one has to opt into having this dependency tracking/updating problem)

None of that has any bearing on pathologic development/business processes that treat post-release maintenance as a four-letter word, nor does it help anyone who doesn't have access to complete corresponding source code to everything.