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

61–70 of 112 posts

Re: Building on Rock, Not Sand

#61

Post by jabot »

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.

I would really like to see a comparison of the efforts of a) writing a program in a safe language like rust and b) writing the language in C and verifying it with a toolset like the one used by the polarssl guys.

Given that the number of C projects that use similar toolsets is... low (?), I'd guess that said comparison would favor rust, but I'm prepared to be surprised :-)

Re: Building on Rock, Not Sand

#62

Post by weberc2 »

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…

Seems like it would be easier to audit and/or prove a compiler than all of the important software built from it.

Re: Building on Rock, Not Sand

#63

Post by bpicolo »

chrismorgan wrote: post #60
ryansama wrote: post #16

It would be nice to have more healthy competition in this space. Any suggestions? Would it not be great to have a language as powerful as Rust but with the ease of Go? Anyhow, must be like CAP. You can't have everything in a language.

When Mozilla first sponsored Rust, it was with the goal of being the fastest memory-safe language around; at the time, it was thought that that required garbage collection. Only later (2011 or so), with the application of some comparatively recent research, did it progressively become apparent that it was in fact possible to have a practical memory-safe language without garbage collection; Rust progressively lost its…

Happen to have a link to the research that relates to this? I've been trying to up my CS-paper-reading game.

Re: Building on Rock, Not Sand

#64

Post by chrismorgan »

bpicolo wrote: post #63
chrismorgan wrote: post #60

Earlier quoted context omitted.

When Mozilla first sponsored Rust, it was with the goal of being the fastest memory-safe language around; at the time, it was thought that that required garbage collection. Only later (2011 or so), with the application of some comparatively recent research, did it progressively become apparent that it was in fact possible to have a practical memory-safe language without garbage collection; Rust progressively lost its…

Happen to have a link to the research that relates to this? I've been trying to up my CS-paper-reading game.

A quick search based on certain keywords I remembered yields https://www.reddit.com/r/rust/comments/2d94tu/is_there_any_a... which may help. Regions is the key thing. But right now I’m going to bed.

Re: Building on Rock, Not Sand

#65

Post by thehardsphere »

Quarrelsome wrote: post #51
rixed wrote: post #49

Earlier quoted context omitted.

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.

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.

Then you may not be working in the same problem domain as the person who asked the question.

I mean, my experience is pretty much the same as yours, to the point where if someone blames the language for poor performance I'm immediately skeptical of the claim. But other cases do exist, is especially for problems that are CPU intensive.

Re: Building on Rock, Not Sand

#66

Post by petiepooo »

bsder wrote: post #19
petiepooo wrote: post #8

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

You might want to look up the fact that the author is a HEAVY FREAKIN' DUTY C++ PROGRAMMER before making uninformed whingeing. http://robert.ocallahan.org/2017/09/rr-50-released.html http://robert.ocallahan.org/2017/07/confession-of-cc-program...

The first link has no relevance to the discussion, and the second I had indeed read before posting. Need I point out that C++ IS NOT C. Being a good C++ programmer does not make you a good C programmer, and vis versa. I would argue, in fact, that many of the capabilities that a knowledgable, current C++ coder depends on would make them more liable to encounter issues coding in C, std::auto_ptr being chief among them.

Re: Building on Rock, Not Sand

#67

Post by bpicolo »

chrismorgan wrote: post #64
bpicolo wrote: post #63

Earlier quoted context omitted.

Happen to have a link to the research that relates to this? I've been trying to up my CS-paper-reading game.

A quick search based on certain keywords I remembered yields https://www.reddit.com/r/rust/comments/2d94tu/is_there_any_a... which may help. Regions is the key thing. But right now I’m going to bed.

Thanks :)

Re: Building on Rock, Not Sand

#68

Post by pjc50 »

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 (usually it's the network itself or the disk), you have to write horizontally scalable code anyway if you want to make use of multiple cores, so almost all cases where it's a bottleneck are more cheaply dealt with by scaling rather than tinkering with the software.

There are people doing HFT in Java. The managed languages are quite capable of great performance with a little effort and imagination.

Re: Building on Rock, Not Sand

#69

Post by rbehrends »

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.

10% is fairly typical overhead for mark-and-sweep GC for an imperative program. It requires artificially high allocations rates – that well-written imperative code shouldn't have – to go much higher than that.

The cost of array bound checks is generally negligible with a modern compiler/CPU and the speed/safety tradeoff is not even worth haggling over for any code that's exposed to the internet.

Re: Building on Rock, Not Sand

#70

Post by jlg23 »

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 coverage analysis tools for C/C++/Ada than you can for Rust.

Of course, but comparing the toolchain of a relatively new language with those of languages into which - literally - billions of dollar were put does only make a temporary point. And with lessons learned from those billions incorporated into the design of the new language, closing the gap will be much, much less expensive and time consuming than the initial development for the languages you mentioned.

Post reply on HN