Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building on Rock, Not Sand

robert.ocallahan.org

Post reply on HN
Print view View original

81–90 of 112 posts

Re: Building on Rock, Not Sand

#81

Post by zeveb »

petiepooo wrote: post #8

Another rust proponent lecturing the world on how they should rewrite everything in rust. yawn

Someone who has something which is indeed better and knows it will believe everything should be rewritten thus; someone who has something which is middling or worse but believes it to be better will think the same thing.

The interesting question is not whether or not the author is a Rust proponent; it's whether or not Rust is an improvement on C. As neither a C nor a Rust programmer, it appears to me that the answer is unequivocally 'yes' — and this despite the fact that Rust is roughly as intelligible as Mandarin to me.

Re: Building on Rock, Not Sand

#82

Post by pcwalton »

duneroadrunner wrote: post #47
sanxiyn wrote: post #17

Note that you can write safe C code. seL4 is written in C! (And verified in Isabelle.) If that is too hard core, PolarSSL is a normal looking C code, which still has been proved to lack any buffer overflow. https://trust-in-soft.com/polarssl-verification-kit/ has details. On the other hand, it probably is less effort to rewrite PolarSSL in Rust than doing that proof.

> On the other hand, it probably is less effort to rewrite PolarSSL in Rust than doing that proof. It's probably even less effort to convert to SaferCPlusPlus[1] (essentially a memory-safe subset of C++). There's even an tool[2] (under construction, but functional) to do a lot of the conversion for you. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus [2] https://github.com/duneroadrunner/SaferCPl…

SaferCPlusPlus is not memory safe, according to your documentation.

For one thing, the "this" pointer problem is pretty much unsolvable in C++.

Re: Building on Rock, Not Sand

#83

Post by nine_k »

agumonkey wrote: post #48
jabot wrote: post #20

Earlier quoted context omitted.

I think the seL4 kernel rather proves that you can write safe haskell, verify it, and then transpile that to C. That's different from directly writing C...

in the end the idea is that if you are semantic aware, then everything is safe; it's just operations from exp -> env -> store to env -> store etc etc

Indeed! You can write safe programs for e.g. the original Turing Machine.

But I bet you'll end up writing tools to make creating a safe program of any non-trivial size feasible. A large class of these tools is usually called "programming languages".

Re: Building on Rock, Not Sand

#84

Post by pcwalton »

xelxebar wrote: post #35

I'm always confused by the "safe language" evangelism. Reducing cognitive load is a Good Thing TM; I get that. But aren't we just trusting the Rust compiler and JVM to not have subtle bugs that introduce memory management errors into our programs? Centralizing the memory management code to some well tested core---like the Rust compiler or some C lib---sounds to be the crux of wiring memory safe code, not the language…

> But aren't we just trusting the Rust compiler and JVM to not have subtle bugs that introduce memory management errors into our programs?

Empirically, programs written in memory-safe languages produce multiple orders of magnitude fewer memory-related bugs than C and C++ codebases do.

> Centralizing the memory management code to some well tested core---like the Rust compiler or some C lib

That isn't practical in C (or in C++). "Memory management" here means "pointers", and you can't program in C or C++ without pointers.

Re: Building on Rock, Not Sand

#85

Post by Chris2048 »

titzer wrote: post #31
Nokinside wrote: post #24

If someone thinks that compiler for their favorite programming language provides safety they have no idea what safe code is. C/C++ is used to write safe code for medical and aerospace applications every day. The compiler for the languages like C, C++, Ada, Rust or whatever, is not enough. You can get better static and dynamic code analysis and test coverage analysis tools for C/C++/Ada than you can for Rust.

