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.
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?
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.
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)
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!
> 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.
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.
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.
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++.”
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.)
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.
> 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.
“Simpler” is so fuzzy that it doesn’t accurately express what’s going on. Rust doesn’t have the backwards compat baggage that C++ has, so it’s simpler.
However, I can today easily write clean C++ that’s easy to understand, and using containers, algos and smart pointers is also robust. This is what the C++ community has settled on, while pushing complexity into libraries.
The Rust community has settled on async, moves and references (with the lovely lifetime annotations) and other cognitive overhead, because they think that getting errors at compile time offsets all the mental overhead of those constructs. Then they gaslight all the beginners which complain about that mental overhead.
So in theory Rust may be simpler, but idiomatic Rust isn’t. It’s differently complex.
C++ has exactly the same async mechanism as Rust. Moves and references are much simpler in Rust - values only ever move and copies require an explicit clone unless the type is copyable in which case the compiler will implicitly clone if there’s conflicting ownership in the code.
This is orders of magnitude simpler than c++ overloading of copy/move assignment and constructors, even when you follow the rule of 0 (not least of which is that you don’t to teach people about it or how to keep code exception safe).
It’s kind of amusing to claim that c++ is simpler than Rust when it’s demonstrably not true - a new person to Rust is more productive after 6 months than a person new to c++. That implies the bar to getting proficient is low. A person can reach intermediate more quickly implying the bar to the next levels is lower. And it’s easier to maintain a rust project due to cargo meaning a usable easy build system out of the box that the entire community uses vs opinionated choices each project has to do, and macros that are easier to manage than preprocesser mess. So easier to maintain and easier to jump into any project. Oh and tests and mictobenchmarks out of the box and a very rich ecosystem of supporting libraries.
Idiomatic rust is simpler than idiomatic c++ and it’s clearer what constitutes idiomatic rust whereas c++ in practice is rarely idiomatic and there are going to be conflicting ideas on what is idiomatic.
This is ignoring the very real benefits of rarely to never dealing with a whole class of difficult to debug bugs (threading and memory safety) in the vast majority of code you’ll write .
> C++ has exactly the same async mechanism as Rust
Is this true? I ask because I've seen it mentioned that a C++ co_await suspends that call frame alone (thus the call returns to the caller and resumes immediately), where as Rust's .await suspends the entire call stack (all frames up to and including the caller). If true, in what sense are these mechanisms same?
Not the mechanism itself but the same in the context of this statement:
> The Rust community has settled on async, moves and references (with the lovely lifetime annotations) and other cognitive overhead
The rust community has settled on async in the same way that the C++ has - it's an optional keyword that is some syntactic sugar over compiler-generated stuff. The main unique "cognitive overhead" is that Rust forces you to write down lifetimes when they can't be inferred, but the rest is the same or worse in C++.
As for the async mechanism, I don't believe there's magic in Rust that suspends the entire call stack. It walks up the stack the same as in C++. If you don't await an async function call or one returning a future, then there's no suspension and the inner function is executed until the first suspension point if I recall correctly same as in C++. There's nuances in differences but at a high level they're very similar in that it's generating a state machine and nothing more; Rust does require a runtime whereas C++ can do without since the Rust picked generic futures that work on all runtimes whereas in C++ you have to have the runtime provide the future implementation (or have the future not be part of any runtime).
Only in Rust is the async use idiomatic, the C++ co_* is pretty new and not yet ready for prime time.
References are not at all simpler, they're memory-safe, which in conjunction with lifetimes makes them significantly more complex to understand and write. This is a known problem...
In C++ I copy by default and move if I want to optimise. Moves also happen behind the scenes as an optimisation, this is how things should be, don't push the work on the programmer!
I don't agree with your claim that a new person to Rust is more productive. What's that based on? In my experience, a new person to Rust will write memory-safe code by default, which is good, but they pay the cost of Rust's lack of ergonomics forever. See https://news.ycombinator.com/item?id=40172033 which covers async, refactoring and design issues that plague even experienced programmers.
> Idiomatic rust is simpler than idiomatic c++ and it’s clearer what constitutes idiomatic rust whereas c++ in practice is rarely idiomatic and there are going to be conflicting ideas on what is idiomatic.
It's really not, because C++ copies by default which is typically both memory-safe and very easy. If using smart pointers and clone was idiomatic in Rust, you'd have a point, instead references and lifetimes are idiomatic.
Modern C++ has a pretty clear definition, albeit it's evolving as new things are added to the standard. C++ is moving too fast recently, but then again so is Rust.
> This is ignoring the very real benefits of rarely to never dealing with a whole class of difficult to debug bugs (threading and memory safety) in the vast majority of code you’ll write .
That, cargo and lack of historical baggage are the only real benefits of Rust compared to C++. The lack of ergonomics, slow compile times and to some extent the aggressive community make it far from a clear choice.
I have written and worked with a sizable C++ code base multiple times in my past career and I can't really agree.
> Rust doesn’t have the backwards compat baggage that C++ has, so it’s simpler.
C++'s "compat baggage" is mostly self-imposed, because it didn't have any working isolation system (including module systems) for a very long time, and the current C++ module system is still not fully isolating.
> [T]hey think that getting errors at compile time offsets all the mental overhead of those constructs.
This complaint might be true for some (but not all) people, but even in that case Rust will give a full memory safety (with some specific but reasonable definition). You can always use other languages if you don't find the memory safety that important---after all, there are many other axes of safety to consider and balance. But if you do need the memory safety for many good reasons, Rust is definitely a better language than C++ to achieve that.
Also C++ might be forgiving, but it takes much time to learn C++ to avoid many pitfalls and yet I regularly got tripped up by things that I do know but didn't have in mind at the time. I hate the "modern C++" argument; such argument is only reasonable when you are forbidden to write any legacy code without explicitly overloading. (Again, C++ has no real isolation to allow such mode switching.)
To be fair RPIT is part of a family, but they're actually just a weird way to name a variety of features that it made sense to give similar syntax in Rust. "IT" in RPIT means "impl Trait" the syntax, but what that syntax does varies by position (the P).
Return Position Impl Trait is Existential Types, but Argument Position Impl Trait is just a simpler syntax for some Generics, same syntax, different meaning. This is actually one of the places where Rust is probably easier to pick up in use than to understand in theory. APIT and RPIT both "feel" right, but in type theory these are radically different features.
In that way it's like some natural languages, native English speakers don't notice a bunch of the grammar rules they learned as kids, those rules just "feel" right and not formally taught.
> Only because this stuff all evolved from C code. Smart pointers would certainly work.
> [In a following reply:] Actually, TBH it's because I'm not real great with C++. It's a difficult language, and after 2016 I stopped even trying to improve my C++ skills. Instead, I've been focusing on Rust. Even when I wrote these tests in 2019, I strongly considered using Rust instead of C++. In the end, the only thing that forced me to use C++ is because I wanted them to live in the base system, rather than in ports.
So he surely knows about smart pointers but intentionally didn't use them.
But let’s be real. Language preference is a real thing. Some developers don’t want to learn C++ properly and would rather use their own favourite language when developing. Likewise, some people don’t want to learn rust and would rather stick to C++ or Go or whatever.
Of course some devs prefer C++ and some prefer rust. How is that surprising?
For a community systems project like FreeBSD, rust would be a great option for developers who prefer it. But it would fragment the ecosystem more for everyone else. Whether or not that’s worth it for the project is always going to be a hard choice.
Yeah, that's why I can't really blame phk for objecting against Rust per se. But FreeBSD apparently had Perl in the base system for a long time, so presumably there always were needs for more (or different) languages to serve different needs. This time FreeBSD would also care about its dependence on broader ecosystems that wouldn't be usable within the base system though.
Freebsd got rid of perl because the cost was more than the gain. Sure you can write some things in perl better than sh, but now everyone needs to know both because somethings can't be perl.
Of course, but it does show that Perl did have enough value to be included---only for a while though. An alternative with a similar gain but lower cost could have been explored.
The argument against Perl is probably the most compelling of the arguments against Rust.
In practice Perl programmers wanted various extra components. They didn't want to use out-of-the-box Perl, they wanted this popular CPAN library, and that one, and actually, also this other one. FreeBSD found that often "We have Perl" wasn't enough and yet "Lets add six more Perl libraries" is a tall order for them.
Unlike the Linux kernel programmers, FreeBSD's programmers are mostly writing userspace code, there is after all a lot more userspace. But in userspace, Rust programmers will reach for popular crates. Clap for example, to consistently parse arguments, or Regex to have excellent regular expressions. And so we're back to the same problem as Perl.
Like I said, this is the most compelling argument against Rust in base FreeBSD. However, it does make me wonder what the situation is for the C++ in Base today. Are FreeBSD base programmers part of the (large) C++ contigent who want to land everything in the stdlib because that way they can smuggle in larger dependencies ie it's just the same as allowing an extra dozen popular Rust crates or Perl libraries, but without any FreeBSD process ?
C++ appears likely to get the entire BLAS, a graph library, another whole suite of container types, several distinct lockfree reclamation mechanisms (including RCU and Hazard Pointers), a full blown Dimensioned Units type system and more, are these all vocabulary? Maybe such an argument can be made for the BLAS, and mp-units, but I'm sceptical. RCU is not vocabulary, neither in practice is this graph library. These will not enable practical interoperability.
Indeed, the bar is understandably high but C++ being above the bar is questionable. Maybe the reasoning was backward: any mainstream C compiler needs C++ so C++ had to be in the base system.
We need a better answer for this. Application programmers don't want to be stuck in the dark ages where packages in Cargo / pip / etc aren't available - or where all the packages you depend on have to be copied by hand into the system package managers (pkg/apt/rpm/etc).
C and C++ deal with this by having dependency management be utterly horrible for application developers. You have to either vendor dependencies, or figure out how to find compatible versions of the packages you depend on on every system you want to support. (Ok, there's libsdl on ubuntu. On debian - oh, its a super old version. On redhat its split into multiple rpms. On macos? On freebsd? On windows? What about arch? Nix? Ok, next up - libpng. Oh no...)
Of course perl devs want to use packages in CPAN. And of course rust devs want to use packages from Cargo. They're really good! And there's hundreds of tiny libraries which are way better than anything I'd write myself - from SIMD accelerated UTF8 validation, to serialization, arg parsing, network libraries, FFI for other languages, and so on. This stuff shouldn't be manually, partially mirrored in freebsd ports, apt and all the other places. Thats a ridiculous solution to a very real problem.
> Some developers don’t want to learn C++ properly
I do get your point but now you are kind of losing nuance. As engineers we also have to be able to answer the questions: "Is it really worth continuing to sink time and energy into technology X? Would it really give me increased productivity? Would it reduce runtime bugs? Would the return of investment be a favorable coefficient?"
So yes, people actually stop and think about these things. What monsters indeed.
The fallacy of "you have to know it perfectly to reject it" is tiring. If you want a technology to keep being used then maybe make it worth people's time.
And I don't think language preference plays any measurable role in this; sure it exists but every serious engineer I've known just scoffs at syntax, myself included (whether I am a serious engineer or not, I make no claims). Syntax is something people constantly overplay as a factor and in reality I'd think at least 80% of all programmers get used to it in the first 2 - 8 weeks and then forget about it.
To sum up, "learning C++ properly" is not a worthy endeavor and has not been in a long time. Of course people who only know that will reach for any other venues to attack the "youngsters" or whatever other ad hominem they prefer this week. That's known and well-understood, and hence their stance is obviously biased and as such is not a good starting discussion point.
I agree re: syntax, but there’s sooo much more to be said about the differences between C++ and rust than syntax. There’s OO. The borrow checker vs smart pointers. Templates vs traits. Async. Philosophy around safety. And on and on.
> To sum up, "learning C++ properly" is not a worthy endeavor and has not been in a long time.
Even as someone who adores rust, this is where you lose me. The problem is that smart engineers disagree about whether rust and/or c++ is worth learning & using in 2024. I don’t think there’s any getting around that. You simply won’t convince a lot of C++ devs to like rust any more than you’ll convince many rust devs to learn & enjoy C++.
The remaining question is what do you want to do about that? Would rust be good for the FreeBSD kernel? Are there enough rust devs around in the FreeBSD community to justify making rust a first class citizen in the base system?
C++ is an enormous sprawling mess. Thousands of pages of English written over many decades by dozens of authors trying to describe an imaginary "standard" programming language. It seems unlikely that in the short to medium term it will stop getting worse. C++ 26 probably (depending on committee decisions over the next few months) adds compile time reflection to the language and also a contracts mechanism, both of which interact with numerous existing parts of the language and further increase its overall complexity. Nothing of comparable significance is to be removed.
The "experts" choose to specialise. They learn a lot about some key topic (e.g. the algorithms library), and a few things about related topics, and maybe they know which other experts to consult with when there's overlap, and that's it.
So it's not likely that "learning C++ properly" is even possible for humans today unless you choose to define "properly" not to include a comprehensive understanding of the language but only some loose standard like "Know enough C++ to read this particular codebase".
Let's take the thousands of pages of English claim. Only the latest C++23 standard barely pushes over 2000 pages. The core language is described in about 500 pages, while the rest is taken up by the specification of the library.
* First of all, having a specification and an ISO standard is good, because it doesn't allow powerful actors like e.g. Google to take the language in whichever direction they want and in a huge ecosystem of compilers, platforms, SoCs, etc gives one a certain amount of certainty on what to expect. But fine, let's talk again in 10 or 20 years and see how non-standardised Rust's doing.
* Second of all, no developer will ever learn the language from the standard document. This is something for compiler writers or developers that need to understand the standardese in very specific cases.
A regular developer will learn based on a series of books (such as Josuttis, Meyers and Stroustrup - personally I also like Bancila), then check their assumptions on cppreference!
What the experts do is irrelevant for the average developer, because the great majority of us aren't experts in a language, nor do we want to be. It's a tool, not a purpose in life.
* Thirdly, one doesn't have to learn the language comprehensively to be productive, indeed this is not how many developers learn, because they must often learn several languages and therefore satisfice. Yes, there's developers that prefer to go deep, like me, but based on what I read online and have seen in real life, that's the exception. And even I don't go as deep as learning the standard by heart, that's a waste of time when there's so much actually useful domain knowledge to acquire.
That being said, C++ is growing too much and too fast and is too complex. At some point I'd like to be "done" with learning the same language, but Rust and C++ are like a never-ending journey. That's why many developers wisely skip both and why I prefer to invest my time in Python and Go instead of CPP-but-with-memory-safety.
> The core language is described in about 500 pages, while the rest is taken up by the specification of the library.
For C that's a useful distinction because you actually can use the C language. The "freestanding" C's standard library is literally a bunch of type definitions and constants so you really do only get the language itself.
But in C++ like Rust the language doesn't work on its own, we must have an extensive library, parts of the one defined in the rest of the ISO document. So we can't just throw away the rest of the ISO document, we can argue about how much is still needed - probably the BLAS won't end up landing in freestanding for example, but lots of the stdlib is in fact part of the language wherever it's used.
Worse, we're not even talking about a freestanding environment, FreeBSD base is userspace, this software has an Operating system (FreeBSD) and so the entire library is available, the grotty filesystem APIs, the regular expressions (FreeBSD core no longer has Perl, so, I guess it might be useful?) and whatever else is now "thrown in" with C++ on those other pages.
> First of all, having a specification and an ISO standard is good
No, it's expensive and it was good for Bjarne's ego but functionally it delivers negative value. We actually have practical examples where WG21 wrote a new document saying "C++ shall have feature X" and then the three compiler vendors who actually matter said "No, I don't think so" and sure enough C++ does not have feature X. Does your C++ have a garbage collector? No? But WG21 standardized garbage collection, so why not? Because no compiler implemented it.
> [...] But fine, let's talk again in 10 or 20 years and see how non-standardised Rust's doing.
Rust is almost ten. Rust 1.0 was over nine years ago. Time flies doesn't it? There's no value in a "standard" for Rust, and indeed C++ handily illustrates that. A specification is useful, and work towards that is ongoing.
> Thirdly, one doesn't have to learn the language comprehensively to be productive
But then what does "properly" even mean? The person that was told they ought to learn "properly" is in fact productive so...
> That's why many developers wisely skip both and why I prefer to invest my time in Python and Go instead of CPP-but-with-memory-safety.
Both Python and Go are growing languages. Because Python 3 was such a nightmare and yet they managed to "forget" lots of the fixes they'd intended, the Python developers just decided that it's OK to ship incompatible language changes in minor versions now, so, make sure you're running that Python 3.11 code on Python 3.11 and not Python 3.12 (too new) or Python 3.10 (too old) or else it might malfunction.
For a while Go had this idea of a "Go2" but then since Go was successful they decided they'll just fold new features into Go, you can expect that to continue, albeit more steadily than the breakneck pace of C++.
You can have GC in C++, completely pauseless GC (https://github.com/pebal/sgcl). The only one in the world, even Java doesn't have anything like it. The GC support in the C++ standard was useless, so it was removed.
It's true, Java presumably doesn't want your weird custom thing, they already have several garbage collectors.
And yes, writing a standard which specifies things nobody does is indeed useless and that's why it was removed, but that was my entire point. The ISO document is just dress up, what actually matters is the implementations.
Java will never have a completely pauseless GC. Because Java generates a lot of garbage and because Java's GC moves objects. It's funny that you think the best solutions have already been invented.
C++ does work on its own and there are projects which don't or can't use the STL. That can still be very useful in specific contexts.
Rust also works on its own as far as I'm aware (no_std), but I haven't used that.
Furthermore, it makes a major difference whether the language is covered in 500 or 2000 pages, because the former is much easier to search through and understand. Not to mention that it's very rare for the average developer to even read the whole thing, as I mentioned. The realistic use case is to look into a few paragraphs of a specific chapter of the standard.
The fact that the standard library is available or not in FreeBSD is not that relevant, because specific libraries can be trivially excluded by agreement, in code review, automatically in CI, etc.
In conclusion, your claim about the standard was a theoretical exaggeration, which is based on my experience not an issue for C++ developers in practice. If you've had a different experience, please provide concrete examples.
The GC is by the way not a good example: it's irrelevant for practicing C++ developers and just a historical curiosity and little gotcha to be included in online discussions.
By and large, the ISO standard enabled C++ to survive for many decades. It's not clear that Rust will survive that long. Rust may be 10, but it's only seen (relatively) significant public use in the past one or two years. The real challenge is changing and evolving the language while it's in wide use, not while it's used by a small group of enthusiasts. So do let's talk again in 10-20 years ;-)
Properly to put it very simply means that the programmer is able to write in a reasonable amount of time correct, idiomatic, maintainable code which satisfies its given requirements. If the community in fact agrees that smart pointers are the favoured approach, then not using them because one stopped learning C++ is non-idiomatic and barring exceptional circumstances not "proper".
And actually this is one of my issues with Rust: idiomatic code is reference-heavy, meaning lifetime-heavy and it seems async is or is about to be idiomatic. The language is non-ergonomic.
The same kind of language astronauts that are running the Rust show are present also in C++, conjuring template contraptions, but they can be mostly ignored and one can write simpler code.
It is, much the same as most people don't all learn the same way. Even more, most language wars are people arguing their preferences, not objective pros and cons. Rust is different though, as it has real, objective advantages that merit consideration IMO.
- It has multiple working compiler implementations
- It has a mountain of existing working software & libraries that may never be ported to rust, like most AAA video games, Chrome, Firefox, Windows, CUDA, etc.
- C++ has better interop with pure C code.
- C++ usually produces smaller binaries than rust.
- Complex data structures (like b-trees) are easier to write in C++. (Rust supports pointers in unsafe blocks - but the syntax around pointers is, for some reason, horrible.)
I adore rust, and I'd pick it over C++ every day of the week. But C++ is a powerful, fast, mature programming language with a rich ecosystem of compilers and tools. Rust is not a drop-in replacement for C++ in every case.
These advantages are not really advantages in the same way the advantages Rust offers are advantages.
In fact, most of the advantages you've listed here could apply to numerous languages not especially suited to modern development. As in, they're not real advantages and pale in comparison.
Pushing Rust while slamming C++ is by far not an innocent, purely technical discussion.
There’s a significant degree of ideology and grassroots activism behind this, which deserves to be criticized.
The person which posted the Rust-positive quote is usually very supportive of Rust and chose the one quote which puts C++ in a bad light, yet conveniently forgot to include the numerous criticisms of Rust from BSD developers and the fact that one of the main devs prefers C++ for example.
Anyone who can't tell the difference between C vs C++ and so put then in a single 'and' as if there is no differece is slamming C++. How does modern C++ compare to old code? is the issue only where we must interoperate?
I have seen too many people talk about C and C++ in what quickly becomes clear is a case of they cannot tell the difference. As such I just assume the non-charitable interpretation - I think it is reasonable to assume anybody who knows modern C++ will want to carefully discuss it separate from C.
Sure, I can accept that happens. Having in mind that C++ has a metric ton of footguns as well as C, I am not sure the difference is very meaningful in practical terms. After all, "if you know what you are doing there will not be memory safety bugs" is said by the C proponents as well.
I like the point made by some other comment in this thread: The "modern C++" argument is tiring.
It only truly works if C++ has a hard mode-switch between modern and legacy C++, which it doesn't have. Things like smart pointers reduce memory bugs, true, but Absolutely Nothing in modern C++ disallow you to mix in raw pointers too. At best you have conventions requiring people to utilize the modern features, but that is asking the humans writing the code to be disciplined, and you know very well we are not. Mistakes happen.
If modern C++ has a `legacy` block that works in a similar vein as Rust's `unsafe` then perhaps your position would have been much stronger. Alas, it'd be very weak still because modern C++ continues to carry the baggages of legacy C++.
I'd like to chip in with another perspective here. I don't think we can. The reason people use terms like Rust activist is because some of the user community is quite frankly unhinged. On numerous occasions across various sites, a helpful Rust user will pop up with an out of context and unwanted discussion fork into rewriting everything in Rust or misapplying it to a problem which is unrelated. When reminded thanks but no thanks this is usually responded to with either "you're one of the ones that doesn't get it" or something much more vicious. I had one on here yesterday. I had on in person at work last week.
This is a real problem because any zealot of this level serves only to discredit the product by association.
I have no opinion on Rust other than I don't have the time to learn it at the moment and it doesn't look like it solves any problems in the domain of things I care about at the moment. I have no opinion past that. I am interested in technical discussion on it in case it overlaps a problem domain I am interested in, which is why I am on this thread :)
Some people are unhinged... it doesn't matter what's the topic. Look around the world, there is a lot of stuff you don't agree with probably.
Some people don't see the Cons, they don't want to see the Cons... be happy for them to be so enthusiastic about a topic they love and ignore the rest of what they say ;)
> The reason people use terms like Rust activist is because some of the user community is quite frankly unhinged.
Every community has them. Every single one. Find me a group of a super niche hobby, say 20 people in total. I can bet my neck I'll still find at least one of them in there who is a zealot. Not sure why people focus on the 0.01% of the Rust users who are fanatics. No they are not on important positions at all, they are some frustrated people who scream on Reddit and sometimes on HN, that's it.
> This is a real problem because any zealot of this level serves only to discredit the product by association.
No it does not. How did you even do this logical leap? Let me give you an example of what you did just say:
At some point somebody somewhere used their laptop to physically assault someone and caused them a head trauma. So surely, laptops are now discredited and you should never use one, correct?
Now replace "laptop" with literally anything else you have ever used.
> I am interested in technical discussion on it in case it overlaps a problem domain I am interested in, which is why I am on this thread :)
99.9% of the discussions where Rust is involved are technical. You should consider how you are picking your discussion threads if that percentage is much lower for you. I have not stumbled upon a Rust zealot on HN in at least 6 months. Last one I saw on Reddit was 3-4 months ago (though admittedly I gave up on Reddit's technical forums because they seem full of very emotional people).
> Every community has them. Every single one. Find me a group of a super niche hobby, say 20 people in total. I can bet my neck I'll still find at least one of them in there who is a zealot.
Out of all the tech communities I've observed or been a part of, I think Linux in general might be the worst for having zealots.
> Even if that is factually correct -- a generous assumption
I don't think it's a generous so much as reasonable assumption given the size and impact of the Linux project, and that there were much more anti-ms people in the late 90s and 2000s.
> so what?
I gave my perspective in a context where it seemed relevant. Why so adversarial?
My apologies if I came across adversarial. I just realized that I shortened "what's the relevance to the argument at hand?" to "so what?" as I was in a rush. Sorry again.
The relevance to the argument at hand, I think, I was just stating an anecdote to show a scale of sorts. I think talking about the level of zealotry is relevant and kind of interesting.
I don't disagree, it's an interesting topic to try and understand what makes people so radical and why are they so adamant in being such.
At the same time, it's very disheartening for me how so many people wouldn't use something just because there are zealots who can't shut up about it. :(
The problem with loud zealotry in a group is that anybody who brushes against it that might be interested sees the zealotry and realizes they'll have to associate with the zealots.
Do you really have to associate with the zealots though? I for one have been an Elixir and Rust advocate for a while but always made it 100% clear, in every discussion, that there are right tools for the job and that sometimes you just need to whip out a quick Python script and be done with the task at hand, for example.
This has mostly worked well for me, and paradoxically only HN is the place where even trying to defend Rust on its actual technical (as in: objective) merits still gets you labeled as a "Rust loonie" or "a zealot" or "Rust evangelist strike force". Even Reddit, that I view as an absolute cesspool, and had accounts banned for asking a question clearly adhering to the template given in the subreddit, has more nuanced discussions on Rust.
I find that quite fascinating, and even though my HN account is fairly non-recent, I still don't associate with the apparently very bone-headed people who jump like hit by a power line when Rust is mentioned.
> The exact advocates you'd trust in this case are C++ experts who've, through experience, found a better solution.
Did they really? Just hand-waving and saying "use smart pointers" obviously did not work for many other people.
> A person who doesn't know the core language, saying that another is better anyways, is obviously a flawed statement to begin with.
How did you go from "he's not perfect in his C++ skills" to "a person who does not know the core language"? That's quite the leap and is not arguing in good faith.
> Not sure why this was downvoted.
Because it keeps repeating a very tiring falsehood: that there are "Rust activists".
People constantly conflate a push to use something that objectively reduces several classes of bugs -- backed by researches from Microsoft and Google, and others -- with "they are activists pushing for their favorite tech".
Losing those nuances is what makes discussion practically impossible. Just dehumanizing (or de-something-else) your discussion opponents is not a way to go yet the people who insist C++ is the best thing ever invented do it all the time, while playing the victim. As a person who had to moderate forums and chats and real-life meetings, I am not impressed by their discourse, yours and your parent commenter's included.
I remember your nickname from some quite biased past comments on this Rust topic. Even in your recent history one can find downvoted sarcastic comments about Rust vs. C++ and now you want to be objective and want to discuss nuance.
Ok, let's be objective then:
* a C++ programmer that is not comfortable with smart pointers in 2019 is incompetent and wouldn't pass any C++ interview in 2014, never mind five years later.
* we're not talking about researches from Google or Microsoft, but about bluejekyll which chose a biased quote to make C++ look bad and Rust good, when in the article it was very clear that the core FreeBSD maintainers prefer C++ and do not want Rust in their codebase.
There is no nuance to the above, it's a repeated pattern from several HN users which I and others have identified as activism. This is not dehumanising (seriously?) and I've kept things polite.
> we're not talking about researches from Google or Microsoft
It's an important part of the picture. If the big boys are telling you it's not all hype and there's merit that can help OSS projects, kernels and drivers included, it could and should be used to reduce tension because shouting at people "You'll never force us to use Rust!" is not a mature thing to do (and it's present in a clip somebody linked in this thread).
If we can just discuss on merits, things will improve hugely. As it is though, people are being people and prefer to attack others based on emotions, yourself included, as illustrated here:
> I remember your nickname from some quite biased past comments on this Rust topic. Even in your recent history one can find downvoted sarcastic comments about Rust vs. C++ and now you want to be objective and want to discuss nuance.
This was one recent comment. One. You, my friend, are cherry-picking in an attempt to discredit me. Go and count my downvoted comments, I'll wait. We both know what you'll come back with.
I always wanted to discuss objectively and with nuance. Does not stop me being sarcastic sometimes, sue me. :)
I am surely showing more willingness to discuss than you however. Good enough for me.
The point was also probably that there is already a C++ compiler in the base, vs adding new headaches for adding and maintaining a rust toolchain in the base.
But that's an interesting point. Why is there a C++ compiler in the base? Do I find a long discussion on the FreeBSD list about whether it should have a C++ compiler? If not, why not?
Because the System has to be self-hosting, remember it's a whole OS and not just the Kernel, and as you can see ~25% of src is C++, 62% C etc.
Rewrite everything C++ is not a small undertaking with (maybe?) not allot plus-sides, and even then you still need C++ because of LLVM. LLVM and GCC are both C++, and you have to compile the Compiler (self-hosting), and even if your a 100% Rust or C OS, you still need C++ because of LLVM/GCC....well if you want a modern compiler ;)
But when you look what all that C++ is doing in Base, it seems like it's basically LLVM and then a lot of code that's just there to help you write more C++ code. Not a whole lot of the FreeBSD Base userspace, the uilities and so on - is actually written in C++ despite that. It's getting a free ride because the compiler uses it.
Because most C compilers also include a C++ compiler, or that the compiler toolchain of choice for freeBSD happens to be LLVM (it was an old version of GCC before because newer version use an incompatible license, and before that I think gcc replaced pcc in the original bsd unix, the discussion to pcc with gcc is probably lost in time) that includes C and C++ compiler.
I am guessing that performance of current standalone C compiler is not as good as the one produced by compiler suit.
Following the conversation thread, rust also use llvm under the hood, but a customized one. Which would force the base system to have two versions of llvm.
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.
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.
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.
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).
I don’t think the relative % of rust has changed a lot in the past few years though, has it? After they got the obvious low lying fruit it slowed down dramatically didn’t it?
It's a good question but I have no plans to write a script that walks mercurial history and plots the relative percentages of the code based on language.
If you find the time and urge I'd be interested to know the results.
I don't see why this is a reason to be skeptical. Firefox is a huge codebase. Substantial chunks of it have been rewritten using Rust while maintaining the entire app and adding features. This is entirely the plan: You can slowly, as you touch parts, migrate the codebase.
Firefox (and many other projects) was already a mix of multiple languages - it uses C, C++, Javascript, ... and now Rust. And while there is value in having less languages to deal with, there is equally value to use multiple languages and apply them where you see major benefit. For example, replacing exposed and high-risk components (image/file parsers for example) with a language that de-risks those implementations. Like all of the things in software engineering, this is a tradeoff. It may not make sense for your application, but it can make sense for others.
I think your use of "force-jam" suggests a bias you may have.
Making existing, well-used OS kernels safer is probably a lot easier than writing a new kernel from scratch, porting drivers, marketing it, and gaining a larger user base.
Not saying that's not a worthwhile endeavor, but it's up to everyone to decide what they want to do.
Ultimately the maintainers of a non-Rust project will decide if they want Rust in there. No amount of "force-jamming" is going to make it happen without their considered consent.
This wasn't a request to rewrite anything in Rust. This was a request to have the facilities to build Rust in FreeBSD base (which includes userland and kernel code). Specifically the request was to write new code in Rust.
I find my use of force-jam was entirely appropriate, after careful consideration informed by the How rust proponents push rust into pre-existing projects.
As well as the drama they bring alongside them, and their propensity to resort to personal attacks.
> Why not go work on redox, or write something new?
Because the BSDs and Linux are actually used in hundreds of millions of systems and provide clear value to lots of people. Redox is cool, but it's in an entirely different league. It's not surprising that some people prefer to work on brand new stuff (like Redox), and some people prefer to work on improving old stuff that is actually in widespread use.
> 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.
I take it you prefer to always demolish your house and build a new one whenever any renovation, nomatter how small, involves a significant change in materials or methods or technology?
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.
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!
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++.
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 -- and to reiterate, no one is trying force
anyone else to learn Rust nor prevent refactorings of C code.
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.
I find that the Rust Kernel maintainer in that video was the only one that stayed professional during the "attacks" (it was ad hominem at some point). You could really hear how people got agitated and emotional while saying things like:
I am not a kernel developer and I do find the discussion somewhat frustrating and I largely agree with your analysis.
However, I do think that the "other side" also raises a valid point in that they can not reasonably be expected to maintain the semantics on the C side so that the Rust bindings (which does make assumptions in order to create clean and powerful bindings to use the Rust type system) do not break. Pre-Rust, the onus is indeed on them to ensure that the entire codebase conforms with any semantic changes, but now, if we say get a new filesystem entirely written in Rust that relies on the bindings, who is responsible and how will the coordination happen?
Again, I am not a kernel developer and only a mediocre (at best) systems programmer. Thus, I could have misunderstood the discussion.
That's all fine, I am just talking about the emotional part of the debate and the ad hominems.
They are uncalled and should not be tolerated.
We had a colleague in my last job that was good technician but nobody wanted to talk to him or ask for help or anything because frankly, he was an asshole.
I listened to 3 min of it. And I don't see any emotional part of it.
They simply have a fundamental difference of opinion. And I actually understand the C person is suggesting. Although may be he wasn't clear in explaining it. It is not the responsibility of C maintainer to spend additional time to explain their code. Especially in a way that Rust people understands. And may be in order for them to do that, without all the Rust context, they might as well learn Rust. And if Rust blinding is even set as a priority then all C maintainers would now have obligations, one way or another to work well with rust. Which neither does the C maintainers want to spend time on or have the interest to spend time on.
The Rust people on the other hand saw their move as common good and want everyone to work together. Unfortunately most developers would only discover very late in their carrier, you can only make that happen when everyone 's interest are aligned.
My understanding is that no one's asking them to take on that burden. What seems to be being asked is for them to explain the current semantics of the API, because it's unclear what they actually are.
From the sounds of it, some of them consider this request unreasonable.
Turns out, people who want to improve an OS on the technical merits have no patience to get constantly attacked on every other platform and don't want to do any non-technical discussions.
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.
To add: The only people I know who think C++ is easy to write "good" code for, and who think that you can "just" be careful and skilled, have NEVER written multithreaded server code in C++.
Hit a multithreaded C++ server with 20k users a day alone and you would not believe the edge cases and weird states they will generate for you.
I am glad that you have changed your mind. Not because I am a Rust advocate (haven't worked with the language in at least a year now, what advocate would that make me?) but because this:
> I was extremely skeptical of Rust, due to the hype and some very obnoxious Rust proponents.
...is obviously a very biased way of gauging anything. As mentioned upthread in another comment of mine, every single community has the minority of loud bad apples and it's not fair to judge Rust because its community is literally like any other on this planet.
You did the right thing, you ignored the emotional responses and went to check for yourself, factually and objectively. I'd be honored to call you my colleague.
It wasn't easy, and I was quite toxic towards Rust posts before that - simply because everything at the time was saturated with Rust news, and a lot of very silly "rewrite it in Rust" posts. There are only three things that annoyed me this much in the last 10 years: Crypto (which was largely a hype-bubble), Rust (which turned out to be very cool), and AI (we'll see where that goes).
> You did the right thing, you ignored the emotional responses and went to check for yourself, factually and objectively.
I'm currently talking to lots of other C and C++ developers I know, and trying to convince them to give it an honest shot. The first thing I say is pretty much "Hey, I know this thing is overhyped and you're probably fed up, I thought so, too, but ...", and then follow that up with tagged unions, pattern matching and showing the toolchain. That sells most of them on it. Error handling also is a huge plus if they're also big error-handling nerds.
Also note how I never mention memory safety -- the reality is barely anyone gets really excited about that. We'd all use @safe Dlang[0] if it was that exciting to us all.
> Also note how I never mention memory safety -- the reality is barely anyone gets really excited about that. We'd all use @safe Dlang[0] if it was that exciting to us all.
That's a different approach, thanks for describing it. I've tried it as well but apparently I spoke with some very bone-headed people because they hand-waved it away immediately with "meh, C unions are fine, you're a noob if you need Rust to hold your hand". :(
I'll remember to bring those up next time, because I found myself caring about exhaustive pattern matching / enums more lately, compared to memory safety (which I do care about a lot still).
C unions dont work in C++ in most cases, because you can only have trivially constructible members in a union. So literally everything except primitives is out. "std::variant and the 12 ways to implement the visitor pattern" sounds like a book title, but is actually just the reality of writing C++
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.
> 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)
> 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.
> Again, if you can TL;DR it meaningfully people could be interested, otherwise it looks like plain old gatekeeping.
I did, you keep missing the point.
True gatekeeping is preventing people from exploring ideas by saying people should not fork. Quite literally, you’re the one pushing for the gate to be kept closed.
I can’t help you with text comprehension, I’m sorry. Since you keep missing the point I won’t be replying any further, it’s wasted time.
You explained exactly nothing. You only said "do your homework" as if I am supposed to extract your exact meaning from a likely series of blog posts and videos.
I get that you want to emerge the "winner" here but it's not going to work, HN readers are fairly well-educated. I asked for a summary, you refused it by also reaching for an ad hominem.
To be frank again, there wasn't really bad faith and hostility in the way you mean. You were snarky to them, and they escalated by insulting you. That doesn't really excuse anyone from anything; you both made your choices, and neither of you chose to descalate or to walk away. (To be clear, I have already read what happened, and I cannot be convinced otherwise. Any more than I can be convinced the sky is green. I'm just letting you know, because you invited the audience to pass judgment. If you feel compelled to justify yourself, just know that it's falling on deaf ears.)
I'm not trying to convince you of anything. I have indeed invited any future reader to draw their own conclusions and they're 100% free to do so. It was not implying that I'm sure my point of view is the only valid one -- more like that people of certain character type would align with me, and others with the other poster. That was all there was to it and it was my way to disengage.
Can you point out what did you perceive as snark, btw?
Forking (as opposed to branching which at least has community acknowledgement) should be taken as a last resort.
Without the support from upstream, just _syncing_ your fork with upstream can be a massive pain, as your changes conflicts with the new upstream changes. It's even more debilitating when you realize your efforts may not even be rewarded -- the upstream can simply decide to refuse to merge your fork.
> Without the support from upstream, just _syncing_ your fork with upstream can be a massive pain, as your changes conflicts with the new upstream changes.
This happens if you don't fork often, post your changes once in a very long time, and don't rebase your work very often.
If you rebase often enough you shouldn't have the mergeability problem.
> It's even more debilitating when you realize your efforts may not even be rewarded -- the upstream can simply decide to refuse to merge your fork.
The alternative is letting people greenlight you to even go and do a proof of concept. It smells like bureaucracy to me.
Having a fork and a working proof of concept can back your argument about feature development. The implementation is just a detail and can be adjusted or reworked as necessary.
Otherwise you risk your ideas getting stalled (or worse, completely rejected) by people that don't even fully understand what you're talking about.
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...
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.
> 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.
Is there reason to believe that language package managers are universally destined to decline in quality rather than, for instance, that we've made progress one bad package manager at a time?
I also don't see reason to declare npm to be a failure, and frankly pip was never good. Cargo is excellent. I don't see why it would decline.
I don't really understand what you're getting at. No language should provide a package manager? All languages should use the same package manager? That seems unnecessarily constrained and coupled.
This is all so vague, and that confuses me. Language package managers are "destined to decline in quality" for unstated reasons. Language package managers are "don't work well" because there are multiple languages (and I presume you also mean multiple operating systems/distributions). That argument would seem to apply equally well to any package manager (including those maintained by OSs), so why are we singling any of them out?
(Cargo does have a build script mechanism, with a major use case being integrating with other languages at compile time. Eg, running `make`. The other package managers I'm familiar with have similar mechanisms. I would assume they all do, since it's a problem they all have.)
I do not know of a solution. I'm pointing out a problem.
> Cargo does have a build script mechanism, with a major use case being integrating with other languages at compile time
I already use cmake and my own custom build environment manager. While there are warts it is setup and works well enough that I don't want to switch. But rust wants me to forget about all that and use cargo. While in theory I can use something else, they don't bother documenting those workflows (I'm not convinced they will keep them working if I do get it working)
I can sympathize with that, I'm very particular about some elements of my workflow. But when you decide to go homegrown rather than turnkey, you do accept responsibility for maintenance. It also seems to me that you can call Cargo from cmake if you so desire.
I would be very surprised if changing the arguments to rustc (or the equivalent in any language) wasn't considered a breaking change, so I'm not sure how well founded your skepticism is. If it's poorly documented, that is a shame.
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.
> 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.
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.
150 comments
[ 648 ms ] story [ 3711 ms ] threadC++ 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.
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
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)
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.
Doubt: 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.
These words are doing a lot of work.
(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.)
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.
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.
However, I can today easily write clean C++ that’s easy to understand, and using containers, algos and smart pointers is also robust. This is what the C++ community has settled on, while pushing complexity into libraries.
The Rust community has settled on async, moves and references (with the lovely lifetime annotations) and other cognitive overhead, because they think that getting errors at compile time offsets all the mental overhead of those constructs. Then they gaslight all the beginners which complain about that mental overhead.
So in theory Rust may be simpler, but idiomatic Rust isn’t. It’s differently complex.
This is orders of magnitude simpler than c++ overloading of copy/move assignment and constructors, even when you follow the rule of 0 (not least of which is that you don’t to teach people about it or how to keep code exception safe).
It’s kind of amusing to claim that c++ is simpler than Rust when it’s demonstrably not true - a new person to Rust is more productive after 6 months than a person new to c++. That implies the bar to getting proficient is low. A person can reach intermediate more quickly implying the bar to the next levels is lower. And it’s easier to maintain a rust project due to cargo meaning a usable easy build system out of the box that the entire community uses vs opinionated choices each project has to do, and macros that are easier to manage than preprocesser mess. So easier to maintain and easier to jump into any project. Oh and tests and mictobenchmarks out of the box and a very rich ecosystem of supporting libraries.
Idiomatic rust is simpler than idiomatic c++ and it’s clearer what constitutes idiomatic rust whereas c++ in practice is rarely idiomatic and there are going to be conflicting ideas on what is idiomatic.
This is ignoring the very real benefits of rarely to never dealing with a whole class of difficult to debug bugs (threading and memory safety) in the vast majority of code you’ll write .
Is this true? I ask because I've seen it mentioned that a C++ co_await suspends that call frame alone (thus the call returns to the caller and resumes immediately), where as Rust's .await suspends the entire call stack (all frames up to and including the caller). If true, in what sense are these mechanisms same?
> The Rust community has settled on async, moves and references (with the lovely lifetime annotations) and other cognitive overhead
The rust community has settled on async in the same way that the C++ has - it's an optional keyword that is some syntactic sugar over compiler-generated stuff. The main unique "cognitive overhead" is that Rust forces you to write down lifetimes when they can't be inferred, but the rest is the same or worse in C++.
As for the async mechanism, I don't believe there's magic in Rust that suspends the entire call stack. It walks up the stack the same as in C++. If you don't await an async function call or one returning a future, then there's no suspension and the inner function is executed until the first suspension point if I recall correctly same as in C++. There's nuances in differences but at a high level they're very similar in that it's generating a state machine and nothing more; Rust does require a runtime whereas C++ can do without since the Rust picked generic futures that work on all runtimes whereas in C++ you have to have the runtime provide the future implementation (or have the future not be part of any runtime).
References are not at all simpler, they're memory-safe, which in conjunction with lifetimes makes them significantly more complex to understand and write. This is a known problem... In C++ I copy by default and move if I want to optimise. Moves also happen behind the scenes as an optimisation, this is how things should be, don't push the work on the programmer!
I don't agree with your claim that a new person to Rust is more productive. What's that based on? In my experience, a new person to Rust will write memory-safe code by default, which is good, but they pay the cost of Rust's lack of ergonomics forever. See https://news.ycombinator.com/item?id=40172033 which covers async, refactoring and design issues that plague even experienced programmers.
> Idiomatic rust is simpler than idiomatic c++ and it’s clearer what constitutes idiomatic rust whereas c++ in practice is rarely idiomatic and there are going to be conflicting ideas on what is idiomatic.
It's really not, because C++ copies by default which is typically both memory-safe and very easy. If using smart pointers and clone was idiomatic in Rust, you'd have a point, instead references and lifetimes are idiomatic.
Modern C++ has a pretty clear definition, albeit it's evolving as new things are added to the standard. C++ is moving too fast recently, but then again so is Rust.
> This is ignoring the very real benefits of rarely to never dealing with a whole class of difficult to debug bugs (threading and memory safety) in the vast majority of code you’ll write .
That, cargo and lack of historical baggage are the only real benefits of Rust compared to C++. The lack of ergonomics, slow compile times and to some extent the aggressive community make it far from a clear choice.
> Rust doesn’t have the backwards compat baggage that C++ has, so it’s simpler.
C++'s "compat baggage" is mostly self-imposed, because it didn't have any working isolation system (including module systems) for a very long time, and the current C++ module system is still not fully isolating.
> [T]hey think that getting errors at compile time offsets all the mental overhead of those constructs.
This complaint might be true for some (but not all) people, but even in that case Rust will give a full memory safety (with some specific but reasonable definition). You can always use other languages if you don't find the memory safety that important---after all, there are many other axes of safety to consider and balance. But if you do need the memory safety for many good reasons, Rust is definitely a better language than C++ to achieve that.
Also C++ might be forgiving, but it takes much time to learn C++ to avoid many pitfalls and yet I regularly got tripped up by things that I do know but didn't have in mind at the time. I hate the "modern C++" argument; such argument is only reasonable when you are forbidden to write any legacy code without explicitly overloading. (Again, C++ has no real isolation to allow such mode switching.)
https://www.youtube.com/watch?v=CWiz_RtA1Hw
Return Position Impl Trait is Existential Types, but Argument Position Impl Trait is just a simpler syntax for some Generics, same syntax, different meaning. This is actually one of the places where Rust is probably easier to pick up in use than to understand in theory. APIT and RPIT both "feel" right, but in type theory these are radically different features.
In that way it's like some natural languages, native English speakers don't notice a bunch of the grammar rules they learned as kids, those rules just "feel" right and not formally taught.
> Only because this stuff all evolved from C code. Smart pointers would certainly work.
> [In a following reply:] Actually, TBH it's because I'm not real great with C++. It's a difficult language, and after 2016 I stopped even trying to improve my C++ skills. Instead, I've been focusing on Rust. Even when I wrote these tests in 2019, I strongly considered using Rust instead of C++. In the end, the only thing that forced me to use C++ is because I wanted them to live in the base system, rather than in ports.
So he surely knows about smart pointers but intentionally didn't use them.
[1] https://lists.freebsd.org/archives/dev-commits-src-main/2024...
But let’s be real. Language preference is a real thing. Some developers don’t want to learn C++ properly and would rather use their own favourite language when developing. Likewise, some people don’t want to learn rust and would rather stick to C++ or Go or whatever.
Of course some devs prefer C++ and some prefer rust. How is that surprising?
For a community systems project like FreeBSD, rust would be a great option for developers who prefer it. But it would fragment the ecosystem more for everyone else. Whether or not that’s worth it for the project is always going to be a hard choice.
In practice Perl programmers wanted various extra components. They didn't want to use out-of-the-box Perl, they wanted this popular CPAN library, and that one, and actually, also this other one. FreeBSD found that often "We have Perl" wasn't enough and yet "Lets add six more Perl libraries" is a tall order for them.
Unlike the Linux kernel programmers, FreeBSD's programmers are mostly writing userspace code, there is after all a lot more userspace. But in userspace, Rust programmers will reach for popular crates. Clap for example, to consistently parse arguments, or Regex to have excellent regular expressions. And so we're back to the same problem as Perl.
Like I said, this is the most compelling argument against Rust in base FreeBSD. However, it does make me wonder what the situation is for the C++ in Base today. Are FreeBSD base programmers part of the (large) C++ contigent who want to land everything in the stdlib because that way they can smuggle in larger dependencies ie it's just the same as allowing an extra dozen popular Rust crates or Perl libraries, but without any FreeBSD process ?
C++ appears likely to get the entire BLAS, a graph library, another whole suite of container types, several distinct lockfree reclamation mechanisms (including RCU and Hazard Pointers), a full blown Dimensioned Units type system and more, are these all vocabulary? Maybe such an argument can be made for the BLAS, and mp-units, but I'm sceptical. RCU is not vocabulary, neither in practice is this graph library. These will not enable practical interoperability.
C and C++ deal with this by having dependency management be utterly horrible for application developers. You have to either vendor dependencies, or figure out how to find compatible versions of the packages you depend on on every system you want to support. (Ok, there's libsdl on ubuntu. On debian - oh, its a super old version. On redhat its split into multiple rpms. On macos? On freebsd? On windows? What about arch? Nix? Ok, next up - libpng. Oh no...)
Of course perl devs want to use packages in CPAN. And of course rust devs want to use packages from Cargo. They're really good! And there's hundreds of tiny libraries which are way better than anything I'd write myself - from SIMD accelerated UTF8 validation, to serialization, arg parsing, network libraries, FFI for other languages, and so on. This stuff shouldn't be manually, partially mirrored in freebsd ports, apt and all the other places. Thats a ridiculous solution to a very real problem.
I do get your point but now you are kind of losing nuance. As engineers we also have to be able to answer the questions: "Is it really worth continuing to sink time and energy into technology X? Would it really give me increased productivity? Would it reduce runtime bugs? Would the return of investment be a favorable coefficient?"
So yes, people actually stop and think about these things. What monsters indeed.
The fallacy of "you have to know it perfectly to reject it" is tiring. If you want a technology to keep being used then maybe make it worth people's time.
And I don't think language preference plays any measurable role in this; sure it exists but every serious engineer I've known just scoffs at syntax, myself included (whether I am a serious engineer or not, I make no claims). Syntax is something people constantly overplay as a factor and in reality I'd think at least 80% of all programmers get used to it in the first 2 - 8 weeks and then forget about it.
To sum up, "learning C++ properly" is not a worthy endeavor and has not been in a long time. Of course people who only know that will reach for any other venues to attack the "youngsters" or whatever other ad hominem they prefer this week. That's known and well-understood, and hence their stance is obviously biased and as such is not a good starting discussion point.
> To sum up, "learning C++ properly" is not a worthy endeavor and has not been in a long time.
Even as someone who adores rust, this is where you lose me. The problem is that smart engineers disagree about whether rust and/or c++ is worth learning & using in 2024. I don’t think there’s any getting around that. You simply won’t convince a lot of C++ devs to like rust any more than you’ll convince many rust devs to learn & enjoy C++.
The remaining question is what do you want to do about that? Would rust be good for the FreeBSD kernel? Are there enough rust devs around in the FreeBSD community to justify making rust a first class citizen in the base system?
The "experts" choose to specialise. They learn a lot about some key topic (e.g. the algorithms library), and a few things about related topics, and maybe they know which other experts to consult with when there's overlap, and that's it.
So it's not likely that "learning C++ properly" is even possible for humans today unless you choose to define "properly" not to include a comprehensive understanding of the language but only some loose standard like "Know enough C++ to read this particular codebase".
* First of all, having a specification and an ISO standard is good, because it doesn't allow powerful actors like e.g. Google to take the language in whichever direction they want and in a huge ecosystem of compilers, platforms, SoCs, etc gives one a certain amount of certainty on what to expect. But fine, let's talk again in 10 or 20 years and see how non-standardised Rust's doing.
* Second of all, no developer will ever learn the language from the standard document. This is something for compiler writers or developers that need to understand the standardese in very specific cases. A regular developer will learn based on a series of books (such as Josuttis, Meyers and Stroustrup - personally I also like Bancila), then check their assumptions on cppreference! What the experts do is irrelevant for the average developer, because the great majority of us aren't experts in a language, nor do we want to be. It's a tool, not a purpose in life.
* Thirdly, one doesn't have to learn the language comprehensively to be productive, indeed this is not how many developers learn, because they must often learn several languages and therefore satisfice. Yes, there's developers that prefer to go deep, like me, but based on what I read online and have seen in real life, that's the exception. And even I don't go as deep as learning the standard by heart, that's a waste of time when there's so much actually useful domain knowledge to acquire.
That being said, C++ is growing too much and too fast and is too complex. At some point I'd like to be "done" with learning the same language, but Rust and C++ are like a never-ending journey. That's why many developers wisely skip both and why I prefer to invest my time in Python and Go instead of CPP-but-with-memory-safety.
For C that's a useful distinction because you actually can use the C language. The "freestanding" C's standard library is literally a bunch of type definitions and constants so you really do only get the language itself.
But in C++ like Rust the language doesn't work on its own, we must have an extensive library, parts of the one defined in the rest of the ISO document. So we can't just throw away the rest of the ISO document, we can argue about how much is still needed - probably the BLAS won't end up landing in freestanding for example, but lots of the stdlib is in fact part of the language wherever it's used.
Worse, we're not even talking about a freestanding environment, FreeBSD base is userspace, this software has an Operating system (FreeBSD) and so the entire library is available, the grotty filesystem APIs, the regular expressions (FreeBSD core no longer has Perl, so, I guess it might be useful?) and whatever else is now "thrown in" with C++ on those other pages.
> First of all, having a specification and an ISO standard is good
No, it's expensive and it was good for Bjarne's ego but functionally it delivers negative value. We actually have practical examples where WG21 wrote a new document saying "C++ shall have feature X" and then the three compiler vendors who actually matter said "No, I don't think so" and sure enough C++ does not have feature X. Does your C++ have a garbage collector? No? But WG21 standardized garbage collection, so why not? Because no compiler implemented it.
> [...] But fine, let's talk again in 10 or 20 years and see how non-standardised Rust's doing.
Rust is almost ten. Rust 1.0 was over nine years ago. Time flies doesn't it? There's no value in a "standard" for Rust, and indeed C++ handily illustrates that. A specification is useful, and work towards that is ongoing.
> Thirdly, one doesn't have to learn the language comprehensively to be productive
But then what does "properly" even mean? The person that was told they ought to learn "properly" is in fact productive so...
> That's why many developers wisely skip both and why I prefer to invest my time in Python and Go instead of CPP-but-with-memory-safety.
Both Python and Go are growing languages. Because Python 3 was such a nightmare and yet they managed to "forget" lots of the fixes they'd intended, the Python developers just decided that it's OK to ship incompatible language changes in minor versions now, so, make sure you're running that Python 3.11 code on Python 3.11 and not Python 3.12 (too new) or Python 3.10 (too old) or else it might malfunction.
For a while Go had this idea of a "Go2" but then since Go was successful they decided they'll just fold new features into Go, you can expect that to continue, albeit more steadily than the breakneck pace of C++.
You can have GC in C++, completely pauseless GC (https://github.com/pebal/sgcl). The only one in the world, even Java doesn't have anything like it. The GC support in the C++ standard was useless, so it was removed.
And yes, writing a standard which specifies things nobody does is indeed useless and that's why it was removed, but that was my entire point. The ISO document is just dress up, what actually matters is the implementations.
Furthermore, it makes a major difference whether the language is covered in 500 or 2000 pages, because the former is much easier to search through and understand. Not to mention that it's very rare for the average developer to even read the whole thing, as I mentioned. The realistic use case is to look into a few paragraphs of a specific chapter of the standard.
The fact that the standard library is available or not in FreeBSD is not that relevant, because specific libraries can be trivially excluded by agreement, in code review, automatically in CI, etc.
In conclusion, your claim about the standard was a theoretical exaggeration, which is based on my experience not an issue for C++ developers in practice. If you've had a different experience, please provide concrete examples. The GC is by the way not a good example: it's irrelevant for practicing C++ developers and just a historical curiosity and little gotcha to be included in online discussions.
By and large, the ISO standard enabled C++ to survive for many decades. It's not clear that Rust will survive that long. Rust may be 10, but it's only seen (relatively) significant public use in the past one or two years. The real challenge is changing and evolving the language while it's in wide use, not while it's used by a small group of enthusiasts. So do let's talk again in 10-20 years ;-)
Properly to put it very simply means that the programmer is able to write in a reasonable amount of time correct, idiomatic, maintainable code which satisfies its given requirements. If the community in fact agrees that smart pointers are the favoured approach, then not using them because one stopped learning C++ is non-idiomatic and barring exceptional circumstances not "proper".
And actually this is one of my issues with Rust: idiomatic code is reference-heavy, meaning lifetime-heavy and it seems async is or is about to be idiomatic. The language is non-ergonomic. The same kind of language astronauts that are running the Rust show are present also in C++, conjuring template contraptions, but they can be mostly ignored and one can write simpler code.
It is, much the same as most people don't all learn the same way. Even more, most language wars are people arguing their preferences, not objective pros and cons. Rust is different though, as it has real, objective advantages that merit consideration IMO.
- It has multiple working compiler implementations
- It has a mountain of existing working software & libraries that may never be ported to rust, like most AAA video games, Chrome, Firefox, Windows, CUDA, etc.
- C++ has better interop with pure C code.
- C++ usually produces smaller binaries than rust.
- Complex data structures (like b-trees) are easier to write in C++. (Rust supports pointers in unsafe blocks - but the syntax around pointers is, for some reason, horrible.)
I adore rust, and I'd pick it over C++ every day of the week. But C++ is a powerful, fast, mature programming language with a rich ecosystem of compilers and tools. Rust is not a drop-in replacement for C++ in every case.
These advantages are not really advantages in the same way the advantages Rust offers are advantages.
In fact, most of the advantages you've listed here could apply to numerous languages not especially suited to modern development. As in, they're not real advantages and pale in comparison.
sighs Can we leave meaningless emotions out of such discussions.
You clearly already have an opinion about "Rust activists" in particular.
What are the pros and cons of using Rust in a kernel, that's where it gets interesting.
There’s a significant degree of ideology and grassroots activism behind this, which deserves to be criticized.
The person which posted the Rust-positive quote is usually very supportive of Rust and chose the one quote which puts C++ in a bad light, yet conveniently forgot to include the numerous criticisms of Rust from BSD developers and the fact that one of the main devs prefers C++ for example.
It is when the discussion is about the merits of Rust over C++.
I will slam C++ all day long and praise Rust. But I'll also acknowledge that it's easier to do some things in C++ (and C) than in Rust.
It only truly works if C++ has a hard mode-switch between modern and legacy C++, which it doesn't have. Things like smart pointers reduce memory bugs, true, but Absolutely Nothing in modern C++ disallow you to mix in raw pointers too. At best you have conventions requiring people to utilize the modern features, but that is asking the humans writing the code to be disciplined, and you know very well we are not. Mistakes happen.
If modern C++ has a `legacy` block that works in a similar vein as Rust's `unsafe` then perhaps your position would have been much stronger. Alas, it'd be very weak still because modern C++ continues to carry the baggages of legacy C++.
This is a real problem because any zealot of this level serves only to discredit the product by association.
I have no opinion on Rust other than I don't have the time to learn it at the moment and it doesn't look like it solves any problems in the domain of things I care about at the moment. I have no opinion past that. I am interested in technical discussion on it in case it overlaps a problem domain I am interested in, which is why I am on this thread :)
Some people don't see the Cons, they don't want to see the Cons... be happy for them to be so enthusiastic about a topic they love and ignore the rest of what they say ;)
Every community has them. Every single one. Find me a group of a super niche hobby, say 20 people in total. I can bet my neck I'll still find at least one of them in there who is a zealot. Not sure why people focus on the 0.01% of the Rust users who are fanatics. No they are not on important positions at all, they are some frustrated people who scream on Reddit and sometimes on HN, that's it.
> This is a real problem because any zealot of this level serves only to discredit the product by association.
No it does not. How did you even do this logical leap? Let me give you an example of what you did just say:
At some point somebody somewhere used their laptop to physically assault someone and caused them a head trauma. So surely, laptops are now discredited and you should never use one, correct?
Now replace "laptop" with literally anything else you have ever used.
> I am interested in technical discussion on it in case it overlaps a problem domain I am interested in, which is why I am on this thread :)
99.9% of the discussions where Rust is involved are technical. You should consider how you are picking your discussion threads if that percentage is much lower for you. I have not stumbled upon a Rust zealot on HN in at least 6 months. Last one I saw on Reddit was 3-4 months ago (though admittedly I gave up on Reddit's technical forums because they seem full of very emotional people).
Out of all the tech communities I've observed or been a part of, I think Linux in general might be the worst for having zealots.
I don't think it's a generous so much as reasonable assumption given the size and impact of the Linux project, and that there were much more anti-ms people in the late 90s and 2000s.
> so what?
I gave my perspective in a context where it seemed relevant. Why so adversarial?
The relevance to the argument at hand, I think, I was just stating an anecdote to show a scale of sorts. I think talking about the level of zealotry is relevant and kind of interesting.
At the same time, it's very disheartening for me how so many people wouldn't use something just because there are zealots who can't shut up about it. :(
This has mostly worked well for me, and paradoxically only HN is the place where even trying to defend Rust on its actual technical (as in: objective) merits still gets you labeled as a "Rust loonie" or "a zealot" or "Rust evangelist strike force". Even Reddit, that I view as an absolute cesspool, and had accounts banned for asking a question clearly adhering to the template given in the subreddit, has more nuanced discussions on Rust.
I find that quite fascinating, and even though my HN account is fairly non-recent, I still don't associate with the apparently very bone-headed people who jump like hit by a power line when Rust is mentioned.
The exact advocates you'd trust in this case are C++ experts who've, through experience, found a better solution.
A person who doesn't know the core language, saying that another is better anyways, is obviously a flawed statement to begin with.
Did they really? Just hand-waving and saying "use smart pointers" obviously did not work for many other people.
> A person who doesn't know the core language, saying that another is better anyways, is obviously a flawed statement to begin with.
How did you go from "he's not perfect in his C++ skills" to "a person who does not know the core language"? That's quite the leap and is not arguing in good faith.
> Not sure why this was downvoted.
Because it keeps repeating a very tiring falsehood: that there are "Rust activists".
People constantly conflate a push to use something that objectively reduces several classes of bugs -- backed by researches from Microsoft and Google, and others -- with "they are activists pushing for their favorite tech".
Losing those nuances is what makes discussion practically impossible. Just dehumanizing (or de-something-else) your discussion opponents is not a way to go yet the people who insist C++ is the best thing ever invented do it all the time, while playing the victim. As a person who had to moderate forums and chats and real-life meetings, I am not impressed by their discourse, yours and your parent commenter's included.
Ok, let's be objective then:
* a C++ programmer that is not comfortable with smart pointers in 2019 is incompetent and wouldn't pass any C++ interview in 2014, never mind five years later.
* we're not talking about researches from Google or Microsoft, but about bluejekyll which chose a biased quote to make C++ look bad and Rust good, when in the article it was very clear that the core FreeBSD maintainers prefer C++ and do not want Rust in their codebase.
There is no nuance to the above, it's a repeated pattern from several HN users which I and others have identified as activism. This is not dehumanising (seriously?) and I've kept things polite.
It's an important part of the picture. If the big boys are telling you it's not all hype and there's merit that can help OSS projects, kernels and drivers included, it could and should be used to reduce tension because shouting at people "You'll never force us to use Rust!" is not a mature thing to do (and it's present in a clip somebody linked in this thread).
If we can just discuss on merits, things will improve hugely. As it is though, people are being people and prefer to attack others based on emotions, yourself included, as illustrated here:
> I remember your nickname from some quite biased past comments on this Rust topic. Even in your recent history one can find downvoted sarcastic comments about Rust vs. C++ and now you want to be objective and want to discuss nuance.
This was one recent comment. One. You, my friend, are cherry-picking in an attempt to discredit me. Go and count my downvoted comments, I'll wait. We both know what you'll come back with.
I always wanted to discuss objectively and with nuance. Does not stop me being sarcastic sometimes, sue me. :)
I am surely showing more willingness to discuss than you however. Good enough for me.
Rewrite everything C++ is not a small undertaking with (maybe?) not allot plus-sides, and even then you still need C++ because of LLVM. LLVM and GCC are both C++, and you have to compile the Compiler (self-hosting), and even if your a 100% Rust or C OS, you still need C++ because of LLVM/GCC....well if you want a modern compiler ;)
https://github.com/freebsd/freebsd-src
Not important, you have to compile your Compiler fini, btw for Linux (just the Kernel) you need Perl ;)
I am guessing that performance of current standalone C compiler is not as good as the one produced by compiler suit.
Following the conversation thread, rust also use llvm under the hood, but a customized one. Which would force the base system to have two versions of llvm.
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.
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).
If you find the time and urge I'd be interested to know the results.
Firefox (and many other projects) was already a mix of multiple languages - it uses C, C++, Javascript, ... and now Rust. And while there is value in having less languages to deal with, there is equally value to use multiple languages and apply them where you see major benefit. For example, replacing exposed and high-risk components (image/file parsers for example) with a language that de-risks those implementations. Like all of the things in software engineering, this is a tradeoff. It may not make sense for your application, but it can make sense for others.
Making existing, well-used OS kernels safer is probably a lot easier than writing a new kernel from scratch, porting drivers, marketing it, and gaining a larger user base.
Not saying that's not a worthwhile endeavor, but it's up to everyone to decide what they want to do.
Ultimately the maintainers of a non-Rust project will decide if they want Rust in there. No amount of "force-jamming" is going to make it happen without their considered consent.
It means that rewriting part of something in rust has chances to reduce the overall security of the software
I find my use of force-jam was entirely appropriate, after careful consideration informed by the How rust proponents push rust into pre-existing projects.
As well as the drama they bring alongside them, and their propensity to resort to personal attacks.
Because the BSDs and Linux are actually used in hundreds of millions of systems and provide clear value to lots of people. Redox is cool, but it's in an entirely different league. It's not surprising that some people prefer to work on brand new stuff (like Redox), and some people prefer to work on improving old stuff that is actually in widespread use.
> 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.
I take it you prefer to always demolish your house and build a new one whenever any renovation, nomatter how small, involves a significant change in materials or methods or technology?
When such an analogy is put forth, I cannot believe there is any intent to discuss the subject in good faith.
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++.
https://www.phoronix.com/news/Rust-Linux-Maintainer-Step-Dow...
'''
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 -- and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code.
Thanks, -Wedson
'''
Having another maintainer completely shut down your talk by somewhat angrily shouting out irrelevant and fundamentally incorrect complaints and comparisons is incredibly disrespectful.
"You're not gonna force all of us to use Rust!"
However, I do think that the "other side" also raises a valid point in that they can not reasonably be expected to maintain the semantics on the C side so that the Rust bindings (which does make assumptions in order to create clean and powerful bindings to use the Rust type system) do not break. Pre-Rust, the onus is indeed on them to ensure that the entire codebase conforms with any semantic changes, but now, if we say get a new filesystem entirely written in Rust that relies on the bindings, who is responsible and how will the coordination happen?
Again, I am not a kernel developer and only a mediocre (at best) systems programmer. Thus, I could have misunderstood the discussion.
They are uncalled and should not be tolerated.
We had a colleague in my last job that was good technician but nobody wanted to talk to him or ask for help or anything because frankly, he was an asshole.
They simply have a fundamental difference of opinion. And I actually understand the C person is suggesting. Although may be he wasn't clear in explaining it. It is not the responsibility of C maintainer to spend additional time to explain their code. Especially in a way that Rust people understands. And may be in order for them to do that, without all the Rust context, they might as well learn Rust. And if Rust blinding is even set as a priority then all C maintainers would now have obligations, one way or another to work well with rust. Which neither does the C maintainers want to spend time on or have the interest to spend time on.
The Rust people on the other hand saw their move as common good and want everyone to work together. Unfortunately most developers would only discover very late in their carrier, you can only make that happen when everyone 's interest are aligned.
From the sounds of it, some of them consider this request unreasonable.
Color me shocked.
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
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.
Hit a multithreaded C++ server with 20k users a day alone and you would not believe the edge cases and weird states they will generate for you.
> I was extremely skeptical of Rust, due to the hype and some very obnoxious Rust proponents.
...is obviously a very biased way of gauging anything. As mentioned upthread in another comment of mine, every single community has the minority of loud bad apples and it's not fair to judge Rust because its community is literally like any other on this planet.
You did the right thing, you ignored the emotional responses and went to check for yourself, factually and objectively. I'd be honored to call you my colleague.
Bravo.
> You did the right thing, you ignored the emotional responses and went to check for yourself, factually and objectively.
I'm currently talking to lots of other C and C++ developers I know, and trying to convince them to give it an honest shot. The first thing I say is pretty much "Hey, I know this thing is overhyped and you're probably fed up, I thought so, too, but ...", and then follow that up with tagged unions, pattern matching and showing the toolchain. That sells most of them on it. Error handling also is a huge plus if they're also big error-handling nerds.
Also note how I never mention memory safety -- the reality is barely anyone gets really excited about that. We'd all use @safe Dlang[0] if it was that exciting to us all.
[0]: https://dlang.org/spec/memory-safe-d.html
That's a different approach, thanks for describing it. I've tried it as well but apparently I spoke with some very bone-headed people because they hand-waved it away immediately with "meh, C unions are fine, you're a noob if you need Rust to hold your hand". :(
I'll remember to bring those up next time, because I found myself caring about exhaustive pattern matching / enums more lately, compared to memory safety (which I do care about a lot still).
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.
"Can still be merged back into upstream" is a huge uphill battle. I understand the people who want to skip it.
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)
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.
I did, you keep missing the point.
True gatekeeping is preventing people from exploring ideas by saying people should not fork. Quite literally, you’re the one pushing for the gate to be kept closed.
I can’t help you with text comprehension, I’m sorry. Since you keep missing the point I won’t be replying any further, it’s wasted time.
Good luck with everything.
I get that you want to emerge the "winner" here but it's not going to work, HN readers are fairly well-educated. I asked for a summary, you refused it by also reaching for an ad hominem.
It's very visible who is who in this situation.
Good luck indeed.
To be frank, I think most of us just see two people failing to communicate.
Can you point out what did you perceive as snark, btw?
Without the support from upstream, just _syncing_ your fork with upstream can be a massive pain, as your changes conflicts with the new upstream changes. It's even more debilitating when you realize your efforts may not even be rewarded -- the upstream can simply decide to refuse to merge your fork.
This happens if you don't fork often, post your changes once in a very long time, and don't rebase your work very often.
If you rebase often enough you shouldn't have the mergeability problem.
> It's even more debilitating when you realize your efforts may not even be rewarded -- the upstream can simply decide to refuse to merge your fork.
The alternative is letting people greenlight you to even go and do a proof of concept. It smells like bureaucracy to me.
Having a fork and a working proof of concept can back your argument about feature development. The implementation is just a detail and can be adjusted or reworked as necessary.
Otherwise you risk your ideas getting stalled (or worse, completely rejected) by people that don't even fully understand what you're talking about.
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...
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.
And non-UNIX OSes, where by definition C library belongs to the compiler it is shipped with.
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.
There's even a precedent for this, check out DragonFly BSD if interested in reading more.
I also don't see reason to declare npm to be a failure, and frankly pip was never good. Cargo is excellent. I don't see why it would decline.
This is all so vague, and that confuses me. Language package managers are "destined to decline in quality" for unstated reasons. Language package managers are "don't work well" because there are multiple languages (and I presume you also mean multiple operating systems/distributions). That argument would seem to apply equally well to any package manager (including those maintained by OSs), so why are we singling any of them out?
(Cargo does have a build script mechanism, with a major use case being integrating with other languages at compile time. Eg, running `make`. The other package managers I'm familiar with have similar mechanisms. I would assume they all do, since it's a problem they all have.)
> Cargo does have a build script mechanism, with a major use case being integrating with other languages at compile time
I already use cmake and my own custom build environment manager. While there are warts it is setup and works well enough that I don't want to switch. But rust wants me to forget about all that and use cargo. While in theory I can use something else, they don't bother documenting those workflows (I'm not convinced they will keep them working if I do get it working)
I would be very surprised if changing the arguments to rustc (or the equivalent in any language) wasn't considered a breaking change, so I'm not sure how well founded your skepticism is. If it's poorly documented, that is a shame.
I'm saying that as one who knows little about the language.
But for a kernel (and a few other cases like network servers, browsers, foreign data decoders), I think that trade-off is perfect.
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.