The Case for Rust (in the base system)

cracauer@ said:
I don't think Rust in the FreeBSD kernel was ever in serious discussion.
Click to expand...
Yes. If I recall correctly, there were something like "it's difficult as of technical hurdles with glue logics".
And the currently planned Proof-of-Concept is (if I understand corrctly) for userland.
Anyway, memory-safe language in kernel may be unavoidable in the future, regardless it's Rust or not. And hopefully it should be something sanely link against existing C codes by default, without any hassle. Just a hope.
 
T-Aoki said:
Yes. If I recall correctly, there were something like "it's difficult as of technical hurdles with glue logics".
And the currently planned Proof-of-Concept is (if I understand corrctly) for userland.
Anyway, memory-safe language in kernel may be unavoidable in the future, regardless it's Rust or not. And hopefully it should be something sanely link against existing C codes by default, without any hassle. Just a hope.
Click to expand...

As proved by the seL4 kernel, it does not matter what language does, the only think that matters is that you have a proof, that nothing fails.
 
jb82 said:
Out of curiosity, is the question of Rust in the kernel over given that how it ended up in Linux, or some people still do think it's a great idea? No flame. Just asking about the opinions.
Click to expand...

This is my assessment of the convo happening on the freebsd-hackers mailing list:

- some people really like Rust and it’s obvious to them it should be in base
- some people really dislike Rust and it’s obvious to them it should not be in base
- there are two axes of contention: (1) whether Rust has any merit at all (2) the practicalities of incorporating Rust in base
- there is a lot of circular arguments: when somebody talks about the merits, someone else pipes in saying it doesn’t matter because it’s impractical to incorporate the tool chain. When someone talks about how to incorporate the tool chain, someone else pipes in about how Rust isn’t worthwhile to begin with
- there is some reasonable discussion that looks like “if you can find a use case, and solve the tool chain problem, we can consider it”

I don’t think the Linux drama has anything to do with it, other than to serve as a cautionary tale for what happens when community members dig their heels in.
 
patmaddox said:
This is my assessment of the convo happening on the freebsd-hackers mailing list:
Click to expand...
The summary is missing a practical route, perhaps hardly mentioned on there. Perhaps it falls under:
patmaddox said:
- there is some reasonable discussion that looks like “if you can find a use case, and solve the tool chain problem, we can consider it”
Click to expand...

Rust belongs in its own ports which gets overlayed on top of the regular FreeBSD ports, or its own ports tree which has necessary parts from C family programs. Cargo should only be used for libraries, while Rust Ports can have everything which isn't a library. Otherwise, you'll have redundancy.

Of course Rust has merit, but it is so different than of the C family. It's a frontrunner now of modern languages, though it has issues. As for how much merit, depends upon opinion, but it fundamentally has merit no matter what.

What belongs in the current FreeBSD ports is all that belongs in the C family, and of intended replacements that didn't go anywhere. By giving Rust its own port system, which uses Cargo with minimal redundancy, people can select it to their preference, or use that as a blueprint to come up with a ports system for another Non C family language. Having different port systems for programs of modern languages will reduce unnecessary dependency hell. Of course, old languages which didn't get anywhere stay in the traditional FreeBSD Ports.

Edit: It should be Zig, or a successor of that, or of C, because those are in the C family, and they'll cause minimal complications, as opposed to a language outside of the C family in the base system.
 
The main reason the summary misses a practical route is because I haven't seen one appear yet in the discussion :) I'm not making a case one way or another, just summarizing what I've seen on freebsd-hackers mailing list.

Rust in ports is one of the proposed approaches to resolving the tool chain issue. The main argument against it is that freebsd-src is no longer self-sustaining, the way it is with vendor LLVM.

This is the first time I've heard this idea of Rust having its own ports tree, overlayed with freebsd-ports.
 
patmaddox said:
- some people really like Rust and it’s obvious to them it should be in base
- some people really dislike Rust and it’s obvious to them it should not be in base
Click to expand...
More than "likes" or "dislikes" reasonable technical arguments have been raised on both sides.

patmaddox said:
- there is a lot of circular arguments: when somebody talks about the merits, someone else pipes in saying it doesn’t matter because it’s impractical to incorporate the tool chain. When someone talks about how to incorporate the tool chain, someone else pipes in about how Rust isn’t worthwhile to begin with
Click to expand...
I didn't see any circularity. People disagree on the value of the trade offs involved.

patmaddox said:
I don’t think the Linux drama has anything to do with it, other than to serve as a cautionary tale for what happens when community members dig their heels in.
Click to expand...
More of a cautionary tale of what happens when you rush to embrace the latest cool thing.
 
Jose said:
More of a cautionary tale of what happens when you rush to embrace the latest cool thing.
Click to expand...
Yeah, I don't think Linus respects whatever caution this tale is telling.
Switching to a more modern topic, the introduction of the Rust language into Linux, Torvalds is disappointed that its adoption isn't going faster. "I was expecting updates to be faster, but part of the problem is that old-time kernel developers are used to C and don't know Rust. They're not exactly excited about having to learn a new language that is, in some respects, very different. So there's been some pushback on Rust." -- https://www.zdnet.com/article/linus...-linux-kernel-is-the-only-thing-that-matters/
Click to expand...
"I'm not sure why Rust has been such a contentious area," Torvalds said during an on-stage chat this week with Dirk Hohndel,
Click to expand...
"Clearly, there are people who just don't like the notion of Rust, and having Rust encroach on their area." -- https://www.theregister.com/2024/09/19/torvalds_talks_rust_in_linux/
Click to expand...
"I see the whole Rust thing as positive even if the arguments are not necessarily always"
Click to expand...
 
