4 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 handl

by sai_c 5y ago

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"? Fair enough. But this would mean that Rust is (factually) a systems language in the same sense that Go was initially declared to be a systems language. If I look at the Rust community (I give it a try from time to time), I would totally agree with your point, that most users would be pestered by this overhead. I see mostly CLI tools, "web apps" and the kind. Furthermore, I just can't shake off the feeling that the embedded (bare metal, 16 or 32 bit architectures) or (in-house) kernel crowd will always be 2nd class citizens. I keep saying this, but the obvious fix is for the Linux kernel to use overcommit internally just like they expect user space to do. I'm not a kernel developer, but aren't you (maybe) asking for a bit too much? You ask the Linux kernel devs to change the kernel in a significant way, just so you can use Rust for writing drivers in a way you write user space applications.

dathinab 5y ago
No it's about "by default" not pestering users. Rust has all the tools needed to gracefully handle memory allocation failure. Yes, the tools are a bit limit wrt. usages in the standard library where you mainly can use them to handle "known to potentially fail big" allocations but not every single small allocation. But enter no_std and it's basically all your choice, which is also the default thing to use for embedded/bar-metal and I count the kernel as embedded/bar-metal. (It's default because the std library types are tuned for the most common use-cases including web-server and user-space system programming, in which you always can have panic on OOM, and error kernel as a much more ergonomic pattern then explicitly returning a result on every thing which potentially allocates). Through without question the discussion around it is a mess.
volta83 5y ago
> 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 5y 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 5y 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 5y 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.

by sai_c 5y ago

dathinab 5y ago

No it's about "by default" not pestering users. Rust has all the tools needed to gracefully handle memory allocation failure. Yes, the tools are a bit limit wrt. usages in the standard library where you mainly can use them to handle "known to potentially fail big" allocations but not every single small allocation. But enter no_std and it's basically all your choice, which is also the default thing to use for embedded/bar-metal and I count the kernel as embedded/bar-metal. (It's default because the std library types are tuned for the most common use-cases including web-server and user-space system programming, in which you always can have panic on OOM, and error kernel as a much more ergonomic pattern then explicitly returning a result on every thing which potentially allocates). Through without question the discussion around it is a mess.

volta83 5y ago

> 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 5y 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 5y 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 5y 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.