The Case for Rust (in the base system)

kpedersen said:
Its a good approach. They realize that Rust is never going to see the update required to replace C or C++. The only solution to remain relevant is basically a glorified binding generation system.

If the AI can make the code "Rust-centric" rather than just all in an unsafe{} will be interesting. If it can, that refactor could just go towards cleaning up the C and C++ code and making it safe, rendering Rust completely redundant in the first place.

It will basically be a static analyzer on steroids for C and C++. A great idea.
Click to expand...
If the project is a brand-new from-scratch ones, unsafe{} block would be needed for unavoidable limited parts.
But for existing project like FreeBSD and transitioning from C/C++ to Rust codes, unsafe{} block should be prohibited in Rust part, unless it's mandatory to link with codes by other languages (means, purely definitions for interfaces).
This way, in theory, when some memory-unsafe vulnerabilities are observed, developers does NOT AT ALL need to read Rust part of codes.
Of course, in theory. But limiting review to C/C++/Asm parts only would be of help. In the future.

On the other hand, if the above aren't true, why rewrite to Rust? Rust may help decreasing problems about memory safety. But rewriting can cause other kind of errors. My guess is that what Rust can help is about memory safety only.
 
bakul said:
I don't know what that means but I don't want it.
Click to expand...
It means the AI shall do what LLMs are good at - translate one language into some other. Without getting creative, this can help a lot. But we have no way to gauge how much time needs to be spend debugging the outcome, so no way to know if it can actually save time.

The first test I would hand the "AI" would contain things like duff's device and other evil things it will encounter in the wild. Let's see what happens.
 
And don't forget, if AIs are trained with buggy codes in the wild and not told the codes have problems, AIs would surely generate buggy codes, as they don't know the codes they learned as valid are problematic.
 
T-Aoki said:
unsafe{} block should be prohibited in Rust part
Click to expand...
Yep, this is what I meant by Rust-centric. The AI would need to understand about the borrow checker, RC, RAII and other techniques. It is not useful to simply convert C to Rust and wrap it in an unsafe{}.

But if the AI can do that and understand about "borrowing", then there is no longer a need for the language to enforce it; the AI will be able to flag up unsafe code instead and we can all go back to C.
 
sko said:
I don't want any "AI" (i.e. nothing "intelligent" but only a bunch of text-bashing algorithms...) generated crap running on my servers...
Click to expand...
Luckily we are many thousands of generations away from true "AI". All we are really talking about here is a bunch of glorified search algorithms.

It may be more sophisticated than i.e splint, but it isn't more "intelligent" in any kind of way.
 
Jose said:
There's probably a lot of money to be made here. Unfortunately, I'd have to learn Rust.
Click to expand...
I'm reading Rust spec (slowly, though) and discouraged when I found unsafe{}. Now I consider Rust as "not memory safe".
Memory-safe languages mutually cannot describe, for example, drivers for devices that input and output buffers/ports are physically shared.
If the physical design of the hardware is already mutualy memory (port) unsafe, drivers for them are mutually works as memory unsafe, regardless of what language was used to describe it.
Note that the buffers/ports are strictly controlled with synchronous time-division manner could be memory/port safe.
 
