For this particular work the huge benefit of Rust is its enthusiasm for encapsulating such safety problems in types. Which is indeed what this article is about.
C and particularly the way C is used in the kernel makes it everybody's responsibility to have total knowledge of the tacit rules. That cannot scale. A room full of kernel developers didn't entirely agree on the rules for a data structure they all use!
Rust is very good at making you aware of rules you need to know, and making it not your problem when it can be somebody else's problem to ensure rules are followed. Sometimes the result will be less optimal, but even in the Linux kernel sub-optimal is often the right default and we can provide an (unsafe) escape hatch for people who can afford to learn six more weird rules to maybe get better performance.
lol... you're talking about the linux kernel, written in C.
The vast majority of software over many decades "bottoms out" in C whether in VMs, operating systems, device drivers, etc.
The scale of the success of C is unparalleled.
https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/pre...
If, somehow, we'd got to an era where (a) operating systems were widely deployed in a different language, and (b) the Morris Worm of 1988 had happened due to buffer overflow issues, then C in its current form would never have been adopted.
C's choices were for performance on hardware-limited systems. I don't really see what other ones made sense historically.
Actually, what made sense _was_ assembly when performance mattered above all. C was actually seen as a higher level language.
However C's advantage was the fact that it was cross platform, so you could compile or quite easily port the same code to many different platforms with a C compiler (Solaris,Windows,BSD,Linux and latterly Mac OSX). That was its strength (pascal shared this too, but it didn't survive).
You can see this in the legacy of software that's still in use today - lots of gnu utilities, shells, X windows, the zlib library, the gcc, openssl and discussed fairly recently POV Ray which has been going since the 80's.
Is the huge macro more convenient than the "bswap" instruction? No, but it's portable.
> I don't really see what other ones made sense historically.
Pascal chose differently in a couple of places. In particular, carrying the length with strings.
C refused to define semantics for arithmetic. This gave you programs which were "portable" so long as you didn't mind different behavior on different platforms. Good for adoption, bad for sanity. It was only relatively recently they defined subtraction to be twos-complement.
16-bit Windows even used C with the Pascal calling convention. http://www.c-jump.com/CIS77/ASM/Procedures/P77_0070_pascal_s...
I'm not sure if you're being facetious here, but that's absurd. It is certainly one of our lowest-level options before reaching for assembly, but it's still a high-level language that abstracts machine details from the programmer.
> In an era where performance mattered, and much software was written for hardware, and controlling hardware, it's hard to see an alternative.
During that era, people who really needed to care about performance used assembly. The optimizations done by C compilers at that time were not nothing, but they were fairly primitive to what they do now.
Using an unsafe block with a very limited blast radius doesn't negate all the guarantees you get in all the rest of your code.
Unsafe blocks limit amount you need to get correct, but you need to get all of them correct. It is not a blast limiter.
The prevalence of buffer overrun bugs in C code shows that it very definitely is possible for programmers to screw up when calculating indices. Rust removes a lot of the footguns that make that both easy to do and dangerous in C. But in unsafe Rust code, you’re still fundamentally vulnerable to any arithmetic bug in any function that you call as part of the computation of an index.
Sounds like bad design. You can typically limit the use for unsafe for so small area than you can verify the ranges of parameters which will cause memory problems. Check for invalid values and raise panic. Still ”memorysafe”, even if it panics.
Let me emphasize that I am not criticizing Rust here. I am just pointing out an incontrovertible fact about how unsafe blocks in Rust work: memory safety bugs are not guaranteed to be localized to unsafe blocks.
UBs have unlimited blast radius by definition, and you'll need to write correct code in all your unsafe blocks to ensure your application is 100% memory-safe. There's no debate around that. From this perspective, there's no difference between a C application and a Rust one which contains a single, incorrect unsafe block.
The appreciable difference between the two, however, is how much more debuggable and auditable an unsafe block is. There's usually not that many of them, and they're easily greppable. Those (hopefully) very few lines of code in your entire application benefit from a level of attention and scrutiny that teams can hardly afford for entire C codebases.
EDIT: hardy -> hardly (typo)
The main value is that you only have to make sure that a small amount of code surrounding the unsafe block is safe, and hopefully you provide a safe API for the rest of the code to use.
This is definitely a strong benefit though.
It's true that you need to have unsafe code to do low level things. But it's a misconception that if you have to use unsafe then Rust isn't a good fit. The point of the safe/unsafe dichotomy in Rust is to clearly mark which bits of the code are unsafe, so that you can focus all your attention on auditing those small pieces and have confidence that everything else will work if you get those bits right.
How much of this is actually 100% unambiguously necessary? Is there a good reason why anything in the filesystem code at all needs to be unsafe?
I suspect it's a very small subset needed in a few places.
I have to admit, while I do enjoy rust in the sense that it makes sense and can really "click" sometimes. For anything asynchronous I find it really rough around the edges. It's not intuitive what's happening under the hood.
One of the major wins of Rust is encoding thread safety in the type system with the `Send` and `Sync` traits.
Right, but tasks are sharing the same thread which is fine, but when we need to expand on that with them actually working async, i.e non blocking, fire and quasi-forget, its tricky. That's all I'm saying.
Now, lifetimes attached to function signatures is definitely a problem.
> C#'s Task/Task<T> are based on background execution. Once something is awaited, control is returned to the caller.
Async/await in any language happens in the background.
What happens during a Task.Yield() (C#)? The task is yielded to the another awaiting task in the work queue. Same as Rust.
> OTOH, Rust's Future<T> is, by default, based on polling/stepping,
The await syntax abstracts over Future/Stream polling. The real difference is that Rust introduced the Future type/concept of polling at all (which is a result of not having a standard async runtime). There is a concept of "is this task available to proceed on" in C# too, it's just not exposed to the user and handled by the CLR.
In c# you probably never call yield.
Synchronous part of an async method in C# will run "inline". This means that should there be a computationally expensive or blocking code, a caller will not be able to proceed even if it doesn't await it immediately. For example:
var ptask = Primes.Calculate(n); // returns Task<ulong[]>
// Do other things...right?
// Why are we stuck calculating the primes then?
Console.WriteLine("Started.");
If a caller does not control .Calculate, the most common (and, sadly, frequently abused) solution is to simply do
var task = Task.Run(Primes.Calculate);
// Do something else
var text = string.Join(',', await task);
However, a better solution is to instead insert `Task.Yield()` to allow the caller to proceed and not be blocked, before continuing a long-running operation:
var ptask = Primes.Calculate(n); // returns Task<ulong[]>
// Successfully prints the message
Console.WriteLine("Started.");
static async Task<int[]> CalculatePrimes(int n)
{
await Task.Yield();
// Continue execution in a free worker thread
// If the caller immediately awaits us, most likely
// the caller's thread will end up doing so, as the
// continuation will be scheduled in the local queue,
// so it is unlikely for the work item to be stolen this
// quickly by another worker thread.
}