<story><title>Preventing heartbleed bugs with safe programming languages</title><url>http://bluishcoder.co.nz/2014/04/11/preventing-heartbleed-bugs-with-safe-languages.html</url></story><parent_chain><item><author>djjaxe</author><text>Speed or security?... Age old question.</text></item><item><author>Scramblejams</author><text>We really need to stop writing network code in unsafe languages, period.</text></item></parent_chain><comment><author>kilburn</author><text>If you are speaking about &lt;i&gt;execution&lt;/i&gt; speed, you got the idea wrong. From a quote in the article:&lt;p&gt;&amp;gt; If you use the high level typing stuff coding is a lot more work and requires more thinking, [...] (but) you can even hope for &lt;i&gt;better&lt;/i&gt; performance than C by elision of run time checks otherwise considered mandatory, due to proof of correctness from the type system. Expect over 50% of your code to be such proofs in critical software and probably 90% of your brain power to go into constructing them rather than just implementing the algorithm. It&amp;#x27;s a paradigm shift.&lt;p&gt;The idea is to formally prove that the code is not doing unexpected things. The process is relatively simple to understand:&lt;p&gt;First you define the assumptions you make about the program, its execution environment, and the acceptable&amp;#x2F;expected results of your program. This is known as &amp;quot;formal specification&amp;quot; of the program. It is a critical part. If your specification is wrong, then the whole approach breaks down. However, this part should be &lt;i&gt;much&lt;/i&gt; smaller than your whole codebase, and hence you can be extra careful on it.&lt;p&gt;Next, using this specification, you write proofs showing that the code &lt;i&gt;can not&lt;/i&gt; do anything unintended (such as accessing a buffer out of its valid range). The compiler goes through this proofs and checks that everything is provably correct (according to the specification). Then it can generate code without runtime checks that you would otherwise probably implement, because it is &lt;i&gt;sure&lt;/i&gt; that certain things cannot happen. As a result, the code may end up being actually faster.&lt;p&gt;Although a bit involved, the idea should be pretty intuitive. It is exactly what you are doing in your mind when programming. The main differences are:&lt;p&gt;1. We humans are pretty comfortable working with inexact and&amp;#x2F;or incomplete specifications. Then some undefined behavior happens, and our programs bug out. For instance, it is very easy for us to think about the division operator as something that always yields a value, ignoring the &amp;quot;division by zero&amp;quot; edge case. Computers are not, and force you to specify what exactly should happen when you encounter such edge cases.&lt;p&gt;2. We are also pretty bad at exhaustively checking every possibility, whereas computers excel at it. With the help of human-written proofs, obviously (otherwise verifying a program would involve checking every possible input for it, which is obviously intractable).&lt;p&gt;TL;DR: The tradeoff here is between &lt;i&gt;development&lt;/i&gt; and &lt;i&gt;compilation&lt;/i&gt; speed versus &lt;i&gt;correctness&lt;/i&gt;, which implies improved security &lt;i&gt;and&lt;/i&gt; execution speed.</text></comment>
<story><title>Preventing heartbleed bugs with safe programming languages</title><url>http://bluishcoder.co.nz/2014/04/11/preventing-heartbleed-bugs-with-safe-languages.html</url></story><parent_chain><item><author>djjaxe</author><text>Speed or security?... Age old question.</text></item><item><author>Scramblejams</author><text>We really need to stop writing network code in unsafe languages, period.</text></item></parent_chain><comment><author>ohazi</author><text>Both!&lt;p&gt;&lt;a href=&quot;http://rust-lang.org/&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;rust-lang.org&amp;#x2F;&lt;/a&gt;</text></comment>