LWN: Comments on "Standards for use of unsafe Rust in the kernel"

Valid structures and bugs

farnz — Sun, 01 Sep 2024 09:26:59 +0000

That's part of what I mean by "change the way you think"; if you've designed your filesystem such that constructs that are valid in isolation result in kernel bugs when combined, you have a problem. If you merely have a situation where the kernel remains bug-free, but there's data loss on a corrupt filesystem due to the conflicting structures (e.g. two inodes sharing an extent record means that either inode can modify that extent record), then you don't have a problem.

And part of this is distinguishing severities of bug; a filesystem bug that gives me total control of your machine because a consequence of an impossible construct being present is that the kernel jumps to an attacker-controller address is a different type of bug to one where the filesystem, when faced with a corrupted filesystem image, corrupts it further.

WUFFS and the Linux kernel

pizza — Sat, 31 Aug 2024 17:30:09 +0000

> Part of the point of languages like WUFFS is to change the way you develop software that handles potentially dangerous inputs; instead of trying to validate on the fly,

For filesystems, you still have to validate on the fly. Because there are constructs that are valid in isolation but conflict with each other. You have to validate (and maintain) the _entire_ state holistically, and that is not practical when your metadata alone can easily exceed your memory size.

WUFFS and the Linux kernel

farnz — Sat, 31 Aug 2024 17:18:08 +0000

I did indeed mean 2**(2**44), since I have a 2 TiB exposed capacity drive (no idea how much raw capacity there is) - it's a huge number of possible states. And if I understated the number, that just makes it worse - the underlying issue that WUFFS and friends aim to help you with is reducing the number of input states from "all possible bit patterns" to "valid bit patterns", by forcing you to provide functions from "possible bit pattern" to "valid bit pattern or error state".

WUFFS and the Linux kernel

sammythesnake — Sat, 31 Aug 2024 15:26:35 +0000

> there's around 2**44 possible states for my SSD's exposed storage areas

You have a 44 bit SSD? [scratches head]

Did you perhaps mean something like 2**2**44 (which by my quick stab at calculating corresponds to a ~2TB drive)

Banning unsafe in Rust for Linux device drivers

sammythesnake — Sat, 31 Aug 2024 11:22:53 +0000

Reddit has a handy relative of this (though I don't think history is visible(?)) Edits are noted with something like "last edited at [time]" unless made within some small grace period after the initial post, because:

> most people spot their mistakes as they click "post" :-)

This is *absolutely* the case for the overwhelming majority of edits I'd like to make to *my* posts/comments :-/

The Tower

atnot — Thu, 29 Aug 2024 09:18:28 +0000

I think most of her blog posting energy goes into the axo.dev blog now, e.g. https://blog.axo.dev/2024/07/an-app-by-any-other-name

The Tower

amarao — Wed, 28 Aug 2024 18:48:55 +0000

Btw, why did she stop posting? It was really interesting blog.

Null reference as insta-UB

farnz — Thu, 22 Aug 2024 08:11:23 +0000

That's why I said references must point to a valid place, not a valid instance. It's entirely permissible for the place that's pointed at to not be a valid instance, as long as it's a valid place for the referent type to live in.

The Tower

jsakkine — Wed, 21 Aug 2024 22:37:06 +0000

Your suggestion is based on an imaginary topology that does not exist. Right of the bat, these attributes affecting the topology come to mind:

The top-most commit ID
Kernel config
CPU architecture

Subsystem maintainers will do always only what is best for that particular subsystem.

Null reference as insta-UB

mb — Wed, 21 Aug 2024 22:22:00 +0000

Ok, I guess I don't understand your original posting then.

Null reference as insta-UB

riking — Wed, 21 Aug 2024 22:07:00 +0000

The validity invariant is the things that unsafe code can't ever do. The safety invariant is the things it can be careful about and can't let escape to uncontrolled safe code.

Null reference as insta-UB

mb — Wed, 21 Aug 2024 21:14:15 +0000

But this is only true for "initialized". Even unsafe is not allowed to construct null-references.

Null reference as insta-UB

riking — Wed, 21 Aug 2024 20:38:37 +0000

Note: "references must point to a valid instance of the object" is actually the safety invariant. The validity invariant is "initialized, non-null, aligned to the alignment of the object".

