The Case for Rust (in the base system)

And yes, I'm aware you can prefetch it, until this happens...it's the freebsd equivalent of rpm dependency hell.

Code: 
[00:01:39] Package fetch: Skipping rust-1.79.0_1: deps wanted: curl-8.9.1_1
 
Holger said:
I appologize for hurting your feelings. I did not answer to your demographic argument because it is a red herring. If just a minor percentage of the young folks decides to acknowledge the wisdom that has been put into “legacy” code like FreeBSD, that will be enough. Yes, the C programming language, OS-Design, etc. may become niche in the future, but niche is good, because it provides, e.g., job security.
Click to expand...

Thanks, but luckily nobody was hurt.
Frankly, I fail to see the potential of the FreeBSD code base for starting a religious cult around it.

Holger said:
The way to fix things is to fix things. Introducing a new programming language won't help here.
Click to expand...

Disagree with the latter, but that wasn't even my argument, you came up with this unrelated legacy thing. Might want to try a borrow-checker on that.

Holger said:
It's really sad that programming in assembly nowadays seems to be implying being stupid or braindead. The C compiler was once called a “portable assembler” and, indeed, it directly reflects how a CPU works. I concur with Torvalds here who said: “If you think like a computer, then C makes sense!”
Click to expand...

That was true for the first generation of compilers and CPUs back then. Any serious compiler from the last 30 years will optimize your code far beyond from how you would map that C code to assembler. Same goes for performance-oriented CPUs. So nowadays as an excellent programmer, you have to think like a compiler first, and then like a computer. Whether using C or a higher level language.

Holger said:
It may be true that other, more “modern” (yikes) languages are more convenient, but convenience is irrelevant, unless you are a coding monkey that just wants to “get the job done”.
Click to expand...

Go on with that ranting if it makes you feel better. I'm getting snarky, sorry, so I'll leave it at that.
 
cracauer@ said:
Don't forget the 2nd system effect.

Second-system effect - Wikipedia

en.wikipedia.org en.wikipedia.org

People can't resist "improving", which comes down to adding things, when re-implementing anything.
Click to expand...
Exactly. But it usually makes more pains, unfortunately.
Keeping on restructuring (for porting) and adding hooks for future expansion would be the largest addition/modification (other than simplest porting) allowed for the first step.
 
noise said:
Frankly, I fail to see the potential of the FreeBSD code base for starting a religious cult around it.
Click to expand...
I do not see this either. First of all, we lack a guru. Then we lack the missionary zeal. Then … are you sure you are not talking about Linux?

noise said:
[…], you came up with this unrelated legacy thing. Might want to try a borrow-checker on that.
Click to expand...
If I recall correctly, your assumption was that new and talented developers would prefer working with Rust instead of that legacy C-thing that currently is FreeBSD. This is were the “legacy” thing came from.

noise said:
That was true for the first generation of compilers and CPUs back then. Any serious compiler from the last 30 years will optimize your code far beyond from how you would map that C code to assembler. Same goes for performance-oriented CPUs. So nowadays as an excellent programmer, you have to think like a compiler first, and then like a computer. Whether using C or a higher level language.
Click to expand...
No. Machine code coming from C is prefectly debuggable. Sure, some operations might be optimized away, but the general structure is still clear. This is in stark contrast to, e.g., C++, where constructors, destructors, template-metaprogramming etc. create a stark distance between the source code and what is generated by the compiler.

noise said:
Go on with that ranting if it makes you feel better. I'm getting snarky, sorry, so I'll leave it at that.
Click to expand...
Yes, I do use strong language from time to time. Sorry for that. But what drives me up the wall (and what I'm reading in your posts) is the trend in the tech industry to simply throw away stuff that has been worked on for years simply because it is not “modern”, “cool” or “convenient” anymore. And when I use the word “dumb” in this context, I mean exactly this trend.
 
cracauer@ said:
Don't forget the 2nd system effect.

Second-system effect - Wikipedia

en.wikipedia.org en.wikipedia.org

People can't resist "improving", which comes down to adding things, when re-implementing anything.
Click to expand...
As well as removing things they don't like. At Google they used to say version N was obsolete but version N+1 (a rewrite) was not ready for prime time.

IMHO the rustbusters are better off simply starting from scratch. That is, keep the FreeBSD syscall interface (so old programs continue working) but rewrite the kernel and drivers. Then they can gradually rewrite user programs. This way they are not constrained by the current way of doing things or current internal kernel interfaces (which have evolved over decades and gotten rather messy).
 
bakul said:
This way they are not constrained by the current way of doing things or current internal kernel interfaces (which have evolved over decades and gotten rather messy).
Click to expand...
Don't forget about 3rd party kernel modules like x11/nvidia-driver.
C part in the kernel for interface (hopefully, headers only?) should be mandatory even the case you mentioned.
No one can force 3rd parties to support both C and new languages like Rust on transitioning time window. And if NOT all 3rd parties transits to new language, the transitioning time window shouldn't end.
 
T-Aoki said:
Don't forget about 3rd party kernel modules like x11/nvidia-driver.
C part in the kernel for interface (hopefully, headers only?) should be mandatory even the case you mentioned.
Click to expand...
Not to worry. Since Linux guys will rewrite it in Rust, this API will also be in Rust ;-)

