And when you look into C++ libraries/stdlib, they often look like they're written in another language entirely. This is not normal.
Why would that be true? When you write a library, you are writing code to cover all possible uses; everything within the scope of your library should at least be considered, even if you personally have no need of that particular bit of functionality. But when you write a program it only has to do one thing, so of course it's going to be simpler. To me, it seems obvious that (good) library code will be very different from (good) application code.
(I've used libraries that were written like applications, but they were bad libraries; I was constantly fighting the fact that the library author wrote only for their own use-case, and didn't consider any other.)
Here’s std::vec: https://doc.rust-lang.org/src/alloc/vec/mod.rs.html
I tried to read C++’s vec class when I was learning C++ and I was confused and lost. I agree with the GP post - it feels like another language.
I see rust's safety guarantees like having a good static type system. Static type systems don't claim to prevent all bugs, but they do catch an awful lot of bugs at compile time in practice. Rust's default safety with opt-out unsafe blocks work the same way. Despite what some zealots would have you believe, the point isn't to make every single line of code "safe". Good rust code still uses unsafe code - for example your binary includes unsafe code whenever you use Vec or Box from std. But all unsafe code blocks are explicitly called out as such, tested thoroughly (eg with miri) and usually constrained to a small part of your program. You can think about it as, C or C++ programs are 100% unsafe. Rust programs are usually only ~2% unsafe or so. That makes a huge difference in practice.
Unsafe code can also usually be encapsulated in safe wrappers. (Eg std::io::File wraps the unsafe call to open(), and std::Vec wraps some raw pointer operations). Unsafe also doesn't turn off the borrow checker. The only difference is unsafe blocks allow you to dereference pointers, call unsafe functions, and a few other things like that.
The standard library has more unsafe than most programs, because "data structures that need a lot of unsafe" has historically been an argument for being put in the standard library, because that way they'll be reviewed very carefully by experts.
This isn't always true, and can't be generally expected, but I think it is true in the case of Go's standard libraries. These are high quality, and are one of my top examples of good, real source code to study (along with the DOOM and Quake source code). A nice touch in Go's library documentation is that you can click any API element (type, function, etc.) to be brought directly to its source code.
Yes, there are differences between writing libraries and writing programs. But there is value in studying well-written source code, even when it has concerns and requirements that differ from yours. You can adapt what you learn to your needs.
(I will admit I've felt profoundly stupid when I go from "how hard could it be to implement std::optional/reference counted pointers/etc., anyway?", to say GNU's implementation of it in libc++.)
What the feeling of security that new features giveth, having to work with large idiosyncratic codebases and a wide variety of toolchains taketh.