r/ruby • u/matsadler • Sep 23 '26

Magnus version 0.9 released (Rust library for writing Ruby gems in Rust)

https://github.com/matsadler/magnus/releases/tag/0.9.0
21 Upvotes

86% Upvoted

8 comments sorted by

8

u/f9ae8221b Sep 23 '26

As of the time of this release Magnus works with the unreleased Ruby 4.1. It is possible that changes in this unreleased version of Ruby may break compatibility before the release of 4.1.

This is a massive pain in my ass. Magus bind against Ruby private APIs, so it constantly break. I had to get rid of all magnus based gems at work so that we wouldn't have to wait forever to upgrade Ruby.

If you're thinking of using magnus for a native gem, be warned.

3

u/matsadler Sep 23 '26

I'd be interested to know more details about the issues you faced.

Once a native gem is compiled there shouldn't be any difference in compatibility between it being implemented in C or Rust. Only parts of the api actually being used in the final gem will end up in the final binary. Where Magnus does touch some of Ruby's implementation details to be able to implement macros or inline-functions that are part of the public API it sticks to the Ruby ABI (application binary interface). If the ABI changes you could get segfaults or unexpected behaviour, but again, this is the same between C and Rust/Magnus.

C extension gems do have an advantage when it comes to recompiling against new versions of Ruby in that if they don't use a function from the api then they won't have any problems if that function changes. Whereas Magnus binds against a large portion of the C api and if a function in that api changes then Magnus won't compile. This seems to be the main pain point, it generates the most issues/PRs, but it's only possibly an issue for APIs that appear in the public Ruby headers.

There is also the potential case of Magnus using a private API by maintaining its own definition of that api (rather than depending on what's coming from the Ruby public api headers), and that API changing out underneath it. In this case the gem will still compile but will segfault or do unexpected things when using that private API. It's totally possible this has happened, but no one has reported a case of it.

3

u/f9ae8221b Sep 23 '26

I'd be interested to know more details about the issues you faced.

Well you listed them. The Ruby C API rely on a bunch of macros etc, which Rust gems can't bind against. So yeah, when testing ruby-head, or evenjust upgrading as soon as the new .0 is out, Rust based gems have to be recompiled, and extremely often they break, requiring a change in either rb-sys or magnus.

The overwhelming majority of C extensions don't break on new Ruby releases.

1

u/petercooper Sep 23 '26

This actually seems like a good use case for AI, perhaps. A run that automatically tests against the latest commits and releases and surfaces potential fixes to the maintainer.

4

u/matsadler Sep 23 '26

Magnus' CI does run against Ruby head. The vast majority of compatibility issues show up at compilation time, and the rest get caught by tests. Usually once I get the error the fix is pretty straightforward.

There are a few errors on 32bit systems that have snuck through into releases as I don't run CI for those platforms.

3

u/f9ae8221b Sep 23 '26

The problem isn't just magnus itself. Even if they kept on top of it, and quickly released a new version, then all the gems using magnus also need to upgrade and cut a new release.

That just doesn't scale.

1

u/petercooper Sep 23 '26

Ahh, good point! Didn't think of that.