> C/C++ is used to write safe code for medical and aerospace applications every day. Crack is smoked by humans every day. This is an Argumentum ad Populum ( https://web.cn.edu/kwheeler/fallacies_list.html ). And I dispute the statement anyway; what is "safe" code without a guarantee of memory safety?

It's actually appeal to authority. "Populum" appeals to the general populace, not specific industries. The people who smoke crack are not highly regarded.

Re: Building on Rock, Not Sand

#86

Post by pcwalton »

blub wrote: post #73
jlg23 wrote: post #70

Earlier quoted context omitted.

> C/C++ is used to write safe code for medical and aerospace applications every day. How comes we still catch lots of errors in reviews there? How comes that the best paying gigs for c/c++ coders are all code review? Best practices and an excellent toolchain don't help if they are not used. A compiler/language that enforces those is a giant leap forward. > You can get better static and dynamic code analysis and test…

What makes you think that a team which doesn't follow practices or uses their excellent toolchain will use Rust properly (without unsafe at any step) or even at all? Not sure what you mean about code review. Security reviews? I guess that's because C and C++ are easy to misuse and most programmers, teams and companies aren't that good at writing correct or safe code. But we already knew that and the solution is not a…

> What makes you think that a team which doesn't follow practices or uses their excellent toolchain will use Rust properly (without unsafe at any step) or even at all?

Rust tends to push you away from using unsafe all the time. Unsafe is a pain to use, because you don't have all the nice pointer operators you do in C and C++, so programmers naturally default toward working in the safe language. Even if you use unsafe more than you should, Rust tends toward much safer code than C and C++ in the aggregate. (This has been observed empirically.)

> I guess that's because C and C++ are easy to misuse and most programmers, teams and companies aren't that good at writing correct or safe code.

If you replace "most" with "virtually every" (i.e. everyone who isn't writing avionics/defense/aerospace/etc. code), I agree.

> But we already knew that and the solution is not as easy as switching to a different programming language.

Programs written in C and C++ empirically have far more memory safety related problems than programs written in memory safe languages do.

Re: Building on Rock, Not Sand

#87

Post by harveywi »

jeremysalwen wrote: post #4

If you really want to build on "rock", check out Bedrock: http://plv.csail.mit.edu/bedrock/ . Don't just prove your program is memory safe, prove it satisfies arbitrary properties! (A bit tongue in cheek, but the tools are really cool). Check out http://adam.chlipala.net/cpdt/cpdt.pdf for a nice introduction.

I would love to see an experience report of someone who has used Bedrock in a nontrivial application.

Re: Building on Rock, Not Sand

#88

Post by elevensies »

pjc50 wrote: post #68
dsign wrote: post #2

We run high-load web services in something-other-than-c with managed memory and checked array access. It is native, 8/9 as fast as C, and it works. We will never have the budget to pay for the additional 1/9th that C would afford us, in terms of security concerns. Yet, everyday, I have to field questions about why our low-level, network-facing system code is not written in C... old prejudices die hard.

> why our low-level, network-facing system code is not written in C Really I think these days, in fact since the Morris Worm, people should be asking the opposite question: why is network-facing code written in C given that almost any error can lead to an exploitable security compromise? I do not buy the performance argument at all any more. So few systems are really performance-constrained by network processing (usu…

Watching Heartbleed and Cloudbleed happen really drove it home for me. Given that routine programming errors can cause private data to be transmitted unintentionally, I have to question the sanity of writing networking software handling private data in C.

Re: Building on Rock, Not Sand

#89

Post by blub »

nine_k wrote: post #80
blub wrote: post #54

Earlier quoted context omitted.

Some managed languages can have pretty good performance, but at significant memory usage cost. Performance is not a single dimension. It's a very legitimate question to ask how it was measured. Obviously they're happy with their performance and we can't comment on that, but the other claims regarding speed vs. C were more general.

Look at the cost equation. Whatever additional resources they need to spend is a payment for improved safety / security. It's like saying that a reinforced door with a lock is more expensive and heavy than a regular cardboard-and-planks one, and is slower to open. It is! But is has other advantages, not attainable otherwise.

By managed languages I understand memory managed, aka GC languages.

It's not correct to say that they use additional resources to provide memory safety or security.

Python for instance uses additional resources because it simply doesn't have a performant implementation and Java uses additional memory to gain execution speed.

Swift and Rust are memory safe, but don't need a GC, so those memory safety advantages are in fact attainable otherwise.

Re: Building on Rock, Not Sand

#90

Post by s_kilk »

weberc2 wrote: post #56
dsign wrote: post #2

We run high-load web services in something-other-than-c with managed memory and checked array access. It is native, 8/9 as fast as C, and it works. We will never have the budget to pay for the additional 1/9th that C would afford us, in terms of security concerns. Yet, everyday, I have to field questions about why our low-level, network-facing system code is not written in C... old prejudices die hard.

Can I ask what it is?

My money's on Go.
Post reply on HN