9 ms·

FreeBSD considers Rust in the base system

111 points by signa11 2y ago

ggm 2y ago
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.
- GeorgeTirebiter 2y ago
  If we're going to write RustBSD, why not RustMinix -- and get the benefits of microkernel design? Isn't it about time we give up a few percent performance for robustness?
  - Pet_Ant 2y ago
    Minix is sadly dead. Minix on RISC-V seems like it would have been a pedagogical gold mine and yet it hasn’t happened last I checked.
    - boricj 2y ago
      xv6 is now targeting RISC-V and has displaced MINIX as a better pedagogical tool in my opinion. MINIX is dead for multiple reasons, including technical ones [1]. Simply put, its design and implementation are no longer fit for purpose on modern systems. At this point, starting over from scratch would probably be more effective than trying to address all of its issues. [1] https://news.ycombinator.com/item?id=34916261 https://news.ycombinator.com/item?id=34916261
  - ggm 2y ago
    If it has an ABI which means POSIX tools just work, I'm fine if its a microkernel. MACH was at the heart of lots of things too. We could do capabilities based OS design you name it. 9P, I don't care. What I care about is getting an interactive shell prompt and a filesystem with . and .. and / and BOURNE shell compatible semantics, and an ability to run vi and emacs. (I am less sure plan9 people care about shell btw they went rc and then into some place I don't understand up in the 5th dimension)
    - bakul 2y ago
      Did anybody mention plan9? At any rate it is not a microkernel. There is at least one effort implementing v6 unix in rust. That would probably meet your minimum requirements!
  - yjftsjthsd-h 2y ago
    > why not RustMinix -- and get the benefits of microkernel design? A person could reasonably argue that this is redox. It's different in that it's a new OS rather than a rust-ified version of an existing thing, but still, it's a microkernel unix-ish OS in rust.
- quectophoton 2y ago
  > When the pace of change of Rust moves to less-than-annual Doubt: https://blog.rust-lang.org/2014/10/30/Stability.html#will-rust-and-its-ecosystem-continue-their-rapid-development https://blog.rust-lang.org/2014/10/30/Stability.html#will-ru... > Will Rust and its ecosystem continue their rapid development? > Yes! [...] and we expect this will only accelerate. Emphasis mine.
  - maxbond 2y ago
    You're quoting a post from 2014, before Rust released 1.0. Of course the pace of changes was going to accelerate. I don't think it's fair to present that as if it were a current forward-looking statement from the Rust project. And of course it will slow down over time. Rust and it's ecosystem are much more stable now, ten years later and 80 releases after 1.0.
    - deleted 2y ago
      [deleted]
    - quectophoton 2y ago
      I got that from https://doc.rust-lang.org/edition-guide/editions/index.html https://doc.rust-lang.org/edition-guide/editions/index.html, the second link in the first paragraph.
      - maxbond 2y ago
        Alright. I can see how that might be confusing. To my eye, they are linking to that page because it documents how they intend to approach releases and editions. Not to indicate that they expect the pace of change to monotonically increase into the perpetual future.
bluejekyll 2y ago
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++.”
- andrewstuart 2y ago
  >> "in many ways" These words are doing a lot of work.
  - woodruffw 2y ago
    I think it’s accurate to say that Rust’s syntax and semantics are both simpler than those of modern C++. That isn’t to say that Rust is a simple language (it manifestly isn’t), only that being simpler than C++ is not a hard bar to clear. (The proxy I use for this is the ratio of years spent programming to insane acronyms known. C++ has given me SFINAE, CTAD, SIOF, etc. so far, while Rust has only given me RPIT.)
    - stingraycharles 2y ago
      Don’t forget RAII and CRTP (Curiously Recurring Template Pattern). As someone who has extensive experience in C++, Haskell, and Rust, I can confidently say that none of them is simple, it’s just that C++ has a mountain of legacy / technical debt that Rust has to deal with. If C++ were to be invented today, it would look a lot more like Rust.
      - lifthrasiir 2y ago
        > If C++ were to be invented today, it would look a lot more like Rust. I'm not sure about this, because the world without C++ would have been quite different from today. The main complication comes from the fact that C++ was considered a much higher-level language than today, so its absence would have made other alternatives evolve differently.
snvzz 2y ago
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.
- bluejekyll 2y ago
  I think you need to consider the intention of why you would want to write base components of FreeBSD in Rust. It’s not to make a Rust operating system with its own new features, it’s to maintain and develop on an in existing system with current users, fixing bugs, offering an upgrade path that’s generally backward compatible with existing usage. New features in Rust, old features probably kept in C, unless they are highly problematic.
  - Xylakant 2y ago
    Specifically, rust was designed and created for this use case. It’s the language created to rewrite Firefox in a memory safe language, component by component. This means rust is uniquely capable of integrating into C/C++ code bases, unlike for example go. So it makes sense to do exactly that - take existing projects and slowly migrate them to a memory safe version.
    - gwervc 2y ago
      Which percentage of Firefox is now written in Rust? If the project it was started for still isn't totally migrated, it makes sense for others to remain skeptical. There's value in simplicity, like having to use a single language for a projet instead of two.
      - fnord123 2y ago
        Of the 32,373,275 lines in Firefox that tokei reports, 3,439,065 is Rust. 5,740,010 is in C (C + C Headers). And 5,643,721 is C++ (C++ + C++ Headers). 7,343,459 is JS. Using the "Code" column to ignore comments and blanks. This is based on the mozilla-central-78a5d30a370f bundle. (Also, holy crap it took tokei 10m to run this analysis).
sakras 2y ago
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.
lifthrasiir 2y ago
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!
- phicoh 2y ago
  I think long term, FreeBSD may lose out if Rust in the base system is not supported. Note the 'may'. It is hard to predict the future in this regard. Where I work, we have some open source C code that is also in the FreeBSD base system. We have decided to create new code in Rust and look into deprecating the C code. Obviously, the FreeBSD project can just take over maintenance of the C code, but that will be burden to the project. Note the 'may' and 'long term'. But for a project like FreeBSD it is good to look at Rust before it becomes an issue. A more silent problem, it is quite possible that Rust programmers are less likely to contribute to a project that is based on C and C++ where Rust is not welcome. Certainly when new code is needed, that group will wonder why it needs to be written in C or C++.
deleted 2y ago
[deleted]
OtomotO 2y ago
Meanwhile a Rust maintainer for the Linux kernel steps down: https://www.phoronix.com/news/Rust-Linux-Maintainer-Step-Down https://www.phoronix.com/news/Rust-Linux-Maintainer-Step-Dow...
- deleted 2y ago
  [deleted]
- signa11 2y ago
  yeah, here is the message on lkml [https://lore.kernel.org/lkml/20240828211117.9422-1-wedsonaf@gmail.com/ https://lore.kernel.org/lkml/20240828211117.9422-1-wedsonaf@...] ''' Hey folks, This is as short a series as one can be: just removing myself as maintainer of the Rust for Linux project. I am retiring from the project. After almost 4 years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it's best to leave it up to those who still have it in them. To the Rust for Linux team: thank you, you are great. It was a pleasure working with you all; the times we spent discussing technical issues, finding ways to address soundness holes, etc. were something I always enjoyed and looked forward to. I count myself lucky to have collaborated with such a talended and friendly group. I wish all the success to the project. I truly believe the future of kernels is with memory-safe languages. I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to it what it did to Unix. Lastly, I'll leave a small, 3min 30s, sample for context here: https://youtu.be/WiPp9YEBV0Q?t=1529 https://youtu.be/WiPp9YEBV0Q?t=1529 -- and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code. Thanks, -Wedson '''
  - dralley 2y ago
    Having listened to the audio clip mentioned in their resignation, I can't blame him for getting fed up, certainly if that's a representative sample of how the effort has been treated. Having another maintainer completely shut down your talk by somewhat angrily shouting out irrelevant and fundamentally incorrect complaints and comparisons is incredibly disrespectful.
  - OtomotO 2y ago
lionkor 2y ago
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.
- 2y ago
znpy 2y ago
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.
- pdimitar 2y ago
  To me forking everything is a short-sighted view. Ultimately the OS authors want users of their platform because they believe they can improve the current state of the art. Who needs 100+ more UNIX almost-clones? "Can still be merged back into upstream" is a huge uphill battle. I understand the people who want to skip it.
  - znpy 2y ago
    > To me forking everything is a short-sighted view. Ultimately the OS authors want users of their platform because they believe they can improve the current state of the art. Who needs 100+ more UNIX almost-clones? Actually this has been proven wrong in the real world. Bryan Cantrill in his talk about OpenSolaris (and its sad ending) talked specifically about how being fork-a-phobic was an issue. > Who needs 100+ more UNIX almost-clones? Who needs 100+ GNU/Linux distros? and yet here we are and 100+ GNU/Linux distros is one of the strength of GNU/Linux. Other than this, 100+ more "UNIX almost-clones" are only an issue if they are long lived. If the clone serves the purpose of showing a PoC implementation you can get the PoC reworked and merged into mainline and just kill the fork (see my other comment)
    - pdimitar 2y ago
      > Actually this has been proven wrong in the real world. How so? TL;DR it for me and future readers, please? > Bryan Cantrill in his talk about OpenSolaris (and its sad ending) talked specifically about how being fork-a-phobic was an issue. Nobody is "fork-a-phobic", this is childish talk and completely misses the otherwise clear point that I think I presented. Again, if you can TL;DR it meaningfully people could be interested, otherwise it looks like plain old gatekeeping.
mobilemidget 2y ago
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...
- majewsky 2y ago
  You could say the same about C library dependency hell. I have not used FreeBSD myself, but if I'm remembering correctly, the main reason that dependency hell does not affect the BSDs is that they have their own internal set of C libraries that are developed in tandem. As an OS vendor, FreeBSD could do something like that with Rust. If a Rust application is developed inside the FreeBSD source tree, make it so that it can only use the Rust standard library plus whatever libraries exist inside the FreeBSD source tree.
  - pjmlp 2y ago
    Just like any UNIX proper, the ways of GNU/Linux are the exception. And non-UNIX OSes, where by definition C library belongs to the compiler it is shipped with.
- deleted 2y ago
  [deleted]
- emporas 2y ago
  > All languages with package systems turn into a horrible quality over time. If a new package manager (or the existing one, cargo) tries to fetch packages and doesn't fetch it correctly, the users will be faced with thousands of compilation errors in a moments notice. The new package manager will be abandoned, or the users will revert the existing one to a previous version in which it worked as expected.
- quectophoton 2y ago
assimpleaspossi 2y ago
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.
- whytevuhuni 2y ago
  Rust: - Has the memory safety of Java - But is as fast as C/C++ The thing you have to pay to get that combination, is a LOT more time and frustration fighting the borrow checker, and getting things to compile. But for a kernel (and a few other cases like network servers, browsers, foreign data decoders), I think that trade-off is perfect.
  - wtetzner 2y ago
    > is a LOT more time and frustration fighting the borrow checker, and getting things to compile. As someone who works in Rust professionally, I've only found this to be true in the initial learning curve (which is admittedly steeper than many other languages). But once that up-front cost was paid, I actually find myself more productive in Rust than in other languages.
ruthmarx 2y ago
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.

111 points by signa11 2y ago

ggm 2y ago

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.

GeorgeTirebiter 2y ago
If we're going to write RustBSD, why not RustMinix -- and get the benefits of microkernel design? Isn't it about time we give up a few percent performance for robustness?
- Pet_Ant 2y ago
  Minix is sadly dead. Minix on RISC-V seems like it would have been a pedagogical gold mine and yet it hasn’t happened last I checked.
  - boricj 2y ago
    xv6 is now targeting RISC-V and has displaced MINIX as a better pedagogical tool in my opinion. MINIX is dead for multiple reasons, including technical ones [1]. Simply put, its design and implementation are no longer fit for purpose on modern systems. At this point, starting over from scratch would probably be more effective than trying to address all of its issues. [1] https://news.ycombinator.com/item?id=34916261 https://news.ycombinator.com/item?id=34916261
- ggm 2y ago
  If it has an ABI which means POSIX tools just work, I'm fine if its a microkernel. MACH was at the heart of lots of things too. We could do capabilities based OS design you name it. 9P, I don't care. What I care about is getting an interactive shell prompt and a filesystem with . and .. and / and BOURNE shell compatible semantics, and an ability to run vi and emacs. (I am less sure plan9 people care about shell btw they went rc and then into some place I don't understand up in the 5th dimension)
  - bakul 2y ago
    Did anybody mention plan9? At any rate it is not a microkernel. There is at least one effort implementing v6 unix in rust. That would probably meet your minimum requirements!
- yjftsjthsd-h 2y ago
  > why not RustMinix -- and get the benefits of microkernel design? A person could reasonably argue that this is redox. It's different in that it's a new OS rather than a rust-ified version of an existing thing, but still, it's a microkernel unix-ish OS in rust.
quectophoton 2y ago
> When the pace of change of Rust moves to less-than-annual Doubt: https://blog.rust-lang.org/2014/10/30/Stability.html#will-rust-and-its-ecosystem-continue-their-rapid-development https://blog.rust-lang.org/2014/10/30/Stability.html#will-ru... > Will Rust and its ecosystem continue their rapid development? > Yes! [...] and we expect this will only accelerate. Emphasis mine.
- maxbond 2y ago
  You're quoting a post from 2014, before Rust released 1.0. Of course the pace of changes was going to accelerate. I don't think it's fair to present that as if it were a current forward-looking statement from the Rust project. And of course it will slow down over time. Rust and it's ecosystem are much more stable now, ten years later and 80 releases after 1.0.
  - deleted 2y ago
    [deleted]
  - quectophoton 2y ago
    I got that from https://doc.rust-lang.org/edition-guide/editions/index.html https://doc.rust-lang.org/edition-guide/editions/index.html, the second link in the first paragraph.
    - maxbond 2y ago
      Alright. I can see how that might be confusing. To my eye, they are linking to that page because it documents how they intend to approach releases and editions. Not to indicate that they expect the pace of change to monotonically increase into the perpetual future.

bluejekyll 2y ago

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++.”

andrewstuart 2y ago
>> "in many ways" These words are doing a lot of work.
- woodruffw 2y ago
  I think it’s accurate to say that Rust’s syntax and semantics are both simpler than those of modern C++. That isn’t to say that Rust is a simple language (it manifestly isn’t), only that being simpler than C++ is not a hard bar to clear. (The proxy I use for this is the ratio of years spent programming to insane acronyms known. C++ has given me SFINAE, CTAD, SIOF, etc. so far, while Rust has only given me RPIT.)
  - stingraycharles 2y ago
    Don’t forget RAII and CRTP (Curiously Recurring Template Pattern). As someone who has extensive experience in C++, Haskell, and Rust, I can confidently say that none of them is simple, it’s just that C++ has a mountain of legacy / technical debt that Rust has to deal with. If C++ were to be invented today, it would look a lot more like Rust.
    - lifthrasiir 2y ago
      > If C++ were to be invented today, it would look a lot more like Rust. I'm not sure about this, because the world without C++ would have been quite different from today. The main complication comes from the fact that C++ was considered a much higher-level language than today, so its absence would have made other alternatives evolve differently.

snvzz 2y ago

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.

bluejekyll 2y ago
I think you need to consider the intention of why you would want to write base components of FreeBSD in Rust. It’s not to make a Rust operating system with its own new features, it’s to maintain and develop on an in existing system with current users, fixing bugs, offering an upgrade path that’s generally backward compatible with existing usage. New features in Rust, old features probably kept in C, unless they are highly problematic.
- Xylakant 2y ago
  Specifically, rust was designed and created for this use case. It’s the language created to rewrite Firefox in a memory safe language, component by component. This means rust is uniquely capable of integrating into C/C++ code bases, unlike for example go. So it makes sense to do exactly that - take existing projects and slowly migrate them to a memory safe version.
  - gwervc 2y ago
    Which percentage of Firefox is now written in Rust? If the project it was started for still isn't totally migrated, it makes sense for others to remain skeptical. There's value in simplicity, like having to use a single language for a projet instead of two.
    - fnord123 2y ago
      Of the 32,373,275 lines in Firefox that tokei reports, 3,439,065 is Rust. 5,740,010 is in C (C + C Headers). And 5,643,721 is C++ (C++ + C++ Headers). 7,343,459 is JS. Using the "Code" column to ignore comments and blanks. This is based on the mozilla-central-78a5d30a370f bundle. (Also, holy crap it took tokei 10m to run this analysis).

sakras 2y ago

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.

lifthrasiir 2y ago

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!

phicoh 2y ago
I think long term, FreeBSD may lose out if Rust in the base system is not supported. Note the 'may'. It is hard to predict the future in this regard. Where I work, we have some open source C code that is also in the FreeBSD base system. We have decided to create new code in Rust and look into deprecating the C code. Obviously, the FreeBSD project can just take over maintenance of the C code, but that will be burden to the project. Note the 'may' and 'long term'. But for a project like FreeBSD it is good to look at Rust before it becomes an issue. A more silent problem, it is quite possible that Rust programmers are less likely to contribute to a project that is based on C and C++ where Rust is not welcome. Certainly when new code is needed, that group will wonder why it needs to be written in C or C++.

deleted 2y ago

[deleted]

OtomotO 2y ago

Meanwhile a Rust maintainer for the Linux kernel steps down: https://www.phoronix.com/news/Rust-Linux-Maintainer-Step-Down https://www.phoronix.com/news/Rust-Linux-Maintainer-Step-Dow...

deleted 2y ago
[deleted]
signa11 2y ago
yeah, here is the message on lkml [https://lore.kernel.org/lkml/20240828211117.9422-1-wedsonaf@gmail.com/ https://lore.kernel.org/lkml/20240828211117.9422-1-wedsonaf@...] ''' Hey folks, This is as short a series as one can be: just removing myself as maintainer of the Rust for Linux project. I am retiring from the project. After almost 4 years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it's best to leave it up to those who still have it in them. To the Rust for Linux team: thank you, you are great. It was a pleasure working with you all; the times we spent discussing technical issues, finding ways to address soundness holes, etc. were something I always enjoyed and looked forward to. I count myself lucky to have collaborated with such a talended and friendly group. I wish all the success to the project. I truly believe the future of kernels is with memory-safe languages. I am no visionary but if Linux doesn't internalize this, I'm afraid some other kernel will do to it what it did to Unix. Lastly, I'll leave a small, 3min 30s, sample for context here: https://youtu.be/WiPp9YEBV0Q?t=1529 https://youtu.be/WiPp9YEBV0Q?t=1529 -- and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code. Thanks, -Wedson '''
- dralley 2y ago
  Having listened to the audio clip mentioned in their resignation, I can't blame him for getting fed up, certainly if that's a representative sample of how the effort has been treated. Having another maintainer completely shut down your talk by somewhat angrily shouting out irrelevant and fundamentally incorrect complaints and comparisons is incredibly disrespectful.
- OtomotO 2y ago

lionkor 2y ago

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.

2y ago

znpy 2y ago

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.

pdimitar 2y ago
To me forking everything is a short-sighted view. Ultimately the OS authors want users of their platform because they believe they can improve the current state of the art. Who needs 100+ more UNIX almost-clones? "Can still be merged back into upstream" is a huge uphill battle. I understand the people who want to skip it.
- znpy 2y ago
  > To me forking everything is a short-sighted view. Ultimately the OS authors want users of their platform because they believe they can improve the current state of the art. Who needs 100+ more UNIX almost-clones? Actually this has been proven wrong in the real world. Bryan Cantrill in his talk about OpenSolaris (and its sad ending) talked specifically about how being fork-a-phobic was an issue. > Who needs 100+ more UNIX almost-clones? Who needs 100+ GNU/Linux distros? and yet here we are and 100+ GNU/Linux distros is one of the strength of GNU/Linux. Other than this, 100+ more "UNIX almost-clones" are only an issue if they are long lived. If the clone serves the purpose of showing a PoC implementation you can get the PoC reworked and merged into mainline and just kill the fork (see my other comment)
  - pdimitar 2y ago
    > Actually this has been proven wrong in the real world. How so? TL;DR it for me and future readers, please? > Bryan Cantrill in his talk about OpenSolaris (and its sad ending) talked specifically about how being fork-a-phobic was an issue. Nobody is "fork-a-phobic", this is childish talk and completely misses the otherwise clear point that I think I presented. Again, if you can TL;DR it meaningfully people could be interested, otherwise it looks like plain old gatekeeping.

mobilemidget 2y ago

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...

majewsky 2y ago
You could say the same about C library dependency hell. I have not used FreeBSD myself, but if I'm remembering correctly, the main reason that dependency hell does not affect the BSDs is that they have their own internal set of C libraries that are developed in tandem. As an OS vendor, FreeBSD could do something like that with Rust. If a Rust application is developed inside the FreeBSD source tree, make it so that it can only use the Rust standard library plus whatever libraries exist inside the FreeBSD source tree.
- pjmlp 2y ago
  Just like any UNIX proper, the ways of GNU/Linux are the exception. And non-UNIX OSes, where by definition C library belongs to the compiler it is shipped with.
deleted 2y ago
[deleted]
emporas 2y ago
> All languages with package systems turn into a horrible quality over time. If a new package manager (or the existing one, cargo) tries to fetch packages and doesn't fetch it correctly, the users will be faced with thousands of compilation errors in a moments notice. The new package manager will be abandoned, or the users will revert the existing one to a previous version in which it worked as expected.
quectophoton 2y ago

assimpleaspossi 2y ago

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.

whytevuhuni 2y ago
Rust: - Has the memory safety of Java - But is as fast as C/C++ The thing you have to pay to get that combination, is a LOT more time and frustration fighting the borrow checker, and getting things to compile. But for a kernel (and a few other cases like network servers, browsers, foreign data decoders), I think that trade-off is perfect.
- wtetzner 2y ago
  > is a LOT more time and frustration fighting the borrow checker, and getting things to compile. As someone who works in Rust professionally, I've only found this to be true in the initial learning curve (which is admittedly steeper than many other languages). But once that up-front cost was paid, I actually find myself more productive in Rust than in other languages.

ruthmarx 2y ago

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.