Rust in the FreeBSD kernel

jwillia3 said:
On the other hand, it is also clear is how advocates underestimate and downplay the costs of rewriting.
Click to expand...
This 25-year-old article by Joel Spolsky, about how doing a complete rewrite of Netscape killed it, is still one of the most important articles ever posted on the Internet:

www.joelonsoftware.com

Things You Should Never Do, Part I

Netscape 6.0 is finally going into its first public beta. There never was a version 5.0. The last major release, version 4.0, was released almost three years ago. Three years is an awfully long tim…
www.joelonsoftware.com www.joelonsoftware.com

BTW, in the mainframe world, all the folks who are advocating rewriting millions of lines of old COBOL code in Java are facing the same issue.
 
If you don't rewrite in order to fix issues, someone else will do it for you and take all your users. 🤷‍♀️

Related, Rust-in-Linux is no longer experimental as of 7.0.
 
msplsh said:
If you don't rewrite in order to fix issues, someone else will do it for you and take all your users. 🤷‍♀️

Related, Rust-in-Linux is no longer experimental as of 7.0.
Click to expand...

They are not rewriting the Linux kernel in Rust. There aren’t even that many people writing Rust code for the kernel. In the last five years, only about 25,000 lines of Rust have been added to the Linux kernel that’s nothing. I could write 25,000 lines of code in a couple of months casually. A vulkan hello world demo showing a spinning triangle is around a 1000 lines of code. For God’s sake, Perl is more popular than Rust. Rust is only slightly more popular than Scratch, which is essentially a kids’ toy language. https://www.tiobe.com/tiobe-index/scratch/

You know what type of people program in rust? The type who ask there sister to teach them how to kiss! Sister kissers!!!

Programming in rust is like asking your dog to give you herpes! You shouldn't do it, its gross.
 
zester said:
They are not rewriting the Linux kernel in Rust. There aren’t even that many people writing Rust code for the kernel. In the last five years, only about 25,000 lines of Rust have been added to the Linux kernel that’s nothing. I could write 25,000 lines of code in a couple of months casually. A vulkan hello world demo showing a spinning triangle is around a 1000 lines of code. For God’s sake, Perl is more popular than Rust. Rust is only slightly more popular than Scratch, which is essentially a kids’ toy language. https://www.tiobe.com/tiobe-index/scratch/

You know what type of people program in rust? The type who ask there sister to teach them how to kiss! Sister kissers!!!
Click to expand...
While I don't know Rust at all and I'm not involved in any system development, I think everything goes downhill at the moment C complains about an illegal operation when you store a byte on a memory address with no visible context in the program. This is a control hijack... Because the kernel says so, you lost bare-metal control. The commercial software industry will embrace it and call anything without it malware.
 
msplsh said:
If you don't rewrite in order to fix issues, someone else will do it for you and take all your users. 🤷‍♀️

Related, Rust-in-Linux is no longer experimental as of 7.0.
Click to expand...
I don't think end-users care which language is used to write the kernel or other utilities. Users care that it works, it's secure, is free of bugs, and is affordable. For instance, when I put the key in my car's ignition to start it that I expect its firmware be written in <pick your favourite language>. (And yes, there are firmware bugs, like the trunk doesn't always open until the ignition is turned off, but not always.) Similarly users of laptops and phones.

I'm sure the people here at FreeBSD who are thinking about this are considering all the angles. I know some of them. They are considering all the angles.

When I take my developers hat off and put my sysadmin's hat on or put my end-user hat on, I don't care. Most average people don't.
 
msplsh said:
My favorite thing about this forum is that nobody can read what anyone else posts.
Click to expand...

Hey!! Don't judge me just because I can't read!!
MG said:
While I don't know Rust at all and I'm not involved in any system development, I think everything goes downhill at the moment C complains about an illegal operation when you store a byte on a memory address with no visible context in the program. This is a control hijack... Because the kernel says so, you lost bare-metal control. The commercial software industry will embrace it.
Click to expand...

Most companies are investing in AI to maintain and extend the software they already have most of it wasn’t written in Rust. And, the vast majority of development is happening in areas where Rust has no market share, such as Android, iOS, macOS, the web, AI, game development. I test AI every now and then just to see how good it’s getting. Honestly, I’m glad I only have a few years left until retirement, because at this rate it's going to be able to replace me within a year or two. AI wont need rust it will make it's own programming language.
 
cy@ said:
I don't think end-users care which language is used to write the kernel or other utilities. Users care that it works, it's secure, is free of bugs, and is affordable. For instance, when I put the key in my car's ignition to start it that I expect its firmware be written in <pick your favourite language>. (And yes, there are firmware bugs, like the trunk doesn't always open until the ignition is turned off, but not always.) Similarly users of laptops and phones.

I'm sure the people here at FreeBSD who are thinking about this are considering all the angles. I know some of them. They are considering all the angles.

When I take my developers hat off and put my sysadmin's hat on or put my end-user hat on, I don't care. Most average people don't.
Click to expand...

I would be far more concerned with how c developers who use FreeBSD feel about it, because they are the ones who contribute back to FreeBSD.
 
zester said:
Hey!! Don't judge me just because I can't read!!


Most companies are investing in AI to maintain and extend the software they already have most of it wasn’t written in Rust. And, the vast majority of development is happening in areas where Rust has no market share, such as Android, iOS, macOS, the web, AI, game development. I test AI every now and then just to see how good it’s getting. Honestly, I’m glad I only have a few years left until retirement, because at this rate it's going to be able to replace me within a year or two. AI wont need rust it will make it's own programming language.
Click to expand...
I was talking about the economic "advantage" that it takes if all independent developers are artificially forced to rely on a commercial entity. Phones are already done. If your software isn't in an appstore, nobody will see it, use it or buy it and there's no other way except unsafe. The PC will be next. I expect within 5 years. It requires a kernel with supervision above the physical user. The digital age verification and the anti-cheat facilities in game systems have the same motivation.
 
