The Case for Rust (in the base system)

Crivens said:
Sure, lisp would fit the bill, but so does Oberon. And I think the system in the OberonStation (available as a spartan design), was completely written in Oberon, with no assembly code required.
Click to expand...
The Design of an Operating System, a Compiler, and a Computer - Revised Edition 2013
A welcome consequence of the simplifications of language and processor is the fact that all parts that had been written in assembler code in 1992 -- and therefore were not included in the book -- have now been expressed in Oberon as well.
Click to expand...

In the 1992 edition, the NS32032 processor was used, but was no longer available or recommended in 2013, so Wirth switched to RISC. From the above quote, the NS32032 did use assembler, but it wasn't available in the book. However, in the 2013 RISC edition, Wirth was able to use Oberon without the need for assembler.
 
I know a lot of people will automatically think Rust is not a good candidate because the Linux kernel started allowing it. Or because Rust is becoming trendy. I know the FreeBSD kernel allows C and C++. Personally I agree with something others have said. "C++ took all the problems from C and added new ones". Rust is made to be more secure than both and outruns C on 4 different algorithms. C is still faster overall, but Rust easily outruns C++. That being said, I don't know if Rust will stand the test of time. Carbon, Zig and Mojo are probably all future candidates that might replace it in a few years. Zig and Carbon are both backwards compatible with C, where Rust is not. Mojo isn't backwards compatible, but is very fast and very simple python-like syntax. Personally, I would wait a few years and see how those evolve. In the meantime I'd rather see any of the C++ code ported to C. That's me though.
 
gpatrick said:
The Design of an Operating System, a Compiler, and a Computer - Revised Edition 2013


In the 1992 edition, the NS32032 processor was used, but was no longer available or recommended in 2013, so Wirth switched to RISC. From the above quote, the NS32032 did use assembler, but it wasn't available in the book. However, in the 2013 RISC edition, Wirth was able to use Oberon without the need for assembler.
Click to expand...

There's a small amount of assembler (for the boot loader and some kernel routines like disk and clock).

github.com

Source-Code/CERES Oberon V4/ASCII at main · Project-Oberon/Source-Code

Project Oberon Source Code. Contribute to Project-Oberon/Source-Code development by creating an account on GitHub.
github.com github.com
 
astyle said:
Well, GNU coreutils are getting re-written in Rust... and yes, that is "a whole bunch of components getting re-written".
Click to expand...
Ah, I've mis-understood its license. It was MIT licensed and already in ports tree as sysutils/rust-coreutils (not confirmed all equivalents of GNU coreutils are reimplemented).
I've not yet tried these, but looking very roughly into the entry in FreshPorts and official site, current largest problem would be the lack of manpages.

Original sysutils/coreutils contains manpages and a bunch of LC_MESSAGES translations. These would be needed as MIT- (or any other BSD-compatible-)licensed to finish the ports.

And question about crates. All crates linked (if any) are needed to be BSD-compatibly licensed and allowed to be committed to official FreeBSD repo.
Without it, this great work cannot be the Rust-implemented replacements for FreeBSD base system.

And what I was thinking of is about kernel objects (*.ko) and fundamental libraries outside libc/libc++. They would be way more difficult to be demostrated.
 
T-Aoki said:
Ah, I've mis-understood its license. It was MIT licensed and already in ports tree as sysutils/rust-coreutils (not confirmed all equivalents of GNU coreutils are reimplemented).
I've not yet tried these, but looking very roughly into the entry in FreshPorts and official site, current largest problem would be the lack of manpages.

Original sysutils/coreutils contains manpages and a bunch of LC_MESSAGES translations. These would be needed as MIT- (or any other BSD-compatible-)licensed to finish the ports.

And question about crates. All crates linked (if any) are needed to be BSD-compatibly licensed and allowed to be committed to official FreeBSD repo.
Without it, this great work cannot be the Rust-implemented replacements for FreeBSD base system.

And what I was thinking of is about kernel objects (*.ko) and fundamental libraries outside libc/libc++. They would be way more difficult to be demostrated.
Click to expand...
T-Aoki , you might want to read this thread: Thread licensing-rant-debate-thread.90051 if you haven't already.

I personally don't care about the licensing for the rust stuff. I do agree that having good manpages is something that project would need.

I do think that manpages for the original sysutils/coreutils can serve as implementation specs for sysutils/rust-coreutils - but that's up to devs to decide, I'm just a noisemaker here.
 
Differences between OSS licensing usually don't matter for end users like us, but is critical who reuse the codes in their products, especially there are any NDA'ed technology incorporated. For these cases, GPL pollution is critical, as they could be forced to disclose NDA'ed codes missingly based on GPL'ed codes.
With requirements like this, FreeBSD project needed to become allergic about licenses for codes to be merged into base.
For ports, it basically doesn't matter, as each ports themselves are NOT a part of FreeBSD itself. Only ports framework matters.
 
Azrael said:
Can't find the article I saw that talked about this, but if you build a custom kernel and watch it a while you'll see both cc and c++ being called.
Click to expand...
Possibly toolchain-related outside /usr/src/sys?

As bakul showed, no C++ codes in kernel itself.
I tried adding -o -name '*.hpp' to bakul's command line to pick possible C++ header files, still nothing hit.
 
Azrael said:
I'd rather show something everyone could see and examine. Go to FreeBSD's github for the kernel source here. Half way down on the right you'll see a breakdown of all the languages used like this:
Click to expand...
It should be for the whole bunch of FreeBSD src repo (/usr/src), including outside of /usr/src/sys. Maybe most of C++ codes would be of llvm-project.
Going down to sys directory, it didn't shown.
 
T-Aoki said:
It should be for the whole bunch of FreeBSD src repo (/usr/src), including outside of /usr/src/sys. Maybe most of C++ codes would be of llvm-project.
Going down to sys directory, it didn't shown.
Click to expand...
Kernel source starts in /usr/src. As Unitrunker mentioned, searching from there you will find thousands of C++ files. I also linked the files from the FreeBSD repo. You can see there which ones go to what in the code.
 
Hm, see github repo you linked carefully.
Especially Source Roadmap section near the bottom.
This section for kernel is shown /usr/src/sys page.
Files used for building kernel exists outside /usr/src/sys, but sources built into kernel is under /usr/src/sys.
 
You must log in or register to reply here.
Back
Top