5 ms·

Linus Torvalds once told this about C++ : https://lore.kernel.org/lkml/Pine.LNX.4.58.0401192241080.2311@home.osdl.org/ https://lore.kernel.org/lkml/Pine.LNX.4.

Linus Torvalds once told this about C++ : https://lore.kernel.org/lkml/Pine.LNX.4.58.0401192241080.2311@home.osdl.org/ https://lore.kernel.org/lkml/Pine.LNX.4.58.0401192241080.231... " any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel " This was about C++ . So,given that Rust is similar to C++ , How does this quote applies to Rust? Edit: I am getting downvoted for this post. Downvoters,any reasons?

lachlan-sneff 6y ago
The rust std library doesn't hide allocations at all. It's very explicit.
- dthul 6y ago
  I'm not even sure what Linus was referring to when he talked about memory allocations in C++ being hidden. Aren't the only options either an malloc (kmalloc) call or a `new` operator call?
  - cbsmith 6y ago
    I believe he was referring to encapsulation of allocations in constructors, and implicit invocations of the copy operator and constructor. He may have also been referring to a lot of how STL works, though the STL is pretty explicit about its allocations & behaviour.
    - dthul 6y ago
      Yeah, maybe he was referring to constructors. That might make sense, since something like "MyType t;" could allocate. I guess in the kernel context the STL (or whatever was around in 1992) would not be used though. Edit: or even something like "a = b"
      - cbsmith 6y ago
        It's not constructors per se. It's what people put in to them. So MyType t also allocates in C, right (it'd be a stack allocation of sizeof(MyType) bytes)? But the difference is in C++ that could cause a bazillion heap allocations. The problem gets magnified when you pass around these objects by value, thereby invoking copy constructors that also do those allocations, and doing value assignment, where you could have all those allocations happen again. His comments predate r-value references, and a lot of stuff that r-value references have improved would be exactly the kinds of things where he saw a problem (though he'd hate the r-value solution).
  - estebank 6y ago
    I would think that overridable constructors and destructors are the alluded problem. Rust doesn't have the first and the later is slightly more constrained.
