That's probably true of quite a few languages actually. I mean if there is any library you want to be as fast as possible, it's the standard library. Take python for example, a big chunk of the standard library is actually written in c (although there is often an equivalent implementation in python). In rust the standard library uses quite a bit of unsafe code, and even nightly only features and standard-library-only features that you don't usually need in real code, because you will be calling something in core or std that does it for you, and has been rigorously checked to be safe. The java standard library has parts that are written in c++. Etc. Etc.

> In rust the standard library uses quite a bit of unsafe code, and even nightly only features and standard-library-only features that you don't usually need in real code

I have found the Rust std lib to be a great resource. Much of the unsafe is necessary because there is literally no other way to build up abstractions like Box or certain data structures without it. Obviously once those are written though, you want to build on top of them where possible and not use unsafe.

It's probably important to delineate between a good example of application code vs library code also. The std lib is not going to help much with application code.

Exactly. The rust standard library can be very informative (and the same is true of other standard libraries as well), but it isn't necessarily going to be the same as what you would do in application code, because in application code you have the benefit of the standard library.

Do you know of any examples of good quality application code in rust?

There are many like firecracker vm, polkadot, linkered proxy, tokio, hyper etc. And these are the one I know and I think there are too many good quality application code in Rust.

I wouldnt have thought of tokio as application code bc its a library, but I guess it kinda is because it also provides a runtime.

Thanks for the list

> I mean if there is any library you want to be as fast as possible, it's the standard library.

To a decent extent yeah, though I would emphasize the issue isn't quite being as fast as possible (although in some cases it is, but also see I/O streams...), but rather having near-absolute correctness, and achieving high performance as a secondary goal. You can usually find a faster third-party implementation of anything in the C++ standard library. The problem is third-party implementations always cut corners somewhere, whether it's strong exception-safety, proper trait/concept handling, thorough testing of rare edge cases, extensibility/customizability, or other stuff. Even the syntactic complexity rises as a result, let alone the complexity of the actual semantics. (Even minor stuff like using difference_type/size_type instead of ptrdiff_t/size_t makes things more verbose and harder to read in the standard library; third-party implementations would often opt for the latter.)

Uh yeah if you try and read the Haskell standard library, you're screwed. It's list fusion and fancy algorithms to hack asymptotics all the way down.

What does it mean to “hack asymptotics”?

Algorithm runtime analysis is usually measured with asymptotic estimates (Big O, Little O, Big Theta, etc). In something as commonly and generically used as the standard library of any performance focused language you're liable to find a focus on optimizing these algorithmic performance guarantees for corner cases over optimizing for simple and straightforward code.

Got it, thanks!

Yeah, the first thing that popped into my head was some poor n00b spending the next six years of their life deciphering glibc. There have got to be easier ways :)

musl, I would expect? (granted, that's C, but vs glibc...)

Yeah, musl is simpler and cleaner than glibc. I was referring to C, by the way. libstdc++ is actually part of gcc, not glibc.

And the C++ standard library has too many fundamental design issues that are just bad advice for writing actual maintainable and performant code. For example, the standard specifies all map containers to have pointer stability, which is often not needed in reality. Because of this all <unordered_map> implementations are hilariously slow. Or what about std::vector<bool>, <iostream>, std::string, you name it.

The frustrations people have with it are sometimes up to the point where they begin writing everything from scratch…

That’s actually what I do whenever I’m lacking humility as a coder. One F12 on std::iterator (which is now deprecated lol [0]) is enough for me to remember that I don’t know anything.

[0] https://www.fluentcpp.com/2018/05/08/std-iterator-deprecated...

My gripe with C++ is that you need to know so many things to build even the most basic abstractions. When writing a custom data structure you always end up with having headaches about the specifics of std::iterators and rvalue references and all that jazz rather than focusing on the actual algorithm. There’s a reason why people want to go back to Orthodox C++ (using C++ as C with a few extra features)

This. Want to define a class? Remember the rule of 3 (or is it 5?).

Yeah... for C++ it's more like s/To learn/To really learn/

I was about to post the same but here you are. The only time I would study std:: namespace would be is I needed to write some generic library. Trying to learn C++ by reading std:: can make one's head explode.

The same is true of clojure. Don’t read clojure.core as idiomatic.

One thing I have wondered about is the number of multi-arity functions that individually specify 1, 2, 3, 4, 5 argument cases in 3rd-party library code. Is it a result of people thinking that’s idiomatic, or is

  ([a b c d])

performant enough to matter in library code instead of using

  ([a b & more])

? I hope it’s the former.

This is also true for .NET, especially modern .NET where performance is critical nearly everywhere. It's representative of perf-sensitive code, but not general purpose C#.

I would have commented that if you didn't

thank you