5 ms·

Or perhaps he made a more subtle point: you can't replace all C with Rust. Even if you rewrite the libc (you'll need some assembly), even if you rewrite the ker

by ploxiln 11y ago

Or perhaps he made a more subtle point: you can't replace all C with Rust. Even if you rewrite the libc (you'll need some assembly), even if you rewrite the kernel (you'll need a lot of assembly and "unsafe"), there will still be lots of closed-source C running on undocumented components of your computer as firmware. C is just representative of computers as they really are today, for a bunch of reasons (mostly pragmatism) unrelated to the fact that some people still like C. Just as an ironic aside - C enthusiasts may even have switched to musl-libc already, and are not affected by bugs in glibc, while rust-loving people are vulnerable! Also interesting, Go has for a long time supported using its own dns resolver instead of libc, but only recently in go 1.5 uses the go dns resolver by default on unix systems.

steveklabnik 11y ago
We also provide builds of a MUSL-enabled rustc, if that's your thing.
tkinom 11y ago
Agree. "C" to OS, Kernel, Computer Language, applications is like oxygen is to life on earth. Yes, O2 causes fire from time to time, but you can't live without it.
- cbd1984 11y ago
  Do you know of a language called "C", as opposed to C?
- cbd1984 11y ago
  > "C" to OS There's the solution! Replace C with "C", a garbage-collected version of C! The quotes mean it's safe! /s
- cbd1984 11y ago
  I say we should write it in "Rust", as opposed to Rust.
- dh997 11y ago
  The analogy is wrong because most all languages are Turing complete, and therefore equivalent despite paradigm and feature differences. The main reason seL4 was written in Haskell and again in C was to cross-verify behavior. C might be legacy ubiquitous, however it doesn't have to be the last word in shared library development by any means. Any language which has a toolchain which produce flat binaries or use link scripts to specify sections can potentially be used for kernel and os dev. Bonus points for a toolchain which can compile itself. There are kernels written entirely in Rust with some assembly glue. Others are writing production embedded domain-specific OSes in Haskell, OCaml, etc. for real, mission-critical systems right now and have been doing so for the last 5-10 years. C inherently or inadvertently leads to giant codebases and subtle bugs when used too liberally, as opposed to higher-level, statically-compiled languages like Haskell and others. The main issue with legacy code is how we choose to either keep investing effort in putting fingers into the levees or try something new in an incremental fashion. PS: I would like to see Go get with it and support non-usermode, self-hosted and embedded development without including a giant, hard-to-port runtime in everything.
  - cyphar 11y ago
    > The main reason seL4 was written in Haskell and again in C was to cross-verify behavior. seL4 was modeled in Haskell, then written in C. Then they used tools to verify that the Haskell models matched the C code.
mkj 11y ago
musl isn't without resolver bugs either. http://www.openwall.com/lists/oss-security/2015/03/30/3 http://www.openwall.com/lists/oss-security/2015/03/30/3
viraptor 11y ago
Are you arguing that since we can't replace everything with safe code, we shouldn't replace most of it? Security is not a binary state. Even taking firmware into account, if you compare the number of CVEs affecting "normal code" and firmware, the choice is trivial.
- ptaipale 11y ago
  > Are you arguing that since we can't replace everything with safe code, we shouldn't replace most of it? Well, yes, the effort to replace even a small part of current code base with something perceived as "safe code" is huge. The re-factoring effort is so great that there is no doubt a significant number of new seurity problems wouldn't be created. They would of course be different kind of problems. Not indexing errors, perhaps, but something we don't even know about. And justifiying this very large cost is not so easy.
agumonkey 11y ago
Good point, we shouldn't be dogmatic but pragmatic. But there's a fallacy conveyed by seeing C idioms as the only low level ones.

by ploxiln 11y ago

steveklabnik 11y ago

We also provide builds of a MUSL-enabled rustc, if that's your thing.

tkinom 11y ago

Agree. "C" to OS, Kernel, Computer Language, applications is like oxygen is to life on earth. Yes, O2 causes fire from time to time, but you can't live without it.

cbd1984 11y ago
Do you know of a language called "C", as opposed to C?
cbd1984 11y ago
> "C" to OS There's the solution! Replace C with "C", a garbage-collected version of C! The quotes mean it's safe! /s
cbd1984 11y ago
I say we should write it in "Rust", as opposed to Rust.
dh997 11y ago
The analogy is wrong because most all languages are Turing complete, and therefore equivalent despite paradigm and feature differences. The main reason seL4 was written in Haskell and again in C was to cross-verify behavior. C might be legacy ubiquitous, however it doesn't have to be the last word in shared library development by any means. Any language which has a toolchain which produce flat binaries or use link scripts to specify sections can potentially be used for kernel and os dev. Bonus points for a toolchain which can compile itself. There are kernels written entirely in Rust with some assembly glue. Others are writing production embedded domain-specific OSes in Haskell, OCaml, etc. for real, mission-critical systems right now and have been doing so for the last 5-10 years. C inherently or inadvertently leads to giant codebases and subtle bugs when used too liberally, as opposed to higher-level, statically-compiled languages like Haskell and others. The main issue with legacy code is how we choose to either keep investing effort in putting fingers into the levees or try something new in an incremental fashion. PS: I would like to see Go get with it and support non-usermode, self-hosted and embedded development without including a giant, hard-to-port runtime in everything.
- cyphar 11y ago
  > The main reason seL4 was written in Haskell and again in C was to cross-verify behavior. seL4 was modeled in Haskell, then written in C. Then they used tools to verify that the Haskell models matched the C code.

mkj 11y ago

musl isn't without resolver bugs either. http://www.openwall.com/lists/oss-security/2015/03/30/3 http://www.openwall.com/lists/oss-security/2015/03/30/3

viraptor 11y ago

Are you arguing that since we can't replace everything with safe code, we shouldn't replace most of it? Security is not a binary state. Even taking firmware into account, if you compare the number of CVEs affecting "normal code" and firmware, the choice is trivial.

ptaipale 11y ago
> Are you arguing that since we can't replace everything with safe code, we shouldn't replace most of it? Well, yes, the effort to replace even a small part of current code base with something perceived as "safe code" is huge. The re-factoring effort is so great that there is no doubt a significant number of new seurity problems wouldn't be created. They would of course be different kind of problems. Not indexing errors, perhaps, but something we don't even know about. And justifiying this very large cost is not so easy.

agumonkey 11y ago

Good point, we shouldn't be dogmatic but pragmatic. But there's a fallacy conveyed by seeing C idioms as the only low level ones.