3 ms·
The problem with this sort of analysis is that they are discussing improvements to average commercial software, but, from a security perspective, average commer
by Veserv 5y ago
The problem with this sort of analysis is that they are discussing improvements to average commercial software, but, from a security perspective, average commercial software is atrociously terrible and grossly inadequate in any non-trivial security context. To achieve a game-changing reduction in the total number of vulnerabilities and make them barely adequate would require improvements on the order of 10 to 100 times. A mere 100% improvement does not even move the needle when you need to improve by 10,000% to get to acceptable. It is far more reasonable to look at the existing security-critical systems and designs that already achieved outcomes 100 times better than average commercial software such as those certified to Orange Book A1 and identifying the high ROI improvements that can be cost-effectively retrofit to lower security designs. This is far more likely to result in good outcome than stacking 30% improvements onto a completely inadequate foundation in much the same way it would be easier to retrofit a luxury car design to create a cheap car than to enhance a go-kart design.
- pjmlp 5y agoAverage commercial software is what 99% of developers get to write, the amount of places for the mythical elite 10X developers that always do everything perfect is very tiny.
- mamcx 5y agoI work in this space, and agree with "average commercial software is atrociously terrible and grossly inadequate" not just in security but any metric you can think off. However, this is the thing: A lot of security is related to improve in how deal with your inputs/outputs. And a lot of how you improve that is to make better designs in your classes/structs/enums/functions/etc. In a language like Rust, people think the "borrow checker" is the only(major?) reason of the improvements, but working in this niche, just the fact I must model everything in terms of structs/enums/traits have "fixed" tons of stuff without even trying. And I get for free faster execution and half-resource consumption (or less!) that lower the bills! Yes, still need to worry about security and safety, but the internals get nearly fixed by consequence of the design choices of Rust. For me, the borrow checker is a small thing in the whole picture, and is instead the rest that pay off much more ROI.
- hollerith 5y ago>people think the "borrow checker" is the only(major?) reason of the improvements, but working in this niche, just the fact I must model everything in terms of structs/enums/traits have "fixed" tons of stuff without even trying. Sure, but Haskell had structs and enums (called algebraic data types) and traits (called type classes) (and pattern matching) in 1988, and even the people who think that Haskell should be used much more often than it is will concede that it is not sensible to use Haskell on many projects on which Rust would be a sensible choice (implementing a web browser, for example). In other words, there are probably good technical reasons you weren't using structs, enums, traits and pattern matching before the invention of the borrow checker.
- mamcx 5y agoI use F# before Rust, and find it much more approachable than Haskell. Somehow Haskell look pretty interesting (when I read long ago http://learnyouahaskell.com http://learnyouahaskell.com yet unable to figure how use it, when with F# was almost immediate. Is like how I get Vue yet not Angular... And in the case of Rust, it fit even better than F# (to me). I write "better" functional code in Rust than in F#, and the fact I can easily do small imperative code here and there is a big plus. Anyway, I know most features of Rust are not innovative per se, but find the way is mixed pretty easy to grasp.