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