The Case for Rust (in the base system)

bakul said:
You're thinking of *automatic memory management*, which can be runtime or compile time. GC is runtime only.
Click to expand...

Pages 59 and 60 of the 2018 Rust Programming Language talks about it as ownership when discussing "garbage collection." Consider ownership like compile time GC due to the language statically keeping track of allocations and objects coming out of scope. It does this for stack (easy) and for heap.
 
When ownership is not shared, a compiler can generate code to free objects appropriately but shared ownership would require reference counting. I do not know if in rust objects can form cyclic structures. If so it would require a proper GC. At any rate GC by definition is a runtime thing! The rust book probably meant to use automatic memory management.
 
Rust in base sounds nice for me ... also maybe FreeBSD becomes a tier 1 platform of the rust lang then and thus attracting a few devs hopefully.
 
T-Aoki said:
[…] Rust ABI changes too often, meaning "moving goal". First, stabilize (finalize) Rust ABI and language spec from some version in the future. […]
Click to expand...
Seconded. I like standards (well, specifically expectable behavior) and I like FreeBSD because of its high degree of standards compliance. Today, Rust can be deemed en vogue, but only if Rust becomes an ISO-standardized programming language it is really mature enough to use it for a long long-term project like an operating system and its components.​
 
Kai Burghardt said:
Seconded. I like standards (well, specifically expectable behavior) and I like FreeBSD because of its high degree of standards compliance. Today, Rust can be deemed en vogue, but only if Rust becomes an ISO-standardized programming language it is really mature enough to use it for a long long-term project like an operating system and its components.​
Click to expand...

I don't think such a standard will lead to a stable ABI. Only C in its simplicity can realistically have a stable ABI. Maybe scheme. But even C++ does not, not by far.
 
Capsicum doesn't get enough love and attention it deserves. I think capsicumizing more of base would be a better use of work and resources IMO. Assuming the regurgitated premise of Rust is "better security". Why rewrite stuff that works for cool points?
 
