3 ms·

> So, basically you are saying "Rust is mostly used as an application programming language anyways, so let's not pester those users with the overhead of OOM han

> So, basically you are saying "Rust is mostly used as an application programming language anyways, so let's not pester those users with the overhead of OOM handling"? No. What I am saying is that Rust intended to be a systems programming language that could handle OOM properly everywhere, but that got a lot of opposition because some operating systems, mainly Linux, make it impossible for programs to handle OOM _at all_, so adding proper OOM support to Rust would mean that every Rust Linux programmer would be paying for a feature (in ergonomics, etc.) that they cannot use _at all_. That's the irony. Linux design has made it not worth it for new programming languages to be designed to handle OOM properly, because that's impossible to do in OSes like Linux. People have been complaining about this for user space programs for the last 20 years, and the Linux kernel stand was "that's a feature, not a bug". But now that they are confronted with it, you see Linus writing stuff like "that's not acceptable". That's a huge double standard IMO.

ssokolow 6y ago
I don't think you can use "double standard" as a derogatory term when you're comparing the needs of kernelspace code and userspace code. ...plus, they're already planning to write their own `alloc` replacement if for no other reason that they need to support API features of the kernel allocator that are absent from the userspace allocator, like GFP flags: https://github.com/Rust-for-Linux/linux/issues/2#issuecomment-821143720 https://github.com/Rust-for-Linux/linux/issues/2#issuecommen...
- volta83 6y ago
  > I don't think you can use "double standard" as a derogatory term when you're comparing the needs of kernelspace code and userspace code. You argue that the needs of kernel space and user space differ when handling OOM errors. If that were true, one wouldn't have had to patch the standard library with the `try_...` methods to try to support OOM handling in user space as an afterthought. That request came from firefox, where a user in userspace can click on a link pointing to a 1 Tb large, e.g., image file, that would kill the browser if it can't handle OOM properly. So yes, it is a double standard, because both user space and kernel space have millions of valid reasons for wanting to handle OOM errors, but Linux and in particular Linus Torvalds motto here is "do as I say, not as I do". It is also extremely ironic that this Linux kernel policy that makes it impossible for user space to handle OOM, now causes Linus to cry about it when the kernel wants to start using tools develop for userspace in the kernel. They are directly responsible for this outcome.
  - ssokolow 6y ago
    Rust 1.0 was explicitly intended to be a Minimum Viable Product, containing only the work they felt they couldn't revise later without breaking their API stability promise. As such, they started with the versions of allocating APIs that are most commonly desired... the ones equivalent to how array[index] will either get what you want or panic if you're out of bounds. The try_ allocation APIs which are equivalent to .get on a container then came later. A web browser, while a good program to stress the capabilities of a language's design to make sure it can meet demand, is not a typical program.

ssokolow 6y ago

I don't think you can use "double standard" as a derogatory term when you're comparing the needs of kernelspace code and userspace code. ...plus, they're already planning to write their own `alloc` replacement if for no other reason that they need to support API features of the kernel allocator that are absent from the userspace allocator, like GFP flags: https://github.com/Rust-for-Linux/linux/issues/2#issuecomment-821143720 https://github.com/Rust-for-Linux/linux/issues/2#issuecommen...

volta83 6y ago
> I don't think you can use "double standard" as a derogatory term when you're comparing the needs of kernelspace code and userspace code. You argue that the needs of kernel space and user space differ when handling OOM errors. If that were true, one wouldn't have had to patch the standard library with the `try_...` methods to try to support OOM handling in user space as an afterthought. That request came from firefox, where a user in userspace can click on a link pointing to a 1 Tb large, e.g., image file, that would kill the browser if it can't handle OOM properly. So yes, it is a double standard, because both user space and kernel space have millions of valid reasons for wanting to handle OOM errors, but Linux and in particular Linus Torvalds motto here is "do as I say, not as I do". It is also extremely ironic that this Linux kernel policy that makes it impossible for user space to handle OOM, now causes Linus to cry about it when the kernel wants to start using tools develop for userspace in the kernel. They are directly responsible for this outcome.
- ssokolow 6y ago
  Rust 1.0 was explicitly intended to be a Minimum Viable Product, containing only the work they felt they couldn't revise later without breaking their API stability promise. As such, they started with the versions of allocating APIs that are most commonly desired... the ones equivalent to how array[index] will either get what you want or panic if you're out of bounds. The try_ allocation APIs which are equivalent to .get on a container then came later. A web browser, while a good program to stress the capabilities of a language's design to make sure it can meet demand, is not a typical program.