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

71–80 of 112 posts

Re: Building on Rock, Not Sand

#71

Post by blub »

chrismorgan wrote: post #57
petiepooo wrote: post #8

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

Robert is an expert C/C++ programmer, but understands the problems with those languages, which has led to articles like http://robert.ocallahan.org/2017/07/confession-of-cc-program... . Robert is now a Rust proponent because it works . From today’s article, I think this is the money quote: > My sincere hope is that people will at least stop choosing C for new projects. At this point, doing so is professional negligen…

I don't doubt they're a competent programmer, but I do have some doubts that they're an expert in C++. Two reasons why:

1) They made incorrect claims about C++ in relation to Rust before: http://robert.ocallahan.org/2017/02/what-rust-can-do-that-ot... and http://robert.ocallahan.org/2017/04/rust-optimizations-that-...

2) The Mozilla C++ code base is old and very raw pointer/reference heavy and it doesn't seem to be written with safety in mind.

Their wikis also don't have any particularly good security guidelines. Maybe the good stuff is kept private, who knows.

Saying that someone was a distinguished engineer at Mozilla is not saying much about their abilities of writing modern or safe C++.

Re: Building on Rock, Not Sand

#72

Post by blub »

bjz_ wrote: post #37
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…

Trouble is that in C there is no way to encapsulate the unsafe code. Rust has tools that let you do that - it's not perfect, but depending on the level you are working at you can even build operating systems like Redox with the majority of the code in safe Rust. The language has not been formally specified which is a concern, but this is an active area that is also being worked on in collaboration with universities.…

The ability to grep for "unsafe" is probably the biggest advantage of Rust. I would love to have that in C++.

Re: Building on Rock, Not Sand

#73

Post by blub »

jlg23 wrote: post #70
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. 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 as easy as switching to a different programming language.

Re: Building on Rock, Not Sand

#74

Post by blub »

sanxiyn wrote: post #29
blub wrote: post #23

Earlier quoted context omitted.

There are several safe dialects of C. The issue is that almost no one is using them and they're not about to start to either. A lot of infrastructure software has not been built with security in mind, but the game has changed, and this old C software is getting eviscerated. If one looks at the fixes for these buffer overflows in dnsmasq, no other conclusion can be drawn except that holes are plugged in a leaky sieve.…

I think PolarSSL showed it can be done with reasonable effort and it is not a suicide.

Correct me if I'm wrong, but is this Frama-C and ACSL? That doesn't look like plain C to me.

In the ACSL manual in Example 2.10, does the programmer have to add the asserts? What if they make a mistake in the annotation?

Re: Building on Rock, Not Sand

#76

Post by bjz_ »

bpicolo wrote: post #50
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.

Very formal sorts of languages are super interesting. They might tend towards striking the wrong balance, though. Rust is super interesting to me because it prevents the most common vulnerabilities w/regards to memory safety that show up time and again, but it's accessible enough that it's got a big community and a ton of high quality libraries. I think that's a pretty awesomely potent combination.

For the short term and mid term yes. However I do hope that in the long term the ideas from ATS, Liquid Haskell, Idris, F*, etc. will be iterated on in order to make them more accessible and usable. In the mean time we'll probably start to see Rust graft on more and more correctness tools like dependent types and SMT solvers, and it will begin to get a little ungainly, like dependently typed Haskell is. But there's only so many ideas you can try out in a new language, and Rust has made the right decisions on that front in the interests of getting into production this decade. :)

Re: Building on Rock, Not Sand

#77

Post by barrkel »

rixed wrote: post #49
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.

How do you mesure performance against C ? Did you implement a rival unsafe C version to compete with, or is this just a guess ? If so, what makes you believe C would only yield a 10% improvement? I'm asking because my own gut estimate of the cost of automatic memory management is significantly higher.

The performance loss vs C is in that ballpark; arguably it's sometimes less, because of increased flexibility in refactoring. A bigger issue is memory overhead, that's often 100% larger, and it's harder to avoid. But memory is cheap.

Re: Building on Rock, Not Sand

#78

Post by dsacco »

jlg23 wrote: post #70
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. 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…

> How comes that the best paying gigs for c/c++ coders are all code review?

This has not been my experience.

Re: Building on Rock, Not Sand

#80

Post by nine_k »

blub wrote: post #54
Quarrelsome wrote: post #51

Earlier quoted context omitted.

isn't this exactly the sort of line of questioning that the OP is complaining about? In my experience of managed software 99.9% of performance problems are due to stupids and 0.1% are due to marshalling and GC costs. An average unmanaged developer seems to assume the opposite.

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.

Post reply on HN