4 ms·

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 pointe

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?

pdimitar 2y ago
[flagged]
tialaramex 2y ago
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".
- blub 2y ago
  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.
  - tialaramex 2y ago
    > 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++.

pdimitar 2y ago

[flagged]

tialaramex 2y ago

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

blub 2y ago
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.
- tialaramex 2y ago
  > 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++.