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

101–110 of 112 posts

Re: Building on Rock, Not Sand

#101

Post by pmontra »

sanxiyn wrote: post #18
pmontra wrote: post #13

Nothing comes for free. I expect to have to trade something for security. It seems we have to trade speed and size. Ok, it shouldn't matter to us: this should not be developers' call. Instead it should go into a costs benefit matrix with plenty of other technical and not technical stuff. Developers will advise on their part of the matrix, marketers on their own, etc. Managers will make the decision and be held respon…

> It seems we have to trade speed and size. Why do you think so?

I might be wrong but it seems that the new safer languages don't run as fast as C and create larger binaries. But that's OK if safety is valued more than speed and size.

Re: Building on Rock, Not Sand

#102

Post by roca »

wahern wrote: post #100
pcwalton wrote: post #95

Earlier quoted context omitted.

> Rust solves this for buffer overflows, but nothing else. It's a one trick pony. Completely false. Rust's design prevents all memory safety problems (that's what "memory safe" means). Buffer overflows aren't even the most pernicious kinds of memory safety problems anymore. Use after free is worse, and Rust spends most of its complexity budget on preventing that.

I spoke poorly. My point was that memory safety is but _one_ issue of a far larger problem. And Rust indeed solves it, or at least Rust provides an ergonomic environment for writing solutions that are memory safe. Which is different than saying it's easy to do this in an absolute sense. But certainly writing a program in Rust without using unsafe{} at all is still easier and more ergonomic than using other systems (e…

Full verification is extremely expensive, not just to create the proofs, but also to maintain them as the software evolves. Telling C programmers to go directly to full verification is, indeed, making the perfect the enemy of the good.

And you are missing an important point here. Once you have a reasonably sound and rich type system, you can leverage the type system in library API design to eliminate classes of higher-level bugs. For example, Rust crypto libraries can leverage Rust's affine type system to ensure you don't use a nonce more than once. The Apache Struts vulnerability was about failing to distinguish trusted vs untrusted input; that distinction can be expressed and checked in type systems.

Re: Building on Rock, Not Sand

#103

Post by roca »

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.

That safety-critical C/C++ code tends to be brutally constrained. Typically dynamic memory allocation is not allowed. It's also very expensive to write and verify. If that was the only way people were allowed to use C/C++, most programmers would migrate to Rust or whatever en-masse. I'm for it!

Re: Building on Rock, Not Sand

#104

Post by roca »

pmontra wrote: post #13

Nothing comes for free. I expect to have to trade something for security. It seems we have to trade speed and size. Ok, it shouldn't matter to us: this should not be developers' call. Instead it should go into a costs benefit matrix with plenty of other technical and not technical stuff. Developers will advise on their part of the matrix, marketers on their own, etc. Managers will make the decision and be held respon…

Unfortunately in the real world people are shortsighted and focus on immediate concerns like development velocity and performance at the expense of long-term concerns like latent vulnerabilities. Managers and developers who make these decisions today aren't going to still accountable when a critical bug is discovered in deployed code ten years later.

Re: Building on Rock, Not Sand

#105

Post by roca »

blub wrote: post #71
chrismorgan wrote: post #57

Earlier quoted context omitted.

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 w…

Hi!

Yeah I made a mistake once. It happens.

If having a PhD in computer science (programming languages), being reasonably smart, and using the language for 20 years (up to and including most C++14 stuff) doesn't make you an expert in that language, then your language is far too difficult.

In fact, C++ is far too difficult and there are very few genuine experts in it. For example, who can explain why using push_back on a vector> is not conformant to the Standard, without looking it up? (I'll save you some time: https://bugs.chromium.org/p/chromium/issues/detail?id=683729...)

There's also a definitional bait-and-switch going on here. C++ proponents use "C++" to mean "the language that lots of projects have been using for 20 years and lots of programmers know" when espousing its popularity. But when necessary, the meaning changes to some "'modern', 'safe' subset of C++" ... that few programmers know well and few projects stick to rigorously. The exact definition of that subset changes depending on the situation, too.

Re: Building on Rock, Not Sand

#106

Post by weberc2 »

rlonstein wrote: post #96
s_kilk wrote: post #90

Earlier quoted context omitted.

My money's on Go.

> My money's on Go. Based on submission history, I'd guess Haskell.

Seems like it would be hard to get Haskell to run 8/9 as fast as C. Haskell is much harder to reason about performance than Go or C, and it's pretty easy to make a seemingly innocuous change that slows your program dramatically.

Re: Building on Rock, Not Sand

#107

Post by tome »

weberc2 wrote: post #106
rlonstein wrote: post #96

Earlier quoted context omitted.

> My money's on Go. Based on submission history, I'd guess Haskell.

Seems like it would be hard to get Haskell to run 8/9 as fast as C. Haskell is much harder to reason about performance than Go or C, and it's pretty easy to make a seemingly innocuous change that slows your program dramatically.

> Seems like it would be hard to get Haskell to run 8/9 as fast as C.

The typical factor mentioned in the Haskell world is 1/2 the performance of C.

Re: Building on Rock, Not Sand

#108

Post by sanxiyn »

pmontra wrote: post #101
sanxiyn wrote: post #18

Earlier quoted context omitted.

> It seems we have to trade speed and size. Why do you think so?

I might be wrong but it seems that the new safer languages don't run as fast as C and create larger binaries. But that's OK if safety is valued more than speed and size.

You might be wrong. Rust is as fast as C and creates binaries as small as C.

Re: Building on Rock, Not Sand

#109

Post by blub »

roca wrote: post #105
blub wrote: post #71

Earlier quoted context omitted.

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 w…

Hi! Yeah I made a mistake once. It happens. If having a PhD in computer science (programming languages), being reasonably smart, and using the language for 20 years (up to and including most C++14 stuff) doesn't make you an expert in that language, then your language is far too difficult. In fact, C++ is far too difficult and there are very few genuine experts in it. For example, who can explain why using push_back o…

Hi. In the linked "confessions" blog you've taken the path of making some claims about a topic and supported them through who you are, instead of facts. People who disagree with your claims will question if who you are is relevant.

C++ is difficult, and there are few experts. My thesis is that one doesn't need to be an expert to write safe C++ code, but they do need access to quality libraries focused on safety, and good practices focused on safety. Banning some unsafe C functions, saying "use smart pointers" or making a list of UB is useful, but not enough.

C++ can be written much more safely than it normally is, but it seems that's not happening. I'm not sure why, it could be that the performance loss of additional runtime verification is not acceptable, that the adequate learning resources are not available or that it's not an important topic for the C++ community.

P.S: I'll gladly have the kind of error you linked to. It's at compile time, I will try to figure it out and worst case rewrite my code. UB is the problem.

Re: Building on Rock, Not Sand

#110

Post by xelxebar »

pcwalton wrote: post #84
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 (o…

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

This kind of emperically-driven motivation is great! Would you mind pointing me to some sources? My google-fu didn't immediately yield anything helpful.

Post reply on HN