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

How to not rewrite it in Rust

adventures.michaelfbryan.com

Post reply on HN
Print view View original

221–230 of 231 posts

Re: How to not rewrite it in Rust

#221

Post by kragen »

pron wrote: post #179
kragen wrote: post #175

Earlier quoted context omitted.

No, I'm talking about the Debian OpenSSL bug Luciano Bello discovered. It was a lot worse than Heartbleed. Kurt Roeckx didn't introduce Heartbleed, and Heartbleed wasn't introduced by removing undefined behavior, so there is no plausible reason for you to infer that I was talking about Heartbleed. As for the cost of rewrites, there's a lot of evidence from software project metrics that the cost of modifying software…

> so there is no plausible reason for you to infer that I was talking about Heartbleed. Except that Heartbleed is the only OpenSSL bug I've heard of :) Also, I don't know who Kurt Roeckx is. > there's a lot of evidence from software project metrics that the cost of modifying software can easily exceed the cost of rewriting it But we're not talking about arbitrary modification, but about, at worst, fixing undefined be…

I appreciate your clarification! Indeed, I didn't mean it was impossible to tell what any software would do in any situation, only some software (in practice, nearly all) in some situations. The contrary would imply that not only writing software but also running it would be impossible.

Your blog post looks very interesting indeed! I will read it with care.

I do think there's a subtle point about modifying software. Not just any modification of the software that lacks undefined behavior will do; we want a modification that preserves the important aspects of the original software’s behavior. Not only is this easy to get wrong—as shown spectacularly by the OpenSSL bug (which you've presumably looked up by now), but also, for example, by the destruction of the first Ariane 5—but there is no guarantee that it can be done with purely local modifications, even if the final safety property you wanted to establish can be established with chains of local reasoning.

I do agree that sound static analysis of C that is written to make that analysis tractable is just as effective as rewriting in Rust. Not only can such analysis show the absence of undefined behavior, it can show arbitrary correctness properties, including those beyond the reach of Rust’s type system. Probably the strongest example of this kind of analysis is seL4, although now its proofs verify not only the C but also the machine code, thus eliminating the compiler from the TCB.

Re: How to not rewrite it in Rust

#222

Post by kragen »

jfsszuj wrote: post #220
andrewflnr wrote: post #218

Earlier quoted context omitted.

That's a pretty significant almost. Regardless, kragen's point was not about whether figuring it out was possible but how expensive it would be.

It's not that significant. We can tell what the vast majority existing software will do in an automated way. Compiling a program is the equivalent of encoding it's semantics in another language which implies knowing what it will do - at least that's one way of 'knowing what it will do'.

It would be hard to overstate how incorrect this statement is, if it is read with the implicit qualifier "for all possible inputs", without which my comment above would be obvious nonsense. Of course we can tell what most programs will do for some inputs—we can just run them!

Re: How to not rewrite it in Rust

#223

Post by jfsszuj »

kragen wrote: post #222
jfsszuj wrote: post #220

Earlier quoted context omitted.

It's not that significant. We can tell what the vast majority existing software will do in an automated way. Compiling a program is the equivalent of encoding it's semantics in another language which implies knowing what it will do - at least that's one way of 'knowing what it will do'.

It would be hard to overstate how incorrect this statement is, if it is read with the implicit qualifier " for all possible inputs ", without which my comment above would be obvious nonsense. Of course we can tell what most programs will do for some inputs—we can just run them!

Yup, we can tell what most existing software will do for all inputs. Rice's theorem states that we can't tell what all software will do, not that it's impossible to tell what a given piece of software will do.

Re: How to not rewrite it in Rust

#224

Post by andrewflnr »

jfsszuj wrote: post #220
andrewflnr wrote: post #218

Earlier quoted context omitted.

That's a pretty significant almost. Regardless, kragen's point was not about whether figuring it out was possible but how expensive it would be.

It's not that significant. We can tell what the vast majority existing software will do in an automated way. Compiling a program is the equivalent of encoding it's semantics in another language which implies knowing what it will do - at least that's one way of 'knowing what it will do'.

You can write down the physical laws that apply to a given system, but we don't usually call that "knowing what it will do", unless you can actually predict the state, or in the case of a program, the output. The mere fact that compilers exist is a meaningless form of "knowing what the program will do", only superficially relevant. You can't solve the halting problem with compilers in the same way that Newton's laws don't solve the three-body problem.

Also, did you catch the part where the point is about how expensive it is?

Re: How to not rewrite it in Rust

#225

Post by kragen »

jfsszuj wrote: post #223
kragen wrote: post #222

Earlier quoted context omitted.

It would be hard to overstate how incorrect this statement is, if it is read with the implicit qualifier " for all possible inputs ", without which my comment above would be obvious nonsense. Of course we can tell what most programs will do for some inputs—we can just run them!

Yup, we can tell what most existing software will do for all inputs. Rice's theorem states that we can't tell what all software will do, not that it's impossible to tell what a given piece of software will do.