Jose said:
More of a cautionary tale of what happens when you rush to embrace the latest cool thing.
Click to expand...
Yeah, all the cool kids built microservices. Now companies are learning it's costing them 2.5x more to run microservices in the cloud than it did running monolithic services. Some companies spent 10x more. Following the latest trend doesn't always work out.

I've seen our industry go through many cycles of centralization, decentralization, client/server, then back again, microservices and now back again.

When it comes to programming languages, we've seen a bunch of them. Few so far, except for a tiny few, have affected systems programming. But in the application space it appears to have been a bumpy ride. The web developers I talk to at OpenHack talk about the next new shiny object (programming language). The web development space is terribly fragmented.

IMO importing Rust into the kernel is more aspirational than practical. I doubt it will gain much traction in the Linux kernel because both ecosystems are opposed to each other. A new kernel module here or there? Maybe. But a rewrite? Probably not. Maybe some kid might attempt it but I don't think I'll live that long to see the day Rust replacing C in any kernel.
 
cy@ said:
Yeah, all the cool kids built microservices. Now companies are learning it's costing them 2.5x more to run microservices in the cloud than it did running monolithic services. Some companies spent 10x more. Following the latest trend doesn't always work out.

I've seen our industry go through many cycles of centralization, decentralization, client/server, then back again, microservices and now back again.
Click to expand...
This should be carved in stone.
 
Interesting, detailed blog. More about general software engineering than language choice.

Unsafe Rust Is Harder Than C
Or: The Most Expensive Linked List I've Ever Written

Unsafe Rust Is Harder Than C

Or: The Most Expensive Linked List I’ve Ever Written
chadaustin.me
 
cracauer@ said:

Unsafe Rust Is Harder Than C

Or: The Most Expensive Linked List I’ve Ever Written
chadaustin.me
Click to expand...
Making fair comparisons is always challenging, so resources like this are incredibly valuable. Not only in category theory, but more broadly, one often senses a distinction between things discovered by humans and those invented. C still feels like the former, while Rust feels like the latter. Thanks for sharing!
 
jb82 said:
Making fair comparisons is always challenging, so resources like this are incredibly valuable. Not only in category theory, but more broadly, one often senses a distinction between things discovered by humans and those invented. C still feels like the former, while Rust feels like the latter. Thanks for sharing!
Click to expand...
Well, C was still an invention, not a discovery. C did not exist before UNIX was even invented. Hawaii did exist long before a sailor (sponsored by a British gambler who wouldn't leave the craps table to even eat) discovered it in 1778.
 
astyle said:
C did not exist before UNIX was even invented.
Click to expand...
C was an evolutionary improvement over predecessor languages that Dennis and Ken had been working on (using and designing), in particular BCPL and B. In general, the late 60s and early 70s were a hotbed of programming language designs, with dozens (hundreds?) of new languages showing up. Most of them are only of historical interested today, or outright forgotten. Some have left their influence in modern languages, which sometimes even share the same name and some of the same syntax. But clearly, if someone looked at an early 70s COBOL, Fortran or C program, they would barely recognize it compared to the idiomatic use of today: fixed format, many missing features that are heavily used today, in particular the pre-ANSI function argument syntax.

The same is true of operating systems: At the beginning of the 70s, there were dozens of them in use, all widely divergent, not sharing terribly many design guidelines or code bases or philosophies. The major manufacturers (IBM, Sperry-Univac, CDC/Cray, GE/Bull, DEC, DG, Prime...) all had multiple OSes they sold and supported. In addition, there were quite a few academic or research ones in production (Multics, Plato, the original VM). Today, there are really two left, Windows and Unix, which comes in two flavors, 99% Linux, 1% BSD, the rest is irrelevant.
 
Paul Floyd said:
Whilst non-existent for servers, macOS is still a desktop player, way ahead of any other UNIXy OS.
Click to expand...
You are correct, I forgot both MacOS and iOS, which are both Unix variants, both closely related to FreeBSD (although both contain Mach components too). And I forgot Android, which at the OS level is Linux. So my breakdown of non-Windows as "99% Linux, 1% BSD" is incorrect.
 
ralphbsz said:
C was an evolutionary improvement over predecessor languages that Dennis and Ken had been working on (using and designing), in particular BCPL and B. In general, the late 60s and early 70s were a hotbed of programming language designs, with dozens (hundreds?) of new languages showing up. Most of them are only of historical interested today, or outright forgotten. Some have left their influence in modern languages, which sometimes even share the same name and some of the same syntax. But clearly, if someone looked at an early 70s COBOL, Fortran or C program, they would barely recognize it compared to the idiomatic use of today: fixed format, many missing features that are heavily used today, in particular the pre-ANSI function argument syntax.

The same is true of operating systems: At the beginning of the 70s, there were dozens of them in use, all widely divergent, not sharing terribly many design guidelines or code bases or philosophies. The major manufacturers (IBM, Sperry-Univac, CDC/Cray, GE/Bull, DEC, DG, Prime...) all had multiple OSes they sold and supported. In addition, there were quite a few academic or research ones in production (Multics, Plato, the original VM). Today, there are really two left, Windows and Unix, which comes in two flavors, 99% Linux, 1% BSD, the rest is irrelevant.
Click to expand...
Mac is a thing, you know. And there is a market of RTOS operating systems.
 
You must log in or register to reply here.
Back
Top