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

51–60 of 112 posts

Re: Building on Rock, Not Sand

#51

Post by Quarrelsome »

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.

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.

Re: Building on Rock, Not Sand

#52

Post by tonyg »

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.

You write that the claim is (A) "there exists a compiler X that always produces safe code", but then argue against (B) "C++ always produces unsafe code". To argue against claim A, you have to show that some "compiler X" that always produces safe code cannot exist.

Re: Building on Rock, Not Sand

#53

Post by chrismorgan »

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…

Concerning Rust specifically—Rust’s memory safety comes from its type system; specifically, its strong ownership model, which leads to its lifetime model. Without these, you simply can’t have a fast, memory-safe language: either you surrender speed, by boxing everything, or you surrender safety.

My point is that it’s not possible to just isolate the hazardous chunks into a well-tested core; it needs to be pervasive in the language’s memory model and type system in a way that C and C++ just don’t have.

Re: Building on Rock, Not Sand

#54

Post by blub »

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.

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.

Re: Building on Rock, Not Sand

#55

Post by Quarrelsome »

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.

What part of:

> I'm asking because my own gut estimate of the cost of automatic memory management is significantly higher.

Is reasonable and not dripping with bias? My gut estimate says it doesn't matter in many cases. So where does that leave us?

Re: Building on Rock, Not Sand

#56

Post by weberc2 »

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?

Re: Building on Rock, Not Sand

#57

Post by chrismorgan »

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 negligence.

Re: Building on Rock, Not Sand

#58

Post by jabot »

sanxiyn wrote: post #22
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...

Well, you aren't directly writing C anyway. Unless you are https://xkcd.com/378/ -- using tools is perfectly okay. Anyway, PolarSSL is definitely not transpiled. Its source language is C.

http://www.cvedetails.com/vulnerability-list/vendor_id-12001...

... and your point is?

EDIT: more recent bugs:

https://tls.mbed.org/security

These bugs include double-free and use-after-free - which are not covered by the original analysis, right?

Re: Building on Rock, Not Sand

#59

Post by blub »

Quarrelsome wrote: post #55
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.

What part of: > I'm asking because my own gut estimate of the cost of automatic memory management is significantly higher. Is reasonable and not dripping with bias? My gut estimate says it doesn't matter in many cases. So where does that leave us?

I said it's a legitimate question to ask, not that their stated reason for asking is legitimate and I stand by what I said.

Re: Building on Rock, Not Sand

#60

Post by chrismorgan »

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 garbage collected types (the @ sigil), and steadily settled down to its current model, which requires strong ownership to make it memory-safe and references + lifetimes to make it useful (otherwise you have a straightforward linear type system, which while functional is not very useful for fast code—you need references for that!).

The hard part of Rust is strongly tied to ownership and lifetimes. You can’t get rid of them and keep memory safety without introducing garbage collection on at least almost everything. And thus you’re roughly at Go.

Post reply on HN