(What does that mean? It means that unsafe code can temporarily hold references that don't point to valid objects as long as it's careful what it does with them (doesn't try to read) and doesn't let the reference escape into safe code not controlled by the author of the unsafe code.)

Banning unsafe in Rust for Linux device drivers

riking — Wed, 21 Aug 2024 20:25:31 +0000

You need to pair this with delaying email notifications until just after the edit period has expired.

Rust and UB

ralfj — Tue, 20 Aug 2024 06:35:31 +0000

Then I hope someone will invest in improving the compilers here. :) I'm not enough of an expert for these low-level parts to judge how much performance they are leaving on the table. But this is simply not something that can be reliably fixed at higher levels of abstraction.

Do you know if there's a bug report against GCC and LLVM discussing the correctness and feasibility of such optimizations?

Maybe this is enough?

corbet — Mon, 19 Aug 2024 14:17:54 +0000

So this has gone on for quite some time; I don't think any minds will be changed at this point. Maybe time to wind it down?

Thank you.

Java/C# vs Rust

khim — Mon, 19 Aug 2024 13:39:19 +0000

> New stuff only rarely replaces the old stuff; instead it's layered on top. It's turtles all the way down.

> And again, it is a simple FACT that Java is vastly more approachable than the stuff it supplanted

Can you stop contradicting yourself at least in two adjacent sentences?

> Multiple generations of ARM processors ran the Java bytecode natively

Nope. Few ARMv5 CPUs has the ability to run some small subset of Java bytecode. It was, basically, to run few games on some phones and for nothing else. Starting from ARMv6 only “null” implementation of Jazelle is supported.

So that's another example of pointless waste (thankfully very limited compared to the damage caused by the large C#/Java crazyness).

> Completely supplanting Pascal in introductory programming courses

Yeah. And also Scheme in some course. Another negative.

> That was a *HUGE* change over the former status quo.

Where do you see me objecting? Sure, C#/Java caused lots of changes. Almost all of them negative.

But you are arguing as if I'm objecting about magnitude of change… I'm not! C#/Java caused absolutely huge negative change.

There were, also, some minuscule positive changes, sure, but compared to problems that C#/Java craze caused they are hard to even notice.

> Sure, many of its use cases have since been better served with newer stuff.

That's not important. What is important is that almost all use cases are better served by older stuff.

> Isn't that the fate of all technology?

Sure. But C#/Java is different: that's the rare case where bad technology was replaced with worse one.

Wanted to say that it's the only such change, but nope, there are many other like that: solar and win power plants, electric cars, etc. That have only started happening recently. About quarter century ago. But, sadly, it's not limited to IT and not limited to C#/Java. True.

But the fact that was achieved by temporary disconnect between feasibility of technology and availability of funding doesn't make that change good and we would pay for that stupidity, and, it looks like, rather sooner than later.

Microsoft and Sun have already paid the price, but I doubt it would be limited to that.

Java/C# vs Rust

pizza — Mon, 19 Aug 2024 12:48:41 +0000

> No matter how you look on it the whole thing it looks like a net negative to me: we haven't gotten any tangible benefits from that rewrite

Wait, _rewrite_? Surely you jest.

New stuff only rarely replaces the old stuff; instead it's layered on top. It's turtles all the way down.

And again, it is a simple FACT that Java is vastly more approachable than the stuff it supplanted, and was useful for nearly everything, from deeply embedded stuff [1] to teaching/toy problems [2] to desktop applications [3] to enterprise consultant wet dreams -- All from the same base tooling. That was a *HUGE* change over the former status quo.

Sure, many of its use cases have since been better served with newer stuff. So what? Isn't that the fate of all technology?

[1] Multiple generations of ARM processors ran the Java bytecode natively
[2] Completely supplanting Pascal in introductory programming courses
[3] Including browser applets. Which I don't miss.

UB in Rust vs C

intelfx — Mon, 19 Aug 2024 00:34:50 +0000

> tive fix for the billion dollars mistake, essentially. References, in Rust, couldn't be null, attempting to create such a reference is an instant UB

Here you're just restating the question and handwaving vigorously. This is not an answer.

>but Option<&T> can hold None and, more importantly, it's guaranteed that in-memory representation for None in Option<&T> is the exact same thing as null in pointer and it's even guaranteed that it would be the same as null in pointer used by C on that platform!

Okay, yeah, so if I correctly understand what you are trying to say here, it's to make niches optimization possible. I didn't think of it.

Java/C# vs Rust

