undefined | Better HN

0 pointsManishearth10y ago0 comments

> If Rust's goal is to supplant C, it needs to be capable of everything C is capable of doing.

We have demonstrated this multiple times. You can either use your own stdlib like sqlite, or use recover. You may not like the solution, but the fact still remains that it still is a tangible solution (well, the latter one is -- "your own stdlib" is a pretty specialized solution which you shouldn't need) to the problem. Given that a solution exists, the only issue is with usability -- and you have to ask the question if there are any improvements to the OOM-handling API that can be made without burdening the users who don't care about OOM too much. There is one improvement which can be made that doesn't affect non-OOM users at all (custom allocators v2, which lets you use Rust error handling with stdlib heap types). This improvement is something the core team cares about and will probably happen (don't know about the time frame, since it handles a lot more things than just Resulty heap types). Other improvements will either mean having regular users check for null all the time, or make panics standard fare, neither of which are good ideas.

Please stop ignoring the fact that Rust does have a solution to the OOM problem; I'm tired of reiterating this argument. One can make arguments that it's much not as usable as C++ or C -- that's okay, but ignoring it entirely is just silly.

(As far as usability wrt C++ and C, I still don't see why it's less usable, C has the horrible check-every-time-or-else situation, and Rust's solution is more or less identical to C++ with the exception that it's the road less traveled on. Given that the API handles exception safety explicitly, this should not be that big a problem).

> you're suggesting that the former audience is the better bet

Not necessarily. The former audience encompasses the latter. Rust doesn't want to put undue burden on general users (like having to check all allocations or having to think about exception safety). That's a reasonable ask. It similarly doesn't want to put undue burden on systems users, and it doesn't -- not any more than C or C++. I don't think the Rust designers feel that they have, recover() is a pretty decent API with a lot of thought put into exception safety.

> If Rust's standard library isn't suitable for all environments where Rust might be used (like C++'s standard library is)

The reason #[no_std] was brought up was because you gave an example of sqlite, which does the same thing. It's meant to be used in certain situations in embedded programming or writing a kernel (note that Rust still has a "core std lib", called libcore, which is available and doesn't need malloc) where things like malloc may not even exist. Embedded programming in C++ does something similar.

0 comments

quotemstr10y ago

You haven't changed my mind about Rust being unfit for purpose.

> Please stop ignoring the fact that Rust does have a solution to the OOM problem;

I disagree that what you're calling a solution is, in fact, a solution. It's more like defining away the problem. It's the case that most Rust programs, those that use stdlib, will never be able to rigorously respond to all allocation failures.

You don't get to wave away problems with Rust stdlib with appeals to an unhosted environment when C++'s stdlib doesn't have the problems I'm highlighting. There's no reason std::vector couldn't be used in a kernel --- just no history.

The SQLite criticism is not the point. The request was for a tested component that recovers from allocation failure. Now you're saying that this example isn't good enough because it's written in C. You're moving the goalposts.

I've already outlined what it would take for me to agree that Rust's OOM problem is solved. It looks like Rust is just adding a few ways of optionally doing more stringent checks, not actually propagating failure from core routines appropriately.

> Not necessarily. The former audience encompasses the latter. Rust doesn't want to put undue burden on general users (like having to check all allocations or having to think about exception safety)

Should these poor users get a pony too? Programming is about managing resources. I've outlined elsewhere the kind of trap you force yourself into when you simultaneously avoid both exceptions and error codes. By doing both, you're not making the world a simpler case. You're just hiding the nasty bits that can go wrong, and users deserve better.

ManishearthOP10y ago

> It's the case that most Rust programs, those that use stdlib, will never be able to rigorously respond to all allocation failures.

I'm not talking about using a different stdlib, I'm talking about recover().

> You don't get to wave away problems with Rust stdlib with appeals to an unhosted environment when C++'s stdlib doesn't have the problems I'm highlighting.

I didn't do that. I'm asserting that Rust's stdlib is appropriate for more or less all situations where you would use C++s stdlib. I have already explained why recover() should be adequate when you want to handle OOM, and recover() is part of the regular stdlib.

I was just putting the raison d'etre for no_std out there, and noting that the situations where you would use it in Rust exist in C++ too. I was trying to dispel the argument that "no_std exists in Rust, hence the stdlib isn't appropriate for all use cases, hence it shouldn't be part of the distribution", which you might have been making in the grandparent comment (I'm not sure if you were).

> The SQLite criticism is not the point. The request was for a tested component that recovers from allocation failure. Now you're saying that this example isn't good enough because it's written in C. You're moving the goalposts.

Fair. I'm not the one who made the original request, so I forgot about that.

> It looks like Rust is just adding a few ways of optionally doing more stringent checks, not actually propagating failure from core routines appropriately.

I'm not sure what you mean here.

Rust already has the ability to catch all panics and handle OOMs at an abstraction boundary of your choice as a global solution, similar to exceptions in C++.

Rust is getting the ability to do fine-grained C-like (or "C++ with try/catch around every `new`" -like) allocation failure handling in custom allocators v2, which can also tie in with your regular error propagation machinery.

> I've already outlined what it would take for me to agree that Rust's OOM problem is solved.

You really haven't. You've just attacked Rust's lack of exceptions incessantly without much arguments to back it up. You've not mentioned why recover() (given that it has exception safety built in and exception safety was a first-class concern during its design) is inadequate.

> you simultaneously avoid both exceptions and error codes.

Rust's Result type is basically a safer and more robust error code. Custom allocators v2 gets you error-code-like allocation that can tie in with your regular error handling.

(FWIW you can do errno-like error handling of OOM using the current support for custom allocators already, though making this safe might be tricky)

j / k navigate · click thread line to collapse