A pair of Rust kernel modules

That is incredibly difficult to achieve. For two perfect examples from the database arena, SQL and DataBASIC. There's a whole bunch of subtle differences between SQL dialects, as many people here will be able to attest. Likewise, although far fewer people here are familiar with it, DataBASIC. Both have multiple competing implementations, and there are many corner cases where early design decisions collide badly with compatibility - my favourite DataBASIC statement

REM: REM = REM(6,3); REM this takes the remainder of 6 / 3

Every single usage of REM makes sense, and is legal in at least one DataBASIC compiler, but trying to support all four in this one statement is, well, tricky ... (I believe at least one does, probably OpenQM/ScarletDME.)

We're likely to end up with just the one implementation of rust just to get round the dialect problem. Like most C code is written to the "it compiles with gcc" standard for exactly the same reason.

Probably one of the big drivers pushing the kernel towards llvm/clang is too many developers are getting fed up with the breakages caused by the gcc developers attitude towards "undefined behaviour". And if we do get the kernel compiling successfully with llvm/clang we could rapidly hit a tipping point where new code supports the "well it compiles with llvm/clang" standard.

Cheers,
Wol

If the warning is inappropriate in Rust, simply explain why in the source code

// We genuinely need Drop here, see https://some.example/url
#[allow(drop_bounds)]

And we can promote a warning in the opposite way

// We tried asking people nicely, it didn't work. If you write an overlapping range this won't compile. Learn to count.
#[forbid(overlapping_range_endpoints)]

I have not noticed any such tendency in Rust.

One of the advantages of Rust is that the more powerful type system, and a number of language design features, make a lot of things more explicit and possible for the compiler to reason about precisely. For instance, reference types and nullability are orthogonal, so you don't have to constantly add checks for null; the type tells you if a reference could possibly be null, and so there there can be fewer spurious compiler warnings due to the higher precision of the type system.

Another example would be warnings about use of uninitialized value, like the famous Debian SSH key bug that was introduced by trying to silence a warning about use of uninitialized values. Because this warning was found by someone later who wasn't the original author, they weren't as familiar with the code when trying to fix it, and they made a mistake and removed the actual source of entropy that was being used as well as the uninitialized value. In Rust, this is not a separate warning, but part of the language, so it's something that needs to be dealt with by the original author, rather than by someone else later on trying to silence warnings and not paying enough attention.

That's one of the major design goals of Rust; rather than having to rely on imprecise lints that can frequently lead to spurious warnings and dubious fixes, to have greater expressiveness in the language itself that allow these checks to be precise and enforced consistently, which leads to less confusion.

Usually, the kinds of workarounds that you need to do in cases where the compiler gets it wrong are to just be a little bit more explicit, possibly at the cost of being more verbose. I don't know of many cases where this has caused the introduction of bugs; I'm sure it could happen, but in my experience it seems like the additional expressiveness and precision of the type system far outweighs that, leading to many fewer of these kinds of bugs than you find in C.

> Note, the two of you said at least once "nobody shows" or "nobody claimed" etc. It's pointless to use such rhetoric. It doesn't add any value and needlessly increases tensions because anyone can have one personal counter example.

Sorry, fair point! This is a somewhat common misconception, so you're right, my rhetoric was probably too strong here.

> 15 years ago I was told that Ruby was *the* language of the future, that prevented bugs etc... (hint: it just made them slower to appear). Now in 2022 can anyone cite any developer not working for Gitlab still using this language ?

Ruby seems like a fairly different case than Rust, but off the top of my head, Homebrew, Vagrant, Discourse are all fairly widely used tools written in Ruby; and of course, Ruby on Rails is still a quite popular framework for writing web apps, though many of them are non-free, simply SaaS applications.

> I do have the same concern about Rust: as long as it remains the self-defined input of rustc, it's not exactly a language and it can seriously fail over time.

There are plenty of other successful, long-lived languages. Python has been around for as long as the Linux kernel, and it is defined by a single primary implementation, while also having alternate compatible implementations that are useful like PyPy, and Python is widely used for a large variety of software.

Rust is younger, and thus its alternate implementations are younger and not yet as complete, but it has one independent implementation mrustc which can be used for bootstrapping the compiler, it has another completely independent implementation in the gcc-rs project, and it has a GCC-based backend being added to rustc to supplement the LLVM based backend. The progress on these two implementations has been discussed on LWN recently: https://lwn.net/Articles/907405/

I've also heard rumors that there are other implementation projects that haven't yet been made public; of course those could never see the light of day, but there is a lot of active work in this field right now.

There is also the Rust reference, there's an extensive test suite, there's the entirety of crates.io which is used as an additional test suite, and there's a draft Ferrocene Language Specification https://spec.ferrocene.dev/ which is intended to provide a set of requirements that can be verified against for safety-critical applications.

> Rust does need to adopt a similar approach where there is no more *the* leading implementation and a few others trying to catch up like clang does with gcc or gnugo does with Go

I'm not sure I follow; as you're saying here, the situation for Rust is no different than the situation with C in the Linux kernel, where GCC is the leading implementation and clang is catching up. Are you saying that Rust needs to be held to a higher standard, where there are two independent implementations with feature parity before you can use it? I don't think that this is a reasonable requirement.

Yes, there is value in having multiple independent implementations, but there's also substantial cost in writing the new compiler and the standardization process itself. As mentioned, there is work in progress on all of these fronts (alternative implementations, and more detailed specifications/standards), but I don't think there's any reason to avoid using Rust before those are complete.

Ruby has been overshadowed by Go and JS now that most complex webapps have frontends in JavaScript and the backend just provides a REST API. But back in the day, Ruby allowed tons of small companies to quickly build decent applications and get to market with them.

This list includes GitHub, AirBnB, Groupon, Zillow and many others. The company where I work is built on top of a Ruby app as well.

So it's fair to say that Ruby absolutely fulfilled its promise in the area of web apps. And it has never been really intended as a systems language or a language for desktop applications.