It's not nothing, there are numerous intrinsics needed, and also "hacks" where the standard library does something that's labelled UB if you did it in your code but is magically blessed OK when the stdlib does it.
That preference to solve things in "the" library leads to other horrible problems though, where C++ ought to have a first class language feature, but instead WG21 has enshrined a workaround in the library which is probably better than if you'd made your own, but rather poor compared to a first class feature.
Take the array. Rather than provide a good array type in the actual language, C++ offers std::array, a library class in the standard library. But this standard library class isn't available in "freestanding" C++ while the builtin C-style array is available. So you end up with awkward syntax and the core language loses flexibility.
Likewise strings, in Rust the type of an arbitrary literal "Hacker News" is &'static str, a reference to an immutable view of this text which lives as long as necessary. In C++ the type of "Hacker News" is char*, a pointer to bytes. C++ 17 at last provided std::string_view which is the thing you actually wanted for about two decades, but the type of "Hacker News" isn't string_view it's still char*.
HN thinks asterisks mean you want to emphasise text (these days using italics) so you should in most cases escape them with a backslash.
Much of the C++ standard library (including for example std::array) is not available in freestanding C++. Should it be? Perhaps. But it isn't.
In contrast to Rust's conscious decision to provide core, alloc and std as separate layers, in the C++ there's a rather ad hoc process to decide what's freestanding.
<source>:6:7: error: request for member 'foo' in 'x', which is of non-class type 'const char [12]'
6 | x.foo();
They are an unstable type (an array) that, because of its C affinity, tends to quickly decay to pointers, hence the need to use ̵a̵ ̵p̵a̵r̵t̵i̵c̵l̵e̵ ̵a̵c̵c̵e̵l̵l̵e̵r̵a̵t̵o̵r̵ the universal reference to observe its fleeting lifetime.
Good point, I should have remembered these are actually immutable arrays of char (with a bonus 0 byte at the end).
The main thrust of my point though is that this type is terrible - even before it decays, and you don't get a std::string_view which is what you probably actually ought to get in modern software.
> C++ 17 at last provided std::string_view which is the thing you actually wanted for about two decades
Err..string_view was available in Boost for quite a while actually - at-least for a decade as far as I remember, possibly more. There are so many missing features in Rust that are only available in crates even today: sane error handling for one/custom allocators for another, but god forbid if you criticise Rust on that basis. You will get downvoted to oblivion.
I don't see how string literals end up in the same category as custom allocators. Maybe you write some very special code which rarely uses strings for anything but needs a lot of custom allocators, the vast majority of programmers, even C++ programmers are very much the opposite.