I think 'The Rust epidemic' will end sooner or later (as it did with Java). And everyone will be immune. In the worst case, we will mutate and switch to Rust en masse (as it did with Python).:(
 
Not to be hurted, existing projects like FreeBSD base should:
  • do not use crate repo directly, but import needed ones like contrib codes,
  • basically build each single crate into single shared object,
  • use cdylib interface between objects to link with C/C++ objects.
If I understand correctly, crate repo is not a managed-in-whole single project nor single standard library set.
So using crates should be done carefully, crate by crate.

Of course, small enouch projects would be fine rewriting at once, but larger projects like FreeBSD are not. It needs to be step-by-step.

Some of you would reading a thread on freebsd-hackers ML opened by Alan Somers. Would have been already introduced in this thread.
 
This is happening too fast. Whenever some new tech is announced, all of a sudden you see everybody asking questions about it on Stack Overflow in a rush to learn the new thing. I know Rust has been around for a bit but now there's this big rush to incorporate it into every living thing and that signals something just isn't right.
 
cracauer@ said:
It really is the best new
systems-program language for decades. IMHO, it's the only one that's
a compelling replacement for C++ in all new applications, and C in
most.

github.com

GitHub - asomers/freebsd-src at rust-in-base-demo

FreeBSD src tree (read-only mirror). Contribute to asomers/freebsd-src development by creating an account on GitHub.
github.com github.com
"
Click to expand...
How about an old systems programming language as a compelling replacement for C++: Ada? It is time-tested, but continues to be improved. There is an Ada 2022 standard with backward compatibility. And there is a formally verified subset, Spark, that has had recent improvements. Are systems programming languages with good memory-safety profiles other than Rust being considered in this context in this discussion or in another discussion?
 
waleedmebane said:
How about an old systems programming language as a compelling replacement for C++: Ada? It is time-tested, but continues to be improved. There is an Ada 2022 standard with backward compatibility. And there is a formally verified subset, Spark, that has had recent improvements. Are systems programming languages with good memory-safety profiles other than Rust being considered in this context in this discussion or in another discussion?
Click to expand...
The most significant problem about Ada is that (as far as I know) there is no BSD-compatibly licensed compiler/standard libraries for it.

I myself am not using it, but ports-mgmt/synth is written in Ada and once threatened on vanishment, as Ada compiler (prior version of lang/gnat12) was to be dropped due to the lack of maintainer. It would be come true unless the current maintainer popped in.
I myself haven't learned Ada and don't know how many developers in FreeBSD project can write codes in Ada.

And yes, gnat is a part of gcc project, thus, GPL'ed. Cannot include into base.

But as Ada is STRONGLY standardized (for compilers allowed to be named Ada), if the above-mentioned problems/risks becomes no problem, Ada can be the best candidate for memory-safe alternative.
 
waleedmebane said:
How about an old systems programming language as a compelling replacement for C++: Ada? It is time-tested, but continues to be improved. There is an Ada 2022 standard with backward compatibility. And there is a formally verified subset, Spark, that has had recent improvements. Are systems programming languages with good memory-safety profiles other than Rust being considered in this context in this discussion or in another discussion?
Click to expand...
Try this: lang/gcc6-aux. I found it on freshports, it's still actively maintained.
 
T-Aoki said:
The most significant problem about Ada is that (as far as I know) there is no BSD-compatibly licensed compiler/standard libraries for it.
Click to expand...
Thanks for a very helpful reply!

T-Aoki said:
And yes, gnat is a part of gcc project, thus, GPL'ed. Cannot include into base.

But as Ada is STRONGLY standardized (for compilers allowed to be named Ada), if the above-mentioned problems/risks becomes no problem, Ada can be the best candidate for memory-safe alternative.
Click to expand...

GCC used to be shipped with FreeBSD, so perhaps that is not an absolute restriction? GNAT Ada standard libraries have a linking exception.
As for Ada compilers with BSD-like licenses, it doesn't seem like there are any options that are close to complete or likely to be soon. That need not be a permanent situation, though.
 
waleedmebane said:
GCC used to be shipped with FreeBSD, so perhaps that is not an absolute restriction?
Click to expand...
FreeBSD is now on the way dropping non-BSD-compatiblly licensed components from base, and nearly completed.
And one of the reasons switching from old version of gcc to current llvm/clang is, if I understand correctly, to avoid GPL'ed components.
Remaining GPL'ed components should be because there are no alternatives yet or existing candidates are not enough usable for now.
So it would be an absolute restriction.
 
I read somewhere that a company that uses FreeBSD in their products was stuck to use a very old GCC version (I believe 4.2.something) because it was the last one that was licensed under GPL-v2 and they were very happy when FreeBSD moved to Clang.
 
waleedmebane said:
How about an old systems programming language as a compelling replacement for C++: Ada? It is time-tested, but continues to be improved. There is an Ada 2022 standard with backward compatibility. And there is a formally verified subset, Spark, that has had recent improvements. Are systems programming languages with good memory-safety profiles other than Rust being considered in this context in this discussion or in another discussion?
Click to expand...

Ada (and Spark) are fine when you want to dwell in specification, and avoid as many bugs as possible at the cost of tedious programming and maintenance work. Not a good match for an operating system, unless any failure is deemed safety-critical. Also FreeBSD is already struggling to keep up with hardware and software progress, no need to slow things down.

In contrast, Rust covers a lot of common programming mistakes by its language design and compiler checks, without much extra work. Thus it has the potential to take some mental load from both programmers and reviewers, while speeding up the more relevant parts of development.
C was designed when compilers were extremely limited. It still has its role for being very close to the hardware, but I think it's only a matter of time that we want to get rid of the numerous deficiencies of C.

drhowarddrfine said:
This is happening too fast. Whenever some new tech is announced, all of a sudden you see everybody asking questions about it on Stack Overflow in a rush to learn the new thing. I know Rust has been around for a bit but now there's this big rush to incorporate it into every living thing and that signals something just isn't right.
Click to expand...

Maybe, but this "hype" has a remarkably steady push by the developers who actually work with it. Rust (the language) does improve a lot of things, even if it's not a silver bullet or a "Wunderwaffe".
Unlike the current "AI in everything" hype for example, which is a lot of marketing.
 
You must log in or register to reply here.
Back
Top