Hacker News Reader

Comment by professoretc | Hacker News Reader

> I'm always saying that good way to learn language patterns and idioms is to look into standard libraries implementations.

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

View on HN

>> I'm always saying that good way to learn language patterns and idioms is to look into standard libraries implementations. > >Why would that be true?

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 hear you. But I’ve also learned a lot about how to write idiomatic rust from scrolling through rust’s standard library. You’re right - because it’s written to support lots of programs, it sure is packed with a lot of functions I’ll probably never use. But it’s still quite beautiful and readable. Much more so than C++.

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'm not very familiar with rust, but isn't the point to mostly avoid `unsafe` and write safe code? Strange that basic std vec functions like insert and remove call `unsafe` - isn't this an example where you don't want to be like the std lib?

At the end of the day, rust is still a systems language. Lots of useful things require unsafe, including most data structure implementations and FFI - including syscalls.

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.

> Strange that basic std vec functions like insert and remove call `unsafe`

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.

I think you're right, and perhaps I think the underlying issue uncovered by OP might be: the lack of a single core set of features to achieve a sense of mastery with, that feeling like you've understood an implementation stdlib might have given.

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

Reply on news.ycombinator.com