5 ms·

> Rust is great for the embedded space Honestly, I would disagree here, unless we're talking in terms of potential, rather than actual ability right now. There

> Rust is great for the embedded space Honestly, I would disagree here, unless we're talking in terms of potential, rather than actual ability right now. There's certainly some level of support, but I really did not get the feeling that Rust was 'great' for embedded, rather that it could be.

bluejekyll 9y ago
> but I really did not get the feeling that Rust was 'great' for embedded, rather that it could be. My experience is very limited here, but I have used TockOS on one of their dev boards. That was very pleasant, no stdlib makes it a little harder than std Rust, but still felt more deterministic than writing in C.
- verletx64 9y ago
  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.
  - stmw 9y ago
    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.
    - Const-me 9y ago
      > 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.
      - steveklabnik 9y ago
        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.
        Const-me 9y ago
        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#.
        sinhpham 9y ago
        "C calls into you" means you already have a C code base and now need to call your C# functions.
        Const-me 9y ago
        Right, C# is OK when C code calls into it. https://stackoverflow.com/a/5235549/126995 https://stackoverflow.com/a/5235549/126995
        steveklabnik 9y ago
        To be clear, I’m not saying it’s not possible. I’m saying that one less runtime is an advantage.
        int_19h 9y ago
        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. https://www.nuget.org/packages/UnmanagedExports https://www.nuget.org/packages/UnmanagedExports I'm not sure if any of that works on other platforms, or with .NET Core. Probably not.
  - bluejekyll 9y ago
    Again, not speaking from experience here, but it should be easy enough using tools like https://docs.rs/bindgen/0.31.3/bindgen/ 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.
    - vvanders 9y ago
      Yup, bindgen works great. It has a little problem with c macros but they're easy enough to redefine into a static constant to make them work.
ChickeNES 9y ago
Agreed, I've been waiting 3+ years for first-class support for bit fields
koffiezet 9y ago
Same, I have a number of devices here on my desk that will never get a Rust compiler targeting them. With C, it's simple, the "only" thing you have to worry about is what bugs or quirks the C compiler will have on that specific platform, not if there's a compiler at all. Now I've left embedded development behind me for a while now, things are mostly Linux on relatively modern ARM in the field where I used to do stuff, so Rust would probably be an option there, but I still have a hard time considering them to be "embedded".

bluejekyll 9y ago

> but I really did not get the feeling that Rust was 'great' for embedded, rather that it could be. My experience is very limited here, but I have used TockOS on one of their dev boards. That was very pleasant, no stdlib makes it a little harder than std Rust, but still felt more deterministic than writing in C.

verletx64 9y ago
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.
- stmw 9y ago
  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.
  - Const-me 9y ago
    > 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.
    - steveklabnik 9y ago
      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.
      - Const-me 9y ago
        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#.
        sinhpham 9y ago
        "C calls into you" means you already have a C code base and now need to call your C# functions.
        Const-me 9y ago
        Right, C# is OK when C code calls into it. https://stackoverflow.com/a/5235549/126995 https://stackoverflow.com/a/5235549/126995
        steveklabnik 9y ago
        To be clear, I’m not saying it’s not possible. I’m saying that one less runtime is an advantage.
        int_19h 9y ago
        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. https://www.nuget.org/packages/UnmanagedExports https://www.nuget.org/packages/UnmanagedExports I'm not sure if any of that works on other platforms, or with .NET Core. Probably not.
- bluejekyll 9y ago
  Again, not speaking from experience here, but it should be easy enough using tools like https://docs.rs/bindgen/0.31.3/bindgen/ 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.
  - vvanders 9y ago
    Yup, bindgen works great. It has a little problem with c macros but they're easy enough to redefine into a static constant to make them work.

ChickeNES 9y ago

Agreed, I've been waiting 3+ years for first-class support for bit fields

koffiezet 9y ago

Same, I have a number of devices here on my desk that will never get a Rust compiler targeting them. With C, it's simple, the "only" thing you have to worry about is what bugs or quirks the C compiler will have on that specific platform, not if there's a compiler at all. Now I've left embedded development behind me for a while now, things are mostly Linux on relatively modern ARM in the field where I used to do stuff, so Rust would probably be an option there, but I still have a hard time considering them to be "embedded".