khim — Sun, 18 Aug 2024 14:55:11 +0000

> ...So billions of lines of inherently memory-safe code deployed onto commodity systems never happened?

Of course they happened! Billions of lines of code already written is various memory-safe language (from COBOL and Clarion to Visual Basic and FoxPro) were, with great pains, rewritten in two other, more resource hungry memory safe languages.

Yes, these languages never have been using “managed code” or “tracing garbage collection”, but they were perfectly memory safe and they worked perfectly fine.

No matter how you look on it the whole thing it looks like a net negative to me: we haven't gotten any tangible benefits from that rewrite (although some industries have gotten rich, that's true, but that's like burning the house to heat a stew), code that was before than “grand revolution” written in memory safe languages was still written in memory safe languages (only now with lots of more unneeded complexity) and code written in non-memory safe languages continued to use non-memory safe languages.

Java/C# vs Rust

pizza — Sun, 18 Aug 2024 13:58:12 +0000

> Java have diverged the industry, made it waste trillions of dollars on mirage that never materialized

...So billions of lines of inherently memory-safe code deployed onto commodity systems never happened?

Java/C# vs Rust

khim — Sun, 18 Aug 2024 13:35:24 +0000

> Lisp machines and AS/400s were about as far removed from commodity systems as it could get, and were effectively unobtanium for mere mortals.

And how is that a bad thing? They were solving programs that either are not needed by mere mortals or are not solved by Java.

Java managed to [ab]use managed code but failed to achieve thing that managed code is really good for: forward compatibility. While AS/400 doesn't even give you an ability to execute in native code it's not uncommon for a Java program to code with it's own version of JRE because it may misbehave with any other version and conversion between .NET 1.x, 2.x and .NET core is pretty damn non-trivial.

Thus, in the end, C# and Java achieved intermediate goals these exotic systems achieved in pursit of worthwhile goals yet failed to achieve anything worthwhile outside of hype train.

> Like it or not, Java's particular combination of features and accessibility changed the entire trajectory of the industry.

Isn't that my original point? Java have diverged the industry, made it waste trillions of dollars on mirage that never materialized, sent it into a dead end, and now we would need to spend more trillions of dollars to undo all that damage.

Hardly something to celebrate.

Java/C# vs Rust

pizza — Sun, 18 Aug 2024 12:58:49 +0000

> Sure, Java have shown that you may develop things in a managed code, but List machines did that before Java. Java have shown that you may write portable code but AS/400 did that before.
>None of achievements that Java may show are new and the ones that are new are completely unrelated to these things that Java was supposed to achieve.

Congratulations, you just demonstrated my point.

Lisp machines and AS/400s were about as far removed from commodity systems as it could get, and were effectively unobtanium for mere mortals.

...Unlike Java, which you could obtain for low-to-zero cost and could run on the systems you already had.

Like it or not, Java's particular combination of features and accessibility changed the entire trajectory of the industry.

Java/C# vs Rust

khim — Sun, 18 Aug 2024 12:47:00 +0000

It looks like an attempt to draw a target around the place where arrow hit.

Of course if you spend enough time reframing Java achievements then you can always find a way to define them in way to show that Java did something first.

But premise was to achieve something pretty concrete, billions (if not trillions!) of dollars were spent in an attempt to deliver that and none of the achievements that may last needed these things.

Sure, Java have shown that you may develop things in a managed code, but List machines did that before Java. Java have shown that you may write portable code but AS/400 did that before.

None of achievements that Java may show are new and the ones that are new are completely unrelated to these things that Java was supposed to achieve.

It's like these solar and wind power stations or electric cars: sure, they advanced certain narrow fields significantly, but does the damage they did to the world economy (and, ironically, to the world ecology) are worth it?

This question is debatable but the fact that original promise of “self-sustainable development” wasn't achieved and wouldn't be achieved on this path remains. I suspect that it would be “achieved”, in the end, via sleight of hands when nuclear power would be declared “green”, too and then everyone would be happy about how “green” power works while completely forgetting decades of investment into a dead end.

Java/C# vs Rust

pizza — Sun, 18 Aug 2024 12:27:00 +0000

> I couldn't name any single goal that Java set before itself and made better then some other language.

*single* goal, no. But these goals didn't exist in isolation, and until Java came along, nothing else put them all of those "single goals" together in a way that was both accessible at the entry level (in part due to running on commodity systems) and useful at the high end.

Java/C# vs Rust

