6 ms·
There is some overlap in the use cases between Ada-in-the-mainstream (which seems to be what the article is suggesting) and Rust. The existence of Rust will mak
by jeffdavis 7y ago
There is some overlap in the use cases between Ada-in-the-mainstream (which seems to be what the article is suggesting) and Rust. The existence of Rust will make it even harder for Ada to break out of its existing domains.
Both seem to have good ecosystems, but quite different. Ada has more high-assurance tooling and practices. Rust has more in terms of packaging and general-purpose high level libraries.
With Ada, it's pretty hard to shake the feeling that it's not as welcoming. Either you are building a spacecraft, or "what are you doing here?". Not that anyone actually says that, and in my limited experience playing with the language, everyone seemed nice. It's just a feeling that's hard to escape. I wish it weren't so, because I think Ada has a lot going for it and it could be good in more donains.
One kind of cool thing is that it's designed to get by without so many heap allocations, and it does some interesting things to allow/encourage more stack allocations. It also has more sophisticated runtime checks, like contracts, that are kind of between a unit test and a compile-time check.
Rust is great at managing complexity. I keep holding out hope that Ada can somehow give us some simplicity back while still making useful software.
- im_down_w_otp 7y agoI understand what you're getting at here I tbink, but one of the ecosystem challenges we run into is that while Rust is abstractly a fantastic choice for the domain of systems development that would often be served by Ada (in fact we think it's a lot better in some respects because we can do more statically ahead of time, that Ada does dynamically at runtime, by abusing the Rust type system and borrow-checker), the Rust ecosystem isn't really focused on this class of problems. There's significantly more attention provided to things like Wasm than there is to things like embedded use cases for example. The two languages, ecosystems, and communities seem to have largely non-overlapping objectives despite having overlapping technical capabilities.
- Gibbon1 7y ago> ore attention provided to things like Wasm than there is to things like embedded use cases for example. Things might be better, but last time I checked rust's compiler was a lot slower than C and the binaries were several times bigger. That last one is a big deal for embedded.
- steveklabnik 7y agoYou can get Rust binaries just as small; the smallest known one was 145 bytes. Some defaults were recently adjusted to make them smaller by default too. https://github.com/tormol/tiny-rust-executable https://github.com/tormol/tiny-rust-executable
- dev_dull 7y agoNobody wants to play with their compiler to get a small binary. Languages are typically judged by their defaults. If rust can produce small binaries, then it must produce small binaries.
- devnulloverflow 7y ago> The two languages, ecosystems, and communities seem to have largely non-overlapping objectives despite having overlapping technical capabilities. I keep thinking servers should be written a bit more like embedded thingies. (Though I suspect the actual trend is in the other direction). Both kinds of software deeply interested an asynchrony and concurrency (though not necessarily parallelism). And both also tend to talk over networks to other gadgets as part of a complex system. And since my job often revolves around putting out fires when severs OOM, I'd also like to see a lot less malloc(). It would be nice if software could place hard upper limits on how many resources (including RAM) it takes to serve a request and then reject requests early. With real-world languages and frameworks, we can only do very primitive approximations to this. But a framework written from the bottom-up with a malloc-is-evil mentality () might be able to do it.
- swsieber 7y agohmm... there are many libraries that are no-alloc. It seems quite feasible (well, that and custom allocators are a thing now)..
- im_down_w_otp 7y agoWe have a crate internally that uses type-level programming to do statically tracked memory allocation (technically the method can be used for other kinds of resource management too), so that we can have compile-time guarantees that allocations will always succeed and we'll never allow memory to be allocated from inappropriate regions (e.g. mapped registers). Layered on top of that we can also ensure that if at runtime your device memory configuration is sufficiently different from what your assumptions were at compile-time, then we don't allow the device to boot so that you don't end up in a dangerous resource exhaustion situation by accident. We use this for no_std embedded shaped use cases, but you could also use this library and programming model to create a special heap in your normal programs which have statically tracked allocations to create some region of your program context that you want to have assurances like that. We have 3-4 things kind of in that vein in our pipeline to open source, and I think that's number 3.
- fluffything 7y ago> There's significantly more attention provided to things like Wasm than there is to things like embedded use cases for example. Rust is a language developed by its users. The reason less things happen in Rust embedded domain, is because less companies pay people to work on embedded Rust than they do on WASM rust.
- haolez 7y agoHaving a big ecosystem of libraries is not even close to a big concern when developing critical applications like what Ada seems to be used for.
- jeffdavis 7y agoBut it is a concern for bringing Ada into more domains, which seemed like the point of the article. EDIT: on a second read, it's not clear whether the article is saying we should use Ada the next time we are building a rocket, or the next time we are building an OS.
- ddoolin 7y agoThere was a post here recently about an attempt to bring those concerns to Rust: https://ferrous-systems.com/blog/sealed-rust-the-pitch/# https://ferrous-systems.com/blog/sealed-rust-the-pitch/#
- dev_dull 7y agoTotally. For defense, I think a large third party ecosystem is pointless unless every square inch of it has been verified for compliance. Do people think part of missile software includes “npm install wordpad”?
- oblio 7y agoNo, but I would expect it to contain "npm install launchpad" :-p
- elamje 7y agoInteresting, I am highly interested in convincing NASA to start using Rust for their embedded systems they use on ISS experiments and such. I would love to get more widespread adoption at the embedded system level.
- davesims 7y agoWe came to the same conclusion at Kubos, and moved from C to Rust for most of our flight segment/application code (embedded Linux on the satellite OBC). https://www.kubos.com/ https://www.kubos.com/
- elamje 7y agoAwesome, do you think it’s a hard sell for old school government contractors? I am passionate to write embedded systems with Rust, but I worry it will be too hard of sale to d school contractors with stacks already written C, and C developers on staff.
- davesims 7y agoI've had a good number of conversations actually with some NASA FSW coders, and in general they're open to these ideas. NASA has a project with architectural and structural goals pretty well-aligned with what we set out to do at Kubos: https://cfs.gsfc.nasa.gov/Features.html https://cfs.gsfc.nasa.gov/Features.html The biggest challenge is to prove that it works. The space software community historically is very conservative and risk-averse, and mostly for good reason. As Kubos (and hopefully others) get more flight heritage with Rust on the flight segment, it'll be a much easier sell. That's the biggest obstacle I think. Someone will have to break the seal and establish that "Rust in Space" actually succeeds consistently, then larger "trad space" organizations will follow.
- antocv 7y agoI still cannot forgive Rust for not learning anything from Ada. "Code is read more often than it is written". Reading Ada is so unambigous, and clear. If you mean if then, you have the keyword then, when you want to say procedure you say procedure and you can read that. Rust? fn, because is it fun, or functor, so fuck you.
- Ono-Sendai 7y agoDo you really want to type out 'procedure' thousands of times?
- olzd 7y agoYou type 'proc' and let the editor autocomplete that for you: this is a long solved issue.
- antocv 7y agoYes of course, even if my IDE doesnt autocomplete anyway. Code is read much more often than it is written. Yes, I do want to read out what I type and possible speak it to collegues without sounding like I have a fn seizure.
- OneWingedShark 7y agoYes. Because the alternative is idiotic, hard to read BS like fn. The problem is that "fn" is optimizing the WRONG things: not only is your code going to be read more than it is ever written, but this abbreviated form is actively hostile towards domain-level subject-matter experts that you may want to audit or verify your code. Now, instead of him jumping into code that reads like English (Ada), now he has to 'decode' Rust BEFORE AND DURING his evaluation of the code, distracting him from his purpose.
- jhomedall 7y agoYou learn what 'fn' means once, and then you know it forever. It's a non-issue.
- 7y ago