The title in the article is literally "Async Rust vs RTOS showdown!" and the article shows "Embassy/Rust against FreeRTOS/C". There should also be a (2022) appended.
You just need to read the Reddit comments to see why this is not a useful comparison [1] [2].
Technically RTOS’s can also be cooperatively multithreaded, to some degree at least (see FreeRTOS). The comparison is valid IMO as threading with fixed yield points is an abstraction that isn’t exclusive to async Rust.
I can't help but think at this point that Ghostty's "departure" from GitHub is unserious. It's been two and a half months now and not even a single peep of discussion about where they may be migrating to or what they may be doing.
I'm honestly a bit shocked this was done entirely using declarative macros. Normally when I see such arbitrary syntax I assume it's implemented as a proc macro.
I once wrote a pure C project years back that made heavy use of complex numbers and 2D/3D vector math. At one point I got so fed up debugging my expressions under an endless parentheses-hell of `vadd(vmul(vadd(...), vadd(vmul(...))))` that I threw my hands up and changed the file extensions to .cpp just to use std::complex<T> and enough operator overloading to type vector expressions like a human being.
Honestly, I don't know. I think it's because of frustration, but the community attitude is part of it. I experienced first hand people frustrated with Rust moving to Zig and finding other people to pick onto Rust and finding fertile ground (especially if moderators and heads of the community let this kind of behavior continue).
Rust has never been about outright eliminating unsafe code, it's about encapsulating that unsafe code within a safe externally usable API.
When creating a dynamic sized array type, it's much simpler to reason about its invariants when you assume only its public methods have access to its size and length fields, rather than trust the user to remember to update those fields themselves.
The above is an analogy which is obviously fixed by using opaque accesor functions, but Rust takes it further by encapsulating raw pointer usage itself.
The whole ethos of unsafe Rust is that you encapsulate usages of things like raw pointers and mutable static variables in smaller, more easily verifiable modules rather than having everyone deal with them directly.
>when you a pass a pointer to my function, do I take ownership of your pointer or not?
It's honestly frustrating how prevalent this is in C, and the docs don't even tell you this, and if you guess it does take ownership and make a copy for it and you were wrong, now you just leaked memory, or if you guessed the other way now you have the potential to double-free it, use after free, or have it mutated behind your back.
I remember talking about this concept with my brother a while back. Since LLMs have no neuroplasticity, they are locked in to what they were trained on in the time they were trained in. A model trained in 2026 would stay exactly the same for use by someone in 2126 to gain an insight on our time. Like a book that you can actually talk to.
Perhaps "Embedded async Rust vs. C RTOS"
reply