1. Greenfield project
  2. Drop-in replacement
  3. Reopen class
  4. Ship to production
  5. Binary distribution
  6. Non-Traditional Use-Cases
  7. Performance parity with C
  8. Miscellaneous features and QoL improvements

Helix is still a young project with a lot of work still to be done. To give you a better sense of where we’re at, whether you can use Helix for your project, and how you can help contribute, we broke down the outstanding work in terms of a few expected use-cases.

Greenfield project

You’re developing a brand new feature or rewriting a feature inside your app (as opposed to a public library). Since you have full control over the API, you can make adjustments to work around current limitations in Helix.

You might use Helix for a CPU-bound algorithm, in a request, mailer or background job. Problems with a potential for parallelism are an especially good fit.

Because of the limited type coercions available, problems that can communicate through string or number values are the best fit. Since background jobs and HTTP requests share this constraint, you can often get a little creative and model many problems this way.


Drop-in replacement

You’re rewriting some code in a public library from Ruby to Rust. The benchmark example we’re using for this use-case is a high-fidelity implementation of ActiveSupport::Duration written in Rust, and passing all of the Rails tests.

Another example of this use-case is JSON::Pure vs. JSON::Ext in the json library.

Because it has a public API, you need to maintain full compatibility with exotic Ruby features that are not easy to represent in Rust.

If this is your goal, you can accomplish a lot today by mixing-and-matching Rust and Ruby. Typically, you would implement the heavy-lifting in Rust and write sugar for features like optional or keyword arguments in Ruby, normalizing the inputs and then call into Rust.

However, the long-term goal of the Helix project is to support all of these features in the ruby! macro.


Reopen class

For full fidelity with ActiveSupport, we should support reopening existing classes directly from Rust.


Ship to production

Once you’ve integrated Helix into an application, you need to deploy to production. Since you’re in full control of the build environment, you can supply a Rust compiler in that environment.

In this use-case, Rust compilation is similar to asset compilation: just like you’d supply a JavaScript runtime or Sass compiler to compile your assets, you’d supply a Rust compiler to compile your Helix projects.


Binary distribution

If you want to use Helix in a gem, and distribute it to users without requiring a Rust compiler, you will need to build binary distributions for your target environment.

We want to support a smooth workflow for specifying your target environments and getting the binaries for each of them. We are exploring both cross-compilation solutions, VM-based solutions, and some combination of the two.


Non-Traditional Use-Cases

You might want to use Helix in environments other than traditional use-cases for Ruby. We want to explore good workflows for these use-cases, especially when Rust and Ruby both support an environment.


Performance parity with C

In general, Rust is in the same performance ballpark as C for code written in Rust (sometimes it’s even faster). However, the cost of crossing from Ruby to Rust is still high (compared to Ruby C extensions).

That being said, because using native code is so much faster than Ruby, you can recoup the cost difference pretty quickly. This problem is more important for chatty APIs, or drop-in replacements for Ruby APIs that intrinsically require a lot of communication with Ruby (e.g. to_str).

Those costs are largely not intrinsic, and we’re exploring ways to reduce the costs.


Miscellaneous features and QoL improvements