FreeBSD considers Rust in the base system

This is exactly my experience with Rust as well, people keep thinking C++ is an alternative to Rust with all the same features, but it’s not true. Rust is in many ways a simpler language than C++ and that can make it more productive, “To Kamp's assertion that developers should just use C++, Somers said that he was far more productive in Rust and his code had fewer bugs, too. He said he had used C++ professionally for 11 years, but was more skilled in Rust after six months. The problem, he said, was C++.”

Meanwhile a Rust maintainer for the Linux kernel steps down:

https://www.phoronix.com/news/Rust-Linux-Maintainer-Step-Dow...

Why not go work on redox, or write something new?

I don't get this fixation rust proponents have to try and force-jam it into pre-existing projects, instead of writing their own rust software.

It is totally okay to not use Rust in the base system, as phk reasonably objected. But many arguments against Rust would not necessarily translate to other languages that may reasonably replace C and don't (yet) come with a large ecosystem. (Zig would be a good example here.) In fact, a more productive path forward will be finding such language and funding its evolution so that it remains usable without a large ecosystem to be eventually built!

Isn't this what forks are meant for? Fork FreeBSD to RustBSD and experiment?

Personally I'd prefer if it stays out of FreeBSD. All languages with package systems turn into a horrible quality over time. PHP Composer, Python Pip, node NPM and so on, initially it seems effective but the version dependency/issue hells are true nightmares. And I fear rust with cargo is going to be the same. Maybe I'm wrong, and in case it does go into base, I really hope I'm wrong so the quality of FreeBSD doesn't go down...

Unsolicited opinion: I've been writing C++ for many years, leading a large open source project, writing lots of different code in different domains (embedded, multi-threaded game servers, games, cross platform games, toy kernel(s), website backends, toy databases, a lot of interpreters, compilers, and other such things, parsers). I'm happy to use any and all newer features. I never got into coroutines, but other than that, I find boost's code to be "not so bad". I have similar experience with C alongside that.

I wrote some small games in Zig, I made some money writing Go. I dabbled in Elixir, Erlang, some Lisps, it goes on. I love programming. After my 9-5 C# Job nowadays I usually spend a few hours programming with my friends.

I was extremely skeptical of Rust, due to the hype and some very obnoxious Rust proponents. I learned Rust, I'm still learning it, but I've shipped a few smaller backend apps and worked on a few larger projects now.

The main reason why I think that Rust should replace C++ in all new projects is actually very simple: Tagged unions, pattern matching, reflection, no OOP and the toolchain. There is a lot of syntax in Rust that is beautiful, but besides that, those are the most useful features. They save hundreds to thousands of lines of code per codebase, compared to C++. The Option<T> alone is a simple

    enum Option<T> {
        Some(T),
        None,
    }

Whereas in C++, std::optional<T> is a massive class with edge cases, weird implicit conversions ({} = std::nullopt, beware), and don't even start with differences between different STL implementations. What about `std::make_optional`? At least C++23 adds monadic operations like `.and_then()`, but with the "let's capture by reference why not" lambdas in C++, you easily have dangling references in your lambdas if you do anything multithreaded.

In Rust, I just write code, and if it compiles, it runs and does *exactly* what it says. I don't have to run the code to see if it crashes just because I'm using multiple threads, or a bunch of tokio async tasks. In C++, sure, if it compiles you cleared the first hurdle, but about 60% of the time the code has edge cases you're not considering. Most if not all C++ code I've seen makes assumptions about the lifetimes of things, and/or uses globals, and/or happily uses shared pointers in ways that they were not designed. Anything using `boost::asio` is a gigantic clusterfuck of "make sure you pass by value, by rvalue reference, or as a shared pointer" that, of course, not a single linter or compiler will tell you about if you don't. They don't have to tell you, because that's UB, and that probably crashes horribly, but maybe not!

I can't wait for more people to use Rust so their ecosystem matures a little more.

I can see both sides of this. The excitement of "new" and the concern of what is lost.

C++ wasn't put into critical dependency in the kernel in FreeBSD either. If you think it's just a dialect of C (I don't) then that speaks to the strength of opposition.

Lua was put in the kernel. Perhaps because "it's just forth" and has less risk of drift from a critical dependency.

When the pace of change of Rust moves to less-than-annual, I think it might be valid but frankly I think RustBSD is a better model: fork the code, write a rust kernel, maintain an ABI which C can live with, move forward.

I think that trying to impose some change into an OSS codebase is largely unproductive and in a way, very stupid.

The codebase is bsd-license, it's as good (fork-wise) as it can be.

So go ahead, fork it and explore your ideas... If they're good, they can still be merged back into upstream.

People in the FLOSS scene nowadays are too much fork-a-phobic in my opinion.

Some reference is made to the government report about writing all programs in memory safe languages now. However, the base system is not a "program" and I'm not sure Rust is a viable use here for that reason.

I'm saying that as one who knows little about the language.

Am I understanding correctly that they are proposing to add Rust to only userspace packages, not the kernel like in Linux? I guess the real limitation then is that the base system is built in tandem with the kernel, unlike in Linux.

Honestly if any of the BSD projects were going to consider incorporating Rust you'd think it would be the one that markets itself as being security focused.