3 ms·

"Google has immeasurable money..." True. In the context of this thread, note however that the risk of continued fragmentation when it comes to security enclave

"Google has immeasurable money..." True. In the context of this thread, note however that the risk of continued fragmentation when it comes to security enclave architecture has made Google open source a very good design in OpenTitan to woo not just deep-pocketed open source friendly chip vendors etc but also any scale of open source software shops to promote the tech. Google wouldn't go down this path unless it had very good ideas about the adoption of Rust in this space - irrespective of the scale of the entities involved and definitely considering the long-term viability of the language. "If you're using a Cortex R microcontroller..." I take your general point. However I think you may be cherry picking the functional safety argument. I agree that Rust has not penetrated functional safety ISO61508/ISO26262 domains and as such it will take a fair amount of work to get it at par with C. BTW there's efforts underway to solve that with Ferrous Systems' Sealed Rust initiative. However - and this is a contentious one - most embedded software is not written to comply to safety standards compliant. A lot of the software that is bracketed under the 'embedded' umbrella is the sort of software where the use of C today is a problem from a security standpoint and that is where Rust's value is increasingly being appreciated. Does that more general embedded software require tooling that C has but Rust doesn't ? I'd say it's quite the opposite actually. Some of the packaging, distribution and updating ease that Rust has by virtue of it's top-class tooling is something that C shall likely never have - at the language level. More specifically about Cortex-R: The Rust embedded working group has teams dedicated to Cortex-M (the most popular 'IoT' target) and the ecosystem there for bare-metal development or RTOS centric development is actually pretty rich. Try it. For Cortex-A less so but that's getting sorted slowly. There is a proposal to have a Cortex-R group now and I am confident that Cortex-R support will trend well. Again - the kind of generic tooling associated with embedded software - such as compilers, debuggers (both general and run-time specific - say for a given RTOS etc) - all of that exists already and the support for those will most certainly increase in the short term. "If you're using 8051, a lower-end PIC, RX, RL78, RH850, 68k, etc, you don't have a compiler at all. That's a pretty dire situation..." I don't disagree. I must confess I'm quite biased but I think the long term trend shall be towards a smaller set of more capable ISAs and from that standpoint I think things will converge towards the set of Arm, x86 and RISC-V, support for all of which exists in varying forms already - most very good. Totally agree that if you want to use a PIC etc then you the situation from a fundamental language support PoV is arguably dire. Personally I would future proof my design and move away from those processor choices on the double if I want to be connected - and even if not. Overall the memory safety that C has thrust upon an increasingly unsafe and insecure planet is a serious problem and I haven't seen any real scalable counters to Rust from an open, expressive, feature-rich and performant PoV.

seabird 7y ago
Rust tooling certainly has plenty of time to improve and target more architectures. Vendors are extremely slow, but I do understand that in 10-20 years, it's very possible for Rust support to be on par or beyond C. Do remember that the comment I initially replied to was saying that there's no reason to start any new C codebases in 2020 when Rust exists, which is a pretty ridiculous claim considering that we're at least a decade from reasonably well supported vendor tooling being available for most commercial projects. As for the ISA convergence argument, I don't think things will pan out that way. Different ISAs exist because of a combination of very compelling price points (remember that you have to license ARM), compelling features, nearly unstoppable historical momentum (PIC is a big one in this arena), golf-course deals, or a combination of all of the above. Time will tell on this one, but remember that everything that has happened up to this point happened for a reason, and history has a way of repeating itself.
- fork-bomber 7y ago
  The 'any' in that person's comment was ridiculously absolutist, I agree. Looking at things from a more general standpoint, there are many examples of Rust being used in production already. Admittedly as previously stated where the need for functional safety assessments aren't stringent nor is the need for a robust set of commercial grade tools. That's still a solid chunk of the market. I think a lot of open source projects that land in commercial products don't have the same degree of quality tooling associated with commercial counterparts. That doesn't stop those products from succeeding. On the basis of examples such as Microsoft's disclosure of the use of Rust in the Windows 10 kernel's IPC COM bridge, Google's use of Rust in OpenTitan and a couple of others that I'll need to dig up (but evidently do exist in the public domain), I would say that in the general case Rust doesn't need a 10-20 year horizon to work in the same general spaces as C. Time will tell how true that ends up being but the trend is quite clear to me (and I was a Rust nay-sayer for quite a while before actually doing a reasonably sized OS kernel port that made me see the value). Excuse the slight meandering but you come across as the sort of person who would appreciate some of these points. The significant value add that Rust brings is compile time memory safety - something that C/C++ simply don't have or likely to in a scale-deployable manner. The security and safety stick is hitting so hard now that a lot of the traditional arguments against an upstart programming language option are now seemingly more palatable to a lot of shops. There's a lot more to Rust then just the memory safety - I often lament about how the other bits don't get enough attention. The threading is top-notch, the expressiveness as a result of functional patterns is addictive (I find myself using Rust programs as alternatives to everyday Python/Ruby scripting - 'tis true!), the generics are lean and not overwrought as C++, the composability using traits is a good middle-ground to insane class hierarchies in C++. I could go on! Now it may be that there emerges another alternative but at present Rust has blazed a memory safety trail that I don't see anyone in a position to challenge. When C and C++ are massaged to get to a similar space, they likely won't be the same languages anymore anyway. Speaking about performance parity as a related aside: As an admittedly crude but IMO representative example Rust is already at par or better than C and/or C++ for the only truly open and idiomatically comparable suite I could find - drum-roll...micro-benchmarks - specifically The Benchmarks Game (results publically available). Now I concede that micro-benchmarks don't represent reality but they are what _every_ compiler engineer uses first to sanitise their port (and even what a lot of processor architects use in their RTL simulations - because that's often all they can run to completion at KHz rates) and therefore have good representative value in the first order. More representative macro-level use-case comparisons are harder but there are sufficiently many examples of higher level frameworks (web servers etc) that showcase Rust's safety and performance. Those didn't require commercial grade tooling and a fair number are being used in production today. About ISA convergence - and talking about the low perf deep embedded end - which is where the compiler tooling is lacking - Arm has been providing zero dollar cost licenses for the past 2 years now. See Arm DesignStart Eval and DesignStart Pro. You can do Cortex-M0 and Cortex-M3 evals at 0 USD upfront cost and have pretty much the same royalty arrangement as you would with any alternative. Heck at 75K USD you can even do a Cortex-A5. Such initiatives are likely only the beginning so the trend is quite likely going to be convergence. That's all speculation I admit but the argument is a lot easier to buttress with concrete examples now. I would urge folks to give Rust a go. Wait - that sounded like a pun! :)

