From what I understand, Rust is not making in-roads into the OpenBSD world for at least these reasons:

1) Rust's use of LLVM means it will not work on some hardware platforms that the OpenBSD folks are committed to run on.

2) The Rust project currently does not offer a long term support release.

These are important to the OpenBSD team. Additionally, I am sure that they value the memory safety that Rust offers.

I wonder if the OpenBSD team would ever design a systems language?

Note I said "BSD World" :) FreeBSD is already using LLVM (Clang) instead of GCC, and support fewer platforms - I think this would be a more pragmatic place to push something new like Rust.

If it works out there, OpenBSD could audit and import things at their leisure, at least in theory.

Why didn't they just use Ada then? Ada have been long before Rust and is a good alternative to C.

I have hopes for Rust, too, in this space. They're making a lot of good design decisions to balance safety & performance. Far as Heartbleed, that sort of thing can be detected using techniques from "information flow control security." Essentially, the programmer labels resources in terms of confidentiality and integrity. The type system, compiler, whatever checks them against a security policy. So, a variable containing confidential data shouldn't be accessed by functionality sending data to public sources.

Here's an example from one of the leading groups in the field:

http://www.cs.cornell.edu/jif/

That was turned into SIF, Swift, Fabric, and I think Civitas voting system. Swift even auto-partitions the system between client and server side while maintaining confidentiality/integrity policies. Fabric kicks butt on all kinds of issues in the hardest space of them all. So, given the above, I'm sure a problem like Heartbleed in a mere SSL protocol would be trivial to prevent at language level if software and compiler developers merely chose to adopt info-flow security at least for important projects.

Note: One can use stuff like that even if not supported in main tool set by creating a mock-up of software in supporting toolset. The abstraction gap presents issues but a problem in one might mean problem in other. Especially for what amounts to covert channel analysis of software.

What tedunangst says is true enough in the logical sense, but it makes me nervous in the human sense. Humans seem prone to the following logic failure:

    1. Object X frequently removes limbs from the user.
    2. Object Y does the same thing, but more safely.
    3. Wait, Object Y causes hangnails if you misuse it hard enough.
    4. It's OK to keep using Object X!

Like many fallacies, this doesn't survive being clearly written out, but I still see it an awful lot.

I don't know, I think it's a pretty fair treatment - there are links to an advisory that Ted thinks Rust could have prevented (http://www.x.org/wiki/Development/Security/Advisory-2015-02-...) and to a blog post disagreeing with his http://tonyarcieri.com/would-rust-have-prevented-heartbleed-...

I am saying tedunangst's treatment is fair. What I don't like is what people in general tend to do with the argument. I am not claiming tedunangst is doing that with the argument.