Why you should, actually, rewrite some of it in Rust (unhandledexpression.com)

If you rewrote only part of a large C++ project in Haskell, is there a way to link it back in again?

the cool thing about rust is that you can use it for real-time programming, one example being DSP/audio. it often means no locks, nothing blocking, no dynamic allocation (malloc and most other allocators do not provide upper bounds of execution time), no recursion, and others.

haskell is not tailored for that.

of course there are other domains for which haskell is top-nocth and rust falls flat.

I am not sure if you are serious or not.

How does verification prevent buffer overflows? It can reduce their frequency, but you can never know you got them all. They find issues in libCURL and openSSL that have existed for years. Very few people are better than the people working on those libraries.

It is better to be safe by default then add risk only when you need it. I say this as a C++ developer, I think const should be the default state of all variables and one should have to opt out of that, and Rust did that right and C is so far from that I see no reasonable way to use plain old C safely. At least with C++ I can hide my stuff in classes and verify one thing at a time.

Why not Rust? Given that you aren't very familiar with niether C++ nor Rust, I'm not convinced that C++ is saner or faster.

Or just rewrite it in modern C. This is sane and doable in a short period of time. You just have to make sure it's modern C.

(no true Scotsman)

Oh no, no, no! Some people may reasonably, with some extreme care and diligence, maybe try to claim they can write safe and UB-free C code. If stars align properly. (See maybe SQLite. Seen as one of the pinnacles of crazy pedantism in C. Also, see the article about errors found recently in SQLite with fuzzing!) But with C++, it's just impossible for a human. It's too big, too quirky, too big, too wide, too deep, too tricky, too big, too complicated, and also too huge. And purposefully (sic! for performance) sprinkled with UB, which means barbed fences, trip-wire mines (to boost your in-flight performance), and hidden pit traps. Writing C++ code longer than a few lines without UB is humanly impossible. Sorry. And that's just about UB, because it's the most unpredictable thing; but there's still exception safety, for example, which you also should be doing, which can "only" spoil your code's logic (and then, obviously, go on writing over random memory, but that's nothing uncommon for us C++ers). Is every line of your C++ codebase exception safe? Yeah, sure. Good luck. And "modern C++" only means more C++. Because backwards compatibility. Unless at some point some quest for a "safe subset of C++" finally gains traction, which may maybe bring back some sanity. I do really hope for that.

A personal opinion from a person who loved C++ for quite some time, before diving deep enough to realize how dark is the abyss.

Fastest to develop, yes. Portable, yes. Safest? Well, only in as much most of the errors will be blamed on the programmer for not doing the correct modern C++.

I mean, seriously, understanding the borrow checker is nowhere near as hard as understanding this: https://akrzemi1.wordpress.com/2013/10/10/too-perfect-forwar...

There's a No True Scotsman aspect to C++ advocacy. Anything that is obviously dumb either is because the programmer did it wrong, because it belongs to the ever-growing list of features you avoid or "doesn't come up that often".

As long as it possible to run the same old C code inside your "modern C++" rewrite, you might have ported the security holes to C++. The problem is, C++ is far to compatible to C here. The idea of all "safe" modern languages is, that unsafe constructs are simply not allowed by the compiler. Why not let the compiler do the checking work vs. hoping that the human programmer didn't miss a check?

If you read the article you'll notice that he proposes that Rust is a better language because it allows incremental rewriting, rather than a complete one; Rust doesn't have a runtime, doesn't have GC, and can fairly seamlessly/painlessly integrate with C (you can both call and be called from C easily).

That changes the equation considerably, compared to something like Go where none of these benefits exists. For example, exporting code from Go not only requires the runtime and GC, there's also significant function call overhead because of the way Go maps goroutines to threads.

There are many other good languages, but few of them have these benefits. C++ is probably the option with the least amount of friction against C, but then you're also inheriting most of the unsafety of C.

All of your questions are addressed in the article.

> Why Rust? Why not Idris? Why not Haskell?

    it can easily call C code
    it can easily be called by C code (it can export C compatible functions and structures)
    it does not need a garbage collector
    if you want, it does not even need to handle allocations
    the Rust compiler can produce static and dynamic libraries, and even object files
    the Rust compiler avoids most of the memory vulnerabilities you get in C (yes, I had to mention it)

No GC, higher performance than either. Most other safe languages have more overhead than Rust.

As for why not use sanitizers and such: That's an ongoing cost of using the sanitizer. Rewriting in Rust is a one-time cost, and can be done incrementally.

Or better, why not pascal?

The HONEST question is because developers hate progress. We could have left in the past C/C++ by now, but not, is better to move forward with the same problems as DECADES ago.

Rust is a potential contender because is not that far from C/C++, and have {}, and the last point is not even a joke.

-----

Is weird to me why a clean fork of C/C++ was not made, if the prospect to move to something else was too much progress for the minds of the industry, the slow progress is a good alternative. You could have C.1, C.2, C.3, etc...

Think how much is about "modern C, modern C++, coding well" and then why not commit all that wisdom as the language?

The creator of Pascal made a point that a new version of a language must remove and correct the mistakes of the precious version, not accumulate problems.

That is fight AGAINST entropy.

The runtime, of course. No GC, etc.

BTW Haskell has been used to write OS kernel modules: [1], [2]. It's still quite a bit cumbersome.

I also wonder why ATS language does not receive enough love in this area.

[1]: http://www.pfq.io/ [2]: https://tommd.wordpress.com/2009/09/13/kernel-modules-in-has...

Good idea. We've added that bit above.

?? Surely Rust would have helped against heartbleed? I mean, some servers were leaking private keys because they sent random segments of memory back to clients.

> Rust isn't going to help you with that.

As I noted elsewhere in this thread ( https://news.ycombinator.com/item?id=14753692 ), I've actually been working on a low-level media decoder in Rust. Compared to my earlier work in C (the xmlrpc-c library, for example), my Rust code has stood up very well to heavy fuzzing. My xmlrpc-c code, on the other hand, was written with ridiculous levels of paranoia, and it has been the subject of multiple CVEs thanks to a third-party XML parser I used.

So in terms of practical engineering reality, Rust seems to make a big difference. And even more importantly, it means I can trust other people's libraries a bit more.

Rust's practical advantages seem to be:

1. Runtime bounds checks! I wouldn't have thought that this was the most important thing, but when fuzzing, it's the last line of defense against quite a few potential exploits.

2. Debug-mode checks for integer overflow. Rust defines integer overflow as an error, and debug builds will actually check for it. This turns out to work really well with fuzzers.

3. The borrow checker. In my experience, this is actually less useful than (1) and (2) above in terms of preventing security bugs. But it does help.

So as somebody who's written parsers for untrusted data in both C and Rust, I definitely found that Rust helped me a lot. Of course, Rust can't help with some forms of stupidity, such as writing a bad custom memory allocator and using it to handle key material. OpenSSL's problems go well beyond the ordinary hazards of C.

So your argument is that because rust doesn't solve all problems people shouldn't strongly consider replacing C code with it, even though rust avoids entire classes of critical bug types in C?

I happen to like rust, though I would not suggest that it is the only solution to the classes of problems it avoids. I would, however, suggest that people very strongly consider using languages that avoid the problems that rust avoids whenever possible. Like, literally any time you're considering writing C or C++, at least strongly consider rust or another much safer option.

I agree that there are technical limitations, but I think those should be sought to be overcome. I disagree with your implicit assertion that all languages are equal (or close enough). If it is possible to make a class of error completely disappear then it should be done when not cost prohibitive, and languages can be designed such that there is no cost to avoid certain errors.

Sure one boundary error could have been detected in any language, but there will always be fewer in a language that simply disallows them. Consider how infrequently Gotos are used now there are no longer errors with setting state before a jmp/goto, because modern constrol flow tools function, case, inheritance, generics and others tools have strong semantics with good implementations that work well and reduce complexity.

Unfortunately language adoption is not a pure meritocratic affair. Bad languages can stick around for far too long because of external factors. Consider that Ada never had real use outside the DoD when it was shiny and new. That group isn't exactly known for evangelizing. The Rust community has better marketing strategy and has chosen a highly meritocratic approach to language design.

> It was caused by failing to validate untrusted input. Rust isn't going to help you with that.

Really?

Validation and sanitization are the last, not the first line of defense. It is not about erecting barriers, it is about failure modes. All your software components, from core to border, should fail fast, safe and in a predictable way -- the exact opposite of what happens in C.

In any sane programming language (e.g. Java -- not particularly sane, but boring enough) Heartbleed would have resulted, at worst, in OutOfBoundsException or similar, and the only damage would have been the denial of service. And to do bounds checking, you don't need to have garbage collector -- it is the most basic thing the runtime can do, and performance penalty is minimal. Why it is customary to skip this in C/C++, I don't know.

Lack of bounds checking, not pointer arithmetic or allocation lifecycle, is the major source of security issues with existing software.

Sometimes I wonder why developers are so masochist with his tools, and so MUCH AGAINST AUTOMATION.

If a language, for example, don't have NULLs and you need to use Sum Types (like ML or Swift) you have solved FOREVER and FOR ALL THE DEVELOPERS that problem.

But say that just because this is one problem among dozens, then is better FOREVER AND ALL THE DEVELOPERS to stay with the problem?

Instead, why not put as our goals to eliminate all the problems that are possible?

Sigh. This again.

The Rust language is more than just memory safety. Memory safety is certainly the most prominent and unique feature of Rust, but the language also includes a lot of features that make writing good, bug-free code easier.

For example:

`Result`, when returned, forces all callees to check for errors. It's all too easy to throw away error codes in C/C++. This is probably one of the most important features in Rust, besides memory safety.

To easily consume an `Enum`, you have to use `match`, which forces you to handle all members of the enum. In C/C++ it's easy to build a switch for an enum, and then later when a new member is added to the enum and you forget to update all your switches.

Support for multiple return values (through tuples) means being able to avoid the nightmare of output pointer arguments to functions.

No NULL pointers.

Unit testing built into the canonical tooling.

Documentation testing built into the canonical tooling.

The `Option` type, which lets you return "nothing". In C/C++ you'd have to return a bool, and again use a nightmarish output pointer argument.

`OsRng` in the rand crate (go ahead, try to write a function that safely reads urandom in C).

No undefined behavior.

The list goes on. The flavor of it, is that Rust makes it easier to write defensive code. Defensive code is code that is hard to use wrong. For example, for a backup solution I built using Rust, I made all the cryptographic types their own unique, opaque types. EncryptionKey, HmacKey, Salt, etc. For someone new to the codebase, these types make it obvious what each function is asking for, and make it really difficult to use the functions or the types the wrong way. And they are super easy to build and use in Rust, see my code: https://github.com/fpgaminer/preserve/blob/master/src/keysto...

C++ would require a whole set of classes, and require instantiating a new class every time I want to add a new cryptographic type. Rust only requires 3 lines per type.

TL;DR: The real magic is that it's easier to do the right thing in Rust.

Heartbleed included memory safety violation. A hand crafted Malloc replacement was used to manage buffers. Uninitialized memory of new buffers was able to be read which allowed the extraction of secrets.

Now the reason why some people claim that Rust would not have stopped it, is that a similar leaky buffer system is possible to be written in Rust. This however is just applicable if you just use byte buffers for everything. At that point you become close to emulation. Also if the system malloc is shit, you just use jemalloc which is the standard for Rust. So there is no need to roll your own malloc replacement in Rust

Isn't this just the nirvana fallacy? You're basically arguing that because Rust can't solve all security problems, it's not worth using it to solve some security problems, and the better option is the status quo of using languages that expose all problems.

> Heartbleed is a great example. It wasn't caused by an error with how C handles memory or strings or anything else. It was caused by failing to validate untrusted input. Rust isn't going to help you with that.

Yes, it would. In Rust, the server would have crashed when it overran the buffer instead of sending that potentially-secret memory back to the client. Heartbleed is a great example of why rewriting in Rust is good.

> If memory safety and correctness was so truly valued above everything else, we'd be seeing a lot more Ada than we do today.

The problem was that many companies had certain problems paying for Ada compilers and rather used the free C compiler delivered with their OS SDK.

Actually, Rust would just have panicked in the Heartbleed case: you wouldn't have been able to perform an out of bounds memory access without causing a runtime panic.

Heartbleed came from allowing reads of uninitialized/out of bounds memory. Rust doesn't absolutely prohibit that, but it is an out of bounds memory access error. Python, Javascript, etc. catch that.

Haskell (and any other GC language) has big runtime requirements that rust does not. It's not just about the ABI.

Your argument does apply to Ada, but freeing from the heap in Ada is unsafe, which has made it difficult to use in a safe way for a lot of cases.

Rust really does make an advance in this regard: safety, and no significant runtime requirements.

D and modern C++ might work for disciplined teams, but seem a few steps behind rust safety-wise.

> Heartbleed is a great example. It wasn't caused by an error with how C handles memory or strings or anything else. It was caused by failing to validate untrusted input. Rust isn't going to help you with that.

I think you'll want to check your facts again:

https://tonyarcieri.com/would-rust-have-prevented-heartbleed...

> The reasons provided by this article are insufficient to solely justify a re-write in Rust;

You didn't read the article. He acknowledged that the hyperbolic calls to "IMMEDIATELY REWRITE EVERYTHING IN RUST!!1!!1one" are silly. In bold, the author states:

> What I’m advocating for is much simpler: surgically replace weaker parts but keep most of the project intact.

Which, by the way, is exactly how Mozilla is applying Rust-written rewrites to Firefox (dogfooding their own programming language).

> Close to half a billion fuzz runs found 5 runtime panics, all of which were detected by Rust before they could compromise security. If I'd written this code in C, several of those errors would have been exploitable.

Wouldn't the apples-apples comparison be fuzzing a C program? If AFL would catch the same bugs, Rust isn't better than C in this case.

I don't agree with the underlying thesis: In 15 years, I'll be heartbroken if we're still facing an endless stream of security updates and remote root compromises when all these projects were rewritten in a popular but unsafe language: Rust.

There do exist fast and SAFE language out there. With guaranteed memory safety, null pointer safety, concurrency safety, dead-lock freedom, race freedom, and even with normal syntax. Rust is not one of them. When will all these rust fanboys finally see the light?

    local
       array: expanded ARRAY[INTEGER];
    do
       array := <<1,3,2>>
       sorter.sort(array)
       ....
    end

    TYPE
       Time = RECORD
          seconds: INTEGER;
          milliseconds: [0..999]
       END; 

    PROCEDURE MyProc =
    VAR
       t: Time; (* Stack Allocated *)
    BEGIN
       t.seconds := 0;
       t.milliseconds := 0   
    END MyProc;

Is there any way to lessen the burden by automating conversion of straightforward portions of a C codebase to Rust? They seem similar enough conceptually and semantically, if not syntactically, that a lot of boring C code might be fairly easy to translate?

    int read(int fd, char buf[], size_t len);

    int read(int fd, char& buf[len], size_t len); 

it's all in the "well written" part. of course well written C/C++ is good. the very point of Rust (and others, like Ada) is to admit that we, programmers, cannot do good work all the time.

anyone thinking "I'll just write these 50k SLOC very well so it'll be ok" should not consider a career in programming.

Well written the hard part there. I am riding on on the idiomatic C++11/14/17 train right now.

Life over here is great, but I can the warts of the language looking backwards. The promised land in the future doesn't look quite as bright as the promises Rust offers. The only thing keeping me from trying it is the giant codebases in my current projects.

I've never seen anything in-depth, but there's a lot scattered throughout pcwalton's comments on HN. For instance: https://news.ycombinator.com/item?id=7587978.

Sadly Compcert is not foss, meaning that they will have a huge problem if they try to push it everywhere. I think that the age of non-free languages and implementations meant for the general public is over, even MS has made their C# and F# implementations free.

Compcert is guaranteed to compile correct C code to correct assembly (given its TCB assumptions). It doesn't say anything about incorrect C code. So in order to benefit from CompCert, first you have to prove that you have valid C in the first place, which is no easy feat. You'd probably be better off using a language that's designed with verification in mind, like Cogent or ADA/Spark, or waiting for lambda-Rust to become production ready, since in those cases you won't have to prove tedious bureaucratic memory safety invariants for the vast majority of your code, and can focus on functional correctness (or, if you just care about memory safety, you can stop there).

First

I think its a little bit of both. Primarily it is aimed at legacy software. IMO not a lot of new code is written in legacy C, so we have a problem with having a ton of dependencies written in a way that may not be the safest or most reliable (from recent experiences). The authors suggestion is to rewrite parts of those applications that tend to be buggy (mostly I/O parts) in Rust.

I really hate to see the naysayers comment on this article without even having read it. I think the author made a very good point.

such as?

Someone has already done the honors:

    https://github.com/shinglyu/RustPython

The relatively low portability of rust programs is definitely one of its largest shortcomings.

What aspects of support are you missing today?

I believe Firefox as of recent versions requires a Rust compiler to be available, and that's a pretty bread-and-butter application to have in your distro's package repository.

> As far as I can tell there's no major package manager accepting or even ready to accept programs written in Rust yet. Am I misinformed?

At least Debian, Fedora, Arch, and Gentoo have rustc and cargo in their repositories. Oh and Alpine, recently. FreeBSD (IIRC) has it in ports.

In the not-too-distant future, there's a pretty important package that will require Rust: Firefox. HEAD already does today.

In this case it seems the author is writing about the concrete results they've already obtained, not about something abstract.

The author is actually using it, to actually rewrite portions of C projects in it, and writing about their experience doing this in practice. For example, the linked paper is about using Rust at the I/O boundary in an existing, complex system.

One of the reasons why I'm super hesitant of learning Rust is the attitude and emotional based opinions of the community. I picked up Python due to my work and I love it and I'd never think I would before trying it. But I also never in my travels seen Python people advertise it negative with "<somelang> SUCKS! FUCKING IMPOSSIBLE! GIT GUD AND USE PYTHONN!" about ANY widespread or niche language but instead they just keep positively gushing over Python: "how clear", "how succinct", "formatted by significant whitespace", "readable", "simple", "pythonic", "wide array of modules available", etc.

When someone in one message both recommends Rust and says that it's absolutely impossible to ever write correct programs in C or C++ that are more than few lines long what am I supposed to take away from that? Rust itself uses C++ written LLVM, is it unreliable too then? Seriously... And implicitly, anyone liking C or C++ is an idiot and a bad programmer.

> Rust has sweet error handling

I feel like a lot of the cool things in Rust get obscured in the never ending safety dance. There is some rad stuff in Rust compared to its closest competitors (C and C++) -- cleaner error handling, a standard package manager, no aliasing -- I want to hear about what else Rust can do for me! More safety guarantees, ehhh, I'll take them but they aren't a huge win in our work.

> the syntax is almost as noise-free as exceptions

No.

const USAGE: &'static str = "usage string";

I did rewrite it in Rust. I rewrote a small low level command line app in Rust. I really wanted to like Rust going in but I freaking hated it going out. They had a few good ideas but they never knew how to say no. The part I hated the most was the Rust macro language. And for real low level to the metal systems programming, everything is unsafe; so you may as well be writing in C.

Go is pretty minimal. They knew how to say no. I like modern C (C99 and C11). It has most of the good ideas from C++.

    const USAGE: &str = "usage string";

    const USAGE = "usage string";

> Runtime arithmetic overflow checks have saved me many times. Knowing I have this safety net I can be cavalier about using smaller integer types.

As a note to others, arithmetic checks doesn't happen in release builds unless you used something like checked_add, add "debug-assertions = true" to [profile.release], or use -C overflow-checks flag with the compiler.

https://github.com/nox/rust-rfcs/blob/master/text/1535-stabl...

I think you see some of that since quite a few people have spent decades in C/C++(myself included) and have had exposure to experiencing these exact problems.

I'm still a huge fan of C++ but Rust gets me to where I want to go with C++ with much less fuss and a lot more confidence.

For what it's worth, while I agree that there is a vocal minority within the Rust community that can be militant this way, it's not an official position, and it's explicitly not endorsed by the Rust core dev team.

Personally, I'm considering C++ for a new software project despite my extensive background in security. I think Rust is a great language, I just don't have much interest in it.

In official Rust spaces, attacks like that are not allowed. We don't directly reference other languages in any official docs and such, to not promote this kind of attitude.

It is true that we built Rust to address shortcomings of C and C++, some some form of crtitique has to happen. But many Rust programmers, and especially Rust leadership, will gladly say there's still some good reasons to write C and/or C++ today. Many of those reasons will still be around for a very long time.

Show me the programming language community that's a fan of the language it's intending to supplant and we'll talk. :)

I see attitude like that a lot on hacker news, but never see it on the rust user forums or IRC and rarely in rust related twitter. I can only speak for what I've seen personally but it seems to have more to say about hacker news comment sections than the rust community itself.

> Some badass below even just said that "writing C++ code longer than a few lines without UB is humanly impossible". Apparently all these FUBAR C/C++ systems (Linux and Windows kernels, all? web browsers, LLVM that the dear rust uses, device drivers, web servers, router software, VMs of Lua, Python, C#, Java, ..., etc.) work well enough to transfer that kind of garbage to me.

Yes, they work well enough, until they don't, because realistically, they are rife with dependencies on undefined behaviour. Linux can only be compiled with gcc last I checked.

> I feel like the biggest reason for me not even thinking of Rust as a viable language right now is the community attitude

Kinda reminds me of the "coal vs. renewable energy" feud. The first tier arguments are formed around {economics, externalized costs, existing infrastructure, base load vs intermittent load} and then second-tier arguments align around {culture, history, identity, momentum, geography, political party}. You are making a second-tier argument against Rust when the article is making a first-tier argument for Rust.

I would argue that you are attributing to "the Rust community" the more outrageous attitudes which are a minority of the Rust community and ignoring the majority which have much more rational and banal attitude. And likely you are attributing the inverse to the existing C/C++ attitudes towards Rust (conveniently ignoring lots of the best arguments for Rust). It's exactly what happens in those feuds you described and in modern US politics (Democrats vs. Republicans, liberals/progressives vs. conservatives, secular vs. religious, etc). By focusing on the strawman arguments, you are missing the potential benefits of using a newer generation language.

> all these FUBAR C/C++ systems (...) work well enough to transfer that kind of garbage to me

I don't think you read the article. The author specifically cites lots of different types of hyperbolic "rewrite everything in Rust!" arguments and explains how this article is not that and he doesn't advocate for that. The author of the article advocates "surgically replace weaker parts but keep most of the project intact." This is exactly how Mozilla is dogfooding Rust in Firefox.

And no one is arguing that all of those C/C++ systems you mention are "FUBAR" -- that's a strawman. Rust advocates, as well as advocates of many of the newer-generation, lesser-used languages advocate for advancing programming beyond the languages designed in the 1970s. We've had an explosion in programming language diversity over the past 30 years and we've developed some great research on how to prevent certain classes of defects. The longer those C/C++-written systems exist without a rewrite in a safer language (or thorough audits including massive amounts of fuzzing), the larger the impact of inevitable non-zero-probability of those vulnerabilities which Rust prevents.

The article's author completely admits that at their best, C/C++ developers can avoid all of the problems that Rust solves. But not everyone is a rockstar and not everyone performs at 100% all of the time. Rust is written for humans and the compiler is a strict nanny, preventing you from getting yourself into danger, the same ways you can with C/C++ memory issues. It also has tooling for unit tests, benchmarking, fuzzing, and standardizing code formatting conventions in the language. You can bolt these things onto C/C++, but that means that you have to go find them (which new developers won't do unless sufficiently motivated to).

I came across this comment before your others. Initially, I thought you were an innocent bystander, and maybe you were, but man did that change quickly. You criticized Rust / C++ bare knuckle boxing but then immediately afterwards jumped into the ring.

You only end up with them in the final program with a naive translation that makes life hard for yourself. Using the native types is much nicer (even ignoring any safety benefits), and so people are naturally encouraged to do so. For instance,

- the C interface can easily be thin wrappers around pure "nice" Rust functions, that just do the necessary unsafe conversions

- and, whether or not that is used, when a function is no longer being called from C (that is, everything that calls it has been converted to Rust) the arguments can be switched to something more natural and strong static typing will point out all the places that need to be updated.

I cannot believe that a pure Rust codebase would want to be passing raw pointers around. And the alternatives don't seem at all better: only ground-up complete-rewrite migrations (hard to justify so often won't even start) or not migrating at all (meaning one has a C codebase that is still full of unsafe pointers).

Lowering the learning curve is a huge objective of this year!

> The whole struggle with lifetimes

How did you try to learn them? I'm interested in trying to make this easier!

> the redundant syntax

Which bits are redundant?

Btw, are you planning to work on a thin integration layer between rust and postgresql? Sufficient to be able to write UDFs in rust? That's imo the most realistic start to get some experience w/ rust in the postgres community, and it provides value on its own.

Yeah, SIMD is being very actively worked on; until then, you can link in an external assembly file, but that's not exactly the best UX.