[flagged]
> 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.
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.
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.
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.