9 ms·
Bare Metal Rust Generics
- deleted 6y ago[deleted]
- agumonkey 6y agoLet's ask ADAers if they moved to rust
- KMag 6y agoI'm a huge fan of Rust, but I was under the impression that the domains where Ada is most commonly used are very risk-averse, so I presume Rust is still a bit young for a lot of the Ada use cases.
- eggy 6y agoI agree. Ada has been around and picked apart for high-integrity software jobs. I am personally learning SPARK2014, the subset of Ada. It has formal verification as part of the toolset. I would think Rust would need to develop similar formal tools and not just the PL to be used in the same industries as Ada/SPARK2014. I know somebody is going to link to the use of Rust for something in aerospace. I know Julia is touting something to do with air traffic control, but the core of these high-integrity applications need the full gamut of design tools around the PL. I still like Rust, but I am also playing with Zig.
- littlestymaar 6y ago> It has formal verification as part of the toolset. I would think Rust would need to develop similar formal tools and not just the PL to be used in the same industries as Ada/SPARK2014. There are people agreeing with you, and they are trying to make it happen: https://ferrous-systems.com/blog/sealed-rust-the-plan/ https://ferrous-systems.com/blog/sealed-rust-the-plan/
- eggy 6y agoThank you. I hadn't heard of it before. I would like to see it happen. I do think it will take many man-years to catch up with Ada/SPARK2014 and win industry favor and confidence, but it's good to see.
- OnlyOneCannolo 6y agoWould they even have a choice?
- agumonkey 6y agoGood point
- shakna 6y agoIgnoring that the engineering sphere that generally uses Ada works on multi-decade timelines, making Rust a bit too young and immature... Ada and Rust don't have 1:1 comparison on their safety guarantees. Rust makes a lot of guarantees around memory safety that Ada does not, whilst Ada is far more focused on correctness. Whilst related, these are very different.
- agumonkey 6y agowhat correctness does ADA focus on ?
- shakna 6y agoSPARK is a formal proving system for Ada. Formal correctness is what they focus on, that Ada can safely prove mathematically how a function will behave, and how a body of functions will behave. If you're using Ada without SPARK, it will try and enforce these same guarantees, but generally with a runtime contract system, rather than compile time.
- OnlyOneCannolo 6y agoI've always wondered this - Does the compiler actually use all that contract information, or is it just the prover?
- shakna 6y agoAs of Ada 2012, the redesign means that the compiler can make use of the contract information, and was one of the main reasons for a lot of the changes.
- OnlyOneCannolo 6y agoThat makes sense. Otherwise why bother conflating the programing language with the verification language.
- 6y ago
- k__ 6y agoDon't tell Go devs!
- deleted 6y ago[deleted]
- dgellow 6y agoI very much enjoyed the way the article is written. The good balance between technical details and humor.
- bluejekyll 6y agoI love this article, gives some great examples of decent abstractions to adopt in different situations to achieve the goals of the project. Great story telling. Right at the beginning this is a great quote: "I was wrong." We'd all do well to say that more often when it happens, and that's not about Rust, just life generally.
- phibz 6y ago...I imagine. Drawn beyond the lines of reason, push the envelope watch it bend
- phibz 6y agoConsidering the article title references sacred geometry and so does the Lateralus lyrics, I thought it was apropos, if a bit silly. Guess some of you disagreed.
- bborud 6y agoI'm hoping that someone will one day build a RTOS in Rust that can run on M0 (or smaller) devices, comes with decent tooling (so you won't need projects like Platformio to compensate for the horrific tooling that embedded platforms have), and abstractions that are "just so". The "just so"-bit is really hard. Embedded systems need something like Rust.
- AlphaSite 6y agombed and its RTOS was a rather nice platform when i fiddled with it.
- bluejekyll 6y agoHave you looked at Tock OS? https://github.com/tock/tock https://github.com/tock/tock I took a class in it at one of the RustConf's and that made me feel, even as a novice in the embedded space, that I would be able to do some great things. If I remember correctly the class was on an M0 board.
- bborud 6y agoThanks for the tip, will have a look. What is needed is to get chip manufacturers onboard - and to make them understand that they need to take software seriously. Right now the situation is a bit depressing. The ones that are ahead of the pack choose based more on politics and less based on technical merit. And most see this as a "solved problem" because people are provably able to write software for their devices. A lot of embedded developers don't really care that the toolchains are awkward because it "works for them". Which isn't helpful. And people easily get annoyed if you suggest that "perhaps this could be done less clumsily". There really isn't any easy way to say "this needs improvement" without provoking a defensive response. And people tend to be fairly frustrated when they get to the point where they reach out to get some help to solve problems. I still know of companies that skip using any RTOS and create their own OS-like infrastructure because the existing offerings are just too much of a time-waster. (Try to use Zephyr for a year on fairly new chipsets. The amount of time spent getting builds to work after upgrades is astonishing and reveals just how sketchy and fragile the tool chains are - which gives even seasoned embedded-devlopers used to sketchy and/or expensive tool chains pause). There have been "bare metal rust" initiatives for a while, but I haven't seen any that have gotten critical mass yet. Or buy-in from the hardware industry. I'm not sure why. I suspect the relative newness of Rust might be a factor. Perhaps people that have invested decades in C/C++ are afraid of starting over with a new language because they want to stick to what is familiar. I think we need to understand better what is needed to make this a success. I'm tempted to think that starting with the tooling might be a good idea. And assume that it needs to support multiple "kernels" (that might not even need compatible interfaces). One thing that is a bit interesting to look at is the difference in how Espressif and ARM have approached this. Espressif devices became popular in hobbyist segment where Arduino (or rather Wiring) was the "gold standard". Rather than fight it, they embraced and supported it. In not that many years this familiarity lead to lots of commercial grade stuff being made with Espressif chipsets - because they are cheap and there's lots of solutions on the web that can get you prototyping fast. This lead to widespread use of their devices and people "graduating" to using their FreeRTOS-based SDK. An SDK that now has pretty impressive support for anything from Audio to motor control. (As for ARM: their tooling and them kind of restarting mBed years ago and causing confusion, regressions in tooling usability etc made me ditch them and look elsewhere. Since the "professionals" didn't even use mBed it just wasn't worth the investment in time) With regard to tooling, it is worth looking at Platformio and ponder why there is a need for a tool to manage embedded toolchains - and what functionality the tool provides. Platformio is perhaps the most convenient system I've used for managing embedded projects. It still has some shortcomings, but it is miles beyond where the industry is right now.
- josh2600 6y agoRust is great. While working with Secure Enclave’s isn’t the same as a microcontroller per se (many SE’s work in tandem with powerful chipsets), at MobileCoin we’ve found a lot of benefits from using Rust. Rust appears to provide the ability to largely move to a world where the bugs are in logic and not in buffer/array verification or multi-threading. It feels like a real advancement to move up a layer of abstraction from plumbing to design. Time will tell, certainly it’s not impossible to have bugs in rust by any stretch of the imagination, but I have found that bugs in rust code tend to be more interesting than “out of bounds memory exception at line X.”
- Squonk42 6y agoIt looks like you can even run Rust on a small BluePill board featuring an STM32F103C8T6 ARM Cortex M3 with a modest 64 Kbytes of Flash memory and only 20 Kbytes of SRAM: https://github.com/TeXitoi/blue-pill-quickstart https://github.com/TeXitoi/blue-pill-quickstart
- wyager 6y agoI think the boards I used for http://yager.io/vumeter/vu.html http://yager.io/vumeter/vu.html had even less memory, like 8kbytes of SRAM or something. Rust wasted a few kB on error reporting functions, iirc, but other than that everything fit without too much effort as long as I didn't try to include soft-float emulation or something.
- throwaway894345 6y agoThe author cites "concern about binary size" bloat as a valid concern his colleagues have about generics. He explains that they normally would write distinct implementations. Am I wrong for thinking that generics shouldn't result in more bloat than the equivalent hand-duplicated code. And conceivably the compiler would be able to recognize that a List<&Foo> and a List<&Bar> are parameterized by equivalently-sized types and thus can share a single copy of the same generated code (although this might break inlining optimizations)?
- steveklabnik 6y agoYes, if you were to duplicate the code, you'd be doing the same thing as monomorphization. But it's possible that they wouldn't actually duplicate it, and do something else that would be smaller, like, casting to a void pointer or something. The compiler can do some optimizations like this, yes, but there's a lot more work to do in this area. As an example of something folks still do by hand sometimes, take the starts_with method on Path: https://doc.rust-lang.org/stable/std/path/struct.Path.html#method.starts_with https://doc.rust-lang.org/stable/std/path/struct.Path.html#m... It looks like this: pub fn starts_with<P: AsRef<Path>>(&self, base: P) -> bool { self._starts_with(base.as_ref()) } fn _starts_with(&self, base: &Path) -> bool { iter_after(self.components(), base.components()).is_some() } Why split this into two functions? Well, you can get smaller code size this way, because you're sort of "hand-de-duplicating" the parts that aren't generic. Once we call .as_ref, everything else is actually identical, but the compiler isn't good enough at this yet to do this itself, so we do it by hand. I wouldn't say this technique is super super common or well-known, just for the standard library (because it's used everywhere) and for folks that are sensitive to code size, like embedded or wasm people.
- oxymoron 6y agoGreat article. The writing style reminds me of James Mickens. For instance, this classic https://www.usenix.org/system/files/1311_05-08_mickens.pdf https://www.usenix.org/system/files/1311_05-08_mickens.pdf
- tomcatfish 6y ago:) This very link is used in the article where it is linked with the text "Zeus Hammers"
- __cuervo 6y agoHey! You just made my day. James Mickens (that article in particular) was a huge inspiration, especially the part about crying blood. May have been a bit too dramatic...
- oxymoron 6y agoIn that style, there is nothing too dramatic. ;)