seabird 7y ago

Rust tooling certainly has plenty of time to improve and target more architectures. Vendors are extremely slow, but I do understand that in 10-20 years, it's very possible for Rust support to be on par or beyond C. Do remember that the comment I initially replied to was saying that there's no reason to start any new C codebases in 2020 when Rust exists, which is a pretty ridiculous claim considering that we're at least a decade from reasonably well supported vendor tooling being available for most commercial projects. As for the ISA convergence argument, I don't think things will pan out that way. Different ISAs exist because of a combination of very compelling price points (remember that you have to license ARM), compelling features, nearly unstoppable historical momentum (PIC is a big one in this arena), golf-course deals, or a combination of all of the above. Time will tell on this one, but remember that everything that has happened up to this point happened for a reason, and history has a way of repeating itself.

fork-bomber 7y ago
The 'any' in that person's comment was ridiculously absolutist, I agree. Looking at things from a more general standpoint, there are many examples of Rust being used in production already. Admittedly as previously stated where the need for functional safety assessments aren't stringent nor is the need for a robust set of commercial grade tools. That's still a solid chunk of the market. I think a lot of open source projects that land in commercial products don't have the same degree of quality tooling associated with commercial counterparts. That doesn't stop those products from succeeding. On the basis of examples such as Microsoft's disclosure of the use of Rust in the Windows 10 kernel's IPC COM bridge, Google's use of Rust in OpenTitan and a couple of others that I'll need to dig up (but evidently do exist in the public domain), I would say that in the general case Rust doesn't need a 10-20 year horizon to work in the same general spaces as C. Time will tell how true that ends up being but the trend is quite clear to me (and I was a Rust nay-sayer for quite a while before actually doing a reasonably sized OS kernel port that made me see the value). Excuse the slight meandering but you come across as the sort of person who would appreciate some of these points. The significant value add that Rust brings is compile time memory safety - something that C/C++ simply don't have or likely to in a scale-deployable manner. The security and safety stick is hitting so hard now that a lot of the traditional arguments against an upstart programming language option are now seemingly more palatable to a lot of shops. There's a lot more to Rust then just the memory safety - I often lament about how the other bits don't get enough attention. The threading is top-notch, the expressiveness as a result of functional patterns is addictive (I find myself using Rust programs as alternatives to everyday Python/Ruby scripting - 'tis true!), the generics are lean and not overwrought as C++, the composability using traits is a good middle-ground to insane class hierarchies in C++. I could go on! Now it may be that there emerges another alternative but at present Rust has blazed a memory safety trail that I don't see anyone in a position to challenge. When C and C++ are massaged to get to a similar space, they likely won't be the same languages anymore anyway. Speaking about performance parity as a related aside: As an admittedly crude but IMO representative example Rust is already at par or better than C and/or C++ for the only truly open and idiomatically comparable suite I could find - drum-roll...micro-benchmarks - specifically The Benchmarks Game (results publically available). Now I concede that micro-benchmarks don't represent reality but they are what _every_ compiler engineer uses first to sanitise their port (and even what a lot of processor architects use in their RTL simulations - because that's often all they can run to completion at KHz rates) and therefore have good representative value in the first order. More representative macro-level use-case comparisons are harder but there are sufficiently many examples of higher level frameworks (web servers etc) that showcase Rust's safety and performance. Those didn't require commercial grade tooling and a fair number are being used in production today. About ISA convergence - and talking about the low perf deep embedded end - which is where the compiler tooling is lacking - Arm has been providing zero dollar cost licenses for the past 2 years now. See Arm DesignStart Eval and DesignStart Pro. You can do Cortex-M0 and Cortex-M3 evals at 0 USD upfront cost and have pretty much the same royalty arrangement as you would with any alternative. Heck at 75K USD you can even do a Cortex-A5. Such initiatives are likely only the beginning so the trend is quite likely going to be convergence. That's all speculation I admit but the argument is a lot easier to buttress with concrete examples now. I would urge folks to give Rust a go. Wait - that sounded like a pun! :)