Mirah: Ruby syntax, static types and JVM bytecode with no runtime library

A statically typed language with Ruby manners

Mirah is described as a customizable programming language featuring static types, local type inference and a heavily Ruby-inspired syntax. The combination is unusual enough to explain the project's appeal. Static typing gives you the compiler errors a JVM audience expects, local type inference means the types are worked out per expression rather than per project, and the Ruby syntax keeps the source short enough that a small program is still a handful of lines. The implementation includes a typer and compiler backend for the JVM which can output JVM bytecode, and the feature list is short and blunt about it: Ruby-like syntax, compiles to .class, fast as Java, no runtime library. That last point is the one that separates Mirah from most JVM languages, since there is no Mirah standard library to ship with your jar, which changes the size and the deployment story of what you build.

Two executables with different jobs

The synopsis section shows both entry points, and they are not the same tool. There is the interpreter, which runs a script file or an inline script, and there is the compiler, which takes a script file and produces a class file:

mirah <script.mirah>
mirah -e "inline script"
mirahc <script.mirah>
mirahc -e "inline script" # produces DashE.class

The -e flag runs a script given on the command line, which is the quickest way to try the language without creating a file, and the compiler entry point is mirahc rather than mirah. The comment in the synopsis about the compiler producing a class file matters because it is the whole point of the design, since a Mirah program is compiled ahead of time into ordinary JVM bytecode and runs on a plain Java runtime with no Mirah specific loader involved. For a language aimed at quick scripts and small tools, having both a run-it-now path and a compile-it-once path matters, and the naming makes which one you are calling obvious at a glance.

Four ways to install it

The install section gives a route for each kind of user, and each one has a small catch attached. The Ruby route is a gem, and if your gem and rake are not from JRuby you prefix the commands with jruby -S:

$ gem install mirah

The jar route goes through Maven Central, where the artifact is published under the org.mirah group, and the README points at the Maven search page for it. The zip route is the GitHub release, and you extract it and add bin to your $PATH so that mirah and mirahc are on the path. The source route needs JRuby 1.7.12 or higher, and then it is a clone and a bundle install:

$ git clone http://github.com/mirah/mirah.git
$ cd mirah
$ bundle install

From there the Rakefile produces the artefacts, with rake gem building the gem and gem install pkg/mirah-*.gem installing it, and rake dist/mirahc.jar creating a mirahc.jar in dist that you can run to compile Mirah source files. The build tooling choice, JRuby with Rake for the compiler side and Maven for the Java side, is the practical reason the source build has a slightly dated feel.

A repository that is both a Ruby project and a Java project

The top level of the repository explains the hybrid nature of the implementation. You have a Gemfile and a mirah.gemspec, which is the Ruby side, a Rakefile for the build, and a pom.xml with a maven directory, which is the Java side. The compiler itself lives in src/ and lib/, with a separate mirah-parser directory, bin and distbin for the executables, javalib/ for the Java parts that back the generated bytecode, tools/ for build helpers, and test/ for the suite. There are also files that reveal the project's age, an nbproject directory from NetBeans, a .travis.yml for continuous integration, a History.txt changelog, a TODO.md, a CODE_OF_CONDUCT.md, a COPYING and a NOTICE. The scripts directory is large and varied, with folders for ant, appengine, macros, maven, plugins, rosettacode and wiki, and standalone scripts such as bintrees.mirah, construction.mirah, fib.mirah, fields.mirah, fractal.mirah, interfaces.mirah, java_thing.mirah, literals.mirah, simple_class.mirah, sort_closure.mirah, swing.mirah and tak.mirah. Those scripts are the closest thing the project has to a specification, and the presence of a rosettacode folder says where the author got ideas for them.

Where a language like this stops being a good fit

The honest limits are all in the same place, the timeline. The requirements section asks for Java 1.7 or higher, and the source build needs JRuby 1.7.12 or higher, which is a toolchain generation that has been superseded several times over. The releases tell the rest of the story, with 0.1.4 from October 2015, 0.2.0 in August 2016 under the title Back in Action, and 0.2.1 in September 2016 under the title Self Closure. Nothing has been tagged in the nine years since, even though the last push to the master branch was on 2026-05-23 and the repository is not archived, so there is work on the branch without a release behind it. For a language, a release is the only artefact most people ever install, and there is not one. The second limit is the community, which is a Google group and a GitHub issue tracker, and the third is the editor story, which the README does not cover at all, so anyone writing Mirah day to day is on their own with tooling.

Licence, packaging and what a reader should take from it

The licence is Apache 2.0, with the COPYING and NOTICE files at the root, which is a permissive choice that lets a company embed a Mirah compiler in its own build tooling without ceremony. The project home is mirah.org, the community is the Google group, and the build status badge in the README points at a Travis CI service that no longer exists, which is a small but accurate signal about the age of the tooling. The primary language recorded for the repository is HTML, which tells you the project also carries its web presence in the same tree. What is left is a compiler and a language design that repays reading. Mirah shows one coherent answer to the question of what happens when you take Ruby's surface syntax seriously and add static types and a no-runtime-library deployment model, and it does it with a codebase small enough that you can hold in your head. That is the case for spending an afternoon with it, rather than the case for putting it in production.

Editorial conclusion

Mirah fits a language designer or a JVM developer who wants to understand what a Ruby shaped, statically typed, runtime free language on the JVM looks like, and it fits a team that wants a very small compiled artifact with no library to ship. It is the wrong choice for a new production project, since the newest tagged release is 0.2.1 from 2016 and the build still expects JRuby 1.7.12 or higher and Java 1.7, and it is a poor fit if you need a maintained package with security fixes. Before you evaluate it further, check whether the source tree still compiles against a current JDK, because the CI badge points at a service that no longer exists and the repository has had no tagged release since September 2016.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. mirah/mirah on GitHub
3. Project website
4. README
5. Releases