3 ms·

> It's also not limited to Rust, it's about providing support for multiple other languages that could be beneficial in those locations But what are these benef

> It's also not limited to Rust, it's about providing support for multiple other languages that could be beneficial in those locations But what are these benefits that other languages bring on the table? From the article it appears that proponents of the new toolchain mention memory-safety as the primary concern: > They focused on security concerns, citing work showing that around two-thirds of the kernel vulnerabilities that were assigned CVEs in both Android and Ubuntu stem from memory-safety issues. Rust, in principle, can completely avoid this error class via safer APIs enabled by its type system and borrow checker. So the natural follow-up question to that concern, it seems to me, would be whether there's something in the existing C/GCC toolchain (or around it) that can resolve the raised concerns without adopting a whole new toolchain (Rust/LLVM) and without having to extend the existing interface with language-specific suffixes like "kmalloc_for_rust".

bsder 6y ago
> So the natural follow-up question to that concern, it seems to me, would be whether there's something in the existing C/GCC toolchain (or around it) that can resolve the raised concerns without adopting a whole new toolchain (Rust/LLVM) The answer to this question appears to be: no. Memory errors sit somewhere around 2/3 to 3/4 of errors irrespective of codebase when C is involved (this has been consistent in things like the Linux kernel as well as the Windows codebase). C++ hasn't seemed to have changed that, either. Remember, Rust IS Mozilla's answer to this question. > without having to extend the existing interface with language-specific suffixes like "kmalloc_for_rust". The requirement to do that is pointing out the that kernel API is poor and is too intimately tied to the build chain. We have seen this before--when Linux got ported to Alpha, for example. The point is to fix the API so that more languages than just Rust can be used. I suspect that more "system programming" languages may appear once Rust does the difficult groundwork of breaking this kind of intimate toolchain dependence. As things currently stand, why develop a system programming language given that no one will ever use it?
- einpoklum 6y ago
  > C++ hasn't seemed to have changed that, either. C++ is not like C. Putting some C++ objects in a C codebase would, indeed, not change it much, but if you write in modern C++, some memory errors will literally disappear, and some become less likely. Caveat: This is based on language mechanics, standard library facilities and recommended idioms; of course people can write unsafe C++ if they want to.
  - bsder 6y ago
    > of course people can write unsafe C++ if they want to. The problem is knowing the safe subset of the language requires continuous study and deep understanding. It also has changed with time. I used to have a bookshelf in order to understand C++. I suspect that has not changed. I do not need a bookshelf to understand the "safe" subset of Rust.
    - einpoklum 6y ago
      You are partially correct but mostly incorrect, I would say. It's true that writing safe code requires some study and some understanding. But you don't need to "know what's safe". That _is_ complicated - there are a lot of complex depths to the language. The thing is, the non-expert user can avoid them. For example, a green developer can start with "Avoid using new and delete directly; use vectors, other containers, or unique_ptr's instead. Maybe shared_ptr's in some cases." If at some point they really need to write their own allocating class, they'll be told to be very careful with the allocation, and take into account the possibility of exceptions, concurrent execution by other threads etc. Also, when you're not sure of yourself, there's a good enough reference in the form of the C++ Core Guidelines [1]. (That's a long document, but you don't need to read through it.) Finally, a whole lot of memory error hazards / unsafe code can be statically identified and discouraged. Gradually, IDEs and other tools have started doing so. [1] - isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
  - roca 6y ago
    And modern C++ features makes some memory errors more likely, e.g. dangling references from lambda captures and string_view/span. I'm not optimistic about the safety of modern C++. Most people who really care about safety long ago left the C++ building.
kbenson 6y ago
> But what are these benefits that other languages bring on the table? From the article it appears that proponents of the new toolchain mention memory-safety as the primary concern: Of the venn diagram of languages that provide more safety than C (and that is, either require it or make it hard to bypass), and languages that people know know or are likely to know in the semi-near future, Rust and Go are probably the big contenders. ATS may be easier to interface with the kernel in, but is random peripheral company writing a kernel module driver likely to know it and use it? Theoretically, everyone can write most or all of their modules in Coq, right? So why don't they? Why is ATS different? > So the natural follow-up question to that concern, it seems to me, would be whether there's something in the existing C/GCC toolchain (or around it) that can resolve the raised concerns without adopting a whole new toolchain (Rust/LLVM) You're mistaking the aims of a project to specifically adapt Rust to the linux kernel and what they focused on. This note is frm a Rust initiative, not a kernel initiative, why would they focus on doing something in a different language? > and without having to extend the existing interface with language-specific suffixes like "kmalloc_for_rust". I addressed this in the last comment. Did you have something new to bring to this aspect of the discussion? It feels like you're ignoring how I noted that this is but one option people are discussing, and using it as a reason why the whole thing is a bad idea. That doesn't make sense.
- pjmlp 6y ago
  Followed by Java, .NET (AOT compiled), and Swift, I would say. In fact it would be nice to have eBPF backends for them as well, naturally only possible for specific language subsets.

