4 ms·

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 pa

by 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++.
- pebal 2y ago
  > Does your C++ have a garbage collector? No? You can have GC in C++, completely pauseless GC (https://github.com/pebal/sgcl 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.
  - tialaramex 2y ago
    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.
    - pebal 2y ago
      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.
  - deleted 2y ago
    [deleted]
- blub 2y ago
  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.

by blub 2y ago

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

pebal 2y ago
> Does your C++ have a garbage collector? No? You can have GC in C++, completely pauseless GC (https://github.com/pebal/sgcl 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.
- tialaramex 2y ago
  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.
  - pebal 2y ago
    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.
- deleted 2y ago
  [deleted]
blub 2y ago
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.