HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
rusterlium
rustler
Rust2016–2025
rusterlium / rustler

rustler

Safe Rust bridge for creating Erlang NIF functions

49Distinct people
58Mentions
0Explicit recommenders
4.9KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Safe Rust bridge for creating Erlang NIF functions

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 6:59:22 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year58 dated mentions

Observed mentions: 2016-03-04 08:03:43 UTC to 2025-04-02 13:15:02 UTC.

02468102016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 10 mentions; 2 submissions, 8 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 7 mentions; 0 submissions, 7 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC1028
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC505
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC707
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC716
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC606
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC413
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC505
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC505
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC707
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Rustler Documentation | Getting Started | Example Rustler is a library for writing Erlang NIFs in safe Rust code. That means there should be no ways to crash the BEAM (Erlang VM). The library provides facilities for generating the boilerplate for interacting with the BEAM, handles encoding and decoding of Erlang terms, and catches rust panics before they unwind into C. The library provides functionality for both Erlang and Elixir, however Elixir is favored as of now. Features Safety The code you write in a Rust NIF should never be able to crash the BEAM. Interop Decoding and encoding rust values into Erlang terms is as easy as a function call. Type composition Making a Rust struct encodable and decodable to Erlang or Elixir can be done with a single attribute. Resource objects Enables you to safely pass a reference to a Rust struct into Erlang code. The struct will be automatically dropped when it's no longer referenced. Getting started The easiest way of getting started is the rustler Elixir library. Add the rustler Elixir library as a dependency of your project. Run mix rustler.new to generate a new NIF in your project. Follow the instructions. If you are already using serde and/or have been using serde_rustler before, please enable the serde feature in your NIF crate's Cargo.toml on the rustler dependency. What it looks like This is the code for a minimal NIF that adds two numbers and returns the result. #[rustler::nif] fn add(a: i64, b: i64) -> i64 { a + b } rustler::init!("Elixir.Math"); Minimal Supported Rust Version (MSRV) Rustler currently has a minimal supported Rust version (MSRV) of 1.91. This is the configured version in .clippy.toml. Supported OTP and Elixir Versions Rustler aims to support the newest three major OTP versions as well as newest three minor Elixir versions. Supported NIF version The minimal supported NIF version for a library should be defined via Cargo features. The default is currently 2.17 (Erlang/OTP 26). To use features from NIF version 2.18 (Erlang/OTP 29), the respective feature flag has to be enabled on the dependency: [dependencies] rustler = { version = "...", features = ["nif_version_2_18"] } To target an older NIF version, disable default features and explicitly enable the required version: [dependencies] rustler = { version = "...", default-features = false, features = ["nif_version_2_15"] } Community You can find us in the #rustler:matrix.org channel on Matrix or in the #rustler channel in the Elixir lang Slack. License Licensed under either of Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0) MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT) at your option. Contribution Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.
Read the full README on GitHub

What Hacker News says

4 sources
With the advent of Nx [1] and Axon [2] for Elixir, I felt like the missing piece was the data munging en route to the machine learning. With Polars [3] making strides and Rustler [4] available to make a safe bridge for Elixir NIFs, I saw a path to get dataframes in Elixir that are _fast_. I'm really pleased with how it turned out. Inspired by the Nx architecture, which uses pluggable backends, I built a thin user-facing API that calls into (theoretically, as polars is the only extant backend) pluggable dataframe backends. What really excited me about this approach is that it permits a similar approach to what we see in dplyr [5], where you can manipulate in-memory data frames using the same API as remote databases or spark dataframes. Next up is to move to lazy-by-default. To be as unsurprising as possible, Explorer dataframes are (for al
Read the rest
l intents and purposes) immutable. This has required a fair amount of copying when using the eager API from Polars, and because Rustler NIF resources use atomic reference counting and the GC only sweeps intermittently, there can be some pretty bad memory performance. Fortunately Polars also has a lazy API. The plan is to use that with 'peeking' for display. After that, I'd like to move into additional backends. I'm particularly keen on Ecto (database) and Apache Arrow/Ballista for distributed and OLAP work. There is also work underway for a pure Elixir backend so the library can ship without a Rust dependency. Speaking of which, there's work on prebuilt binaries underway as well. I'd love feedback on the API! I aimed for a dplyr-ish API as I think it melds better with a functional language than pandas. Generally I find dplyr more intuitive than pandas. The philosophy here is to get from brain to data as simply and intuitively as possible. Finally, contributions and any other feedback are super, super welcome. It's early days and I'm also a startup founder so I haven't been able to dedicate as much time as I'd like, but I try to get some work done and add features at least once a week. Thanks for looking! -- [1] https://github.com/elixir-nx/nx [2] https://github.com/elixir-nx/axon [3] https://github.com/pola-rs/polars [4] https://github.com/rusterlium/rustler [5] https://dplyr.tidyverse.org/
In Show HN: Dataframes in Elixir Backed by Rust
> I won't take a GUI framework without a graphical designer, or a component ecosystem from companies selling GUI widgets in 21st century. Well, yeah, what I’m saying with “these types of modern frameworks don’t impose very many constraints on the language” is that there’s no reason that Qt, UWP, Interface Builder, etc. can’t support Rust (or most other languages, really), because in the end the tooling is just generating/editing data in a declarative markup language, that the language’s toolkit binding parses. You don’t have to modify the tooling in order to get it working with a new language; you just need a new toolkit binding. Just like you don’t need to modify an HTML editor to get it to support a web browser written in a new language. Qt et al, like HTML, is renderer-implementation-language agnostic. > Distributed computing, again wh
Read the rest
en thinking about distributed calls a la Akka, Orleans, SQL distributed transactions, I rather have the productivity of a GC. I think I agree re: the productivity multiplier of special-purpose distributed-computing frameworks. I don’t think I agree that it’s a GC that enables these frameworks to be productive. IMHO, it’s the framework itself that is productive, and the language being GCed is incidental. But, either way—whether it’s easy or hard—you could still have one of these frameworks in Rust. Akka wasn’t exactly easy to impose on top of the JVM, but they did it anyway, and introduced a lot of non-JVM-y stuff in the process. (I’d expect that a distributed-computing framework for Rust would impose Objective-C-like auto-release-pools for GC.) > Web development with Rust is nowhere close[...] Web development with Rust isn’t near there yet, but unlike distributed computing, I don’t see anything about web development that fundamentally is made harder by borrow-checking / made easier by garbage-collection; rather the opposite. I fully expect Rust to eventually have a vibrant web-server-backend component ecosystem equivalent to Java’s. > Rust best place is for kernels, drivers and absolute no GC deployment scenarios. Those are good use-cases, but IMHO, the best place for Rust is embedding “hot kernels” of native code within managed runtimes. I.e. any library that’s native for speed, but embedded in an ecosystem package in a language like Ruby/Python/Erlang/etc., where it gets loaded through FFI and wrapped in an HLL-native interface. Such native libraries can and should be written in Rust instead: you want the speed of a native [compiled, WPO-able] language; but you also want/need safety, to protect your HLL runtime from your library’s code that you’re forcing to run inside it; and you also want an extremely “thin” (i.e. C-compatible) FFI, such that you’re not paying too much in FFI overhead for calls from your managed code into the native code. Rust gives you all three. (I see this being an increasingly popular choice lately. Most new native Elixir NIF libraries that I know of are written using https://github.com/rusterlium/rustler.)
In All C++20 core language features with examples

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.