cbsmith 6y ago
I wouldn't say that Rust is similar in this regard, nor do I think it is really a fair criticism of C++. It's more a fair criticism of certain C++ design idioms that are popular in certain circles. If you talk to people who do systems programming in C++ (particularly embedded systems), you'll find this isn't a common problem.
estebank 6y ago
Rust is quite explicit about allocations and reallocations. This makes the language slightly harder to use and increases it's verbosity, but on the plus side the behavior of the code is always predictable and the compiler will catch uses that in another language but be accepted and suggests the correct incantation. Rust won't choose between static or dynamic dispatch for you, the code you wrote does. I think this is the right approach for a performant language and a good compromise in usability. The only thing missing would be to have lints letting you know when using other constructs would be a better trade-off, like switching from dynamic dispatch to static dispatch when there's only one possible caller.
- jcelerier 6y ago
  > Rust is quite explicit about allocations and reallocations. gotta explain what's the difference between let mut vec = Vec::new(); vec.push(1); vec.push(2); vec.push(3); // likely allocates one, two, or three times and auto vec = std::vector<int>{}; vec.push_back(1); vec.push_back(2); vec.push_back(3); // same
  - Arnavion 6y ago
    Yeah, I'm really confused by the two subthreads saying Rust doesn't have hidden allocations. The standard library is full of them, and even with `no_std` there is the possibility of a "global" allocator (GlobalAlloc) to be able to do hidden allocations without an explicit allocator. Box, Vec, etc rely on that even in `no_std` code. The only way to have explicit allocations in Rust is to not use libstd (but this isn't special in the context of writing OSes anyway) and disallow using the GlobalAlloc trait, as well as any third-party libraries that rely on it. Unfortunately both the explicit allocator LocalAlloc and the global allocator GlobalAlloc, as well as all the types that rely on GlobalAlloc, are defined in the same library liballoc, so keeping one and removing the others requires patching liballoc. As far as other non-C languages go, Zig has an explicit allocator that neeeds to be threaded through any function that wants to allocate, which would likely satisfy Linus's requirement.
  - deleted 6y ago
    [deleted]
dthul 6y ago
Didn't downvote you, but maybe because it's quite off topic?
- Koshkin 6y ago
  It's not.
- yjftsjthsd-h 6y ago
  Discussing the suitability of Rust for OS development (based on the comments of the developer of a major OS) seems completely on topic when discussing writing an OS in Rust.
  - d1plo1d 6y ago
    I could be wrong but I interpreted the down votes as about incorrectly equating of Rust and C++ allocations. There are a few replies that address this better then I can (I'm limited here in that I grok Rust but not C++) but I believe the comment would have been more correct to draw similarities between C and Rust explicit allocation then C++ and Rust. Hence why Linus is allowing Rust for certain Kernel aspects whereas he has previously rejected C++: https://www.theregister.com/2020/07/13/rust_code_in_linux_kernel/ https://www.theregister.com/2020/07/13/rust_code_in_linux_ke...
pjmlp 6y ago
Linus can keep his opinion for himself and whatever direction he wants to drive Linux. Symbian, Windows, macOS, Android, ChromeOS, Arduino, ARM mbed are all examples of OSes that have C++ at the kernel, or very least at the drivers layer.
- Jasper_ 6y ago
  Android and ChromeOS are based on the Linux kernel. Arduino has no standard OS from what I'm aware.
  - pjmlp 6y ago
    Arduino uses bare metal C++ runtime, which is an OS of some sorts. Android and ChromeOS use a fork of Linux kernel, with legacy drivers written in C. What GNU/Linux users would call regular drivers. Project Treble drivers are written in a mix of C++ and Java. ChromeOS uses a mix of C++ and Rust for its drivers. Linux fans have to come to grips that its place on Android and ChromeOS is only a convenience for a POSIX like kernel.
d1plo1d 6y ago
Hey @varbhat, I think perhaps the downvotes are due to some AFAIK incorrect assertions in your comment. Rust allocations are I believe closer to C then C++ and Linus has already supported Rust: https://www.theregister.com/2020/07/13/rust_code_in_linux_kernel/ https://www.theregister.com/2020/07/13/rust_code_in_linux_ke... So basically the question as it's asked doesn't make sense as I understand Rust and if someone took that to be intentional could be interpreted as language FUD (which could then deserve a down vote). An update to prevent the spread of misinformation about the language would be cool. PS. I've only been using Rust on the daily for the last 8 months so I am by no means an expert. If there is a reason for your assertions that I'm missing I'd like to know. Thnx!

lachlan-sneff 6y ago

The rust std library doesn't hide allocations at all. It's very explicit.

dthul 6y ago
I'm not even sure what Linus was referring to when he talked about memory allocations in C++ being hidden. Aren't the only options either an malloc (kmalloc) call or a `new` operator call?
- cbsmith 6y ago
  I believe he was referring to encapsulation of allocations in constructors, and implicit invocations of the copy operator and constructor. He may have also been referring to a lot of how STL works, though the STL is pretty explicit about its allocations & behaviour.
  - dthul 6y ago
    Yeah, maybe he was referring to constructors. That might make sense, since something like "MyType t;" could allocate. I guess in the kernel context the STL (or whatever was around in 1992) would not be used though. Edit: or even something like "a = b"
    - cbsmith 6y ago
      It's not constructors per se. It's what people put in to them. So MyType t also allocates in C, right (it'd be a stack allocation of sizeof(MyType) bytes)? But the difference is in C++ that could cause a bazillion heap allocations. The problem gets magnified when you pass around these objects by value, thereby invoking copy constructors that also do those allocations, and doing value assignment, where you could have all those allocations happen again. His comments predate r-value references, and a lot of stuff that r-value references have improved would be exactly the kinds of things where he saw a problem (though he'd hate the r-value solution).
- estebank 6y ago
  I would think that overridable constructors and destructors are the alluded problem. Rust doesn't have the first and the later is slightly more constrained.

cbsmith 6y ago

I wouldn't say that Rust is similar in this regard, nor do I think it is really a fair criticism of C++. It's more a fair criticism of certain C++ design idioms that are popular in certain circles. If you talk to people who do systems programming in C++ (particularly embedded systems), you'll find this isn't a common problem.

estebank 6y ago

Rust is quite explicit about allocations and reallocations. This makes the language slightly harder to use and increases it's verbosity, but on the plus side the behavior of the code is always predictable and the compiler will catch uses that in another language but be accepted and suggests the correct incantation. Rust won't choose between static or dynamic dispatch for you, the code you wrote does. I think this is the right approach for a performant language and a good compromise in usability. The only thing missing would be to have lints letting you know when using other constructs would be a better trade-off, like switching from dynamic dispatch to static dispatch when there's only one possible caller.

jcelerier 6y ago
> Rust is quite explicit about allocations and reallocations. gotta explain what's the difference between let mut vec = Vec::new(); vec.push(1); vec.push(2); vec.push(3); // likely allocates one, two, or three times and auto vec = std::vector<int>{}; vec.push_back(1); vec.push_back(2); vec.push_back(3); // same
- Arnavion 6y ago
  Yeah, I'm really confused by the two subthreads saying Rust doesn't have hidden allocations. The standard library is full of them, and even with `no_std` there is the possibility of a "global" allocator (GlobalAlloc) to be able to do hidden allocations without an explicit allocator. Box, Vec, etc rely on that even in `no_std` code. The only way to have explicit allocations in Rust is to not use libstd (but this isn't special in the context of writing OSes anyway) and disallow using the GlobalAlloc trait, as well as any third-party libraries that rely on it. Unfortunately both the explicit allocator LocalAlloc and the global allocator GlobalAlloc, as well as all the types that rely on GlobalAlloc, are defined in the same library liballoc, so keeping one and removing the others requires patching liballoc. As far as other non-C languages go, Zig has an explicit allocator that neeeds to be threaded through any function that wants to allocate, which would likely satisfy Linus's requirement.
- deleted 6y ago
  [deleted]

dthul 6y ago

Didn't downvote you, but maybe because it's quite off topic?

Koshkin 6y ago
It's not.
yjftsjthsd-h 6y ago
Discussing the suitability of Rust for OS development (based on the comments of the developer of a major OS) seems completely on topic when discussing writing an OS in Rust.
- d1plo1d 6y ago
  I could be wrong but I interpreted the down votes as about incorrectly equating of Rust and C++ allocations. There are a few replies that address this better then I can (I'm limited here in that I grok Rust but not C++) but I believe the comment would have been more correct to draw similarities between C and Rust explicit allocation then C++ and Rust. Hence why Linus is allowing Rust for certain Kernel aspects whereas he has previously rejected C++: https://www.theregister.com/2020/07/13/rust_code_in_linux_kernel/ https://www.theregister.com/2020/07/13/rust_code_in_linux_ke...

pjmlp 6y ago

Linus can keep his opinion for himself and whatever direction he wants to drive Linux. Symbian, Windows, macOS, Android, ChromeOS, Arduino, ARM mbed are all examples of OSes that have C++ at the kernel, or very least at the drivers layer.

Jasper_ 6y ago
Android and ChromeOS are based on the Linux kernel. Arduino has no standard OS from what I'm aware.
- pjmlp 6y ago
  Arduino uses bare metal C++ runtime, which is an OS of some sorts. Android and ChromeOS use a fork of Linux kernel, with legacy drivers written in C. What GNU/Linux users would call regular drivers. Project Treble drivers are written in a mix of C++ and Java. ChromeOS uses a mix of C++ and Rust for its drivers. Linux fans have to come to grips that its place on Android and ChromeOS is only a convenience for a POSIX like kernel.

d1plo1d 6y ago

Hey @varbhat, I think perhaps the downvotes are due to some AFAIK incorrect assertions in your comment. Rust allocations are I believe closer to C then C++ and Linus has already supported Rust: https://www.theregister.com/2020/07/13/rust_code_in_linux_kernel/ https://www.theregister.com/2020/07/13/rust_code_in_linux_ke... So basically the question as it's asked doesn't make sense as I understand Rust and if someone took that to be intentional could be interpreted as language FUD (which could then deserve a down vote). An update to prevent the spread of misinformation about the language would be cool. PS. I've only been using Rust on the daily for the last 8 months so I am by no means an expert. If there is a reason for your assertions that I'm missing I'd like to know. Thnx!