[thayne]

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.

[leshow]

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

[thayne]

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.

[msdrigg]

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

[cute_boi]

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.

[msdrigg]

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

[dataflow]

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