khim — Sun, 18 Aug 2024 08:43:49 +0000

> Over time, the bad parts were discarded, and good parts were promoted.

And it's just a sheer coincidence that “bad part” are exclusive for Java but “good part” are not? Really?

> But even with all of its over-engineering, EJB containers like WebLogic or JBoss pioneered some of the best practices that we use even now: artifact-based deployments, monitoring and metrics, centralized logging, and even a notion of proto-containers (WARs and EARs).

Pionered? In what sense? They raised hype around things invented by other, that's all. Syslog doesn't need Java and chroot was invented before it, too. IBM did remote monitoring for decades before Java was ever invented and Google's Borg never needed or used Java (it supported it, though) with Sawzall existing outside of Java, too.

> Java in particular has shown that large and complicated software can be written in memory-safe languages. This was not at all a given in 90-s.

Lisp machines already existed and they have shown that before Java was even dreamed of.

I couldn't name any single goal that Java set before itself and made better then some other language. Even cross-platform development today is mostly happening in JavaScript/TypeScript and not in Java.

C#/Java failed on all goals they set out to deliver (initial goal was to replace C/C++, remember? Javastation was supposed to only run Java applications and Avalon was supposed to replace Win32, not complement it).

C#/Java were pure waste of time and extremely disruptive for the companies that embraced them: Sun is dead is Microsoft have lost much of it's influence, because time that they wasted on unattainable goals was used by others to leapfrog them. If you recall the behaviour of “old” Microsoft then this result is 100% positive and it's true that only C#/Java could have achieved that, but somehow I seriously doubt it was intended.

It would be really funny if Rust would, eventually, replace C/C++. Because it's developers have never embraced that as a goal. There are lots of jokes about “rewrite it in Rust” and some fanboys even say then Rust have to replace C/C++, but actual developers are realists and always designed Rust for the perpetual coexistence with C/C++. On the contrary: Java and C# were designed for the world where everything (except for some low-level components) is in managed code, all development as happening within confines JVM/CLR (basically: commercializaion of List machines concept) and all software is rewritten in managed code. That vision failed utterly and miserably and have only consumed countless resources.

You may point out to the success of Android, but if you read interviews with Andy Rubin, you'll see that Android embraced Java not because of it's wonderful properties, but simply because when Android was made there were lots of Java developers. If Java detour would have never happened he would have picked something else (Apple picked up Objective C because macOS uses it and it worked well for them).

Ultimately the only thing that C#/Java detour us is that world without managed code is viable, while world with only managed code is not. Anyone with two brain cells could have predicted that on the day one, but Google have done a third attempt which is, as expected, falling apart before our eyes.

> Could it have happened this way? Not a chance.

Not in a world obsessed with attempt to make write code so complex that there are no obvious bugs in it work, sure.

Java is very much symptom, not a disease. Disease is that naïve belief that you may replace competence with tools. Planes that are losing doors and AbstractFactoryFactoryBeans come from the same root. And yes, when you traverse that road then C#/Java happens narturally. I just wish we stopped and realized that this is a wrong road to traverse before so much resources would have been wasted.

Banning unsafe in Rust for Linux device drivers

KJ7RRV — Sun, 18 Aug 2024 01:41:26 +0000

This gave me an idea: would it be feasible to actually store article and comment content in a Git repository? That way, the site could just expose an interface to get a comment file's history.

Rust and UB

pbonzini — Sat, 17 Aug 2024 17:32:33 +0000

> that *sounds* like something that the codegen backend of a compiler should take care of

Indeed, but neither GCC nor LLVM even try, as far as I am aware of.

I will check my sources more on the compiler fence vs thread fence issue.

Java/C# vs Rust

Cyberax — Sat, 17 Aug 2024 17:22:42 +0000

> That's why yes, C#/Java craze was gigantic waste of time and resources

I disagree. Java in particular has shown that large and complicated software can be written in memory-safe languages. This was not at all a given in 90-s.

And of course, the Java ecosystem had struggled a lot to formulate the best practices.

If anyone wants to be amazed by over-engineering, just look at the EJB 1.0 standard. But even with all of its over-engineering, EJB containers like WebLogic or JBoss pioneered some of the best practices that we use even now: artifact-based deployments, monitoring and metrics, centralized logging, and even a notion of proto-containers (WARs and EARs). All starting back in 1998-1999.

