3 ms·

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 l

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.
        Const-me 9y ago
        I once tried to use that trick, for nVidia optimus integration. Didn’t work because that recompilation step broke debugger, and invalidated .PDB debug symbols.
  - stmw 9y ago
    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.
    - Const-me 9y ago
      Besides C, C++ and .NET, I have some experience with Python, Perl, VB6 and VBA. All of them have some form of C interop reasonably easy to use. I also have some experience with Java, JavaScript and PHP. They don’t.
      - stmw 9y ago
        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.
        Const-me 9y ago
        A bit more complex than .NET, but only a bit. Python: https://stackoverflow.com/a/33485103/126995 https://stackoverflow.com/a/33485103/126995 Basic: http://codingdomain.com/visualbasic/win32api/callback/ http://codingdomain.com/visualbasic/win32api/callback/ 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.
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.

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.
        Const-me 9y ago
        I once tried to use that trick, for nVidia optimus integration. Didn’t work because that recompilation step broke debugger, and invalidated .PDB debug symbols.
- stmw 9y ago
  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.
  - Const-me 9y ago
    Besides C, C++ and .NET, I have some experience with Python, Perl, VB6 and VBA. All of them have some form of C interop reasonably easy to use. I also have some experience with Java, JavaScript and PHP. They don’t.
    - stmw 9y ago
      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.
      - Const-me 9y ago
        A bit more complex than .NET, but only a bit. Python: https://stackoverflow.com/a/33485103/126995 https://stackoverflow.com/a/33485103/126995 Basic: http://codingdomain.com/visualbasic/win32api/callback/ http://codingdomain.com/visualbasic/win32api/callback/ 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.

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.