Capsicum and Rust serve very different purposes. Capsicum being a capability system is for runtime sandboxing and can prevent unintended access. Rust (as many other languages( avoids many of the issues with C/C++ and so allows you to write programs that are less vulnerable (hence your system would be harder to hack through them). Both can be useful but probably of limited use in an open ended system like FreeBSD & given FreeBSD's very limited human & financial resources.
 
kpedersen said:
Indeed. It opens up the whole of the NPM to us! All those great snippets of code, running directly at ring 0! (or atleast in a node VM that we can't hope to ever be able to audit).
Click to expand...
On a serious note about npm - react works but swc, next.js, and remix.js are all broken. There were workarounds but upstream does not test the workarounds when releasing new versions. Back on topic, ...
 
Back on topic, I can see someone writing a C-to-rust shim plus a few toy drivers. That would let the larger FreeBSD community gain knowledge and experience while rust matures. At this point it is a forward looking research project.
 
I'll tell one of my typical anecdotes. It is actually relevant to this discussion. The Unix tradition has been that the "operating system" itself (not user applications, but what we in FreeBSD call base) is written in a single programming language, namely C (with tiny bits of assembly in the kernel). All other languages then build on that.

Early in its life, Unix competed in the minicomputer space with another OS, namely Digital's VMS. Like Unix, VMS was very popular in research environments; unlike Unix early on, it also had a large customer base in commercial computing. And it supported lots of programming languages: Its FORTRAN compiler was considered the best in the industry, it had perfectly fine C, COBOL, Pascal, PL/I, Lisp, and BASIC compilers, plus obscure things like Ada and RPG-II. All as supported commercial products, orderable from Digital. One of the rules of VMS system development was: Every language that the machine officially supports must also be used in the base operating system. That's to make sure the compilers and runtime libraries have mindshare among the OS developers. Now, for some of the commercial languages, this was a little difficult. I remember a rumor that the "monitor" utility (sort of a cross between ps, iostat, and top, but with much more far-reaching system monitoring) was implemented in RPG-II.
 
Instead of needlessly spending man-hours on adopting new languages I would suggest that FreeBSD developers finally do some serious and organized work on kernel hardware support so that we are not forced to use Linux because of the weakness of our otherwise beloved FreeBSD.

Just my humble opinion, though...
 
In case you did not get it, my remark about using CL in base was in jest. The only language I know to have a worse ABI than Lisp is assembly.
grahamperrin That post summs it up nicely, I think.
 
In my humble opinion, adding one more language to the base system, especially such a complex one as Rust, is not a good idea.

The Rust cognitive complexity is not huge, it is ENORMOUS. Rust is more secure than C, and probably will ever be. However, C safety also gradually increases. Compilers get new checks, there are concepts like the one described in Bounded Flexible Arrays in C. Engineers also try to increase security by applying ideas at the hardware level, for example, CheriABI. Sure, this is still a preliminary stage, but who knows, maybe in a few years all new CPUs will have capabilities.

If I remember correctly, Rust got into Linux not because Linux devs wanted Rust, but because Rust devs wanted Rust in Linux.
 
athan said:
I would suggest that FreeBSD developers finally do some serious and organized work on kernel hardware support so that we are not forced to use Linux because of the weakness of our otherwise beloved FreeBSD.
Click to expand...
What? FreeBSD already supports much more hardware than macOS (and even Windows 11).

(but this is leading off topic. Check out one of the many hardware support threads).
 
cracauer@ said:
I wouldn't say C is broken, but it goes on my nerves. Particularly the lack of ability to have generic algorithms and data structures.
Click to expand...
Actually, you can do that even in C. Sure, you have to come up with your own conventions (e.g. about how to handle specific implementations for specific types in your generic "class") and also, you have to sacrifice strong type safety, as void * is the only "generic" built-in type .... so, it comes with a price, it probably won't work with code someone else wrote (without writing adapters), but still, it's possible.

OTOH, I still admire the simplicity of C, it's IMHO pretty elegant and still there's a solution to (almost) any problem possible in a (somewhat) sane way.

cracauer@ said:
At the same time C++ has IMHO gone off the deep end and sized itself (as in mental load size) out of competition with C++20. I didn't even look at C++23 yet. I guess I am a Rust programmer now?
Click to expand...
I really hated C++ before that, I think some design decisions in that language were b0rked from the very beginning. Details are probably off-topic right here, but it leads to my answer to the general topic:

Looking at the rust language, it looks pretty good conceptually! I think it indeed fills a gap: A "modern" language offering lots of helpful constructs but leaving out the kind of complexity that directly leads to "bloat" while compiling to native machine code and (IMHO in contrast to C++) maintaining a really sane language design.

So given just that, I'd actually love to see it in base. No, it's not just some "hype".

But then, there are a few cons. Like there's still no second independent implementation of rust (at least as far as I know?). Like there are weird requirements (your FreeBSD kernel NEEDS some compat option enabled for programs compiled with rust to work?). Like there's no independent language standard maintained by some standadization body like ISO? Like having to use this system of "cargo and crates" (rolling your own language-specific package manager and then "baking in" dependencies in the build, e.g. by bundling or static linking, seems to be THE "hot shit" nowadays, I think it's just ... well ... without the "hot")?

It would be nice to have improvments on some of these things to really feel positive about including rust in FreeBSD base.
 
drhowarddrfine said:
That's the answer to all questions about programming languages and why C is and should be the dominant language.
Click to expand...
I can't agree with this. Just the fact that you can do something doesn't make it the "best" option. There was evolution in programming languages before C, and it certainly won't stop (actually, it didn't).

C is a good language. It manages to be both "low-level" (more or less directly mapping to machine programs when needed, especially on von-Neumann architectures) and "high-level" (offering quite some helpful abstractions with its concept of the "virtual machine", but here you certainly see its age as well). But the reason it's so dominant nowadays is that it's present at the foundations of almost any OS, because it was the best choice especially for "systems programming" for a long time. I'd bet anything that this won't last "forever" though.
 
All these languages are Turing complete. You can express any program in any of them. That is really not the question at hand.

I will give an example where C fell short for me. I recently worked on a program where a binary search would have been beneficial. A binary search is a simple algorithm that I could probably implement correctly on first try, it is just a few lines. But still, it is a mechanism that should have unit tests and the program doesn't have them (yet). The consequence of screwing this up wouldn't just be a non-working search, it would be memory corruption. C doesn't have array bounds checking. In a different language I could have a type-safe generic implementation and just include it. But in this C program I left a linear search for now pending unit tests.

I also recently corrupted memory by doing incorrect arithmetic for a buffer's size, an operator precedence problem (let's leave aside that a language like Lisp doesn't have operator precedence in the first place). Valgrind caught it before release, but that is not a given. Array bounds checking is something that I turn on in languages that allow that kind of compiler control to trade in the 3% something that it costs (again, Lisp), but C does not offer that.

I'm ready for something more.
 
The whole point of Rust is that the nature of C is that it permits and statistically generates a certain kind of problem that is really, really important to fix and people have had plenty of time to "fix" C and it never happened. It's not that the Rust people want to jam Rust wherever, it's that Rust solves the problem, people want the problem solved, and it's gaining consensus as the tool to solve the problem. It's close enough to ready that people want to start trialing it by fire, which I think is entirely appropriate.

In FreeBSD's case, having two instances of LLVM is right out, though. We just got rid of GCC. So, let that sort itself out (seems just like a "wait a bit" issue), and whatever people are complaining about with API/ABI.
 
cracauer@ said:
I also recently corrupted memory by doing incorrect arithmetic for a buffer's size, an operator precedence problem
Click to expand...
Yep, done that, also been bitten walking pointers for hardware and forgetting about "scalars". Of course, one only forgets about scalars once.
 
You must log in or register to reply here.
Back
Top