There are safe languages that are similar enough to C that it is not hard to pick them up for a C programmer. I agree if the replacement is ML or Haskell. But e.g. Rust, Cyclone, or Go (if a GC is acceptable) are not going to be hard for most C programmers.

Also keep in mind that most of the "safe" languages depend on runtime which isn't written in a safe language.

Rust is almost runtime-less. The Go runtime is mostly Go since 1.4.

This is also true for C - there's some stuff in every C standard library that has to be written in asm, once for each supported platform.

I didn't say it's not going to be work :).

So you're just pushing the problem somewhere else. [...] So the bottom line is: there's always something underneath.

That does not mean that, say, Haskell is not tremendously much safer than C. First, because you only have to implement the icky parts once. Second, because a better type system and abolishment of undefined behaviour gives you more safety for a very small cost (if at all, the extra compile time for a better type system is probably negated by the cost of headers).

Rust is a very large language with an equally large set of standard library functions. It also requires changing how you structure your programs to work within the constraints of the borrow checker.

Rust also relies on LLVM, which has a limited set of target architectures when compared to C.

It's a much better replacement for C++ than C.

It's not about similarity, it's about differences. System code is all about subtleties in language, UBs in C for example. Just because Rust syntax is similar doesn't mean it can be easily picked up by a C dev.

"Rust is almost runtime-less."

Almost is the key. Even FAQ mentions that it's not suitable for low level code exactly because of its assumptions about how memory allocator works. You'd have to implement it. And you still assume that compiler output is flawless (which is very unlikely given Rust's age).

"I didn't say it's not going to be work :)"

But that's exactly what you're implying ;P "Oh come on, it can be done, why not?!" I'm giving you reasons why. These aren't superficial, I worked on OS, OS drivers, I'm currently working on hardware simulators. If your aim is safer systems, switching from C to Rust (which I happen to love) isn't the answer yet. And probably not for the next 10+ years.

"That does not mean that, say, Haskell is not tremendously much safer than C."

I'm not saying that there are no languages inherently safer than C. I'm saying that a) people can't switch just like that, b) familiar syntax isn't enough, c) legacy matters, d) there's always something that will still be "unsafe". As a pragmatic I'm claiming that you can spend time better than switching languages.

"First, because you only have to implement the icky parts once."

How is this not true in C?

"Second, because a better type system and abolishment of undefined behaviour gives you more safety for a very small cost (if at all, the extra compile time for a better type system is probably negated by the cost of headers)."

No, again, cost associated with new language is massive, especially if you care about quality.

There is no Rust or Go compiler for vax, alpha, macppc, sparc64. There are C/C++ compilers though.

Well, I think compilers for some of these architectures (e.g. VAX and Alpha) still exist in gcc largely because OpenBSD and NetBSD have put so much effort in keeping them alive (yes, I know that OpenBSD is using an older version). So, it's not as if you get C compilers for these platforms for free.

(Also, not really advocating the use of Go to replace C in operating system development, just wanted to make a note)

I'm curious as to what you're referring to here, with Rust. Could you elaborate?

My feeling though is that you need to be able to allocate memory to write code in Rust (duh!) and memory allocation is something that OS provides. So if you write OS in Rust... you get the idea. My understanding of Rust isn't deep enough to state whether you'd have to reimplement internals of Arc, Box and what not or you'd just have to provide something they piggy back on. But there's an explicit assumption in most of the code that you can allocate memory (in a thread safe fashion no less) which isn't there if you have no OS underneath.

That interface is super unstable at the moment, and we're working on stabilizing it, but yeah, that's what you'd have to do: write your own allocator and hook it up.

We do use gcc's unwinding library, last I recall, but if you're writing an OS, you can implement the language items to do whatever you want, including just abort.

There's no inherent TLS implementation that I'm aware of.

(If you're arguing that drivers will still need some inline assembly, well, yeah. But the assembly required for hardware interop is pretty straightforward, at least compared to code written in assembly for performance).

I'm not saying it can't in principle, I'm saying it would take years to get to a usable point. But then again - I wouldn't mind being wrong here! :]

"I'd be interesting in knowing what their thinking is as well."

OpenBSD is proudly exploiting quirks of various platforms to stress test the code and find cases where differences break the code and expose bugs. Change from C won't happen just because Rust is here to stay. Especially not until LLVM (and preferably musl) runs on most of the platforms OpenBSD runs on. the official stance for LLVM in general is that it'd have to get to the parity with gcc WRT platforms that OpenBSD finds interesting but reality is that a platform or two out of ~15 could be dropped if LLVM provided benefits over gcc. LTS compiler is something OpenBSD (and not only them) would appreciate greatly. But it's not going to happen, I'm afraid.