bsder 6y ago

> So the natural follow-up question to that concern, it seems to me, would be whether there's something in the existing C/GCC toolchain (or around it) that can resolve the raised concerns without adopting a whole new toolchain (Rust/LLVM) The answer to this question appears to be: no. Memory errors sit somewhere around 2/3 to 3/4 of errors irrespective of codebase when C is involved (this has been consistent in things like the Linux kernel as well as the Windows codebase). C++ hasn't seemed to have changed that, either. Remember, Rust IS Mozilla's answer to this question. > without having to extend the existing interface with language-specific suffixes like "kmalloc_for_rust". The requirement to do that is pointing out the that kernel API is poor and is too intimately tied to the build chain. We have seen this before--when Linux got ported to Alpha, for example. The point is to fix the API so that more languages than just Rust can be used. I suspect that more "system programming" languages may appear once Rust does the difficult groundwork of breaking this kind of intimate toolchain dependence. As things currently stand, why develop a system programming language given that no one will ever use it?

einpoklum 6y ago
> C++ hasn't seemed to have changed that, either. C++ is not like C. Putting some C++ objects in a C codebase would, indeed, not change it much, but if you write in modern C++, some memory errors will literally disappear, and some become less likely. Caveat: This is based on language mechanics, standard library facilities and recommended idioms; of course people can write unsafe C++ if they want to.
- bsder 6y ago
  > of course people can write unsafe C++ if they want to. The problem is knowing the safe subset of the language requires continuous study and deep understanding. It also has changed with time. I used to have a bookshelf in order to understand C++. I suspect that has not changed. I do not need a bookshelf to understand the "safe" subset of Rust.
  - einpoklum 6y ago
    You are partially correct but mostly incorrect, I would say. It's true that writing safe code requires some study and some understanding. But you don't need to "know what's safe". That _is_ complicated - there are a lot of complex depths to the language. The thing is, the non-expert user can avoid them. For example, a green developer can start with "Avoid using new and delete directly; use vectors, other containers, or unique_ptr's instead. Maybe shared_ptr's in some cases." If at some point they really need to write their own allocating class, they'll be told to be very careful with the allocation, and take into account the possibility of exceptions, concurrent execution by other threads etc. Also, when you're not sure of yourself, there's a good enough reference in the form of the C++ Core Guidelines [1]. (That's a long document, but you don't need to read through it.) Finally, a whole lot of memory error hazards / unsafe code can be statically identified and discouraged. Gradually, IDEs and other tools have started doing so. [1] - isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
- roca 6y ago
  And modern C++ features makes some memory errors more likely, e.g. dangling references from lambda captures and string_view/span. I'm not optimistic about the safety of modern C++. Most people who really care about safety long ago left the C++ building.

kbenson 6y ago

> But what are these benefits that other languages bring on the table? From the article it appears that proponents of the new toolchain mention memory-safety as the primary concern: Of the venn diagram of languages that provide more safety than C (and that is, either require it or make it hard to bypass), and languages that people know know or are likely to know in the semi-near future, Rust and Go are probably the big contenders. ATS may be easier to interface with the kernel in, but is random peripheral company writing a kernel module driver likely to know it and use it? Theoretically, everyone can write most or all of their modules in Coq, right? So why don't they? Why is ATS different? > So the natural follow-up question to that concern, it seems to me, would be whether there's something in the existing C/GCC toolchain (or around it) that can resolve the raised concerns without adopting a whole new toolchain (Rust/LLVM) You're mistaking the aims of a project to specifically adapt Rust to the linux kernel and what they focused on. This note is frm a Rust initiative, not a kernel initiative, why would they focus on doing something in a different language? > and without having to extend the existing interface with language-specific suffixes like "kmalloc_for_rust". I addressed this in the last comment. Did you have something new to bring to this aspect of the discussion? It feels like you're ignoring how I noted that this is but one option people are discussing, and using it as a reason why the whole thing is a bad idea. That doesn't make sense.

pjmlp 6y ago
Followed by Java, .NET (AOT compiled), and Swift, I would say. In fact it would be nice to have eBPF backends for them as well, naturally only possible for specific language subsets.