Over time, the bad parts were discarded, and good parts were promoted. It provided a great learning experience for the whole industry. Would have it been better if the industry magically got all this foreknowledge back in 1999 and avoided painful diversions into the AbstractFactoryFactoryBean territory? Sure. Could it have happened this way? Not a chance.

Java/C# vs Rust

khim — Sat, 17 Aug 2024 12:04:30 +0000

> So independent of computing resources, I think it's unlikely something like Rust could have happened in 1995.

Oh, sure. Rust in 1995 could have been a reality only if IT industry would have picked write code so simple there are obviously no bugs in it way to resolve the software crisis.

But in reality said crisis was resolved via write code so complex that there are no obvious bugs in it which, of course, made creation of Rust in 1995 impossible.

It's ironic that around that time (in 1996 to be exact) Hoare wrote his article where he expressed his satisfaction with the fact that this approach was seemingly working.

And, of course, when everyone was to busy piling layers upon layers of scotch and bailing wire there weren't enough people to do research that could have given us Rust in 1995.

We needed two more decades to realize that while “let's pile layers upon layers of scotch and bailing wire till our creations would stop crashing every few hours” approach works to create something that is useful, but then it doesn't work in the face of adversary.

Thus yes, Rust wasn't a possibility in year 1995, but not because of hardware, rather the social issues prevented it's creation, everyone was just too busy inventing various snake oil solutions which would make programs, magically, correct even when people who write them have no idea what they are doing.

But hardware? Hardware was perfectly “kinda ready” for it: Java was insanely heavy and slow by standards of 1995 and Rust would have been a pig, too, but Rust could have become fast when computers would have become more advanced for more optimizations to become possible, same as happened to Java.

That's why yes, C#/Java craze was gigantic waste of time and resources — but also, probably, inevitable one. World needed these trillion dollars loses to admit that this was the wrong turn, before that happened (as even Hoare, himself, noted) it looked as if enough layers of scotch and bailing wire may fix everything.

Java/C# vs Rust

ralfj — Sat, 17 Aug 2024 10:28:29 +0000

Rust is building on a bunch of academic Programming Languages work that just wasn't done yet in the 90s. For instance, it has taken a lot of good ideas from Cyclone.

So independent of computing resources, I think it's unlikely something like Rust could have happened in 1995.

Rust and UB

ralfj — Sat, 17 Aug 2024 10:14:41 +0000

> Yes—but not in Linux, only in QEMU. QEMU is in user space and uses the C memory model, but historically most people involved were more familiar with Linux atomics.

Thanks for clarifying!

> My understanding is that compiler fences can be used instead of thread fences if you know that two threads only ever run on the same physical CPUs. So, as far as the compiler is concerned, they should block the same optimizations as thread fences, generating the same code apart from the fence instructions themselves. The assumptions that are made on generated instructions might be dubious in terms of portability, but they're fine with respect to data races and hence UB.

Interesting. According to the standard, the only thing compiler fences do is perform synchronization with signal handlers running in the current thread. (Signal handlers are "almost" separate threads in the C++ memory model, except that compiler fences suffices to synchronize with them.)

I'm not enough of an expert in this to say whether that model can be extended to "other threads running on the same physical CPU core" without causing problems.

> The main exception is SeqCst fences after SeqCst RMW operation. Those are unnecessary and pretty expensive (a few tens of cycles) even on x86, and we have a couple in really hot places. I think only Arm needs a processor fence instead, for some unobvious reason related to the semantics of LDAR instructions (which are stronger than just acquire) and to the code that's generated for SeqCst RMW operations.

If those fences can always be compiled to NOPs (presumably with some restriction on what happens between the RMW and the fence), that *sounds* like something that the codegen backend of a compiler should take care of. Backends can do optimizations that programmers cannot do if those optimizations are done sufficiently late during compilation that the program can already be considered to run with a lower-level memory model.

Java/C# vs Rust

khim — Sat, 17 Aug 2024 04:13:37 +0000

> They don't have to do monomorphisation that requires you to keep pretty much all the stuff in RAM.

Which means that it would have been Rust with Extended Pascal/Ada like generics (which would have evolved into a Swift-like generics later, most likely).

I think we are arguing about different things: you say that Rust in a form exactly like Rust was done in 2015 wasn't possible to gave in year 1995 while I say that Rust with all the important properties that matter for safety was easy to create using 1995 technology.

