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