I was thinking a lot in terms of device support too, I guess. That's important to me; I know with C that I don't have to think too hard about which device, at least in terms of "Does this board support my language well".
It's probably even more important for professional embedded engineers, where the hardware decisions may not even be made by the software developers, for various reasons.
Again, not speaking from experience here, but it should be easy enough using tools like https://docs.rs/bindgen/0.31.3/bindgen/ to generate FFI interfaces to C libs where that is needed.
So, I wouldn't necessarily say that's a blocker. Obviously everyone should make the best choice given their business requirements, etc.
Good point, although one advantage with Rust is that it plays well with C -- so you could keep some C drivers or libraries, and do the rest of the work in Rust. That reduces attack surface area while providing a smoother on-ramp to full device support.
> one advantage with Rust is that it plays well with C
Advantage over what? This can be said about the majority of programming languages
For example, I’ve recently done an embedded ARM Linux project where I used C# and .NET Core for higher level parts, C++ for lower level, [DllImport] and C API between the two.
You're considering the "call into C" case, which is only half the story. "C calls into you" will always be easier in C++ and Rust, or any other language with "no" runtime, than heavier languages that rely on them. Yes, it can work, but it's a disadvantage.
In C# I use callbacks where I find appropriate (logging, also some rare events). Under the hood, the runtime marshals delegates (most languages would call them lambdas) into unmanaged C function pointers.
Ease of use is the same when I consuming the C API from e.g. C++. No disadvantage for C#.
One neat trick with .NET on Windows, is that you can actually export static methods in assemblies as unmanaged entry points. In other words, things can LoadLibrary/GetProcAddress them, and invoke them as native.
C# doesn't support this out of the box, but it can be easily done by post-processing the generated assembly. There's a NuGet package for that.
I actually think .Net runtime does a well above-average job with this - including clear declarations of managed and unmanaged code - so your ARM project sounds great & what I would expect. I just don't think it's true of "majority" of programming languages, at least if you count by number of users or HN popularity. We're both right.
You have seem Python, Perl or VB6/VBA being called from C code, in a seamless, high-performance way? I suppose it's all a matter of degree, rather than black-and-whites, and perhaps things have improved - but I'm just surprised.
About the performance… Neither of these languages are particularly fast in the first place :-) But I don't see a reason why these callbacks might be too slow.
It's probably even more important for professional embedded engineers, where the hardware decisions may not even be made by the software developers, for various reasons.