• teolan@lemmy.world
    link
    fedilink
    arrow-up
    9
    ·
    3 months ago

    I’m suggesting building a Rust library and exposing a C ABI. That’s what rsvg does for example.

    • CanadaPlus@lemmy.sdf.org
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      3 months ago

      Oh. There’s a still Rust-y way to do this? Nevermind.

      OP wanted stability and predictability. I suppose we’ll see how entrenched one library can become.

      • barsoap@lemm.ee
        link
        fedilink
        arrow-up
        7
        ·
        3 months ago

        The Rustinomicon has a chapter on it. The basics are quite simple: Declare non-opaque types to use layout matching the C ABI, export/import functions, some wibbles around name mangling. Option<T> vs. null pointers. Where things get a bit more involved is unwinding, but then you’re at the end of it, nothing should be shocking to anyone having written C.

        As to how Rusty it is… not very. I mean Rust has first-class FFI support, but the way FFI stuff is written is necessarily unidiomatic because you’re basically writing C in Rust syntax and you won’t get out of declaring your own functions `unsafe’ before you read the rest of the Rustinomicon to understand what properties you need to ensure because the nice and shiny parts of Rust assume them.

        • CanadaPlus@lemmy.sdf.org
          link
          fedilink
          arrow-up
          4
          ·
          edit-2
          3 months ago

          Hmm. So I guess it comes down to what OP is doing. They either want to write a Rust library, or something that uses a Rust library that may not be standardised or even exist yet. If the latter, they should stick with C.

          • barsoap@lemm.ee
            link
            fedilink
            arrow-up
            3
            ·
            3 months ago

            Writing C bindings to a Rust library is the easier scenario because you can rely on the safe code having nice and clean memory semantics.