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

[Posted August 28, 2019 by corbet]

Packt has published a lengthy writeup of a talk by Josh Triplett on work being done to advance the Rust language for system-level programming. "Systems programming often involves low-level manipulations and requires low-level details of the processors such as privileged instructions. For this, Rust supports using inline Assembly via the 'asm!' macro. However, it is only present in the nightly compiler and not yet stabilized. Triplett in a collaboration with other Rust developers is writing a proposal to introduce more robust syntax for inline Assembly."

to post comments

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

Posted Aug 28, 2019 15:04 UTC (Wed) by Archimedes (subscriber, #125143) [Link] (25 responses)

Yes he shows the nice things of Rust compared to C, but there are dark areas as well ...
- Bootstrapping rust was a real pain but is at least getting better a lot
- solely supporting static builds is IMHO a severe error when building systems (especially when security comes in play)
- 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 ...
- license handling of packages drawn in by cargo (which is hard to controll at least during bootstrap) is awful ... They "recomend" the SPEDX license field, but noone is checking if there are additional licenses or patent clauses in the package. If one is forced to check this it is a lot of handy work to get this collected. And the additional problem that it is too easy to draw in a lot of libs which creates a huge amount of work to extract, collect and check the licenses. Yes thats not a rust problem, but a cargo infrastructure problem ... but thats again kind of a rust problem.

So I kind of like Rust as language but it seems I more and more hate the tools around it (cargo/static linking ...)

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

Posted Aug 28, 2019 15:51 UTC (Wed) by moltonel (subscriber, #45207) [Link] (17 responses)

Rust *can* use C-style loosely-versioned dynamic libs with a bit of effort. It's generally not used outside of FFI because safe rust guarantees are dropped at the dynlib boundary, making the security advantage dubious. Making the current system safer at the price of making updates longer can be a good deal. From a disk space PoV, you can use rust-style fully-versioned dylibs.

I've never seen cargo being a problem for complex cases in practice. It can use a build script, call the local CC, be called from another build system, avoid network access... It's the expected "easy case is easy, complex case is doable". There's a working group making sure that cargo interacts well with other buildsystems both as upstream and downstream. And cargo remains optional: a quick duckduck finds cmake and meson examples to build rust projects without cargo.

The cargo-bom subcommand can help with gathering license info. But it would indeed be nice if you could put something like `accept_licenses = ["GPL-3","Apache",...]` in your Cargo.toml.

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

Posted Aug 29, 2019 6:17 UTC (Thu) by Archimedes (subscriber, #125143) [Link] (16 responses)

I am mostly concerned around the upodate "ther system" (being the base librarys) on security flaws (or what else is important) and as below here the .so ...hell... of linux helps, in rust (and yes all other lagnuages which use a similar system) this is more problematic.

cargo gets problemtatic as when you as a maintainer have to even out the developer cargo dependencie trees from multiple groups, so update a dependency which has a CVE (or some other reason) update all toml files and then recompile all code from all groups and hope that the other dependencies in each project can cope with the updated lib. So cargo makes it even harder to maintain a version tree of depencies and update them for the group projects. (I am not saying that the other side, the linux/gnu .so ...hell... is nice but here more tools are available, the API is ...mostly... stable so e.g. updating e.g. openssl and having the advantage in all other libs/bins is simpler then in the rust case. So I should have been more precise in the beginning, the problem is more the idea that the build tool is also the depency handler and library installation tool with mostly no regard on an existing system, then cargo as being a make/cmake as the build tool, but as the configuration and system check tool. (Fortunatly the --offline support is quite usable now)

Yes for that part you can get help, the problem is as long it is not enforced that crates are allowed to pack additional licenses or patent files then there is not much help on the spdx field as one still has to check for additional stuff in all crates. (There is the cargo-license package which can help, but the above is not handled). But of course the problem that C devs mostly need only a one up to a few libs (not counting the dependencies of these libs) for development, on cargo quite simple projects easily have 30+ dependencies ... So in the GNU/C world one has to check a few in the rust world ... a lot ...

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

Posted Aug 29, 2019 11:08 UTC (Thu) by moltonel (subscriber, #45207) [Link] (15 responses)

Your complain about cargo here seems to be about static linking again, not about cargo itself. Cargo actually makes the process of updating deps for security actually much simpler than for other languages: Run `cargo audit` to check to CVEs, run `cargo update` to get the new deps, then `cargo install` and... voilà, you're done.

Yes, it means that those steps need to be repeated for every affected apps, but they're easier than with most other languages, and it brings some advantages: Because the builds are static, if AppFoo is currently buggy with the fixed LibVuln you can still update AppBar and AppBaz, so that's a security win. Thanks to static builds and LTO, there's a chance that AppFoo isn't affected by the CVE in LibVuln, another win. And because Rust programs can use multiple versions of a lib, you won't be stopped by a deps catch-22.

It's possible to embed enough information in compiled binaries so that tools like cargo-audit can work on the binary rather than the repository. Right now it requires an opt-in crate and some code change, but eventually it'll be integrated enough that a distro maintainer can enable it easily on all packages.

Regarding deps, as you said the same problem exists with C and others, it's just on a smaller scale. At least thanks to the Rust ecosystem's standardization, there's better hope of automating the system than with (for example) C. You could for example extend cargo-bom to error out if a crate doesn't have an acceptable license, and bug upstream if their license isn't clearly stated. Harder to do with other ecosystems.

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

Posted Aug 29, 2019 13:43 UTC (Thu) by Archimedes (subscriber, #125143) [Link] (14 responses)

No or more kind of both.
The problem is that cargo helps for each app/project/program. But how about a system of a lot of these.
The system has (and always should) dictate a base of "stuff" the apps can use (apps can also use additional stuff as long as it is not changing the system part).
In the linux/gnu world a .so is updated and by just updating that one (as long as its compatible) all users are *updated*.
In the Rust world a (system) lib is updated, that has to be *forced* to all app/project/programs then all have to be recompiled (including the deps). (So yes the reason is basically that all is statically linked)
So if you have to maintain just a proramm then you benefit a lot of the rust eco system. If you have to maintain a whole system (with lots of different rust projects) it is more the contrary.
Its ok that currently they are mostly focussing developers/programs instead of systems.

I dont see it as security win that only a few targets use the fixed version and one (or more) not**. As the problem is that in the C world "someone" fixes the system and the others "only" have to test.
In the rust world, all groups have to update and to test, so now one has to make sure that everyone is updating. (And logicaly also checking if it is done in the end).
I am working in an evirenment where security is really important so fixing CVEs is much higher ranked as "normally".

**besides that is also possible in a linux/gnu system, there is no problem to maintain libs in different versions (except the work)

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

Posted Aug 29, 2019 14:40 UTC (Thu) by moltonel (subscriber, #45207) [Link] (13 responses)

Partial updates applied immediately are a security win compared to global updates that are applied much later due to a single package that doesn't play well with the update (and that may not even be installed on all systems). This happens very regularly, and can delay features as well as security fixes.

Again: yes, static linking interferes with the traditional way our systems are updated, turning an O(1) process into an O(n) one. There's a need to improve the process so that for example we can assert that we updated all n items, and probably that it can be done by a single person. Testing will always remain O(n).

The system-update issue is thorny and non-trivial. But once it is solved (which should be easier with a Rust app than with a C app with vendored libs), a staticaly-linked system can very well end up safer and more up to date than a dynamically-linked one.

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

Posted Aug 29, 2019 14:52 UTC (Thu) by pizza (subscriber, #46) [Link] (12 responses)

> The system-update issue is thorny and non-trivial. But once it is solved (which should be easier with a Rust app than with a C app with vendored libs), a staticaly-linked system can very well end up safer and more up to date than a dynamically-linked one.

If a vendor can't be bothered to track and issue security updates for a bundled C library their application depends on, they're not going to bother to track and issue updates due to rust libraries their application depends on either.

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

Posted Aug 29, 2019 16:53 UTC (Thu) by moltonel (subscriber, #45207) [Link] (11 responses)

> If a vendor can't be bothered to track and issue security updates for a bundled C library their application depends on, they're not going to bother to track and issue updates due to rust libraries their application depends on either.

Yes and no. With cargo, the bar to check for security updates in your deps is much lower: just run `cargo audit` (possibly daily in your CI) and then run `cargo update && cargo install` if `audit` reports something. It's simple enough that it can be done by the distributor/packager/end-user if upstream is not responsive. The same cannot be said of a C/C++ project with vendored deps.

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

Posted Aug 30, 2019 3:25 UTC (Fri) by pizza (subscriber, #46) [Link] (10 responses)

> Yes and no. With cargo, the bar to check for security updates in your deps is much lower: just run `cargo audit` (possibly daily in your CI) and then run `cargo update && cargo install` if `audit` reports something. It's simple enough that it can be done by the distributor/packager/end-user if upstream is not responsive. The same cannot be said of a C/C++ project with vendored deps.

You keep assuming the problem is technical in nature. It is not.

You assume the existence of a CI system. You implicitly assume the presence of an automated regression testing suite. You assume that releases don't have a weeks-to-months-long process. Heck, you assume there's even some process in place that acknowledges that your dependencies might actually need updating outside of multi-year platform update cycles.

That latter bit is the primary reason why "vendored C++ deps" don't get updated. The base platform layer is fixed, and cannot be changed. period.

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

Posted Aug 30, 2019 9:08 UTC (Fri) by moltonel (subscriber, #45207) [Link] (1 responses)

Your understanding of my assumptions is wrong, I would say ;) My actual reasoning is that updating a system needs a mix of interest and effort; nevermind an absence of testing, a year-long release process or a carefree maintainer : I was just noting that the effort with Rust is lower compared to a vendoring C project, to nuance your observation that "if interest is low, nothing's going to happen anyway". In other words, static Rust is not as bad as static C.

> The base platform layer is fixed, and cannot be changed. period.

That's a major argument in favor of vendoring (and if you're vendoring, you might as well link statically). Whether you're updating your vendored libs is another story. Note that Rust projects generally link statically but don't vendor, and you *can* update libs easily enough as a distributor if upstream doesn't, or as an end-user if your distributor doesn't.

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

Posted Aug 30, 2019 11:58 UTC (Fri) by pizza (subscriber, #46) [Link]

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.

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

Posted Aug 30, 2019 11:37 UTC (Fri) by james (guest, #1325) [Link] (7 responses)

Isn't that a feature though?

If upstream has the problems you mention, the problems will be there for their own code. If cargo audit tells us (users/distributions) which projects aren't maintaining their software properly, we know which projects need help (or, ultimately, need to be forked or ignored).

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

Posted Aug 30, 2019 12:10 UTC (Fri) by pizza (subscriber, #46) [Link] (6 responses)

"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)

Posted Aug 30, 2019 12:22 UTC (Fri) by pizza (subscriber, #46) [Link] (5 responses)

> 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)

Posted Aug 30, 2019 23:36 UTC (Fri) by Wol (subscriber, #4433) [Link] (4 responses)

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)

Posted Aug 30, 2019 23:57 UTC (Fri) by pizza (subscriber, #46) [Link] (3 responses)

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)

Posted Sep 2, 2019 9:14 UTC (Mon) by Wol (subscriber, #4433) [Link] (2 responses)

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)

Posted Sep 2, 2019 10:00 UTC (Mon) by nix (subscriber, #2304) [Link]

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)

Posted Nov 11, 2020 15:08 UTC (Wed) by ceplm (subscriber, #41334) [Link]

> 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.

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

Posted Aug 28, 2019 16:02 UTC (Wed) by Deleted user 129183 (guest, #129183) [Link] (2 responses)

> solely supporting static builds

Actually, Rust does support both compilation and use of shared libraries. The problem is, not every package can be compliled as a shared library, which makes packaging applications for GNU/Linux distributions with policies discouraging static linking a major pain in the ass.

I bet that the reason for it is that the developers of Rust are all rich hipsters using a certain fruity operating system that doesn’t have a notion of the “system package manager”…

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

Posted Aug 28, 2019 16:55 UTC (Wed) by wahern (subscriber, #37304) [Link]

> I bet that the reason for it is that the developers of Rust are all rich hipsters using a certain fruity operating system that doesn’t have a notion of the “system package manager”…

Static linking is hip. Static linking is easier from the perspective of Rust's compiler and toolchain. Finally, Rust was begotten at Mozilla for work on Firefox, where for myriad reasons static linking makes tremendous sense for *every* supported platform--not just fruity, but even the hobby ones.

Alas, the FOSS community seems destined to recapitulate the lessons learned that brought about dynamic linking in the very first place[1], but on the bright side maybe it'll be improved upon. For example, with CTF for improved type safety and automagic runtime FFI.

[1] No, not disk space. But, yes, also disk space, because size always matters, then and now.

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

Posted Aug 28, 2019 20:56 UTC (Wed) by bluss (guest, #47454) [Link]

Just like C++, Rust doesn't doesn't allow dynamic linking of all code, because of generic items that are instantiated with their specific type parameters per use. The mechanics of how this is implemented is a bit more automatic in Rust, but the effect is the same, that the used generic functions & types cannot be compiled separately from where they are used.

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

Posted Aug 28, 2019 16:55 UTC (Wed) by cesarb (subscriber, #6266) [Link]

> solely supporting static builds

Rust does support dynamic builds, rustc itself is composed of several libraries which are usually dynamically linked together.

The reason it's not used often elsewhere is the lack of a stable ABI, which means everything must be compiled with the exact same version of rustc. There is some work being done on that, starting with name mangling (https://github.com/rust-lang/rfcs/pull/2603).

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

Posted Aug 29, 2019 20:47 UTC (Thu) by nicoonoclaste (guest, #128640) [Link] (1 responses)

> Yes he shows the nice things of Rust compared to C, but there are dark areas as well ...
> - Bootstrapping rust was a real pain but is at least getting better a lot
I assume you never had to bootstrap a C toolchain?
At least rustc provides a mostly-straightforward and mostly-documented path for that.

> - solely supporting static builds is IMHO a severe error when building systems (especially when security comes in play)
Rust has supported dynamic linking for as long as I can recall?
It's simply not the default.

> - 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 ...
No comment. >_>'

> - license handling of packages drawn in by cargo (which is hard to controll at least during bootstrap) is awful ...
> They "recomend" the SPEDX license field, but noone is checking if there are additional licenses or patent clauses in the package.
1. Having licensing metadata at all is an improvement over the C ecosystem.
2. From experience, the licensing metadata in crates is accurate in the very vast majority of cases.
3. Distributions are actually checking this metadata when packaging Rust software; for instance, Debian's Rust team (disclaimer: I am a member) definitely does so.

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

Posted Aug 30, 2019 19:05 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

> 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)

Posted Aug 30, 2019 19:08 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

> 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.

Go is the future of system programming

Posted Aug 28, 2019 15:42 UTC (Wed) by ber (subscriber, #2142) [Link] (13 responses)

See, I've done it: Made a claim in the headline, but without actually reasoning why Go is the language that will supercede C as a major system programming language
and not something else like Erlang. ;)

Go is the future of system programming

Posted Aug 28, 2019 16:52 UTC (Wed) by josh (subscriber, #17465) [Link] (1 responses)

It's hard to fit the complete reasoning in the headline, so I had to put it in the presentation instead. :)

Also, while I'm happy with the reporting in this article, I wouldn't have chosen to put "C is the new assembly" in the title; the talk was more nuanced and not adversarial.

One specific point in the talk: I emphasized that I was *not* there to convince people to use Rust, just to show people what we're doing to make it *possible* to choose Rust.

Go is the future of system programming

Posted Aug 29, 2019 17:41 UTC (Thu) by abentley (guest, #22064) [Link]

Also, there's nothing noteworthy about the idea that C is portable assembler. That idea's older than some of my colleagues. Microsoft even tried to come up with a competitor back in '97: https://www.microsoft.com/en-us/research/publication/c-a-...

Go is the future of system programming

Posted Aug 28, 2019 19:32 UTC (Wed) by k8to (guest, #15413) [Link] (9 responses)

To summarize the main thrust of the talk:

C is used for systems programming now, but it's been long outshone by many other languages on features.
A language with a significant number of these compelling features that is a reasonable choice for systems programming is compelling to move to.
Rust is a language with these characteristics.

There's more detail of course.

Go isn't really a contender at least right now, for creating things like firmware, and you probably know this, and the talk isn't really focused on justifying the entire list of capabilities that a systems programming language needs, but rather explaining how rust is a relevant option, and what it offers.

Go is the future of system programming

Posted Aug 28, 2019 19:43 UTC (Wed) by k8to (guest, #15413) [Link]

Correction: And what the recent advancements for rust have occurred to enhance feature parity with C for reasons of complete interoperability to enable a reasonable path of slow migration.

Go is the future of system programming

Posted Aug 29, 2019 0:58 UTC (Thu) by dfsmith (guest, #20302) [Link] (7 responses)

> "C is used for systems programming now, but it's been long outshone by many other languages on features."
Does the world need a whole new language for systems programming? I think a scoped-destructor in C would probably go a long way towards filling in any feature gap. The C++ auto is also handy.
For example:

void obj_destructor(void *vobj) {struct object *obj=vobj; ...; free(obj);}
...
{
   struct object *obj;
   obj = scopealloc(sizeof(*obj), obj_destructor);
   fill_in(obj);
} /* close scope calls obj_destuctor(obj) */

(And a suitable macro would make it look similar to other languages.)

Anyone here on the C committee? There must be a reason why such a feature hasn't been incorporated.

Scoped destructors are not enough

Posted Aug 29, 2019 3:33 UTC (Thu) by draco (subscriber, #1792) [Link] (1 responses)

There are a lot of problems with C, and they all stem from requiring perfection from the programmer:
1) memory leaks
2) use after free
3) buffer overflows
4) incorrect locking of data between threads
...) [not an exhaustive list]

Your proposed scoped destructor can sometimes solve #1. I say sometimes because the lesson of C++ is that backward compatibility with C guarantees that the legacy of C will simply continue to haunt the language forever.

As you've prototyped it in your code, I assume it wouldn't solve #2.

It does not help with #3 or #4 at all. Rust has had destructors from the start, so #1 is largely a solved problem (you can leak memory if you really want to, but you pretty much need to go out of your way to make it happen). More importantly, it bakes in data race protection, which comprehensively solves #2-4.

Scoped destructors are not enough

Posted Aug 29, 2019 10:11 UTC (Thu) by ehiggs (subscriber, #90713) [Link]

If you don't solve "incorrect locking" then you did not solve "use after free". But auto-free would be a valuable addition to C. The only reason it might not be adopted is that it injects code that is not visible to the programmer which C generally does not do.

Go is the future of system programming

Posted Aug 29, 2019 4:50 UTC (Thu) by jonesmz (subscriber, #130234) [Link] (1 responses)

This is a language extension in GCC, and is used by the systemd project extensively.

Go is the future of system programming

Posted Aug 29, 2019 20:52 UTC (Thu) by dfsmith (guest, #20302) [Link]

Thanks, I didn't know about this before. For others interested, it's __attribute__(cleanup...).

Go is the future of system programming

Posted Aug 29, 2019 6:28 UTC (Thu) by roc (subscriber, #30627) [Link] (2 responses)

Apart from the safety issues, and destructors, C lacks all kinds of other basic features, e.g.
-- namespaces
-- parameterized types. Using any kind of data structure is just horrible. The standard library doesn't even give you growable vectors or hash tables.
-- closures
-- modules. For example, compilers don't tell you when you have an unnecessary import.
-- a modern package manager to make third-party dependencies usable
-- sane error handling mechanisms

Then of course there's all the stuff that C *has* but shouldn't have. The preprocessor, lossy implicit casts, tons of undefined behavior, lots of primitive types you should never use, etc.

Go is the future of system programming

Posted Sep 1, 2019 19:46 UTC (Sun) by wahern (subscriber, #37304) [Link] (1 responses)

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

Go is the future of system programming

Posted Sep 1, 2019 20:29 UTC (Sun) by roc (subscriber, #30627) [Link]

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

Posted Aug 31, 2019 13:27 UTC (Sat) by Freeaqingme (guest, #103259) [Link]

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.

zig

Posted Aug 28, 2019 16:20 UTC (Wed) by marduk (guest, #3831) [Link] (7 responses)

Anyone work and/or care to comment on ziglang as an alternative to C for systems programming?

https://ziglang.org/

zig

Posted Aug 28, 2019 17:57 UTC (Wed) by ceplm (subscriber, #41334) [Link]

What are the significant real world project using that language? Rust has at least substantial parts of Firefox speaking for it.

zig

Posted Aug 28, 2019 18:25 UTC (Wed) by excors (subscriber, #95769) [Link]

Getting a new systems programming language adopted as an industry standard seems like an enormous amount of effort and can take a couple of decades. Even if Zig is nicer than C, it seems a waste to spend all that effort to migrate to a language that doesn't even try to fix the fundamental issues like memory safety and concurrency and undefined behaviour.

zig

Posted Aug 28, 2019 19:16 UTC (Wed) by atai (subscriber, #10977) [Link]

what is zig? (yes a link is provided, but what is your reaction if someone asks "what is C"? Until you have the same reaction to both questions how can you expect "zig" to be an alternative?)

zig

Posted Aug 28, 2019 20:28 UTC (Wed) by roc (subscriber, #30627) [Link] (2 responses)

AFAICT there are common sources of memory safety vulnerabilities that Zig makes no attempt to catch statically or dynamically. For example, dangling pointers to the stack frames of functions that have returned:
> Once a function returns, any Pointers to variables in the function's stack frame become invalid references, and dereferencing them becomes unchecked Undefined Behavior.
It's not explicitly stated, but it seems there is nothing to prevent use-after-free bugs even though it has manual allocation and deallocation. For some reason neither of these are mentioned in https://ziglang.org/documentation/master/#Undefined-Behavior.

So if avoiding memory safety bugs is a goal, Zig is not competitive with Rust, despite claiming "Performance and Safety: Choose Two".

There is an open issue https://github.com/ziglang/zig/issues/2301 "make Debug and ReleaseSafe modes fully safe", but no indication of how this could be done. The failure of many many attempts to bolt memory safety onto C and C++ shows that this is pretty to retrofit onto a language that wasn't designed for it from the ground up. I mean, dynamic bounds checking and stuff like that is pretty easy, but dangling pointer issues are the main reason Rust lifetimes exist, which are a really important part of the language.

zig

Posted Aug 28, 2019 20:57 UTC (Wed) by roc (subscriber, #30627) [Link]

That aside, I also have to question many of the aesthetic choices of Zig. No default allocator? Forcing explicit OOM checks everywhere? defererr instead of RAII? Puzzling.

zig

Posted Aug 28, 2019 21:01 UTC (Wed) by roc (subscriber, #30627) [Link]

Oh, Zig also doesn't mention unsafety due to data races.

Rust was designed from the ground up to prevent data races as well as the usual memory unsafety bugs. And of course, if you have manual memory deallocation and you can't prevent data races it's going to be very hard to ensure those data races don't destroy memory safety...

zig

Posted Aug 29, 2019 11:15 UTC (Thu) by moltonel (subscriber, #45207) [Link]

IMHO, while Zig is clearly a better C, it's not compelling enough to justify the work of transitioning. Maybe if there's a requirement to gracefully handle/survive OOM and to use different allocators for different part of the program, but that seems very niche.

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

Posted Aug 28, 2019 16:58 UTC (Wed) by josh (subscriber, #17465) [Link] (28 responses)

Nice to see this posted here. I'm happy to answer any questions.

Also, while I'm happy with the reporting in this article, I wouldn't have chosen to put "C is the new assembly" in the title; the talk was more nuanced and not adversarial.

One specific point in the talk: I emphasized that I was *not* there to convince people to use Rust, just to show people what we're doing to make it *possible* to choose Rust.

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

Posted Aug 29, 2019 1:39 UTC (Thu) by felixfix (subscriber, #242) [Link] (26 responses)

Entirely out of curiosity: have you thought about how Linux could migrate from C to Rust? For instance, c and Rust interaction; writing new sources, new packages, new modules in Rust; replacing old stable sources with Rust.

I explicitly do not mean fantasies about Linus declaring a 5 year holiday while everything is rewritten all at once :-)

It's been ages since I did anything at all with the kernel, and that was pretty minor and strictly for my own use. But I'm always curious about such things.

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

Posted Aug 29, 2019 6:39 UTC (Thu) by roc (subscriber, #30627) [Link] (18 responses)

A good start would be to make it possible to write some kinds of drivers in Rust. This would already be quite a lot of work --- integrating Rust into the Linux build system, writing Rust wrappers around kernel APIs --- but much has already done experimentally. There's a good chance that encouraging people to submit their wacky drivers in Rust would improve the quality of the driver, partly because you can focus attention on the unsafe parts (if any ... many Linux drivers probably don't need much or any unsafe code).

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

Posted Aug 29, 2019 11:40 UTC (Thu) by moltonel (subscriber, #45207) [Link]

https://github.com/lizhuohua/linux-kernel-module-rust (based off https://github.com/fishinabarrel/linux-kernel-module-rust )

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

Posted Aug 29, 2019 16:33 UTC (Thu) by josh (subscriber, #17465) [Link] (16 responses)

I have, yes. I spoke with Greg Kroah-Hartman, and he said he'd be willing to accept a framework in the kernel for writing drivers in Rust, as long as 1) for now it wasn't enabled by default (even if you did "make allyesconfig") so that people don't *need* Rust to build the kernel, and 2) it shows real benefits beyond writing C, such as safe wrappers for kernel APIs.

I'd be happy to talk with someone interested in writing such a framework.

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

Posted Aug 29, 2019 18:34 UTC (Thu) by klmrdn (guest, #134116) [Link]

I don't have many experience with Linux kernel programming, but I love Rust and I would love to help if I can.

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

Posted Aug 29, 2019 20:30 UTC (Thu) by lucasamorim (guest, #106112) [Link] (1 responses)

I would love to help too

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

Posted Aug 29, 2019 21:06 UTC (Thu) by slankes (guest, #134120) [Link]

I would also love to help too

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

Posted Aug 30, 2019 4:21 UTC (Fri) by juchiast (guest, #134127) [Link]

I would love to help too!

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

Posted Aug 30, 2019 4:21 UTC (Fri) by Rufus-Clobin (guest, #134129) [Link]

I would too lovely help also.

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

Posted Aug 30, 2019 4:25 UTC (Fri) by geofft (subscriber, #59789) [Link]

We've got a framework in progress with some safe wrappers and we're working on getting it in a state suitable for upstreaming: https://github.com/fishinabarrel/linux-kernel-module-rust

We don't quite have enough useful API surface for a real module (although there are a few neat demos). I'd like to get it to the point where it's you can have a small filesystem or maybe a small LSM or something entirely in safe Rust.

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

Posted Aug 30, 2019 12:53 UTC (Fri) by lzh (guest, #134122) [Link] (1 responses)

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)

Posted Aug 30, 2019 15:36 UTC (Fri) by josh (subscriber, #17465) [Link]

> 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)

Posted Aug 31, 2019 11:48 UTC (Sat) by slankes (guest, #134120) [Link]

I would too lovely help also.

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

Posted Sep 1, 2019 7:19 UTC (Sun) by da-x (guest, #113602) [Link] (6 responses)

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.

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

Posted Sep 1, 2019 14:24 UTC (Sun) by ksandstr (guest, #60862) [Link] (3 responses)

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.

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

Posted Sep 1, 2019 18:06 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> 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.

Posted Sep 1, 2019 20:58 UTC (Sun) by roc (subscriber, #30627) [Link]

Superior trolling. Good work.

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

Posted Sep 2, 2019 1:37 UTC (Mon) by flussence (guest, #85566) [Link]

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)

Posted Sep 1, 2019 20:54 UTC (Sun) by roc (subscriber, #30627) [Link]

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

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

Posted Nov 26, 2019 15:47 UTC (Tue) by silvergate (guest, #135759) [Link]

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?).

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

Posted Aug 29, 2019 11:01 UTC (Thu) by adobriyan (subscriber, #30858) [Link] (6 responses)

> how Linux could migrate from C to Rust?

The only realistic choice is migrating to C++ exactly because of backwards source compatibility. It is curse for C++ and it is a blessing for anyone migrating upwards.

I have small .config back-to-back compiled and linked with g++ [1].

The flag day items are in fact C99 initializers both regular and array, where languages diverged.

C++ requires something like that

static const auto foo = []() constexpr -> auto {
        array<T, N> _ = {};
        _[42] = 666;
        return _;
}();

and "rubber" constexpr class for the case when array dimensions are derived from initialization.

Boilerplate can be hidden behind macros. Regular initializers require similar changes.

[1] It crashes in the "pr_notice("%s", linux_banner);" though.

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

Posted Aug 29, 2019 11:39 UTC (Thu) by moltonel (subscriber, #45207) [Link] (5 responses)

Linux will never migrate wholesale to a new language (source-compatible or not) like you describe, it'd be high risk with no gain. What's technically feasible is to have some parts written in different languages, and Rust would fit just as well as C++ there.

Introducing a new compiler dependency on the other hand... A much much harder sell. Maybe when LLVM can compile Linux without patches, or if GCC got a Rust backend.

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

Posted Aug 29, 2019 12:32 UTC (Thu) by adobriyan (subscriber, #30858) [Link] (4 responses)

Rust would fit worse because kernel APIs all call into each other. Selecting orthogonal parts will be interesting exercise.

It reminds me namespaces situation where on paper things are independent and orthogonal and in practice they are not:
/proc is filesystem which hosts processes which live in different pid namespaces, but it is a mountpoint, so it lives in some mount namespace and /proc/net is a window into networking and /proc/sys/net is sysctl part of it so half of /proc/sys/net lives in init_net and other half lives elsewhere and must be copied.

C++ requires
*) s/private/priv/ etc
*) casts from "void *" to "T*", demoting some "T*" to "void*" because "T*" is not being dereferenced.
*) partial -Wpointer-arithmetic: (void*) - (void*) becomes "(char*)-(char*)"
*) C99 initializers (see above)
*) enum casts
*) extern "C' for functions called from assembly, probably for module_init/module_exit functions
*) random minor stuff like "extern "C" should be in the beginning of declaration" or "enum foo:int" forward declarations
*) random absolute disgusting horrors like ___bpf_prog_run() -- FORWARD DECLARE A C LABEL ARE YOU SERIOUS?!

Now the important part is that everything except the last point doesn't change code generation.

At this point $(CC) is flipped to "g++" and, if not hidden under macros, C99 initializers flip as well.

This is the only flag day patch where slightly different code generation may uncover something.

At this point, code can be changed gradually and independently from development to approved C++ constructs
like "user_ptr" pointer type which can't be dereferenced.

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

Posted Aug 29, 2019 13:58 UTC (Thu) by moltonel (subscriber, #45207) [Link] (3 responses)

> Rust would fit worse because kernel APIs all call into each other.

I don't see how C++ fares better than Rust in this regard ? Both can call C and be called from C with little boilerplate. They both have no runtime to speak of, and can adhere to the C calling convention, and memory layout. The librsvg rewrite is a good example of how to replace C with Rust gradually while keeping both the private and public C ABI intact. The only kernel-specific issue I can think of is live-patching of tracepoints, which might be trickyer to achieve in Rust.

> Selecting orthogonal parts will be interesting exercise.

That's why drivers are often mentioned, but there are probably other low-hanging fruits.

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

Posted Aug 29, 2019 19:51 UTC (Thu) by adobriyan (subscriber, #30858) [Link] (2 responses)

> Selecting orthogonal parts will be interesting exercise.
That's why drivers are often mentioned, but there are probably other low-hanging fruits.

I'd suggest to start straight away with kernel/sched/core.c, mm/slub.c, mm/page_alloc.c, net/core/skbuff.c, arch/x86/mm/fault.c, fs/dcache.c.
If Rust can do these files, it can do everything.

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

Posted Aug 29, 2019 21:54 UTC (Thu) by roc (subscriber, #30627) [Link]

Proving "Rust can do anything" probably shouldn't be a priority, because Rust can be valuable without "doing everything" and rewriting core code in Rust is probably the *least* valuable way to use it, at leasts initially.

Device drivers are more attractive than core code as a starting point because a) new ones are being written all the time, and writing new code in Rust is more attractive than rewriting old, working code b) third-party driver code is notoriously poor quality so being able to prevent certain classes of bugs is more valuable c) not many people need to touch a driver so not many people need to deal with the Rust code. Need to deal with the reality that a lot of core maintainers are going to be skeptical of Rust so you have to start with code hardly anyone cares about.

If people won't write drivers in Rust then there's no hope of converting core code. If the results of writing new device drivers in Rust are good, then you could consider rewriting existing device drivers and expanding the kinds of drivers written in Rust (e.g. filesystems). If the results of doing that are really positive then maybe one day you'll have consensus to rewrite core code in Rust.

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

Posted Oct 28, 2020 22:35 UTC (Wed) by jerrywrice@fabnexus.com (guest, #142801) [Link]

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)

Posted Aug 29, 2019 1:50 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

It appears some of the major projects like systemd or libvirt have talked about moving to a different language, say C++ or Rust or Go etc and if they are already considering Rust or open to moving to it, it might be worth reaching out to figure out what the roadblocks are, if any for that adoption

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

Posted Aug 28, 2019 17:01 UTC (Wed) by dcg (subscriber, #9198) [Link] (7 responses)

C has been slowly phased out from many areas in the latest decades so I am not surprised that the trend is continuing, but I am not sold on the idea that Rust is the inevitable successor. There are other languages aiming to provide better memory safety, and not everybody enjoys the strictness of the borrow checker. For instance, in userspace systems programming many people are doing just fine with GC'ed languages.

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

Posted Aug 28, 2019 17:27 UTC (Wed) by josh (subscriber, #17465) [Link]

Absolutely! I'd love to see many languages bloom where they can. This talk was specifically about those areas where languages with runtimes or GCs can't go, where you'd otherwise have to use C or careful C++ (or assembly).

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

Posted Aug 28, 2019 19:21 UTC (Wed) by atai (subscriber, #10977) [Link] (1 responses)

"C has been slowly phased out from many areas" but that process may go on forever and never complete

In other words, C is not going to be phased out in general

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

Posted Aug 28, 2019 19:37 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

> In other words, C is not going to be phased out in general

Pretty much no language with a high level of adoption ever gets to be completely phased out. It will just get increasingly sidelined

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

Posted Aug 28, 2019 20:54 UTC (Wed) by roc (subscriber, #30627) [Link] (3 responses)

In most domains where GC is palatable, C has been obsolete for quite a while. For years now those people should have been using Go/Java/C#/etc for new projects.

Before Rust, there was still one very good reason to use C or C++ --- when you don't want GC. Rust has finally eliminated that reason.

Note that there are some good reasons to want to avoid GC that are under-recognized
-- When you want to build a library that can be consumed via C FFI
-- When you want deterministic finalization of heap objects
-- When you want high performance under very different workloads without making your users tune the GC
-- Plus the usual desire to avoid having to trade off latency / throughput / memory usage

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

Posted Aug 28, 2019 21:44 UTC (Wed) by josh (subscriber, #17465) [Link] (2 responses)

A few other reasons you might need to avoid GC:

- Your target has no concept of "background processing".
- You're sensitive to latency and interruptions.
- You're implementing a GC. :)

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

Posted Aug 29, 2019 19:22 UTC (Thu) by ssokolow (guest, #94568) [Link] (1 responses)

> You're implementing a GC. :)

To be fair, PyPy is self-hosting.

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

Posted Aug 31, 2019 6:59 UTC (Sat) by samlh (subscriber, #56788) [Link]

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)

Posted Aug 28, 2019 21:10 UTC (Wed) by kjp (guest, #39639) [Link] (1 responses)

I guess the C++ borrow checker (promised by Herb Sutter) was one of the biggest jebaits ever?
I'd at least like a post mortem on that project...

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

Posted Aug 28, 2019 21:43 UTC (Wed) by roc (subscriber, #30627) [Link]

The first iteration, that promised real memory safety for C++, was (to put it charitably) hugely overoptimistic. https://robert.ocallahan.org/2016/06/safe-c-subset-is-vap...

Since then they trimmed their goals to be much more realistic: catch some common memory safety bugs (though their marketing didn't quite follow suit). This is good work and I think it could be very successful. https://robert.ocallahan.org/2018/09/more-realistic-goals...

It's important to keep in mind that the new goals aren't competitive with Rust in terms of safety.

Relevance

Posted Aug 29, 2019 9:04 UTC (Thu) by ncm (guest, #165) [Link] (20 responses)

The successor-to-C ship has already sailed.

Serious new development has been in C++ for a long time. C has become a language for antiquarians, alongside Fortran.

It is possible that Rust won't fizzle. Anyway, at worst, it won't die out. Rust might compete for Ada's niche, and maybe stretch it a bit. Rust has the enormous advantage, over other languages, of sharing C++'s key innovation: the deterministic destructor, which they call the "Drop trait".

It is common, around here, to lump C++ with C, but that only demonstrates lack of awareness. That you *can* compile C code with a C++ compiler does not mean you should write code that looks like C. If you have a lot of C code, compiling it with a C++ compiler is a first step to modernizing, and there is no upper limit to how much better it can get, incrementally, while still working at every stage. There are few satisfactions that match deleting a whole source file, and all the bugs in it, on the way to a faster program.

Modern C++ code is closer to Haskell than to C, and has become quite fun to write. C++20, out very soon, has major new modernizations, and C++23 will have more. For the next decade and beyond, C++ skills will remain the most marketable for serious work.

Come 2035, there might be room for something else, but it is far from obvious Rust will be that something; it seems more likely to be a language less deeply similar to C++ than Rust is, better suited to programming machines very unlike current designs specifically optimized for C++. I have been on the lookout for such a language for 20 years. I don't see it yet.

Relevance

Posted Aug 29, 2019 9:24 UTC (Thu) by marcH (subscriber, #57642) [Link]

> That you *can* compile C code with a C++ compiler does not mean you should write code that looks like C

How many C++ compiler have a -no-C-crap option?

Relevance

Posted Aug 29, 2019 10:38 UTC (Thu) by moltonel (subscriber, #45207) [Link] (8 responses)

> The successor-to-C ship has already sailed.

And yet new projects are still started in C, so what gives ? The idea that C would have one single successor is pretty shortsighted. It's not C++, D, Rust, Go, Java, Python, Erlang... It's all of those and more, depending on use-case. C is still a better choice than C++ in some use-cases, because amongst other things C++ is still riddled with UB and memory safety issues, is stupidly complicated and impossible to use correctly, has an antiquated tooling, etc... C++ is just not worth it in many cases.

The OP's presentation shows that Rust is (or soon will be) a viable alternative to C even in those use-cases, and has some advantages that C++ and others can't hope to compete with.

> It is possible that Rust won't fizzle. Anyway, at worst, it won't die out. Rust might compete for Ada's niche, and maybe stretch it a bit. Rust has the enormous advantage, over other languages, of sharing C++'s key innovation: the deterministic destructor, which they call the "Drop trait".

That's a tremendous underselling of Rust, it sounds like you haven't looked very closely at the language, its community, or its adoption rate. Rust is long past the stage where it could have fizzled, it's mature, and has an impressive adoption story. It's becoming harder every day to use an OS or connect to a website that doesn't use Rust.

Rust's "niche" is arguably larger than C++'s, as it's a more viable option for example in WASM or security-sensitive environments. C++ still has the upper hand in some areas (GUIs being a particularly sticking point for Rust), but that's not going to hold long.

Plenty of languages have deterministic destructors, that's not considered an innovation anymore, and attributing it to C++ is a bit dubious. Rust's borrows from many languages, but its actual key innovation is its ownership model, which has more far-reaching implications than destructors.

Relevance

Posted Aug 29, 2019 11:45 UTC (Thu) by cencer (subscriber, #40823) [Link] (7 responses)

You are clearly not programming professionally in C++, or have tunnel vision on C++ in linux world.

GUI programming is actually a niche for C++ usage, but I'd guess that since this is a Linux portal, you seem to correlate it with Qt GUI, as that's where it gets the most exposure for open source world.

It is used many more areas, especially where performance, low-latency and power usage really matters:
- heterogenous computing (good luck with trying to program CPUs and GPUs from the same code in other languages),
- automotive (most of the core systems are written in C++, with except to kernel),
- 3GPP based mobile communication - both handsets and base stations,
- gaming (when creating big games that works both on PC and consoles, C++ is basically your only choice, unless you want to rewrite it everytime for each platform),
- trading.

Show me example where C is better than in C++, I am genuinely curious.

C++ sure has many flaws (most of them inherited from C), and sure it won't give you many benefits if you write in C++ the C way.
But if you start to use the language as it is meant to be used, you will see that many of the bugs you could have easily made in C, are reported as errors during compilation thanks mainly to two things: better type safety and automatic lifetime management.

Irrelevance

Posted Sep 5, 2019 12:52 UTC (Thu) by kragil (guest, #34373) [Link] (1 responses)

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++.

Irrelevance

Posted Oct 28, 2020 22:49 UTC (Wed) by jerrywrice@fabnexus.com (guest, #142801) [Link]

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.

Relevance

Posted Sep 6, 2019 20:17 UTC (Fri) by moltonel (subscriber, #45207) [Link] (4 responses)

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.

Relevance

Posted Sep 7, 2019 8:20 UTC (Sat) by ceplm (subscriber, #41334) [Link] (3 responses)

> 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

Posted Sep 7, 2019 11:39 UTC (Sat) by micka (subscriber, #38720) [Link] (2 responses)

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

Posted Sep 7, 2019 17:45 UTC (Sat) by ceplm (subscriber, #41334) [Link] (1 responses)

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

Posted Sep 8, 2019 20:46 UTC (Sun) by moltonel (subscriber, #45207) [Link]

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 ;)

... and Rust is the successor to C++

Posted Aug 29, 2019 12:26 UTC (Thu) by CChittleborough (subscriber, #60775) [Link] (1 responses)

It is true that recent C++ standards contain some great features, such as unique_ptr<T> and shared_ptr<T>, both added since Rust was first created. OTOH, C++ is still carrying some heavy, decades-old baggage. The C++ Core Guidelines effort might have helped a lot, but C++ turns out to be Just Too Hard to fix easily. Worse still, few if any C++ programmers will escape the painful need to maintain old-style code bases to frolic in the sunny uplands of modern C++.

OTOH, you can think of Rust as taking one idea from C++ (automagically running the destructor for stack-allocated variables when the variable goes out of scope) and taking it over 9000. In this not-completely-wrong view, the point of the ownership and borrowing rules is to tell the compiler when heap-allocated objects should be deallocated. Aside: Rust makes the programmer do more work so the compiler can do more work (automatic deallocation) so the programmer can do less work (explicit deallocation, which is so hard to get right). Add algebraic data types, excellent generics and some other recently-popular ideas and you have a truly excellent systems programming language.

In fact, at one stage the Rust team intended to support both reference counting and traced garbage collection, but their reference counting turned out to work so well that they aren't going to bother with traced GC.

PS ...

Posted Aug 29, 2019 12:40 UTC (Thu) by CChittleborough (subscriber, #60775) [Link]

I should not have mentioned the C++ Core Guidelines without recommending the excellent articles by roc about the C++ Core Guidelines (linked above).

BTW, the reason this topic is on my mind is that I've proposed a talk titled “Go and Rust: should you bother?” for the next Linux.conf.au.

Relevance

Posted Aug 29, 2019 12:29 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (5 responses)

> Serious new development has been in C++ for a long time. C has become a language for antiquarians, alongside Fortran.

Source?

When I was working with embedded systems it was all C.,

Relevance

Posted Aug 29, 2019 13:11 UTC (Thu) by pizza (subscriber, #46) [Link] (4 responses)

You see, there's embedded and then there's also Embedded.

That blanket term runs the gamut from an 8051 or Z80 with under a KB of RAM to an Android tablet running a single application to a Xilinx MPSoC system with 4x a53 cores and 8GB of RAM bolted onto the side of a massive FPGA.

Treating "embedded" to mean "runs on a microcontroller", C is still king for RealWork(tm) because it lets you wring every last drop of performance/etc out of very limited resources. (And expending the NRE to enable saving $0.02 on a lower-end microcontroller will pay for itself several times over...)

That said, in recent years what was once considered very high end is now the minimum starting point if you're trying to build an "IoT" device. (After all, the crypto and connectivity code requirements will easily dwarf that of the actual application...) In that space, the "recommended" development environments are typically C++-based. More for object-oriented "abstract away the microcontroller details" features than anything else. The resulting bloat ends up requiring even higher-end parts, which the microcontroller vendor is more than happy to sell...

Relevance

Posted Aug 29, 2019 13:45 UTC (Thu) by excors (subscriber, #95769) [Link] (3 responses)

Careful use of C++ can let you wring out the same amount of performance as C in microcontrollers (as long as you disable exceptions and RTTI to avoid code size overhead), while still getting many of the benefits of C++. E.g. you can implement std::mutex and std::lock_guard with zero cost compared to calling the RTOS API directly, and eliminate the risk of forgetting to unlock the mutex on an error path. You can use contextless lambdas as a nicer syntax for small callback functions. You can define a generic FIFO object which might actually be faster than the C equivalent because you can put the size in a template parameter rather than a runtime variable (or some giant mess of macros).

Non-careful use of C++ makes it very easy to shoot yourself in the foot, but I think it can work well with the right amount of experience and guidelines and code review.

Relevance

Posted Aug 29, 2019 15:13 UTC (Thu) by jpfrancois (subscriber, #65948) [Link] (2 responses)

Careful use of C++ .... blah blah

It seems every one advocating for C++ has to recommend some right way to do it, or use the world careful or deplore the fact that people don't know how to write "good" C++, or reassure people about the fact that all the footguns equipped scissors have been replaced by standard scissors. Scissors and FootGun equipped scissors are stored in the same toolbox, but hey, just be cautious ok, no need to worry.

There is no other language that is advertised by his proponents with so much warnings and recommendations.
C++ seems to be for people way smarter or skilled than I am. I want to use my skill and brain to turn a practical problem into a solution that is understandable and readable. I don't want to use my skill and brain to understand the C++ construct, and how they might or might not be dangerous.

I am working with people that write C in a verbose way. Giving them the possibility to write C++ would turn the codebase into something even more verbose.

C++ might be a superior alternative to C, but I for instance would rather use Go or Rust if possible.
Plenty of embedded system programming code that has no need for performance. I am responsible for the software development of an embedded system. We have a microcontroller, were we are in need of correctness more than performance.

The main CPU is an RPI, and the main daemon basically look at various parameters in a DB, and then write commands to various peripherals. Write data to fd or socket, handle events, state machines,error, timeout. It was originally written in C for the previous platform, and still is. We need some performance, but not that much. Python for instance would be too slow. Other daemon on the system have been migrated to Python. So here I am with my legacy C application, looking for a way to move away from C pieces by pieces. Go is a serious contender, maybe Rust, but certainly not C++. Go or Rust means there will be a clear barrier between new modules and the remaining C app. With C++, things would be much more blurry, and I don' want to spend my times looking for which misfeature has been abused by a coworker wanting to show how smart he is.

Relevance

Posted Aug 29, 2019 19:23 UTC (Thu) by mgb (guest, #3226) [Link] (1 responses)

Today's tools for linting C++ code are remarkably good. Nowadays you have to work much harder to write undetected bad C++ code.

Nevertheless there are still issues. C++ aggregate initialization lags behind C, and C++ static initialization gives so much flexibility to the runtime that little can be guaranteed to the programmer. Some kinds of data structures which in the past could be safely declared must now be built procedurally.

OTOH C++ has the STL and continues to standardize e.g. threads. And half a step removed from official standards are the amazing BOOST libraries. There is much less need to learn the quirks of often buggy home-grown libraries.

Relevance

Posted Aug 29, 2019 22:09 UTC (Thu) by roc (subscriber, #30627) [Link]

> Nowadays you have to work much harder to write undetected bad C++ code.

A somewhat vague assertion, but actually "modern C++" makes it easier to write bad code in some ways.
https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/

Relevance

Posted Aug 29, 2019 22:56 UTC (Thu) by roc (subscriber, #30627) [Link]

> there is no upper limit to how much better it can get, incrementally, while still working at every stage.

Nontrivial C++ code will always contain memory safety vulnerabilities and undefined behavior, so that is an upper limit.

The problem with the evolution of C++ is that it's almost purely additive. Modern C++ doesn't stop you from making old mistakes, and it creates opportunities for new ones. This is a problem for people who want to write safe, reliable code and who sometimes make mistakes.

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

Another problem with the relentless growth of the language (not just the feature set, but the complexity of each feature) is that it's just so hard to learn and then keep up with. Not a problem for the people who go to C++ standards meetings, or maybe CppCon, but enough of a problem that even Scott Meyer won't evaluate errata for his books anymore because in a few years his knowledge of C++ has rotted too much. http://scottmeyers.blogspot.com/2018/09/the-errata-evalua...

Of course people try to manage the complexity by restricting projects to some subset of the language. The problem is that different projects make different decisions and as the language evolves there is pressure to change those decisions over time (not least from C++ fans who pour scorn on projects that don't keep up). Just making those decisions takes a surprising amount of time and energy, and then you get to decide whether to spend more time and energy upgrading existing code or skip it and live with inconsistency between old and new code.

Thus, when people talk about the large number of C++ projects and developers, it's misleading because those projects and developers are really using a whole lot of different languages. How many C++ developers actually know that using std::option<std::unique_ptr<T>> is more dangerous than using std:unique_ptr<T> with a null pointer and can explain why?

Relevance

Posted Aug 31, 2019 13:19 UTC (Sat) by jezuch (subscriber, #52988) [Link]

> 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)

Posted Aug 29, 2019 16:14 UTC (Thu) by mirabilos (subscriber, #84359) [Link] (12 responses)

Does Rust work on DEC Alpha, PA-RISC (hppa), m68k, 32-bit sparc, sh4, RISC Ⅴ, … yet?

*BWAHAHAHAHAHAHAHAHA!*

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

Posted Aug 29, 2019 19:21 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

32-bit SPARC and RISC V are supported by Rust as Tier-2/2.5 architectures: https://forge.rust-lang.org/platform-support.html

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

Posted Aug 29, 2019 19:38 UTC (Thu) by ssokolow (guest, #94568) [Link] (1 responses)

Two of those things are not like the others.

32-bit SPARC on Linux is supported under "Tier 2.5" in the chart of supported targets as sparc-unknown-linux-gnu.

Bare-metal RISC-V (ie. not on top of Linux) is supported by the riscv32imac-unknown-none-elf, riscv32imc-unknown-none-elf, riscv64gc-unknown-none-elf, and riscv64imac-unknown-none-elf targets under tier 2.

The others are blocked on LLVM not having code generators for them though, last I checked, Debian was exploring using the mrustc transpiler to support m68k. (However, currently, mrustc doesn't do borrow checking and is primarily intended for re-bootstraping the self-hosting Rust compiler to provide it free of Trusting Trust attacks.)

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

Posted Aug 29, 2019 20:54 UTC (Thu) by mirabilos (subscriber, #84359) [Link]

Oh, thanks for the honest answers.

Yes, LLVM is another huge portability problem…

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

Posted Aug 29, 2019 22:05 UTC (Thu) by roc (subscriber, #30627) [Link] (8 responses)

Prioritizing the needs of potential Alpha/PA-RISC/m68K/sh4 users over the security of all other users doesn't seem like a great tradeoff to me, in general.

The solution to the LLVM backend problem is simple: Alpha/PA-RISC/m68/sh4 enthusiasts should maintain out-of-tree LLVM backends. That puts the cost of supporting those architectures where it belongs.

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

Posted Aug 30, 2019 6:48 UTC (Fri) by ssokolow (guest, #94568) [Link]

Apparently there was an in-tree Alpha backend that got removed in 2011.

https://github.com/llvm-mirror/llvm/commit/33ba8b0e96acde...

I remember hearing that it was bit-rotting and not good enough, but I don't remember any more details. Still, someone could use it as a starting point.

As for an m68k backend, there have been two attempts I've been able to find with some quick googling:

One that went dormant in 2013 (https://github.com/kwaters/llvm-m68k) and one that had its most recent commit in December 2018 (https://github.com/M680x0/M680x0-llvm).

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

Posted Aug 30, 2019 13:04 UTC (Fri) by mirabilos (subscriber, #84359) [Link] (6 responses)

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)

Posted Aug 30, 2019 16:04 UTC (Fri) by moltonel (subscriber, #45207) [Link] (4 responses)

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)

Posted Aug 30, 2019 19:20 UTC (Fri) by flussence (guest, #85566) [Link] (3 responses)

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)

Posted Aug 30, 2019 20:18 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

RISC-V is supported by the mainline LLVM.

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

Posted Sep 2, 2019 1:28 UTC (Mon) by flussence (guest, #85566) [Link] (1 responses)

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

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

Posted Sep 2, 2019 9:13 UTC (Mon) by moltonel (subscriber, #45207) [Link]

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 ;)

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

Posted Aug 31, 2019 0:03 UTC (Sat) by roc (subscriber, #30627) [Link]

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!