If this were the case in practice, most software would have no bugs.

Re: How to not rewrite it in Rust

#226

Post by pron »

kragen wrote: post #221
pron wrote: post #179

Earlier quoted context omitted.

> so there is no plausible reason for you to infer that I was talking about Heartbleed. Except that Heartbleed is the only OpenSSL bug I've heard of :) Also, I don't know who Kurt Roeckx is. > there's a lot of evidence from software project metrics that the cost of modifying software can easily exceed the cost of rewriting it But we're not talking about arbitrary modification, but about, at worst, fixing undefined be…

I appreciate your clarification! Indeed, I didn't mean it was impossible to tell what any software would do in any situation, only some software (in practice, nearly all) in some situations. The contrary would imply that not only writing software but also running it would be impossible. Your blog post looks very interesting indeed! I will read it with care. I do think there's a subtle point about modifying software.…

Yes, I looked up the OpenSSL bug you referred to, and I think it's quite unusual. I'm not sure what those lines were exactly, but from the description it seems like it was intended to read uninitialized memory, something that (safe) Rust won't let you do, either. Also, it's probably wrong even in C, but it worked. So yeah, touching code in any way is not always 100% safe, but my point was just that sound static analysis is still cheaper than a rewrite, as it requires far less modification.

As to seL4, it isn't exactly similar to sound static analysis, as the work was extremely costly. All of seL4 is 1/5 the size of jQuery and it's taken years of work. But it also includes functional verification, not just memory safety. In fact, it is among the largest programs ever functionally verified to that extent, and yet it was about 3 orders of magnitude smaller than oridnary business software, roughly the same verification gap we've had for decades. We don't yet know how to functionally verify software (end-to-end, like seL4) of any size that's not very small.

Anyway, Rust offers a much more limited form of assurance, and sound static analysis tools offer the same, and at a lower cost for existing codebases.

Re: How to not rewrite it in Rust

#227

Post by jfsszuj »

kragen wrote: post #225
jfsszuj wrote: post #223

Earlier quoted context omitted.

Yup, we can tell what most existing software will do for all inputs. Rice's theorem states that we can't tell what all software will do, not that it's impossible to tell what a given piece of software will do.

If this were the case in practice, most software would have no bugs.

The fact that we can determine what a piece of software will do, doesn't mean we always do that kind of analysis, or that the programmer fully understands his own code. That's why we have type systems, constraints, verification tools, etc.

Re: How to not rewrite it in Rust

#228

Post by HankB99 »

FpUser wrote: post #114
HankB99 wrote: post #85

I don't think I've ever met a developer who didn't want to rewrite their predecessor's code and that includes the one I see in the mirror. Doing it in a different language would definitely be more interesting. Do we admit that this is a factor in the decision to rewrite vs. reuse?

"I don't think I've ever met a developer who didn't want to rewrite their predecessor's code and that includes the one I see in the mirror" Allow me to introduce myself ;) I mostly work on new products and rewriting to me just a waste of time. I am interested in creating features that give actual ROI. The only time I rewrite a piece of code is if said piece presents a major problem (bugs, performance etc)

Pleased to meet you!

Re: How to not rewrite it in Rust

#229

Post by jfsszuj »

andrewflnr wrote: post #224
jfsszuj wrote: post #220

Earlier quoted context omitted.

It's not that significant. We can tell what the vast majority existing software will do in an automated way. Compiling a program is the equivalent of encoding it's semantics in another language which implies knowing what it will do - at least that's one way of 'knowing what it will do'.

You can write down the physical laws that apply to a given system, but we don't usually call that "knowing what it will do", unless you can actually predict the state, or in the case of a program, the output. The mere fact that compilers exist is a meaningless form of "knowing what the program will do", only superficially relevant. You can't solve the halting problem with compilers in the same way that Newton's laws…

> but we don't usually call that "knowing what it will do", unless you can actually predict the state, or in the case of a program, the output.

Who is 'we'? And yes, we can predict exactly what the output of a given program for a given input is, for the vast majority of cases. All you have to do is run the program.

> The mere fact that compilers exist is a meaningless form of "knowing what the program will do", only superficially relevant.

You think static analysis, type checking, intermediate representation, optimization, the translation of the program with exact semantics into another language, etc. - is 'superficially relevant' to understanding a program?

> You can't solve the halting problem with compilers

Now that's pretty irrelevant.

> Also, did you catch the part where the point is about how expensive it is?

Did you catch the part where I was only commenting on a specific part of the comment? But tell me, how expensive is it?

Re: How to not rewrite it in Rust

#230

Post by pron »

chillfox wrote: post #188
pron wrote: post #172

Earlier quoted context omitted.

The main cost either way is not licensing but effort.

That's not always true. While I have no idea of what this particular solution costs, I have seen licensing costs that would easily pay for a 20+ person team. The size of the software is important to consider when you are looking at the cost of rewriting.

Effort is the cost I was referring to.
Post reply on HN