If their code was written in Rust, that sort of bug could not have occurred.
If their code was written in Rust, that sort of bug could not have occurred.
Nearing a half-century of momentum in the community which includes developers, mature tools, etc. Until rust arrived it was nearly the only game in town for predictable low-latency systems programming.
Yes, now that Rust's here there's a bit of an alternative. But if you've got a team of 30+ software devs who know C/C++ and an existing well-tested codebase of millions of lines, even if you had multiple Rust champions it would take a very long time to evolve towards Rust.
If the answer is "no static analysis tool", there's your problem.
But as my first paragraph implied, they can't catch everything, so "we installed many layers of protection and it still got through even so" is definitely a possibility. Rust may have a different set of such issues but they will of course always exist.
AFAIU the JSF software is done in C++, there is (or at least used to be) some JSF coding guidelines document on Bjarne Stroustrups web page. Of course, blaming C++ for the JSF boondoggle is unfair, but still, one wonders whether it was wise of the DoD to allow C/C++...
Maybe the "badass 'C' hax0r" meme was stronger than I realized. But I think a lot of it was just switching cost.
If you mean this one[1], it's merged. Still lots of work to do, and even more corners where things will shake out[2], but there's definitely progress.
[1]: https://github.com/rust-lang/rust/pull/33460 [2]: https://github.com/rust-lang/rust/pull/34174
This is feasible in a sense, but C is a fairly tricky target to compile to: you have to make sure that you don't accidentally include UB in the code you generate. I know pcwalton has lots of feels here...
The easiest way to do it would be if LLVM had a C backend; I know that it did, but it was removed a few years back, and I haven't heard anything about it coming back into tree yet. MIR might also in theory enable new backends, but then you'd have to re-implement all of the optimizations that we currently rely on LLVM supplying.
(out-of-tree) fork(s) have been kept alive by several groups. The most current one I'm aware of is: https://github.com/JuliaComputing/llvm-cbe
This sounds more like generating 'C' is a distraction rather than a goal.
The code base is so modified by macros/typedefs its hardly even C anymore.
Not to mention the LLVM has to support the embedded device you are targeting. And Rust's support of legacy CPU's (8008, 8080, 80386, 68000) are lacking.
Rust won't change anything about this, if there would have been interest in changing the situation other alternatives like Ada would have been available for years.
( no snark; I hope you get my point )
Ironically, reliability is actually a value of merit with 'C'/C++ - in cases. It's just that the ways of doing that seem rather inaccessible these days, or the flow of people past seeing them is not working out.
I don't think there will ever be a way around developing proper test vectors. It's quite interesting work but it tends to go unrewarded.
Programming languages isn't just fashion, we invent them because we thing we can solve old problems in better ways.
Most of my co-workes doing C++ never even wanted to look at the alternatives. Being the only thing they have ever done, they don't even realize how bad it is. They have just internalized it.
The interesting question is - are there actually fewer defects, objectively, or are they simply rendered .. something like latent?
One I fixed in... April - if the file system on an SD card was scrogged, writing to the file system crashes the box. So I moved the write of a configuration file from the event of a switch change ( because if the switch was never put in that position, then there was no reason to ever do that ) to the top of the program so it'd crash when you powered up.
It helps me personally to think that defects are just something I've chosen to do despite my best effort. Keeps me on my toes. I certainly understand people being fatigued by that.
There are other safe languages they could have used which have a longer track record than Rust, e.g. Ada. It's used in avionics. Why shouldn't it being used here?
I do not know what kind of unsafe memory access happened in their systems, but you can do all sorts of memory opperations and as long as the explicit typecasts are a-ok misra won't flinch.
My take is that while there is some overlap, MISRA is unable to guarantee anything, while Rust is able to guarantee certain things that C can't. (that's from my limited understanding of Rust, I haven't futzed with it yet)
Almost any other statically typed language, along with similarly strict guidelines, would be preferable to C, but there is no ideal language. Rust still allows dynamic heap memory allocation and recursive functions. It is also new. Ada has been used for decades.
Applying them feels like buying indulgences. :)
1. Most of those platforms don't have compilers for any languages other than C(++). If the platform has a lot of history behind it, maybe you could write it in Ada, but that's pretty much it.
2. Development tools (debuggers, static analyzers, standards compliance verification tools and so on) for C and C++ are very hard to match, both in strength and in sheer availability. In the meantime, Rust still relatively recently got decent GDB support.
3. A lot of Rust's features simply aren't needed when writing this kind of software (e.g. the breadth of features related to memory management is largely unneeded because everything is statically allocated).
4. For better or for worse, C is well-understood (C++ is... well, not that I haven't seen good safety-critical code written in C++, but in my experience, C++ code is a lot easier to get wrong, both by humans and compilers). Rust isn't, not yet in any case. There's no Rust equivalent for e.g. MISRA, and not because Rust doesn't need one.
5. To, uh, put it bluntly -- C and C++ are very well known in the far corners of the world where a lot of this software is outsourced. Rust -- not so much, because outsourcing companies don't really encourage their employees to learn this kind of stuff.
6. There's a lot of commercial risk involved. I'm not sure about autonomous vehicles, this is probably a more volatile field, but many safety-critical systems have to be maintained for a very long time (10 years is fairly common, and 15-20 isn't unheard of). Rust may well be dead and burried ten years from now, whereas language enthusiasts have been singing requiems to C (on roughly the same tune as Rust, no less) for almost thirty years now.
Rust is a great development in this field and I can't wait for the day when we'll finally put C (and especially frickin C++, Jesus, who writes that!) to sleep, but it's at least five years away from the point where I'd even half-heartedly consider it for a project with critical safety requirements.
> If their code was written in Rust, that sort of bug could not have occurred.
I don't know the specifics of the bugs you mentioned, so I can't really comment on this, but in my experience, most of the similar claims that float around the Interwebs are somewhat exaggerated when put in their proper context. E.g. Heartbleed, which wasn't because C something something PDP-11, but because someone decided to be smart about it and implement their own (buggy) memory management system so as to make the damn thing run decently on twenty year-old operating systems.
I've seen people write that kind of code, for similar reasons, in Java and Go -- and, at least once, with Heartbleed-like results. The ways in which a language can be misused rarely reveal themselves before that language breaks out of its devoted community.
To be clear on it though -- I think Rust is a step in the right direction, and one that we should have taken a long, long time ago. If it can make it through its infancy, and if it can get enough commercial support, it will be a great alternative to C and C++.
True, but I don't think that Rust's other features wouldn't be useful here. References which know about mutability/immutability, sum/enum types, "fat" pointers/slices w/ bounds checking, the ability to construct library APIs which enforce non-memory safety through session/affine/linear types, sane integer typing, etc, could all still be useful to a fully-statically-allocated program.
Rust doesn't exactly need these, no? Most static analysis in C/++ is safety/UB focused. Rust doesn't need this, unless you're going to spend a lot of time with `unsafe` code.
Rust does have clippy, a lint library with >150 lints which catch things ranging from correctness to style to safety issues. I'm one of the maintainers, so I'm biased, but I've personally found it to be much better than its equivalents in C++land. Perhaps not Javaland.
It's issues related to timing constraints, incomplete branches, common but subtle mistakes (e.g. in C, suspicious memory allocations, like malloc-ing strlen(x) instead of strlen(x) + 1 bytes) and so on. E.g. http://www.viva64.com/en/examples/ . Many of these are, indeed, because unsafe memory access allowed without restriction, but they're fewer than one might expect. Most of them are either language warts which no language is devoid of, no matter what its fans would say) or programming blunders that occur because our brains work the way they do.
For the rest, Rust does have static analysis tooling of the kind you describe in the form of clippy. There's still a lot that can be done, but it's already quite helpful and catches all kinds of things.
It depends on what you're working on. In the context of the original question of the thread (i.e. autonomous vehicles), I'd consider memory access to be the least difficult thing that static analysis can help me with. With code review, careful structuring of your data and, if it's available, hardware support for memory access models (e.g. ring buffers), memory access bugs can be reasonably avoided even without code analysis tools (not that it should!). Things like timing analysis are a lot harder to do without proper tools.
> For the rest, Rust does have static analysis tooling of the kind you describe in the form of clippy. There's still a lot that can be done, but it's already quite helpful and catches all kinds of things.
I would, uh, rather not be put in a situation where I have to send documentation to an approval body, and have the documentation mention -- as the only static analysis tool that was used -- a community project that's at version 0.0.75.
For comparison, there was a thread around here a while ago, where I think Gerald Holzmann from JPL mentioned how they used several (something like the top 5) code analysis tools to check their code. A top of all available static analysis tools for Rust would be a lot shorter than that.
This kind of stuff is important for mission-critical applications. I like Rust and I think it's a step in the right direction (and would certainly love to see it go all the way in that direction!) but I'm not about to write code that could kill people in a language whose only viable compiler barely reached 1.0, barely has a working debugger and only lint-level static analysis. It's the right track, but we're not there yet.
Edit: oh -- and I would like to point out one thing that seems to be often lost in the HN bandwagon. If you look at the numbers, it turns out that programmers have been able to get C and C++ to perform reliably for quite some time now. Failures are high-profile, but by and large, the medical, space and automotive industries have been doing a pretty good job at delivering safe tools, considering how many cardiac pumps, cars, airplanes and spaces probes are around and how few of them fail. It goes without saying that we should aspire for better, but the status quo is really hard to beat.
Heh. Yeah, clippy has a lot more to do, and it's not a product with official support, but so far it's been pretty useful :) The version number is just because I want to have an rfc about it before I release a 1.0.
But yeah, it's nowhere near the level of lint tooling C++ has. For most people, I believe it might be sufficient, but for mission-critical stuff I'm not so sure -- you're probably right. Though Rust's type system also might help in creating safety guarantees (non memory safety) for mission critical things.
> only lint-level static analysis
what do you mean? Clippy calls itself a linter because it uses the lint API, but it does all kinds of static analysis. The meaning of "lint" in the Rust community is slightly overloaded.
> if you look at the numbers, it turns out that programmers have been able to get C and C++ to perform reliably for quite some time now.
Of course :)
The instability of the pre-1.0 days left a very bad impression on many people who tried Rust then. They came to know Rust as a compile-today-but-not-tomorrow kind of language. What, if anything, is being done to try to inform these people that the situation has changed, to encourage them to try Rust again? What's being done to restore Rust's reputation?
A lot? For example, "Stability as a Deliverable", which was here on HN: http://blog.rust-lang.org/2014/10/30/Stability.html
I'm not sorry for opening up the language during its early development. The alternatives would have been to produce a deeply flawed language or to keep the language secret. Both of these are far worse than a few ignorant comments.
That put me off starting to develop something in Rust right now, unfortunately, because I'm a huge fan of the way Rust was developed and its core ideals.
In any case, even if you're using nightly your code won't break nearly as much as it did pre-1.0. We use nightly in Servo and we've been through dozens of Rust upgrades that sailed through without a hitch--and we have 150+ dependencies.
This means that while Rust-the-language is stable, the ecosystem around it isn't quite yet. That's perfectly fine and it's nobody's fault, least of all the people developing the language. But it is one of the barriers to me picking it up right now, though.
The programming community of people who actually write real things and create production software, I highly doubt any of those people are the people you are referring to and thus Rust should be doing nothing to restore its reputation with those people, as they are ignorant and/or highly incompetent, and I hope they never write a piece of code that makes it into production.
We try to be fairly vocal about the things we're doing here, but of course, it can be tough to get the word out. While some people may not know things have changed, a lot of people also do.
Some examples of things we do to ensure stability:
* The RFC process requires lots of discussion before major change happens, to ensure we can do things in a compatible way.
* We run a tool, "crater", both on PRs that we are worried might cause issues, and just in general. This tool compiles all of the open source Rust code on crates.io with the new revision, and reports problems. It's not perfect, but it helps a lot.
* For that matter, we don't merge any code ourselves; bors manages a fleet of 30ish machines that test every commit with our full test suite.
* We recently added three significant crates (and their dependencies, which last I checked was around 80ish crates in total?) to be part of our test suite, so we know that they build properly on every commit.
Releasing something called 1.0.
http://blog.rust-lang.org/2014/10/30/Stability.html
EDIT: As you can see from the number of responses you got, this matters a lot to the Rust community :-)
Rust has been _extremely_ vocal about its stability guarantees. Not sure what else can be done here.
Except Rust allows for less undefined behavior. I wouldn't be surprised if it improved at a faster rate then C. Or C++ ()
() Please don't say C/C++. They are different beasts.
These contexts you speak of are rare enough that the "no-C/C++" heuristic is useful.