Hacker News new | ask | show | jobs
by youdontknowtho 3452 days ago
Captain Obvious here with a public service announcement:

Rust's safety guarantees dont extend to logic or protocol implementation problems or misconfigured security settings.the part of the article about service providers leaking creds or other info...Rust all the things and that will still happen.

Some of this stuff is just too much. Also, why not work on lifetime and memory safety in a c based language? Rust looks like Klingon to me. functional-ish-ness is really hot right now. (Like Hansel.)

There's this really sophomoric theme that this seems to be a part of that keeps resurfacing here. its almost like a conspiracy of influences made the wrong tech choice in the past and everything would be ok now if we used X. Where X could be haskell, rust, os2, plan 9, lisp, lisp, lisp, go...theres quite a few saviors out there they resurface every now and again.

2 comments

There are ways to prevent some logic/protocol problems at the type level using rust:

https://hoverbear.org/2016/10/12/rust-state-machine-pattern/

https://blog.tarn-vedra.de/posts/phantom-types-for-safe-apis...

https://insanitybit.github.io/2016/05/30/beyond-memory-safet...

https://scribbles.pascalhertleif.de/elegant-apis-in-rust.htm...

Some libraries use such features to prevent certain kinds of nonce-reuse during encryption (one of the more common ways of screwing up encryption). These constraints are checked at compile-time.

Such guarantees are not possible with weaker type systems like that of C.

I get what you are saying. "Software's Salvation" might require more than compile time type checking.

I'm a huge strong typing fan! I'm just saying, type systems can get you a long way toward correct construction. (Or correctness by construction...) The issues with the software/computing world are bigger than array bounds checking and type correctness.

> The issues with the software/computing world are bigger than array bounds checking and type correctness.

Annoyingly, these bugs still bring down our systems in an age when we're on the verge of self-driving cars. Can you imagine that? Your car can crash because somewhere a programmer messed up a simple bounds check.

By removing the possibility of these small annoying bugs, you leave the programmer free to focus on the big picture. That is the entire point of abstraction, and a language which strives to provide these abstractions at no cost to performance is inherently better than one that

a) doesn't provide these abstractions

b) doesn't provide mechanisms to handle the unabstracted layer safely.

Again, I get where you are going with this.

Rust isn't the only solution. There are mechanisms that can be used in C++ to make a program memory safe by construction. I'm not even saying that Rust isn't a good solution. (I am saying I don't like the syntax...I'm sure I could get used to it at some point.)

I just get very wary when something has this kind of "evangelism" behind it. That's all. I'm really looking forward to seeing what Mozilla does in Firefox with it.

The disconnect you two have is that C++ doesn't force you to always use those safety features. Furthermore due to reasons that are entirely non non-technical in nature will never force you to use them. The reason Rust exists is to solve that problem and the result is that an entire set of bugs, that have plagued developers in the target C++ domain for ages, are literally impossible.

ADT's have been known to be a superior way to express state machines for ages but C++ for both technical and non-technical reasons will never actually get them. Rust solves this problem by starting over.

Would you mind sharing other "correct by construction" ideas/references/libraries you know ?
I was mainly talking about the C++ Guideline Support Library and GSL profile "checkers" that have been in process for the last couple of years.

https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-core-gu...

https://github.com/Microsoft/GSL

https://www.youtube.com/watch?v=JfmTagWcqoE

dont forget microkernels.