LWN: Comments on "An update on gccrs development"

But why

Lennie — Fri, 08 Nov 2024 15:57:36 +0000

- It provides an additional pathway for bootstrapping Rust. (gccrs is not implemented in Rust itself.)

I really like that point, because you can build on something like this:

https://guix.gnu.org/en/blog/2023/the-full-source-bootstr...

But why

ras — Tue, 22 Oct 2024 07:05:25 +0000

> I really do not see the point in gccrs

I find this puzzling. Does there have to be a point to it? People do all sorts of weird things - climb mountains, race cars at lethal speeds, walk across deserts. I guess most people who don't see the point in doing those things either, but beyond "it's not my cup of tea" don't question it. Here someone is donating time and/or money to an open source project. Does it matter why they are doing it, except perhaps to figure out ways to encourage more of it?

I made some (very minor) contributions dotgnu, a C# implementation. There already was a perfectly good open source C# implementation (Mono), but this one was created by someone local and I like playing with compliers, so why not? It was a small group scattered across the globe; great to be part of. I enjoyed myself immensely at the time. DotGNU never really went anywhere, but for me personally I can't think of a better way to learn in great depth about C#, CLR, and it's libraries.

What more reason do need to work on gccrs?

But why

mathstuf — Sun, 13 Oct 2024 20:11:16 +0000

Sure, cookies are more enticing than alcohol for me :) . COI policies may have things to say about actually fulfilling such an offer, but I'll put in a request to do something for LWN (we have our own blog as well, so cross-posting or the like may need considered).

But why

intelfx — Sun, 13 Oct 2024 15:52:24 +0000

> Full disclosure: I'm a CMake developer and implemented its C++ modules support

Can we bribe you with beer and/or cookies to write a guest article for LWN on the state of C++ modules? :-)

I remember one of your multi-screen comments talking about modules a few months ago and I would *love* to see it in form of an article...

But why

mathstuf — Sun, 13 Oct 2024 13:59:33 +0000

> For instance, MSVC has "supported" modules for quite some time now, yet it's quite difficult to find *anyone* (outside of MS at least) who genuinely uses them.

MSVC's module support is ahead of the other implementations IME. Adoption issues have mostly been related to tooling and using modules. Now that CMake[1] has (experimental) support for `import std;` (MSVC and Clang only right now), I think that it is a good time for projects to start investigating modules usage and file issues to compilers for what needs fixing on their side. There's still work to be done on non-compiler, non-build tooling, but I'm working on that too[2].

And I am interesting in modules adoption ecosystem-wide, not just for CMake. I've gone to many build systems trying to get modules support (e.g., xmake[3], tup[4], meson[5], bazel[6]) implemented. There's also the "Are We Modules Yet?"[7] page which aims to track progress.

[1] Full disclosure: I'm a CMake developer and implemented its C++ modules support.
[2] https://cppcon2024.sched.com/event/1gZg8/beyond-compilati...
[3] https://github.com/xmake-io/xmake/issues/386
[4] https://groups.google.com/g/tup-users/c/FhJTA6KAzWU/m/t5P...
[5] https://github.com/mesonbuild/meson/issues/5024#issuecomm...
[6] https://github.com/bazelbuild/bazel/pull/19940#issuecomme...
[7] https://arewemodulesyet.org/

But why

mathstuf — Sun, 13 Oct 2024 13:49:56 +0000

There's still a difference between Polonius (the borrow checker) and the language. The language says "mutable XOR shared"; Polonius and prior borrow checking implementations are imperfect implementations of it. They'll always not be able to check *some* valid coding pattern as following the actual rule and reject code that technically obeys it.

But why

pizza — Fri, 11 Oct 2024 12:45:45 +0000

> Like VLAs?

I asked for an actual citation, not a TLA.

...The only reference I can find about VLAs was when they were formally _documented_ as a GCC extension to C++ (as opposed to just an extension to C since appoximately forever). I found nothing about support for VLAs being _removed_.

