> 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

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