1. 42
  1.  

  2. 21

    For the good of the Internet, and in fact humanity, we need to migrate our software from C/C++ to Rust (or something better) as quickly as possible.

    I feel vaguely embarrassed on behalf of our whole industry that this hasn’t happened already. We’ve seen huge innovation in new languages; we have amazing development tools to make our lives as programmers easier, but the software that users spend 99% of their time directly interacting with is still constructed using the technical equivalent of banging rocks together.

    Better late than never, I suppose.

    1. 22

      I don’t think we should be embarrassed. Rewriting something like DNS in a new language and then having everyone start using that version instead is not something to be taken lightly. To say that’s critical software is an understatement.

      Frankly, I feel like Rust is just now reaching the point where, as a language, you would even consider using it for software of that nature.

      1. 4

        On the other hand, a safe® implementation of DNS was made for Mirage: https://github.com/mirage/ocaml-dns Also a good TLS stack that already passed some tests and is being checked more carefully…

        1. 6

          Well, specifically in the case of browsers–don’t you think it would be wise to wait until we as a civilization had learned how to develop at least one rendering engine that doesn’t leave a steaming trail of CVEs in its wake before recklessly proceeding to build more and more technologies that depend on such engines?

          Webkit, Gecko, and Chromium all have so many critical security flaws reported on a regular basis that the Debian packagers had to special-case their update policies just for them; they are essentially DOSing the distribution with bugs.

        2. 14

          Well in our defense, there wasnt really any great alternatives to c before rust became stable, and it just became stable a few months ago.

          And its a little harder to profile who is using tools like valgrind.

          1. 14

            The standard response to this would probably be Ada. The price tag of the early compilers was indeed an important impediment to its adoption, but I am very annoyed when people dismiss it for being verbose or B&M: verbose is not necessarily a bad thing (all things in moderation I suppose) and being B&M (a term I’m not a big fan of) is preferable to the free-for-all chaos of C.

            1. 15

              Indeed, ada is definitely an example of already been done.

              I like rust and all, but people REALLY need to step off the high horse of everything needs to be converted cause memory safety stool.

              1. Until rust demonstrates itself, it can’t even be considered ada quality, this has NOTHING to do with how well rust works now or will in the future. You do not just rewrite things based on promises of better.
              2. Can we dial the hyperbole back a bit here? All c/c++ is not bad, we can mitigate most of the problems. And with things like compcert we can prove some c is perfectly fine. Statements like using C/C++ now is bad because of rust is both premature, mostly because of 1, and also the entire software industry as a whole should just flip tables and rebuild an entire process and build chain just for memory safety? Yeah that unrealistic and too ideological. Step it back a notch.
              3. I LIKE rust and want it to succeed. But I’m going to take a conservative view on this, I do not want to be the guy with arrows in my back to find out that after all no we should not rewrite everything in rust for whatever reason.

              If we keep hearing stuff like this, and I recognize rust is early in its hype cycle, if things and statements like this one keep getting proffered up by people will set the industry back a lot further than if people are measured and reasonable in how they promote rust.

              Just my pennyfarthings worth of input.

              1. 15

                I agree with some of your conservative-ness here, but at the same time, the only way that Rust can demonstrate itself is if software like this is written in it. Or at least, something of the same order of magnitude.

                In other words, being at different points at the adoption curve is totally fine, but that doesn’t mean that the people who are earlier on it than you are terrible. Their work is needed in order for it to be demonstrated mature in the first place. And early adopters are by nature enthusiastic.

                I recognize rust is early in its hype cycle

                One final note, this is actually a really interesting question. Rust as a project is:

                • 8 years old, if you start from when Graydon first wrote the first line of code.
                • 6 years old, if you start from the first public release.
                • 2 years old, if you start from when contemporary Rust took shape
                • 9 months old, if you go by 1.0.

                So it’s a bit strange to be “early” in the hype cycle. We did a lot of research while building Rust, and so while it is new in a sense, that newness is the culmination of years and years of experimentation. So in some ways, it’s both more and less mature than it seems.

                1. 7

                  So it’s a bit strange to be “early” in the hype cycle. We did a lot of research while building Rust, and so while it is new in a sense, that newness is the culmination of years and years of experimentation. So in some ways, it’s both more and less mature than it seems.

                  Extending Steves point:

                  That’s why I often use “yes, we tried that and it didn’t work out” as a response when many people ask about certain features. It’s amazing how many things where tried on the way to 1.0 and removed again. GC, evented runtime, classes, interfaces, Ruby-like internal iteration…

                  1. 3

                    Is there a collection of these things somewhere? I think it would make for a fascinating blog series.

                    1. 7
                      1. 2

                        I gave a talk “Rust is all that’s left” at Strange Group in Berlin, the end hints to the title and shows some of those things and code.

                        https://speakerdeck.com/skade/rust-is-the-only-thing-thats-left

                    2. 4

                      I say early in the hype cycle mostly due to rust being “new” as far as exposure to most programmers. The same could be said for open source Swift or even open source .NET. Lets go by 1.0 as the demarcation line just to make things simple.

                      I work with Linux kernel development. My question is this, even if I want to use rust in my work, the problem isn’t the programming language. The problem is shifting an entire ecosystem that way.

                      That proposition is basically asking to boil the ocean. Not going to happen, there are many man years worth of effort in existing tooling and languages. Asking to throw that out would be like saying we need to rebuild all our cities on the coasts now due to global warming. It is… a bit tone deaf in my mind.

                      On this:

                      In other words, being at different points at the adoption curve is totally fine, but that doesn’t mean that the people who are earlier on it than you are terrible. Their work is needed in order for it to be demonstrated mature in the first place. And early adopters are by nature enthusiastic.

                      I wasn’t trying to judge anyone that wants to rewrite everything in rust, in fact I encourage them to do it. I just don’t want people to continue down this path of C/C++ users are … because they aren’t using rust. That latter bit I am seeing a LOT of lately and honestly, that shit needs to stop. This is an engineering discipline, if we’re going to become political about things with pros and cons that we can measure, I’ll just change careers to become a politician. They get paid better.

                      That is a good way to start a toxic culture of us vs them. I know rust has done really well by not encouraging this in the past and I’ve been using/playing with rust since about 0.4ish timeframe, but I worry that it will be taken too far and to be honest I only expect it to get more incessant and annoying. And I do not like the needless factionalization of things. Does that explain my view a bit better? Text is hard to convey intent so if I came off as ye grumpy olde c programmer my bad but eh, I only have text. Carry on!

                      1. 5

                        It’s all good. I totally understand a lot of this. To be honest, my first reaction when I saw the headline was “oh no.” And then I opened it, saw it was posted by someone at Mozilla who I didn’t immediately recognize, and said “oh, oh no. A lot of people are probably gonna think this is something that the Rust team/world is all about.” And don’t get me wrong, I would love to see reimplementations of this kind of thing in Rust, but I think suggesting it’s “for the good of humanity” is a bit… much.

                        The problem is shifting an entire ecosystem that way.

                        Yeah, this is certainly true in kernel dev. I don’t see the kernel adopting Rust anytime soon. But we’ll see for other things; Rust will start at the bottom of the userspace stack and move down from there. There’s already a semi-serious coreutils rewrite, for example. I’m excited to see how this pans out. But I don’t think it will take boiling the ocean, either.

                        I just don’t want people to continue down this path of C/C++ users are … because they aren’t using rust.

                        Agreed, very strongly.

                        I worry that it will be taken too far and to be honest I only expect it to get more incessant and annoying.

                        I too am worried about this. I was really worried before 1.0, and that went okay. But part of community growth is that unified opinions become a collection of positions; and they’ll differ. But different groups have different loudness, and so a loud minority position can still be perceived as a majority one. That said, there’s only one thing to do: continue to try to uphold the community norms we do have, and hope it rubs off. I have some thoughts here, but not ready to share them publicly, as they’re rather personal.

                    3. 10

                      The funny and kinda sad thing is that the Rust core team has consistently been really careful not to make claims like this, and has encouraged people to not make them either. Rust is still new, and while there is a new effort to begin providing rigor to some of its safety claims, it’s nowhere near the point where one can categorically say that Rust solves memory safety.

                      1. 8

                        While I am very excited about this work, and agree that Rust should not be portrayed as panacea, I do think it’s also worth surveying existing languages as well. Few of them even have a spec, and very, very, very few of them have a spec that is rigorous enough to be formally proven.

                        We can make empiric improvements at the same time as formal verification is being pursued.

                        1. 3

                          Absolutely! It’s not necessary to wait for Rustbelt to prove everything it can before getting real gains from Rust in real situations.

                        2. 4

                          While we have this conversation on Rust actually trying to verify guarantees it gives its users, paleontologists and cs undergrads everywhere are still trying to decipher the masterful cryptographic document that is the current set of ISO C standards, that are not only epic in length, but unspecific and fangless like a pop pomo artist.

                          I find it hard to be convinced that “we need to test these tools a long time to make sure they don’t suck” is the reason to not uptake new solutions when we’ve “tested” existing heavily flawed tools for so long at the expense of lots of money and privacy. Not that I’m saying that vetting software is a bad thing, but these arguments always come off as electing to stay in the current pile of shit just in case the next system is just as bad.

                          1. 2

                            Oh, I completely agree. I think Rust is a strong improvement over C and C++, and I am very excited to see Rust used more so we can begin to get a better sense of how useful its guarantees actually are in production code. I just wanted to point out that the people usually making the hyperbolic claims about Rust are not part of the development team, but instead are usually relatively new to the language and the community (which is usually opposed to claims viewed as too-string).

                          2. 1

                            To clarify, my original comment is not about Rust specifically so much as about “It took how many years for an improved replacement for C to become a practical choice?”

                          3. 1

                            Statements like using C/C++ now is bad because of rust is both premature, mostly because of 1, and also the entire software industry as a whole should just flip tables and rebuild an entire process and build chain just for memory safety? Yeah that unrealistic and too ideological. Step it back a notch.

                            How high would the rate of software security bugs that would have been prevented by memory safety need to be for you to say that the entire software industry should just flip tables and rebuild an entire process and build chain just for memory safety?

                            1. 1

                              By my understanding CompCert doesn’t help prove theorems about C code. It just proves it’s own optimizations correct so that if your code does do the right thing the compiler won’t then break it.

                            2. 2

                              +1 for ada. If it’s good enough for flight software it could run the Internet.

                              Also I do wonder why Erlang never comes up as a candidate.

                            3. 6

                              I’m actually thinking more of the PLT community than applications developesr. But now that I think of it, there have been many attempts at replacing C with something that would be a very practical, genuine improvement; they just haven’t gone anywhere. I suspect this is due mostly to the fact that the improvements over C have been gradual and not dramatic enough to make a splash or mired in kitchen-sinkism (paradigms–gotta catch ‘em all!), though I suspect a big part of it also is that as far as I know no one has had the backing of an org as big as Mozilla.

                              1. 8

                                Well, there’s some history involved too. There were a plethora of languages available to do “systems” stuff around the time C was brought into the world. But C’s tight integration with UNIX was a killer. Network effects are very real.

                                Since then, there have also been a number of attempts at doing this, but bridging the academic to industry has always been tough.

                              2. 3

                                This is a good point, although it’s worth saying that Rust hit 1.0 in May of last year, so it’s been more than a few months now.

                                1. 1

                                  i think a lot of the userspace stuff could quite productively have been done in any ML/Haskell dialect (see mythryl and mirageos for proofs of concept). you don’t really need the raw speed and bare-metal access of C for much of it.

                                2. 13

                                  Hilariously unrealistic and potentially undesirable. These projects weren’t built yesterday.

                                  1. 15

                                    “The best time to plant a tree is 20 years ago, the next best time is today.”

                                    glibc is under a half a million LOC. A large undertaking, but not totally impossible. The Rust compiler itself is larger. That said, I am not sure who, if anyone is going to truly give it a go.

                                    1. 3

                                      Additionally a rewrite will certainly at least for a period introduce many more bugs than it fixes. See neovim.

                                    2. 3

                                      By far most of the bugs in the history of things built on top of libc were NOT memory safety bugs.

                                      So yes, languages like Rust and D will save us from a large and pernicious source of bugs, but not from all bugs, and certainly not even most of the bugs that have occurred in the history of these projects.

                                      That said, I would support moving to saner safer languages as soon as possible. Rust addresses certain largish classes of bugs, but ultimately the fewest bugs are in the application built out of the best safest / least buggy frameworks. I’m betting on D for that future.

                                  2. 4

                                    Rust’s tooling and support will be there in about ten years. It’ll be interesting to see who wins the race; Rust or C++. I’d definitely bet on C++ at this point, given the institutional support and installed base. C++ has made, recently, tremendous and interesting strides towards making Rust-like guarantees; see https://www.youtube.com/watch?v=hEx5DNLWGgA and the conference proceedings therein. Interesting times.

                                    1. 6

                                      As has been discussed by some major C++ developers, certain historic C++ design decisions make providing the kinds of guarantees Rust provides almost impossible. This is not to say that they shouldn’t try (I’m really excited that they are!), but that in the long term I think it’s unlikely that C++ reaches parity with Rust in this realm.

                                      1. 1

                                        yeah, I thought that too! But definitely check out the slides from that conference – including the presentation by Bjarne himself. Early days, but they’re definitely making some interesting moves.

                                      2. 6

                                        I don’t know if the winner will be Rust, but I do know C++ will be the loser.

                                        Outside of diehard C++ fans, the language is seen as the abomination it truly is.

                                        It is very hard to work towards the cartesian product of assembly and Haskell and legacy C and expect to have anything that is remotely usable by developers, especially when there is so much perfectly useful legacy code that flies in the face of those sensibilities.

                                        1. 2

                                          Other things seen as the abomination they truly are, outside of their fans: Word, Excel, Powerpoint, Windows, iPhones, Android phones, perl, python, ruby, javascript, wifi, linux, x86, ethernet, usb, little-endianness. Notice anything in common about that set? They all have radically superior alternatives and have all been declared evolutionary dead ended and finished, often many times over, frequently owing to a total perceived lack of architecture, feature set, taste or usability.

                                          Hating C++ is easy – I myself hate C++, for instance. Nevertheless, one thing I’ve found in my career is that it pays to keep an open mind and continuously consider the evidence. The Core Guidelines presentation and goals look pretty amazing, and the cast of involved parties includes many of the top luminaries of the language and the most influential computing companies in the world. Can they turn the corner and change the language for the better? Maybe! Seems more likely to me than rust gaining enough traction, tooling, mindshare, deployment, usability, reliability, and soundness to displace 50% of even unsafe C++11 code within the next 10 years.

                                          1. 6

                                            Well, Python 2->3 is still not a solved issue, nor is Javascript (which is trying to replicate the ongoing failure of C++ to the best of its meager abilities). Perl is also having similar issues.

                                            As for the rest of your examples, they’re not programming languages–even the ones that come close, like Excel, PowerPoint, and Windows, all go to great pains to not introduce anything too radically different from what’s come before. That’s a level of taste and restraint not present in the PL world.

                                            I think it’s disingenuous to make comparisons outside the realm of practical PL theory and software engineering.

                                            C++ is not a better systems language than C, so it will have issues on that front. It’s not a better functional language than any of the other alternatives (including Javascript). It’s not a better concurrent language than Erlang. It’s not a better OOP language than Java or C#.

                                            At this point, the supposed sweet spot of C++ is kinda drying up, I don’t think it’ll be “dead” in 5 years. I do think it will be irrelevant outside of legacy commercial and academic codebases in 10.

                                            1. 1

                                              OK, let’s restrict to just your criteria, if you need.

                                              The point about javascript, perl, python, ruby, java, etc., is that your assertion that “Outside of diehard C++ fans, the language is seen as the abomination it truly is” and therefore “I do know C++ will be the loser” is kind of a canard. Every gigantically popular language (or, as I noted, every popular thing) has an outsider group that hates it for great reasons; and that outsider group invariably thinks of itself as the most correct and the largest.

                                              Taking javascript as an example: I think every discerning PL theorist, practical or impractical, can think of several reasons why javascript is a totally shitty language with significantly better alternatives – and was from the first day it was instantiated, continuously, up to now. Nevertheless, none of the other attempts at replacing javascript went anywhere, because it got enough momentum, developers, and installed base that it became an unstoppable juggernaut.

                                              C++ is, for better or worse – and I agree with you, currently for worse – the gigantic mass of ice under the visible iceberg of programming. There’s probably more C++ AST nodes being generated for ‘systems’ purposes per day than all other languages combined. Do all of those lines of C++ suck? Mostly. But unlike other languages that nevertheless are still relevant and highly used 17 or more years after their last major update (fortran), C++’s leaders and related institutions appear to be thinking about moving it into the future, as Java 8 has started to do. I’ll allow that it’s not 100% that they’ll manage it and crush upstarts, but I’d wager it’s more likely than not. The backpressure from all of those institutions and people that want to continue using their existing skills but have the tool be better is bigger than you think.

                                        2. 3

                                          Yeah, the Core Guidelines are a really interesting project. While they’re sort of Rust-like, they’re not nearly as strong: the last word about concurrency, for example, was “We don’t know yet” and data race prevention was a non-goal. Still, I’ll take anything that makes overall computing safer, for sure.

                                        3. 4

                                          I like the idea. I briefly experimented with writing parts of OpenSSL in ATS for safety and would like to have continued further. Keeping track of changes and maintaining it would probably be a full time job though.

                                          1. 2
                                            1. 2

                                              We’ve been doing a lot of work to help make packaging Rust better, so hopefully we can get a Fedora package soon.

                                            2. 1

                                              I think the discussion is missing an important point: if your system design is broken from a security perspective, it does not matter what language you write your applications in, you will always have security flaws.

                                              A lot of security work today is done in firehose mode: fix exploitable flaws, and try to make steps to prevent as much of the currently common attack techniques as possible. C is extremely bad at preventing memory corruption and code execution, so we are developing tooling to catch these issues, trying to make C safer, and urging people to move to a language where this class of bugs doesn’t exist anymore. The “firehose security” model is the best we have if we constrain ourselves to work incrementally from the existing. Solutions proposed have to be evaluated in term of cost (or invasiveness) and effectiveness. But it can only ensure that some bugs have been removed, and is not very effective at proving the absence of bugs.

                                              We already have evidence that preventing out-of-bounds access to memory only changes the class of security exploits: the web. Web security exploits are full of cross-site scripting attacks, confused deputies, etc. Attackers are effective at breaking systems that do not suffer from C’s characteristic security flaws, and the work to defend from these attacks is not of the “move to a safer language” kind, it is system work: designing security policies, APIs, interfaces that guarantee security in a systemic way. In particular, the web has seen a resurgence of the object-capability model (thanks in particular to the advocacy efforts of Mark Miller) that had very positive effects on security architectures.

                                              The Unix security model is terrible at security, because it is full of ambient privileges. Applications are not properly compartementalized. Any application that I run, can, if it misbehaves, read everything in my home directory (which is nowadays just as problematic as playing with my root folder), perform arbitrary network communications, capture any input events (keylogging etc.; this is more about X than Unix, though, and is the part that may be solved soon), etc. If we had a properly compartementalized system, where programs run with only the privileges that are necessary to perform their task and no more, I would worry much, much less about each program’s memory safety and code execution. If the effects of malformed JPEG images was to let attackers display any image inside my browser, and no more, we wouldn’t be clamouring for a whole-system rewrite of all applications in Rust (not that this would be useless; it would still be a good idea). Good security system design beats language choices by a wide margin here.

                                              Unix systems try to develop Mandatory Access Control (MAC) solutions (SELinux for example). But as long as the MAC policy for an application is developed independently from the application, it will be very hard to make usable and much less effective. If we had applications designed for proper compartementalization, we would need much less MAC policies on top of them, and they would be much easier and robust to describe.

                                              A typical example would be filesystem access: when I ask to open a new file, LibreOffice shows me a file-choosing widget that explores my home filesystem to find the file I want. This is broken security design. What it should do is call a privileged file-choosing daemon which is small, isolated, easy to audit for security issues, and would show me a file-choosing widget by exploring my home filesystem, and only send back to LibreOffice an open file descriptor (in read-only or read-write mode according to what LO requested and the consent I gave to it). With this design, LibreOffice would not need the permissions to access my filesystem, just to access open file descriptors that were passed to it. No need to define a sophisticated MAC policy about which part of my filesystem I want to allow office applications to access.

                                              There are systems out there that are doing the right thing towards compartmentalization. On top of legacy operating systems you have Capsicum, which is a capability-security system that was integrated in FreeBSD and is being ported to Linux. For userland scripting there is Shill, designed to let you write scripts that respect least-authority principles. For kernel-level compartementalization there is Qubes OS. There is a renewal of excellent work in this area, and with enough contribution from interested parties there is a hope to make well-designed systems available to a larger public.

                                              (Note that Capsicum-Linux is aiming providing security primitives on top of a big monolithic kernel with an unsatisfying security record. This is bound to be much less secure that approaches with smaller trusted codebases – for the same reason that containers are not a sufficient answer to these security issues. But what Capsicum does which is invaluable is providing a programming API on top of which userland programs are incentivized to write well-designed compartmentalized code. This is why Capsicum matters. If today a killer micro-kernel system became as efficient and well-supported than Linux, it wouldn’t actually do enough good if userland design is still broken. Moving to Capsicum-friendly applications gives us the API support to develop a culture of userland compartmentalization that is essential to long-term secure systems.)

                                              There is no silver bullet for security. We need a mix of security approaches, and a layering of different techniques at different level. But if you are contemplating a rewrite of large parts of your userland ecosystem (in a different language or the same language), please, do not write the same applications again. Write new applications that are properly designed for security.

                                              1. 1

                                                I am curious what projects being rewritten in Rust would have the biggest payoff. Rewriting everything is interesting, but my intuition is that some projects would benefit more.