Hacker News Reader

Comment by steveklabnik | Hacker News Reader

> I don't think my software is all that special.

I think that regularly requesting a single chunk of memory that is likely to be larger than total RAM + total swap in the desktop context is unusual, but it's true this is an opinion.

> The linked-to essay uses new_uninit_slice in Rust

If you wanted to check the allocation, you'd use try_new_uninit_slice, which is the same thing but returning a Result instead of panic-ing.

> where the default is for Rust to handle OOM errors,

Again, it's worth splitting out the language from the library and or culture here: Rust itself never allocates, and so never OOMs.

> also holds for the C code.

I don't mean to imply Rust is better than C in this regard, only that "you can't check for OOM in Rust and therefore it's impossible to build the library how I want" is untrue.

View on HN

My belief is that "C for Rust Programmers" should not be "how to write Rust in C" but "How to write C, for people who are Rust Programmers". The expectations for a production quality C library appear to be different than for a production quality Rust library, and I think one of those differences is memory allocation.

While I am certainly ignorant of Rust, my overall issue is that this statement:

"In order to avoid unhelpful segfaults, the program should check for a null pointer and gracefully exit if one is found:"

The following example shows that "gracefully exit" means a perror() and exit() call, which is not appropriate for a C library.

I presumed this is because the author is someone with Rust experience, and who wants to replicate the expected Rust behavior in C. I think the better alternative is to explain that a well-written C library can have different expectations.

I'll add that the essay has a footnote saying "The corresponding Rust function is not idiomatic, and can only correctly handle ASCII text. If I were writing a production version of this function, it would be a single line of code: forward.chars().rev().collect::<String>()."

I see that production version doesn't handle allocation failures either.

My follow-on presumption is that most Rust libraries use this sort of idiomatic production code, where allocation failures simply panic.

I could well be wrong, but this essay certainly doesn't clearly show that I am wrong in my belief.

That's fine. My aim is to clarify Rust's design and choices. I don't have strong opinions about what should be in the post.

> I'll add that the essay has a footnote saying

Honestly I have an entirely different beef with this footnote: `chars` is for codepoints, not really "characters", because what a "character" is in Unicode is very complicated.

> My follow-on presumption is that most Rust libraries use this sort of idiomatic production code, where allocation failures simply panic.

Yes, I wouldn't argue that most Rust code uses these try_ variants, because of the whole overcommit thing. But in contexts where it does matter, people do. The expectations are different based on context. Lots of Rust code expects (and enforces) no allocations at all, but that doesn't mean I'd claim that all Rust code does.

I also think it's fine to want to hold libraries, C or Rust, to a higher standard with regards to allocation failure, but in practice, most people (in both languages) do not find the juice worth the squeeze, and so don't really do it.

Reply on news.ycombinator.com