Not comparing to Zephyr, which ticks all the same boxes, is absolutely a problem.
And I would argue that Arduino support nowadays is a negative, not a positive. Arduino support means that you are going to do a bunch of things to support 8 and 16 bit systems that look absolutely silly on 32 bit systems. And, it's not even clear that Arduino systems are actually cheaper or lower power than ARM Cortex-M4 systems anymore--which negates the advantage of Arduinos.
I completely switched to the Adafruit Feather M4 series for my hobby electronics about 5 years ago. Each board might be a little more expensive than a base Arduino, but they are way more powerful and have a lot of great features.
Which boards are you thinking of? "Blue pill" STM32F103C8 boards are $2 to $3, if you're willing to run the risk of getting a cloned microcontroller. (The clones are actually quite usable for most purposes.)
Oh, those! I have one of the F401 models -- I didn't know there was a F411 variant, though, nor that they've gotten so cheap. There might be a purchase in my future. :)
Not sure why you're being downvoted. ISAs like avr, 8051, and msp430 aren't really any crazier than arm. The archs that are a pain aren't because they're 8/16 bit.
As Wowfunhappy explained, it's actually a feature not a bug that your repost made it through. This is in the FAQ: https://news.ycombinator.com/newsfaq.html. I'm trying not to have to post like this every time:
Ipv6 should be the way to go nowadays, no ? For sensors network, people are using ipv6: as you don't have enough ipv4 adresses for computers and phones, you don't use ipv4 for sensors networks and IOT, that's a nonsense.
I would imagine almost all IoT devices in the home are using IPv4 at the moment, you can’t rely on IPv6 working properly with many ISPs. They don’t have to use public addresses, so scarcity isn’t a problem.
Tock OS[1][2] is way more promising since it's written in Rust instead. In 2020 there is no reason to invest time in anything new in C, apart from maintaining legacy software.
I'm not trying to be inflammatory, but do you realize how inadequate Rust tooling is for most embedded platforms? I'm all for embracing new technologies, but choosing to write a non-trivial embedded system using Rust on anything other than the most vanilla of ARM platforms would basically be an active attempt to sink the project.
The situation is no longer as dire as you imply. Cortex-M class processors have pretty robust tooling. Google chose TockOS - an RTOS written in Rust - as the foundation for their RISC-V based OpenTitan secure enclave after careful assessment of such concerns. The situation for Cortex-A isn't great but that's already trending well.
Google has immeasurable money and talent; you can choose whatever you want in that arena when you're a software company that employs nearly 100,000 people. Needless to say, most companies aren't like this.
Note that I said "the most vanilla of ARM platforms." If you're using a Cortex R microcontroller like a TMS570 or RM4, using Rust means that you're now missing out on the functional-safety-standards-compliant diagnostics library and various other tooling provided by TI that is a key part of the product, but hey, at least you have a compiler. 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.
None of this is to say that the situation can't be different in 10-20 years, but Rust is nowhere near as universally useful as C is in the embedded landscape, and that counts for a lot.
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.
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.
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! :)
> 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
Apparently Ada (among other alternatives) keeps being forgotten by Rust community.
Genode OS and NVidia are two high profile examples that decided to go with Ada/SPARK instead of Rust due to tooling, market certifications and not having to deal with borrow checker.
There is even a Webminar from NVidia explaining why they went with Ada, after considering Frama-C and Rust as possible alternatives.
Rust community has more to gain, by gathering around all the languages that provide memory safe systems programming, instead of trying to be Duncan MacLeod among them.
On positive note, Microsoft has held an internal Rust Summit, and Kenny Kerr has made public his first Rust/WinRT attempt.
I think it's incorrect to state that Rust 'forgot about Ada'. Rust was designed to approach safety in a very different way. Ada's take on safety has an emphasis on strong semantic typing and run-time correctness. Rust's take on safety emphasises compile-time correctness. Very different. I would argue that compile time safety is a better way to go but everything has trade-offs to consider.
Rust's borrow checker gets bad press because it forces programmers to confront their unsafe programming methodology and fix it. I think it's beautiful and ends up teaching you more rather than cultivating a culture of 'let me do what it takes to shut the compiler up so I can ship the product'. I find it very disingenuous to write the language off because it strives to be militant about safety.
Oh and Ada's compiler is super testy too! It just doesn't get the same bad press simply because far too few people use Ada compared to Rust.
I personally think that the reason people fundamentally add a moniker like 'Duncan MacLeod' to Rust is simply because Rust has gotten far too many things right and that irks dyed in the wool folks. Especially given that the choice of programming language is often enough a more emotive issue than a technical one. Having been one such person myself, I see a lot of folks spout FUD as a default position when confronted with evidence of the good design choices Rust has made. This is true.
Now that does not mean that Rust is perfect - not at all. However, it's safety features, in the face of high performance - are very compelling. Once folks draw a box around the emotive aspects and start doing objective analyses, Rust does make one pause and ponder. That's the reason why there is evidently a growing sub-culture of Rust enthusiasts even within large traditionalist companies like Google, Microsoft, Intel and Arm, to name a few.
Back to the point (!) Ada simply became too niche despite aiming to be general purpose by design. Today the open source Ada community is small compared to the Rust community and I think that is a huge problem for the perpetuation of the language, irrespective of the subset of high profile folks who've switched to it from C.
A large and vibrant community is the reason why Rust's future holds more promise. The language evolves by open source consensus-by-merit (on Github!) and that's a very strong proposition for it's future. Balancing nimble-ness and backwards compatibility has worked well thanks to the editions feature (something that C++ has now borrowed from Rust).
I'd love to see Ada succeed but at present I personally think Rust stands a better chance. Time will tell.
No need to talk about Ada in the past, it is alive and doing well, with more deployments into production that Rust currently has.
Yes the open source around Ada is not that big, not all programming languages need to embrace free beer to stay relevant, if they have something worth paying for.
Right now, they have the certified compilers, ISO standards (open source consensus-by-merit does not do high integrity computing), IDEs, debuggers, and 40 years of experience deploying code into production.
What irks me about Rust is statements like "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", which resemble the meme that "Rust Evangelism Strike Force" has become.
The only thing that this does is turn off the attention from anyone in the known about what Rust might bring into the table.
Finally, Rust's borrow checker also gets bad press, because it still considers invalid code that for a human is perfectly clear that it should compile, hence the Polonius ongoing effort. It also makes it quite hard to do any kind of GUIs without spreading Rc<RefCell<>> everywhere, hence Raph Levien efforts how to improve writing GUIs, and the regular GNOME/Rust meetings.
C++ has not borrowed epochs from Rust, some people were supporting a proposal, which was discussed at Prague meeting and deemed impossible to have such feature without spreading ABI breaks across TU or module interfaces.
"No need to talk about Ada in the past, it is alive and doing well, with more deployments into production that Rust currently has"
Of course. You may have misunderstood my intent - I'm not disputing Ada's strengths or it's penetration. I'm asserting that it does not have the same degree of general purpose appeal that Rust has today.
"Yes the open source around Ada is not that big, not all programming languages need to embrace free beer to stay relevant, if they have something worth paying for."
That's a very subjective opinion. I would assert that safety and security realities are forcing a fresh look at the importance of truly open source options. The mindset is now becoming more of - if you aren't doing open source then you are setting yourself up for pain - especially from a security standpoint.
"Right now, they have the certified compilers, ISO standards (open source consensus-by-merit does not do high integrity computing), IDEs, debuggers, and 40 years of experience deploying code into production."
Please read the thread above. I'm asserting that most software is not written for safety domains. While Rust has not penetrated the ISO26262 styled domains, those domains don't represent the bulk of software written and definitely don't dictate any given language's general purpose popularity.
Further: I would say that it is far less likely for Ada to break out of it's niche and appeal to the masses the way Rust has generally speaking. Also it is far more likely that Rust will make inroads into the functional safety space and given that it's already proving value in many general purpose segments it's likely to stick.
"What irks me about Rust is statements like "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", which resemble the meme that "Rust Evangelism Strike Force" has become."
Yes you seem to belong to the set that I was alluding to - and I mean that in a nice way. I too was in that set. On the balance of probability you will find that there is no need to get irked once you decide to make an empirical comparison of technical and strategic strengths of the 2 languages.
Also: 'Evangelising' empirically good options is never a bad thing anyway. Doing the same without any substance if definitely worth getting irked over. Not so in this case. Save your irk-cycles for something that is truly worth expending energy on - there's lots of that going around sadly.
"The only thing that this does is turn off the attention from anyone in the known about what Rust might bring into the table."
Again a very subjective and non-constructive viewpoint frankly.
"Finally, Rust's borrow checker also gets bad press, because it still considers invalid code that for a human is perfectly clear that it should compile, hence the Polonius ongoing effort. It also makes it quite hard to do any kind of GUIs without spreading Rc<RefCell<>> everywhere, hence Raph Levien efforts how to improve writing GUIs, and the regular GNOME/Rust meetings."
Agree. Partially. You're cherry picking but in this instance I think it's justified. The false positives with the borrow checker get a lot of attention. Furthermore, the Rust compiler's ability to infer memory lifetimes is evidently continually improving.
GUIs are a pain point but are now also getting attention. There are quite likely equally proportioned gaps for Ada as well. Or for any other language. Rust's larger community is definitely helping here.
"C++ has not borrowed epochs from Rust, some people were supporting a proposal, which was discussed at Prague meeting and deemed impossible to have such feature without spreading ABI breaks across TU or module interfaces."
You are quite right. It was a proposal and not a definite pick up of Rust's editions. That's still useful insight and acknowledgement of the predicament that C++ finds itself in when balancing nimbleness in terms of change and backwards compatibility. Rust has evolved a reasonable solution to it - in part because it's standing on the shoulders of giants but more thanks to the fact that it's a community consensus driven language and not a drive-by-ISO-committee language which C++ evidently is.
I'd rather seL4, which isn't written in rust but on a time-proven language (C) and yet has thorough proofs of doing what it's supposed to do, unlike this OS you suggest.
seL4 isn't really written in C, AFAIK it's written in Haskell then translated in C.
Because C is one of the few language to have a formally verified compiler CompCert.
Now does seL4 support properly modern CPUs: multiple cores, with different power settings?
This I don't know.
With the caveat that CompCert is mostly C99 and requires MISRA like C.
What about Spectre? It is an hardware exploit, thus there is only so much one can don in software to prevent it.
However that shouldn't be an argument for not improving the security of the IT stack, people still die when wearing security belts and helmets, but they surely do surving in higher rates than when they weren't a requirement.
Exploits due to logical programming errors, false premises, hardware bugs, will always be around, however reducing the attack surface is already a big improvement.
I'm a seL4 fan. However I feel the need to play devil's advocate! :)
seL4 may give you a formally verified kernel. However, formal verification is a dark art with very few high priests that actually understand it on the planet. Unless it becomes commoditised, it's not going to be popular. There has been some work towards that but it's still high-priest land.
Unless a significant portion of the software that runs on top of that microkernel is also formally verified, there's always risk of many sorts.
Oh and don't forget the fact that the hardware itself is likely not formally verified so open to attack.
That's a very absolutist way of thinking and therefore not very practical I confess - but hey I was playing devil's advocate.
If the Sealed Rust initiative succeeds then we may have a general purpose formal provability story at the Rust-LLVM-IR boundary thanks to the RustBelt project. That, in theory, will open the door to provably correct kernels and full stacks which I think is the right way to attack the problem.
From a high level view, I don't really what's really different for RIOT OS