Integrating “safe” languages into OpenBSD?
I have spent a long time using alternative languages.  I&#x27;m a compiler geek.  However, most of these languages ultimately lead to disappointment.  Not because they necessarily fail, but rather because the problem of writing software is not a problem of language or platform.  It is a problem of thought and abstraction.  So, the big promises that these new languages and platforms make will ultimately only be fulfilled for a subset of applications.  The rest of the time, we must still trudge through the process of good design, good testing, and good real-world feedback.<p>People love to beat up on C, because it does not have feature X or feature Y, and because there is plenty of bad C software to point at.  However, it isn&#x27;t the language that leads to bad software.  Any entrenched popular language has plenty of bad software examples, and plenty of security vulnerabilities.  The problem isn&#x27;t the language, but rather, the developer.  A good developer who understands and appreciates the problem can write good software in machine code, C, C++, Rust, Java, Haskell, C#, Go, D, or any other language or platform.  A good developer who understands secure programming processes can write secure software in any of these languages, given enough time.<p>What these higher-level languages offer is better abstraction, which can make time-to-market faster.  However, in a deeply entrenched system that is already in market, maintaining the current languages and platforms is typically the better play.  This is especially true when the source code is as meticulously maintained as it is with OpenBSD.  Someone who understands the basics of C can easily read the OpenBSD kernel or userland, and understand everything about how a given program works.  Some knowledge of BSD Make, Bourne shell, Korn shell, and Perl may be required to understand the init scripts  and build process, but in all, it is a system that is easy to understand, easy to maintain, and with an excellent development process in place to deliver two builds a year.  OpenBSD isn&#x27;t broke, and a new language isn&#x27;t going to fix it.<p>That being said, there are tools that the OpenBSD team could use that neither impact the build time nor require adopting fad language of the week.  There are excellent model checkers out there for C, and quite a few proof assistants are gaining the ability to check proofs on C code directly, using Separation Logic and Hoare triplets.  These tools can complement an entrenched C system by providing an external mechanism of verification that allows designers to formally verify that implementation meets specification.  While formally verifying all of OpenBSD would be a tall order, taking hundreds of man years, formally verifying critical pieces of the kernel and creating simplified contract boundaries for the remaining code would be an excellent complement to the code review process that the OpenBSD team already does.  Better still, it is something that could pay off without reinventing OpenBSD to match the current fad, as such verification can be run independently of the standard build process.  If I were to make a suggestion to the OpenBSD team, it would be to explore such tools.  But, to de Raadt&#x27;s point, such a suggestion would only be valid if someone did the heavy lifting to put such a tool in place, and if it were of utility to the team.  They won&#x27;t adopt something for the sake of that thing, but they are keen for anything that can practically improve the security of their system.