It wouldn't have been competitive with what we have today but it would have been as fast as Java in 1995 (Java wasn't a speed daemon back then buy any means) and it could have evolved, over time, into safe language that could be used for low-level things like Linux kernel, too.

But Java had better marketing and it also promoted write once, run anywhere myth thus it was chosen. And we had to wait 20 years for a something that's safer than what we had in a year 1981.

Java/C# vs Rust

Cyberax — Sat, 17 Aug 2024 03:45:31 +0000

> I don't think it was lack of resources. From Visual Studio blog: throughout the VS 2015 cycle we’ve been focusing on the quality of our expression SFINAE implementation. That's year 2016!

gcc was not much better. It did not support member templates until 2.95 in 1999. In 1995 it did not even support type deduction properly, instead relying on "guiding declarations": https://support.sas.com/documentation/onlinedoc/ccompiler... - you had to explicitly match types, as the compiler couldn't deduce the common types.

> Um. That's how Turbo Pascal 4+ did starting from year 1987 and how Ada did from the day one in year 1983.

They don't have to do monomorphisation that requires you to keep pretty much all the stuff in RAM.

Java/C# vs Rust

khim — Sat, 17 Aug 2024 03:31:24 +0000

> The abovementioned Watcom C/C++ did not support template members, SFINAE, and even ":" initializers in constructors.

I don't think it was lack of resources. From Visual Studio blog: throughout the VS 2015 cycle we’ve been focusing on the quality of our expression SFINAE implementation. That's year 2016!

It's just hard to support certain things when your compiler is not designed to support them. But the fact is that in year 1995 there already were compilers that supported pretty advanced C++ (I think Borland was the most advanced at that time, still) means Rust could have existed back then if someone would have invented it.

> Rust can't compile individual files like C or C++ compilers (of that time). It can operate at most on the crate level.

Um. That's how Turbo Pascal 4+ did starting from year 1987 and how Ada did from the day one in year 1983. Not a rocket science at all and, in fact, it reduces resources consumption not increases them: no need to parse the same thing again and again and again.

Java/C# vs Rust

Cyberax — Sat, 17 Aug 2024 02:32:14 +0000

Rust can't compile individual files like C or C++ compilers (of that time). It can operate at most on the crate level.

> Sure, if Rust would have arrived in year 1995 then it would have been as slow as C++ with heavy template libraries was back then and then Linus would have rejected it, but I don't see what could have prevented Rust from improving in similar fashion to how C++ improved over time.

Heavy template libraries really started appearing in 2000-s, when RAM and CPUs became available. In 90-s a lot of compilers struggled with the STL. The abovementioned Watcom C/C++ did not support template members, SFINAE, and even ":" initializers in constructors.

Java/C# vs Rust

khim — Sat, 17 Aug 2024 02:19:35 +0000

> Rust wouldn't have been possible in 1995, simply because the compilation times and memory requirements were impossibly high for the computers of that period.

What exactly makes Rust extra-heavy? In my experience Rust compiler have similar memory consumption and similar compilation times to C++ compiler and C++ wasn't even all that new in 1995, Borland C++ 4.5, Visual C++ 4.0, Watcom C++ 10.5 were already released in year 1995. All of them included pretty sophisticated and non-trivial template libraries and other pretty heavy things (windows.h alone was humongous, even back then).

Sure, if Rust would have arrived in year 1995 then it would have been as slow as C++ with heavy template libraries was back then and then Linus would have rejected it, but I don't see what could have prevented Rust from improving in similar fashion to how C++ improved over time.

Banning unsafe in Rust for Linux device drivers

Wol — Fri, 16 Aug 2024 23:10:53 +0000

I don't really make much use of its power at work, but aiui, Slack allows edits for a *short* time.

So you might have a bit of a pain with moderation, but if you only allowed editing within, say, five minutes of the original post, then it balances your need to moderate with a poster's desire to correct something. After all, I expect most people spot their mistakes as they click "post" :-)

Cheers,
Wol

Banning unsafe in Rust for Linux device drivers

rc00 — Fri, 16 Aug 2024 22:07:46 +0000

> Can you delete history on github?

Yes.

Java/C# vs Rust

Cyberax — Fri, 16 Aug 2024 21:29:51 +0000

> Would it have been better if Rust had been available in 1995?

Rust wouldn't have been possible in 1995, simply because the compilation times and memory requirements were impossibly high for the computers of that period.

Golang would have worked, though.