Meanwhile, VLAs are actually part of the C99 spec and documented as supported in the latest GCC 14 releases.

So... again, [citation needed] about "and go at any point".

But why

intelfx — Fri, 11 Oct 2024 12:20:23 +0000

> Got a citation for the "and go at any point" ?

Like VLAs?

But why

pizza — Fri, 11 Oct 2024 11:48:54 +0000

> Linux currently is built with a variety of non-standard GCC extensions that are not part of the C language specification. These come and go at any point, which is why the kernel tends to pin a particular GCC version.

Got a citation for the "and go at any point" ?

GCC has historically been _very_ consistent with intentional behavior, and has a very long timeline for the deprecation and removal of features.

Meanwhile, with regards to "pinning" GCC versions, (when I checked a few weeks ago) the minimum required version to compile Linux is v5.1 [1], released over 9 years ago, and the system I'm typing this on uses the latest GCC release (14.2). Regressions do happen of course, but GCC and Kernel developers are quite diligent about fixing those when they occur..

(It's been what, over two decades since I last remember pinning an old GCC version for kernel use?)

[1] Granted, you may need a newer version than that if you have a more recent CPU architecture, or turn on an optional feature (eg one of the many hardening plugins) that needs a newer GCC version.

And it's GPL

moltonel — Fri, 11 Oct 2024 10:41:56 +0000

Pretty ironic then, that the original/main sponsor of Gccrs is OpenSourceSecurity, who sells proprietary gcc plugins (https://grsecurity.net/featureset/gcc_plugins). Like it or not, Gccrs exists partly to protect the interest of proprietary software.

Another thing to note is that Gcc is still very monolithic, to the point that you usually need to fork the whole compiler to add a new backend for your embedded hardware. When it's maintained at all, it's usually frozen in time, frontend-wise. This is much less an issue with LLVM.

One last data point: Ferrocene, the certified Rust compiler which drove the efforts to write a Rust spec, is by policy the exact same code as upstream rustc.

I don't know the future and am happy that Rust doesn't put all its eggs in the same basket, but I don't see gccrs as a protection agains an hypothetical threat of proprietary Rust.

But why

bfeeney — Fri, 11 Oct 2024 09:41:41 +0000

> Rust for Linux still relies on various "unstable" (in the Rust terminology as well) features that are not yet marked stable. To me, this indicates the language is not yet mature.

I think you're conflating "Rust for Linux" and the "Rust language".

I think you're also being misled by the term "unstable".

Linux currently is built with a variety of non-standard GCC extensions that are not part of the C language specification. These come and go at any point, which is why the kernel tends to pin a particular GCC version.

Rust for Linux is in the exact same situation: it uses extensions that are not part of the format Rust language specification.

Unlike with GCC however, you cannot use extensions from a stable release of the compiler. You have to use one of the nightly releases. This is combination of non-standard feature and nightly compiler release is the meaning of the word "unstable" here.

However despite the "unstable" description, one should note that Rust uses the unstable-branch/stable-trunk philosophy, and has an extensive test suite employed for every "nightly release" which it must pass in order to be made available.

The only difference between C/GCC and Rust/Rustc is there is a plan to formally incorporate the extensions for Rust for Linux into the Rust language specification in the short term, which does not exist for C/GCC.

The Rust compiler and language are stable, in the sense that they're bug free.

But why

moltonel — Fri, 11 Oct 2024 09:28:08 +0000

> It's very common for applications to depend on very new (just-released) versions of Rust.

That's in large part "because we can", not because older versions are buggy or unusable. Installing the latest or multiple versions is trivial with rustup, and compatibility is usually perfect (notwithstanding the recent 1.80 time mess). So some developers might jump on the latest 1.81 just for a small improvement like Duration::abs_diff() in 1.81.

Compare that with C++, Python, and other venerable languages where the only reasonable version to use is the one shipped by your distro, which can take months to handle the various regressions before pushing an update, and where it's common for your users to be years behind the latest compiler.

Being able to easily use the latest compiler and even experimental features is undeniably a good thing, even if part of the community raises their minimum required version a bit too aggressively.

But why

itrue — Mon, 07 Oct 2024 15:56:31 +0000

MSVC is a bad C compiler, but a pretty solid C++ one.

But why

raven667 — Mon, 07 Oct 2024 14:13:43 +0000

Thinking about this again while procrastinating before starting work.

You can describe several milestones of maturity, Rust as a mature standalone application development language, Rust maturity for mixed C/C++ applications and library development, Rust maturity building a standalone kernel, Rust used in some generic mixed C/C++ kernels and Rust for Linux the specifically fits in with the internal style and abstractions of Linux. People can end up talking past one another a bit by not being clear as to what they are referring to.

But why

raven667 — Sun, 06 Oct 2024 22:55:31 +0000

> I didn't even say "it's not mature", I said it indicates to me that it isn't yet - very much about my perception and open to discussion

I think this whole effort _is_ the process by which the specific changes needed for Rust to support the existing Linux kernel (rather than a custom all-Rust kernel or userspace application) become mature, Rust is clearly capable of it, the clock for stability _starts_ when the implementation of Rust is ready, but it's only marked as "stable" after some time of real-world use. A half-thought-through analogy is that some special vintage wine is the same liquid put in the bottle the day it was made, when it wasn't special, but time and some tiny changes made it special later, a feature might land in nightly but with time and some tiny changes it becomes stable infrastructure, but it was substantially there the day it was made in nightly. Rust for Linux is going to take several more years to all come together and be seen as old-and-stable, but that is the trend.

Rust applications that require nightly

farnz — Sat, 05 Oct 2024 13:13:46 +0000

The thing I was calling you out on was the claim that the Rust ecosystem as a whole (ripgrep, alacritty, deno, mdbook, wasmer, wezterm, ruffle, atuin, librsvg and others) require nightly; I'm only aware of three projects in the ecosystem that do - the two big browsers, and Rust for Linux.

But why

slanterns — Sat, 05 Oct 2024 11:26:45 +0000

> Last time Rust was forked, which went nowhere (Crab language), they were terrified of being sued for trademark despite rustc being ostensibly "open source".

That's not a truth. The crablang guys indeed created the project as a troll / pushback towards Rust foundation's new trademark policy (and some other dramas). They already sed-ed all Rust to Crab so there's no possibility to be sued. The project died out simply because the creaters do not have the ability to develop a compiler and no real Rust maintainer showed any interest — I also view it as an unnecessary overreaction since the foundation withdraw the new policy in time. So the only thing they can do it grab code from upstream without their own meaningful work, and the project thus remains a joke.

Rust applications that require nightly

sam_c — Fri, 04 Oct 2024 19:36:19 +0000

Oh yes, very much agreed.

But no, we're all used to C++. We're not used to Rust. Perceptions and getting familiar with something new does matter? Especially with the background I mentioned.

But why

pizza — Fri, 04 Oct 2024 17:56:37 +0000

> I'm not sure game consoles are a great example, because MSVC is very relevant on Xbox,

It's more accurate to say that the only reason to use MSVC is if you're targeting Microsoft platforms (including the Xbox).

> so it's still an important factor for cross-platform games and libraries.

That should be "it's still a source of major headaches for cross-platform games and libraries"

(Granted, many of those problems were due to Windows platform-isms rather than MSVC itself...)

But why

excors — Fri, 04 Oct 2024 17:36:56 +0000

> MSVC simply is not a factor for vendors building a custom toolchain (Intel, AMD, Nvidia, etc) or for anyone targeting mobile, linux dominated environments like cloud or HPC, game consoles, embedded, etc

I'm not sure game consoles are a great example, because MSVC is very relevant on Xbox, so it's still an important factor for cross-platform games and libraries. (But it does seem to be retreating even from that niche - the Microsoft Game Development Kit claims to support both MSVC and Clang on Windows and Xbox, though I have no idea how often people choose Clang.)

But why

StillSubjectToChange — Fri, 04 Oct 2024 16:47:57 +0000

MSVC is no "Cinderella story", so to speak. Sure, Microsoft has stepped up their investment into the product, but the fact remains that MSVC has a substantial deficit to overcome. Also, there is a world of difference between advertising support for a feature and actually using it in production. For instance, MSVC has "supported" modules for quite some time now, yet it's quite difficult to find *anyone* (outside of MS at least) who genuinely uses them. Furthermore, MSVC is a total non-factor when it comes to supporting other standards like OpenMP, and eventually OpenACC and SYCL too.

I'm not trying to degrade MSVC in order to elevate GCC and/or Clang. The fact is that MSVC simply doesn't compete with them in most circumstances. Or rather, MSVC simply is not a factor for vendors building a custom toolchain (Intel, AMD, Nvidia, etc) or for anyone targeting mobile, linux dominated environments like cloud or HPC, game consoles, embedded, etc.

But why

tialaramex — Fri, 04 Oct 2024 13:03:11 +0000

> surely this kind of functionality should be worked out already?

That would depend what "this kind of functionality means". For example Linux really can't abide floating point, so for them it's crucial that you can't by any means end up doing floating point operations in Rust for Linux unless you've spelled out that intent very clearly. Unsurprisingly in most applications it's enough that (as is true in stable Rust) you don't stumble onto floating point operations when you never needed them. For example in Rust, just as in C, 5 / 2 is 2 because it's not performing a floating point divide and then transmuting the type as it would in say, Python.

So to adjust from "Yeah, so don't do that" to "We'll make sure you won't do that" Rust for Linux needed tweaks and the stable Rust does not have those tweaks.

Are you astonished that nobody else had this requirement? Nobody in embedded cares, most of the other operating systems are not in a place where "enforce micro-optimisation of context switch overhead" is a focus. If there are people who care (maybe at Microsoft?), and are using Rust for the OS kernel, they're not advertising this use.

In 2023 you could point at alloc, back then Rust for Linux relied on a fork of alloc because Linus requires that allocations are fallible at the point of use, which means all the Rust APIs which panic on allocation failure must be removed from Rust for Linux. Rust's core does not allocate - it doesn't have an allocator so it can't, and Rust's std layer requires an operating system so it will never be part of Rust for Linux - we're implementing the OS not using it. But alloc was in the middle, and so for a period Rust for Linux forked it. That's done, the stable Rust ships all the explicit allocation failure stuff which Linus insists on.

But actually in alloc we do see things where (I did not check specifics) Rust for Linux might want them but they aren't in stable Rust today. Vec::push_within_capacity for example. In C you'd just use it and YOLO. In Rust that will not work† and you must ask for nightly Rust if you want these features.

† You could use Mara's nighty_crimes! macro or write your own, but that's not a serious suggestion and in practice amounts to the same thing.

But why

josh — Fri, 04 Oct 2024 09:57:05 +0000

> It looks like the last time it broke in FF was packed_simd in Rust 1.78

That's news to me; sorry to hear that. I would not have said it was a long time ago if I'd known about the break in 1.78.

Rust applications that require nightly

farnz — Fri, 04 Oct 2024 08:57:28 +0000

I've never had much luck building any browser from source without severe pain, going right back to the days of the Mozilla suite (before Firefox existed), so I can well believe that browsers are a complete pain. Back in the day, the trouble I kept hitting with browsers was that they depended on patched versions of bleeding edge libraries, often built with very specific C++ compiler versions otherwise they wouldn't work, and I can easily believe that that attitude has carried on into their forays with Rust.

But two browser projects is not a significant chunk of the Rust ecosystem; would you accept me dismissing C++ as a language because you can't compile anything with less than 16 GiB RAM + swap (the current minimum for Firefox and Chromium)?

Rust applications that require nightly

sam_c — Fri, 04 Oct 2024 04:07:40 +0000

From some discussion with others off-LWN, it was suggested that some of the cases we've hit are where it's a just-stabilised feature in the latest rustc release, which would make sense with how we then hit it again in our stable version of rust before we stabilise a new version of it on our end.

Rust applications that require nightly

sam_c — Fri, 04 Oct 2024 03:31:26 +0000

I gave a list of examples that came to mind at https://lwn.net/Articles/992686/. Chromium is the biggest hassle at the moment for us. It's important to keep in mind that for many, this might be their first experience with packaging Rust.

But why

sam_c — Fri, 04 Oct 2024 03:28:20 +0000

I'm not sure I agree with that interpretation: I said we see too much reliance on nightly; someone explains that Rust for Linux is special; I say that my opinion is influenced by other projects too. I'd like to see Rust projects overall relying less on nightly.

I didn't even say "it's not mature", I said it indicates to me that it isn't yet - very much about my perception and open to discussion, which is why I'm commenting at all...

> How confident are you that every single C and C++ program that's packaged has all the correct feature tests for the features it depends on?

I spent a lot of time on this sort of thing last year, which LWN wrote about. Not very confident at all! But my point was and remains that if Rust is mature, I'd expect use in the kernel to not need heaps of nightly features. It comes across as odd to me because if Rust is deployed widely in kernel-like environments, surely this kind of functionality should be worked out already?

And it's GPL

sobkas — Thu, 03 Oct 2024 19:33:10 +0000

You know that with MIT/Apache you can get only binary and it would be ok with the license?
It's harder to change/port code when you don't have access to it.

Clearly delinating quirks from intended behaviour

marcH — Thu, 03 Oct 2024 13:45:01 +0000

Typically: when your code does not behave as you expected. Then you check the documentation and you find a gap or problem there.

But why

aragilar — Thu, 03 Oct 2024 12:44:04 +0000

Not suggesting MSVC is in any way poor quality, but I believe that there are still is a fair amount C features post C89 that are not supported, and the lack of __float128 (or its various other incantations) remains a source of pain (even icc supports it, and has for a while). I suspect it depends what part of the standard you are interested in as to who is ahead in features.

But why

peter-b — Thu, 03 Oct 2024 10:22:23 +0000

In my experience with industry, MSVC is "that quirky thing that lags behind the real compilers, oh and I guess we need to stick a bunch of polyfillsworkarounds all over the code code for every real compiler feature it lacks or does a NIHy thing instead".

Recently the MSVC team have been implementing C++ features well ahead of clang. They have been doing very good work and engaging with C++ standardization in a constructive way.

The quality of the compiler and standard library is right up there with GCC and clang, especially with /permissive-. The diagnostics often catch things that GCC and clang don't.

"MSVC is a crap compiler" was an accurate meme in 2015, but that's no longer the case.

Clearly delinating quirks from intended behaviour

kleptog — Thu, 03 Oct 2024 09:01:01 +0000

> Some behavior is ambiguous? Just discuss it, add documentation and a new test and problem solved!

How does one find the ambiguous behaviour unless you try to reimplement it from the documentation?

Documentation is written in language for humans and so by its very nature ambiguous.

But why

tialaramex — Thu, 03 Oct 2024 08:33:37 +0000

I'm comfortable with "good faith" requirements, but remember your good faith position is that Rust isn't a mature language because of Rust for Linux, and when it's pointed out that there's obviously a better explanation, you point at "a lot" of similar cases without specifying, yet look how thin the actual examples you can scrape up are.

How confident are you that every single C and C++ program that's packaged has all the correct feature tests for the features it depends on? Both languages do notionally provide these tests. I've never used them. My guess is that actually very few even try and that the feature tests which are present in the rest are often faulty, so long as the code builds and seems superficially to work on popular platforms that's enough.

LLVM 68K target

brouhaha — Thu, 03 Oct 2024 05:24:08 +0000

Sorry to be wandering off-topic here, but where would I find the LLVM 68K backend? Google turns up what appear to be several different efforts.

Clearly delinating quirks from intended behaviour

marcH — Wed, 02 Oct 2024 23:57:15 +0000

LLVM has been a deliberate (and successful) attempt to avoid the GPL and its "copyleft". That unsurprisingly upset FSF zealots very much. It's not surprising they threw everything they could at it.

The other way round, "cloning" Apache to GPL should be much more "peaceful", technical and rational :-)

Clearly delinating quirks from intended behaviour

viro — Wed, 02 Oct 2024 22:58:46 +0000

Surely I'm not the only one to remember the chorus whinging about The Inherent Evil(tm) of clang/llvm? Complete with "that would just drain gcc contributors pool", "fracture everything", etc. - as well as "they are morally obliged to work on X rather than Y, 'cuz we sais so!!!", nevermind that advocates involved had not been contributing themselves to either project.

Clearly delinating quirks from intended behaviour

marcH — Wed, 02 Oct 2024 22:43:25 +0000

> I generally agree with you that the conventional wisdom advocating for standards and alternate implementations is far more useful and relevant in a world of competing proprietary implementations, and provides less value when the reference implementation is widely used open source/free software, ...

Exactly that. Standards were critical for compatibility and competition in the _old_ days before: 1. Free software, 2. The Internet, 3. Test-driven development, 4. Continuous Integration.

Even in the old days standards were not so great: just look at the C/C++ mess of undefined/implementation-defined behaviors[*], standards always trailing implementations, ugly politics (looking at you W3C), etc.

[*] plenty of elaboration and examples in other comments.

But in today's era, it is now possible to have a free implementation with an extensive test-suite, fast-paced CI and everything just a click way. THAT is better than some old-fashioned, designed-by-committee standard. Some behavior is ambiguous? Just discuss it, add documentation and a new test and problem solved!

"The standard is this [proprietary] implementation" used to really suck. But now it can really rock when done properly.

This being said, if some people see value in maintaining a 2nd class implementation, then agreed: "all the more power to them". As long as they don't pretend they're equal and defer to the reference implementation when in doubt then everything is fine. I think this is more or less what happened with Java BTW - and despite Oracle!

But why

intelfx — Wed, 02 Oct 2024 20:47:48 +0000

Nobody looks to MSVC as if it was a de facto standard though?

In my experience with industry, MSVC is "that quirky thing that lags behind the real compilers, oh and I guess we need to stick a bunch of ~~polyfills~~workarounds all over the code code for every real compiler feature it lacks or does a NIHy thing instead".

But why

dankamongmen — Wed, 02 Oct 2024 20:04:08 +0000

ignoring MSVC here seems a weird miss

But why

ralfj — Wed, 02 Oct 2024 19:31:12 +0000

Note that the Rust project itself already has alternative implementations of many parts of rustc. For instance, rust-analyzer is an alternative parser and partial type-checker. Miri is an alternative execution mode -- basically a codegen backend, except it does interpretation instead of compilation. And of course there is ongoing work on a specification, not with the goal of saying "every compiler that implements this spec is a Rust compiler", but with a goal of saying "this is how rustc behaves". That effort has and will continue to uncover various language quirks, which can then either be fixed or be accepted as "well that's just how things work now", depending on the trade-offs involved.

So we're already getting many of the benefits of alternative implementations and specifications, without the downsides like fracturing the ecosystem due to incompatibilities.

That said, as far as I know the gccrs people are committed to bug-for-bug compatibility with rustc. As long as that remains the case, there shouldn't be a risk of fragmentation, which alleviates most of the concerns. If they find a weird language quirk, what I hope will happen is that this is brought to the attention of the rust-lang project, and until the question is resolved gccrs behaves like rustc. That way hopefully the entire ecosystem can benefit. :)