More seriously, *all* external interfaces should *very* carefully designed and change rarely and should work across multiple languages. This doesn't seem to be quite the case right now. I have learned to compile the drm-[0-9]+-kmod ports along with the kernel after a few times the system crashed or hung.
 
If leadership allowed Rust in, to evaluate it on technical merits, leadership should not allow nontechnical abuse, as it contaminates the evaluation. If you 🤷‍♀️ about that, then I would be lead to assume you didn't want the evaluation to succeed.
 
msplsh said:
If leadership allowed Rust in, to evaluate it on technical merits, leadership should not allow nontechnical abuse, as it contaminates the evaluation. If you 🤷‍♀️ about that, then I would be lead to assume you didn't want the evaluation to succeed.
Click to expand...

But it's hard to control a conference audience and the points they are making in Q&A.
 
cracauer@ said:
Well, you need thick skin when introducing a new language to an existing project. The "nontechnical nonsense" was bound to happen. Have to shake it off and keep trucking.
Click to expand...
That is not how I saw it. The guy quit because he had no answer to Ted T'so's very reasonable argument. So he blamed his quitting on nontechnical nonsense as a justification.
 
bakul said:
That is not how I saw it. The guy quit because he had no answer to Ted T'so's very reasonable argument. So he blamed his quitting on nontechnical nonsense as a justification.
Click to expand...

That was Ted?

I having made up my mind what I find reasonable in this complex.
 
Mind you, that is my impression and could be wrong. Based on this (from the link blackbird9 shared):
And he concluded his message with a reference to a YouTube video from the Linux Storage, Filesystem, Memory-Management, and BPF Summit in May. Pointing to a portion of the video as an example of the kind of interaction that led him to step down, Filho wrote, "[T]o reiterate, no one is trying [to] force anyone else to learn Rust nor prevent refactorings of C code."

That remark is a response to a comment on the video that, according to Filho, came from Linux kernel maintainer Ted Ts'o: "Here's the thing, you're not going to force all of us to learn Rust."

The video depicts resistance to Filho's request to get information to statically encode file system interface semantics in Rust bindings, as a way to reduce errors. Ts'o's objection is that C code will continue to evolve, and those changes may break the Rust bindings – and he doesn't want the responsibility of fixing them if that happens.
Click to expand...
 
This is what I got from it (rightly or wrongly!)... Ted Tso's problem is he is the maintainer resonsble for keeping that part of the kernel working across an installed base of millions (billions if you include android? - some very large number anyway) of machines. So Ted's main concern is that if some change goes into the C code later on, after the rust code has been integrated, and that subsequent C code change causes the rust code to break in some way, then its him, Ted, that gets landed with the job of fixing it all; which not being a rust expert he'd rather not be responsble for. Seems a pretty valid technical concern to me. At which point the rust guy threw his toys out of the pram and said he wasn't playing any more.
 
blackbird9 said:
subsequent C code change causes the rust code to break in some way,
Click to expand...
He was asking for a defined interface spec so that if the interface changes, the C code has to change AND the Rust code. The interface change precipitates all code change, not C code change precipitating Rust code change.

In this way, just "writing C" does not break Rust, which is what they were trying to emphasize, but writing C that breaks the agreed upon interface does.
 
msplsh said:
I got the sense that was merely the last straw from his "four years" comment, but I have not been paying a lot of attention to this.
Click to expand...
Heh, I noticed that 'four years' comment too ... oh dear... Well, maybe m'sieur Tso is no angel, either... 'twas ever thus!
Although my sympathies lie with Ted in this case as he bears the heavy responsibility of keeping that part of the kernel working, in his position as maintainer. If some major fcuk-up along those lines did occur, we all know whose name would be mud, and it wouldn't be mr rust.
 
msplsh said:
He was asking for a defined interface spec so that if the interface changes, the C code has to change AND the Rust code. The interface change precipitates all code change, not C code change precipitating Rust code change.

In this way, just "writing C" does not break Rust, which is what they were trying to emphasize, but writing C that breaks the agreed upon interface does.
Click to expand...
This is because I want LLVM project developing Rust frontend.
Making backend 100% (not lim.100% but purely 100%) responsible for calling conversions, object formats and so on which affects linking of generated objects could help (hopefully resolve) the problem.

Possibly attempting to do so affects current implementation of whole LLVM if current LLVM-IR is not enouch defined to do so, at the same time forcing them efforts to create Rust frontend. So it's 100% on LLVM guys.
 
I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to it what it did to Unix.
Click to expand...
Bring it.

I expected we would be past tantrums from respected members of the Linux kernel community.
Click to expand...
Whiny baby!

Ted Ts'o's code has stored terabytes of my own data reliably for decades, and untold amounts of my employer's data for at least as long. What has Mr. Whiny delivered besides tantrums?
 
You must log in or register to reply here.
Back
Top