• BatmanAoD@programming.dev
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    6 hours ago

    If your goal is small binaries, it’s possible to get them with Rust, too: https://github.com/johnthagen/min-sized-rust

    There are a variety of reasons why Rust binaries tend to be bigger unless you follow some of those guidelines, but the biggest one (and actually not something those guidelines recommend changing!) is that C is generally dynamically linked against a system version of the C standard library, whereas Rust binaries are statically linked by default, meaning that the binary is actually self-contained.

    • Possibly linux@lemmy.zip
      link
      fedilink
      English
      arrow-up
      0
      ·
      4 hours ago

      C is still better for the embedded world

      If you have gigabytes of storage and memory Rust makes more sense. C shines as it allows fine control over memory. The fact that you can tie into The system libraries makes it very resource friendly since you don’t need redundant code.

      • BatmanAoD@programming.dev
        link
        fedilink
        arrow-up
        0
        ·
        3 hours ago

        I think you’re making some poorly-researched assumptions.

        In the embedded world, there often aren’t “system libraries,” depending on just what you’re targeting. But if, for some reason, you really do want to use libc but not the Rust standard library, you can certainly do that; for instance, here’s a crate that reimplements the Rust standard library’s output and formatting capabilities using libc: https://github.com/mmastrac/rust-libc-print

        Rust provides essentially the same memory control as C does. You can also have inline assembly in Rust, just as in C.

      • ulterno@programming.dev
        link
        fedilink
        English
        arrow-up
        0
        ·
        3 hours ago

        Wasn’t Rust originally made for embedded systems to reduce the time taken debugging runtime errors by shifting those to compile time?