Personally, I'll trust Rust when it will be backed by a standard and multiple robust implementations (not with one taking all the decisions and the others just adapting to that). Right now, it feels like "one of those tech developers obsess about for a decade or two before moving to an other hot thing". FreeBSD looks to me like it expects to have a bigger lifespan than that, it's not a library.
 
I don't think Rust is a good choice.
  • Has "UNSAFE" block that allows anything other than interface definitions between Rust and memory-unsafe languages like C. I don't call such languages a memory-safe language.
  • Unstable spec. Need DeJure international standard before used on OS'es.
  • Unreliable ecosystem that are NOT managed by the project itself.
The first one is most serious. Memory safe languages SHALL not allow writing mutually memory unsafe codes and leave such unavoidable codes to C, asm or something can break memory safety.

If specs about UNSAFE block are clearly made prohibiting to use nothing other than defining "interface to other language" as the last change before standardization and fix initial and imortal mandatory spec are defined in ISO/IEC, and crates are NOT used for base, I'll no longer object to introduce Rust in base. Strictly standardized should be the beginnig of discussion about Rust in base.
 
T-Aoki said:
Strictly standardized should be the beginnig of discussion about
Click to expand...
Would a more productive path be about C (the language most of the <thing> is currently written in)? I mean, can it be achieved by simple starter topics like: "global vars are bad; your programs should capture state". And/or, should style(9) be more exhaustive? The man pages are sometimes really good (-e.g. "don't use atoi(), do this...") but they need more.
 
zester said:
They are not rewriting the Linux kernel in Rust. There aren’t even that many people writing Rust code for the kernel. In the last five years, only about 25,000 lines of Rust have been added to the Linux kernel that’s nothing. I could write 25,000 lines of code in a couple of months casually. A vulkan hello world demo showing a spinning triangle is around a 1000 lines of code. For God’s sake, Perl is more popular than Rust. Rust is only slightly more popular than Scratch, which is essentially a kids’ toy language. https://www.tiobe.com/tiobe-index/scratch/

You know what type of people program in rust? The type who ask there sister to teach them how to kiss! Sister kissers!!!

Programming in rust is like asking your dog to give you herpes! You shouldn't do it, its gross.
Click to expand...

We should have a heart/love/something alike reaction on the forum, thumbs up doesn't do it.
 
T-Aoki said:
  • Has "UNSAFE" block that allows anything other than interface definitions between Rust and memory-unsafe languages like C. I don't call such languages a memory-safe language.
  • Unstable spec. Need DeJure international standard before used on OS'es.
  • Unreliable ecosystem that are NOT managed by the project itself.
Click to expand...

Point #2 and #3 are spot on but #1 requires a bit of expansion. Claim that isolating "memory unsafe" code in the appropriate scopes sounds logical, but only if you work with people who can't constrain themselves from bad design or touching code parts they shouldn't...in essence, commercial development, architects/seniors/juniors style. Think about it, how many experienced system programmers actually care about "memory safety" on the facility level and not on the mindset level. Few to none.

Rust is there to utilize swaths of Javascript-rooted developers into application or system space.
 
JohnK said:
Would a more productive path be about C (the language most of the <thing> is currently written in)? I mean, can it be achieved by simple starter topics like: "global vars are bad; your programs should capture state". And/or, should style(9) be more exhaustive? The man pages are sometimes really good (-e.g. "don't use atoi(), do this...") but they need more.
Click to expand...
My point requiring standization is that backward incompatible changes within FreeBSD branch lifetime causes "non-upgradable (too in-behind) toolchain in base", like when perl was in base. Perl was removed from base, keeping scripts for testing or tool to generate something commitable from existing codes (and the script itself and perl is not needed for usual build targets like buildworld) in-tree.
Not-to-be-outdated thoughout FreeBSD branch lifetime should be considered mandatory. I think more years would be needed to make Rust in such a stable-in-spec state.

msplsh said:
Restricting unsafe to only be used for interop is just code review
Click to expand...
Anything "mutually" memory unsafe something like memory mapped I/O does not fit for rewriting. Rewriting something "possible to be memory safe" would be productive. This should make, especially when rewritten everything belongs to the latter in Rust or some other memory-safe languages, easier to determine that anything C and asm are mutually memory unsafe (or work inprogress or even not started) and other part are already OK.

msplsh said:
Crates not in base is just curation like what's selected for base now
Click to expand...
If backward compatibilities are assured through FreeBSD branch lifetime, it would be OK. But crates doesn't seem as stable in their specs to meet that.
Currently, even Rust itself is, too.
 
Zare said:
Point #2 and #3 are spot on but #1 requires a bit of expansion. Claim that isolating "memory unsafe" code in the appropriate scopes sounds logical, but only if you work with people who can't constrain themselves from bad design or touching code parts they shouldn't...in essence, commercial development, architects/seniors/juniors style. Think about it, how many experienced system programmers actually care about "memory safety" on the facility level and not on the mindset level. Few to none.

Rust is there to utilize swaths of Javascript-rooted developers into application or system space.
Click to expand...
My opinion about "memory safe languages (not limiting with Rust)" is "no need to be able to write everything in itself". Just use right tool that fit for the use-cases is good things. In case with C, something C cannot describe well is written in asm. Just the same applies. Something "memory-safe language(s)" cannot describe well (i.e., "volatile") is written in C, and something C cannot describe well is written in asm.
 
You must log in or register to reply here.
Back
Top