Publishing a Gleam library that uses NIFs?

[swift flame]

Hi everyone!

I'm currently developing a small cryptographic library for Gleam that uses the Rust Orion crate as its backend. I'm using Rustler to bridge between the BEAM and Rust.

While the development process has been smooth overall, I'm encountering some challenges with publishing the library to Hex. Specifically, I'm unsure about how to handle the inclusion of native code. I'd prefer to avoid publishing native binaries for every architecture.

After some research, I noticed there isn't currently a standardized way in Gleam to call external build tools like Cargo for dependencies. So I wanted to know what the current "best" approach for publishing Gleam libraries with NIFs is and how others tend to do it?

Best regards,
Simon

[ebon wagon]

Deliberately not supported, we discourage NIF use in packages, and in the situations where NIFs are suitable we want to encourage people writing Erlang packages as then the whole BEAM ecosystem benefit from them

[swift flame]

Ah, I see. Then I guess I will strip the NIF stuff out into an Erlang package and use it as a dependency. Thanks for the quick response! 🙂
Out of curiosity, can you give me any insights on why you discourage NIFs in packages?

[dull valley]

misuse of nifs can bring down the entire vm

if you ship prebuilt binaries they are

• difficult to audit and will often present too much risk for orgs to use your package (and thus gleam)
• may not work on every platform

if you ship source and compile at build time they

• slow down build times a lot
• require users to have uncommon toolchains installed to build a project that uses this dep

[ebon wagon]

The security side is becoming more important too with the rise of supply chain attacks and the new EU bill of materials legislation coming in

Another disadvantage is their general poor performance compared to Erlang due to the FFI barrier, thei

There are languages and ecosystems that are designed to be high level orchestrators for low level code (e.g. Python), but the BEAM isn't one of those

[swift flame]

Makes total sense. I guess its better to keep everything in the same ecosystem

[vestal dust]

Out of curiosity, do you know if the BEAM provides operations that are suited for implementation of cryptography, or are those necessarily going to be calls to an outside system?

[ebon wagon]

Cryptography is a large field, did you have specifics in mind? You can look at the Erlang stdlib to see what the runtime provides