This Month in Mun - October 2019

Published on November 1, 2019 by Remco

We started October with the launch of our websiteDiscord server, and OpenCollective. Our ideas had advanced far enough that we felt ready to share our vision, but it was still exciting to see how the community would receive our ideas. To our surprise the announcement attracted a larger audience than anticipated - thankfully most of the feedback was positive. Where possible we tried to engage with the community to provide clarity and improve our website accordingly. If you still have any feedback on our website or just want more information, feel free to reach out to us on Discord.

Having built a runtime prototype and framework for lexing, parsing, type checking, and LLVM IR code generation; our goal for the remainder of October was to extend, polish, and stabilise this into a Mun v0.1 release.


To guarantee that this and future releases operate as expected, we spent a lot of time developing tools to test code quality and integrating those tools into our continuous integration pipeline. As part of this effort we implemented snapshot testing for lexingparsingtype checking, and code generation through the use of the insta crate, integration testing of the compiler and runtimetest coverage metricsCI that continuously builds our code on all Tier 1 platforms (64-bit Windows, macOS, 64-bit Linux), and cargo fmt and cargo clippy compliance. This test suite allows us to confidently accept pull requests without introducing regressions and makes it easier for other developers to contribute to Mun.

Mun language

For Mun v0.1 we set out to extend the language specification with function callsboolean operations, and if-then-else statements. With these features in place, we are able to demo Mun’s hot reloading capabilities using fibonacci:

Mun runtime

Whenever we add new semantics to the Mun language, we also want to support hot reloading for it. To hot reload functions, the Mun compiler looks up a function pointer in a dispatch table and calls that function instead of inlining function calls. When the compiled library is loaded into the runtime (i.e. on startup or when hot reloading), a process called runtime linking ensures that all those function lookups to internal and external functions map to the correct function addresses. This allows us to hot reload any function at the expense of a slight runtime overhead.


When designing embedding of Mun into other languages, we wanted the developer experience to be as straightforward as possible. As such we wanted to offer language-specific bindings for some of the languages most likely to embed Mun. As the Mun runtime is written in Rust it became our first target, but we also developed a C API; its stable ABI allowing for the creation of similar bindings in most other languages. To illustrate this we also developed C++ bindings that utilize the C API.

We envisioned three modes of operation for a developer invoking the above Mun function:

  • Invoke a function (can fail)
  • Retry an invocation once (can fail)
  • Wait until the invocation succeeds

Both the retry and wait operations wait for hot reloaded code before trying again. The Rust and C++ syntax for invoking the equal Mun function look as follows:

We are hard at work putting the finishing touches to Mun v0.1, so stay tuned!