The Mun programming language RSS Feed

Release - Mun v0.4.0

Mon, 12 Dec 2022 00:00:00 GMT

Guess who’s back?! The previous Mun release dates back over one and a half years. Since then - slowly but steadily - we’ve been working towards Mun v0.4.0 and it’s finally here! This tick-release mainly focuses on language-support for dynamically-sized arrays, but we’ve also transitioned to a monorepo, added support for Apple’s M1 chips and experimental support for iOS, refactored major parts of our backend to support indirect types and recursion - as seen with arrays and pointers - and solved a range of bugs.

What’s Mun?

For those of you who haven’t heard of Mun before, Mun is an embeddable programming language empowering creation through iteration. The idea to create Mun originated out of frustration with the Lua dynamic scripting language and a desire to have similar hot reloading functionality available in Rust. As such, it’s not a direct competitor with Rust, but instead is intended to be used with Rust (or C/C++) as a host/embedded language pairing. Actually, Mun is completely written in Rust, building on similar crates as rust-analyzer and rustc. Its key features include:

Ahead of time compilation - Mun is compiled ahead of time (AOT), as opposed to being interpreted or compiled just in time (JIT).
Statically typed - Mun resolves types at compilation time instead of at runtime, resulting in immediate feedback when writing code and opening the door for powerful refactoring tools.
First class hot-reloading - Every aspect of Mun is designed with hot reloading in mind. Hot reloading is the process of changing code and resources of a live application, removing the need to start, stop and recompile an application whenever a function or value is changed.

What’s new?

Mun v0.4 does not only bring arrays to Mun, but it lays the groundwork for a plethora of language features that require indirect types and recursion. These required a rewrite of Mun’s ABI, allocator, memory mapper, and garbage collector.

But that’s not all! In total, this release contains 111 pull requests made by 5 of our community contributors and our two Core Team members & Dependabot. Thanks for having our back! For a full list have a look at the changelog, but the main improvements are:

Dynamically-sized arrays

pub fn generate() -> [u64] {
  [5, 4, 3, 2, 1]
}

pub fn add_one(array: [u64], len: usize) -> [u64] {
    let idx = 0;
    loop {
        array[idx] += 1;
        idx += 1;

        if idx >= len {
            break array
        }
    }
}

fn main() {
    add_one(generate(), 5);
}

NOTE: Array functionality is still very basic as you cannot resize arrays (incl. pushing elements) at runtime. You can only get, set, and replace array elements. Future releases of Mun will extend this functionality.

Simplified function invocations from Rust

let runtime_ref = runtime.borrow();
let arg: i64 = runtime_ref.invoke("arg", (a,b)).unwrap();

Simplified struct API for Rust

let builder = Runtime::builder("mun/target/mod.munlib")
  .insert_fn("rand_f32", rand_f32 as extern "C" fn() -> f32);

let runtime = unsafe { builder.finish() }.expect("Failed to load munlib");

let state: StructRef = runtime.invoke("new_state", ()).unwrap();
let state = state.root();
let pong = PongGame { runtime, state };

let state = pong.state.as_ref(&pong.runtime);

Apple M1 & experimental iOS support
Upgrade to LLVM 13

Support for runtime usage in entity component systems (ECS)

fn main() {
  let lib_dir = PathBuf::from(env::args().nth(1).expect("Expected path to a Mun library."));

  App::new()
      .add_plugins(MinimalPlugins)
      .add_plugin(MunPlugin { lib_dir })
      .run();
}

struct MunPlugin {
  lib_dir: PathBuf,
}

impl Plugin for MunPlugin {
  fn build(&self, app: &mut App) {
      app.insert_resource(self.lib_dir.clone())
          .add_startup_system(setup.exclusive_system())
          .add_system(reload_munlib_every_frame);
  }
}

fn setup(world: &mut World) {
  let builder = MunRuntime::builder(
      world
          .get_resource::<PathBuf>()
          .expect("Lib path must be added as resource"),
  );
  let mun: MunRuntime = unsafe { builder.finish() }.expect("Failed to spawn Runtime");
  world.insert_non_send_resource(mun);

  world.remove_resource::<PathBuf>();
}

fn reload_munlib_every_frame(
  mut mun: NonSendMut<MunRuntime>,
) {
    let _ = unsafe { mun.update() };
}

Adopted monorepo for better developer experience
Decreased unsafe code usage and simplified code
Assorted bug fixes

What’s next?

Mun is still in early development, so there is a lot to do. The Mun Core Team operates according to a tick-tock release cycle. Development of a tock release (Mun v0.5) focuses on using and improving existing features, whereas a tick release (Mun v0.6) focuses on implementing new features.

When planning Mun v0.4, we decided to limit our focus to adding support for arrays and optimising our Mun ABI format in the hopes of adhering to semiannual release schedule. However, due to our limited availability, it still took us way longer than expected to release. As such, we’re not giving an estimated release date for Mun v0.5 but we can say that it will introduce impl blocks for functions and we’ll be upgrading to LLVM v16.0. For a complete roadmap, please visit our GitHub milestones.

How can I learn more?

To get started, read the Mun Book and have a look at our Rust and C++ examples.

If you are interested in helping develop Mun feel free to reach out to us on Discord or Twitter, or pick up one of our good first issues on GitHub.

If you cannot personally contribute but would still like to support our cause, please consider donating to our Open Collective or Github Sponsors.

Acknowledgments

This release would not have been possible without the incredible contributions from the Mun Community. We are extremely grateful to all of you!

This Month in Mun - May 2021

Tue, 08 Jun 2021 00:00:00 GMT

The core team has been working on new features for Mun v0.4. The biggest feature will be dynamically sized arrays.

Mun v0.4

Mun v0.4 will be the next release of the Mun programming language. This months contributions from the core team include:

[RFC] dynamically sized arrays [PR#324]

The dynamically sized arrays RFC has been merged. This indicates that the core team has reached a consensus on the the language design details. Development of the feature is underway.
feat: derive clone for RootedStruct [PR#323]

The Mun community pointed out that RootedStruct could not be cloned from Rust code. This has been resolved with this MR.
bump: rust to 1.51.0 and 1.52.0 [PR#327] & [PR#325]

The entire Mun codebase has been updated to support the latest lints from Rust 1.51 and 1.52

Interested in our progress or what we are doing next? Please check out our milestone page on Github that details new features for future releases - Mun v0.4 and v0.5 - as well as a backlog of features that are still to come.

Community

If you are interested in helping develop Mun - but are not sure where to start - feel free to take a look at our good first issues or reach out to us on Discord or Twitter. To support our cause, please consider donating to our Open Collective or Github Sponsors.

This Month in Mun - April 2021

Sat, 08 May 2021 00:00:00 GMT

After the release of Mun v0.3 we are now looking at new features for the Mun v0.4 release. The biggest of which will be support for dynamically sized arrays.

Mun v0.3

This month was highlighted by the release of Mun v0.3. We expected to release Mun v0.3 within a few months of Mun v0.2 but this was pushed back a couple of times because we added more and more features to the release. Mun v0.3 adds support for modules & multi-file projects, a functioning language server which features autocompletion and a lot more. The Mun v0.3 release blog highlights all of the new features packed in this release.

Mun v0.4

Mun v0.4 will be the next release of the Mun programming language. After Mun v0.3’s delays, we concluded that from now on we will create smaller increments - with less features - so we are (hopefully) able to release faster and more often. As it stands the Mun v0.4 milestone is a lot smaller than our original Mun v0.3 milestone.

[RFC] dynamically sized arrays [PR#324]

The next big feature for Mun will be support for arrays.

To gather feedback and get everyone on the same page we opened an RFC pull request where we encourage everyone to comment on our design choices with regards to array support.

We hope to merge this RFC soon so we can get to work on the actual development process of this long-awaited feature.

Community

Release - Mun v0.3.0

Sun, 11 Apr 2021 00:00:00 GMT

It’s been almost eleven months since the previous major Mun release. A lot has happened; in the world, in the Core Team members’ personal lives, and with Mun. The ambitions that we set for Mun v0.3 were big - and the delays equally so - but we are excited to finally present Mun v0.3.0. This tock-release was focused on usability improvements; multi-file projects, a language server with diagnostics and autocompletion, and improvements to robustness and developer workflow to name a few.

What’s Mun?

Mun is an embeddable programming language empowering creation through iteration. The idea to create Mun originated out of frustration with the Lua dynamic scripting language and a desire to have similar hot reloading functionality available in Rust. As such, it’s not a direct competitor with Rust, but instead is intended to be used with Rust (or C/C++) as a host/embedded language pairing. Actually, Mun is completely written in Rust, building on similar crates as rust-analyzer and rustc. Its key features include:

Ahead of time compilation - Mun is compiled ahead of time (AOT), as opposed to being interpreted or compiled just in time (JIT).
Statically typed - Mun resolves types at compilation time instead of at runtime, resulting in immediate feedback when writing code and opening the door for powerful refactoring tools.
First class hot-reloading - Every aspect of Mun is designed with hot reloading in mind. Hot reloading is the process of changing code and resources of a live application, removing the need to start, stop and recompile an application whenever a function or value is changed.

What’s new?

Mun v0.3 brings an insane amount of updates. When we say insane, we mean insane! In total, this release contains 52 pull requests from 7 of our community contributors and our two Core Team members. For a full list have a look at the changelog, but the main improvements are:

Type inferencing

fn integer() -> i32 {
    0 // inferred as i32
}
fn large_unsigned_integer() -> u128 {
    0 // inferred as u128
}
fn with_let() -> u16 {
    let b = 4;    // inferred as u16
    let a = 4;    // inferred as u16
    a
}

Modules & multi-file projects

  // mod.mun
  struct Foo;
  fn main() -> self::Foo {
      Foo
  }
  fn bar() -> Foo {
      super::Foo  // undefined value
  }
  fn baz() -> Foo {
      package::Foo
  }
  // foo.mun
  struct Foo;
  fn bar() -> Foo {
      super::Foo  // mismatched type
  }
  fn baz() -> package::Foo {
      super::Foo
  }
  fn nested() -> self::Foo {
      package::foo::Foo
  }

Visibility & use keyword

// /foo.mun
pub struct Ok;

// /bar.mun
pub use package::foo::Ok as ReallyOk;
pub struct Ok;

// /baz.mun
use package::bar::ReallyOk;

Autocompletion in editors through LSP
Diagnostics in editors through LSP

Type aliases

type Foo = u32;
fn main() {
    let a: Foo = 1;
}

Better compile times, hot reload times, and runtime marshalling times
Decreased unsafe code usage and simplified code
Automatic testing of C/C++ bindings & documentation
Better developer tools
Assorted bug fixes

Make It or Break It

A new release also means the end of our first season of Make It or Break It. Our request for contenders, was answered by a lot of reporters filing bugs in the Break It track, but we only had a single contributor in the Make It track. After some discussion, we decided to skip a poll and instead decide on the - to us - unanimous winner: this Spaceship game created by legendiguess using Mun & Rust:

Congratulations, your contribution will forever be remembered on our Make It or Break It hall of fame!

What’s next?

Mun is still in early development, so there is a lot to do. The Mun Core Team operates according to a tick-tock release cycle. Development of a tock release (Mun v0.3) focuses on using and improving existing features, whereas a tick release (Mun v0.4) focuses on implementing new features.

When planning Mun v0.3, we bit off more than we could chew, resulting in large delays. To avoid the same pitfalls, we’re limiting the scope Mun v0.4. In particular, we’ll focus on adding support for arrays and optimising our Mun ABI format. For a complete roadmap, please visit our GitHub milestones.

How can I learn more?

To get started, read the Mun Book and have a look at our Rust and C++ examples.

If you are interested in helping develop Mun feel free to reach out to us on Discord or Twitter, or pick up one of our good first issues on GitHub.

If you cannot personally contribute but would still like to support our cause, please consider donating to our Open Collective or Github Sponsors.

Acknowledgments

This release would not have been possible without the incredible contributions from the Mun Community. We are extremely grateful to all of you!

This Month in Mun - March 2021

Sat, 10 Apr 2021 00:00:00 GMT

All features are in, our CI pipeline has been primed, the countdown has started. The Core Team is putting the final touches on documentation for Mun v0.3, but otherwise we are ready for lift-off!

Mun v0.3 progress

feat: runtime linking [PR#300]

Adds the possibility to use multiple Mun files from a compiler and runtime perspective.

When a new *.munlib is being written to disk by the compiler, we create and delete a lockfile to trigger relinking. As such, we no longer suffer from IO event delays in the runtime.
refactor: remove delay from runtime [PR#11]

refactor: make type-specific data (such as StructInfo) part of TypeInfo [PR#287] [PR#10] [PR#9]

Generates a typed enum for TypeInfo in the C ABI, instead of unsafely appending additional data per TypeInfo entry.

#[derive(AsValue)]
pub struct TypeInfo {
    ...
    pub data: TypeInfoData,
}

#[derive(AsValue)]
#[repr(u8)]
pub enum TypeInfoData {
    Primitive,
    Struct(StructInfo),
}

bump(rust): bumps Rust to 1.50 [PR#310]
feat(ci): add Github CI workflow [PR#12] [PR#312]

Adds a CI workflow for building and testing our C/C++ Runtime bindings to GitHub.
feat(lsp): support for completions [PR#306]
refactor: generate rust tests for code snippets in book [PR#311]

We now auto-generate Rust tests for all Mun code snippets in the Mun book during the build process, to always ensure that the book is up-to-date.

All desired changes for the Mun Compiler, Runtime, and Language Server have now been merged. That means that we’ll be working hard to update our documentation before releasing Mun v0.3 in the coming days. Can’t wait? Please help us test the latest version of Mun by building from source.

Interested in what we are doing next? Please check out our high-level roadmap on Github that details new features for future releases - Mun v0.4, and v0.5 - as well as a backlog of features that are still to come.

Community

This Month in Mun - February 2021

Thu, 04 Mar 2021 00:00:00 GMT

It’s been a long time coming, but the Core Team is closing in on the finish line for Mun v0.3. We are only a couple of pull requests away from locking the build for bug fixes and documentation. So start your engines!

Mun v0.3 progress

feature: use statements language support [PR#290]

// /foo.mun
pub struct Ok;

// /bar.mun
pub use package::foo::Ok as ReallyOk;
pub struct Ok;

// /baz.mun
use package::bar::ReallyOk;

feature(lsp): implements incremental file updates [PR#298]

Allows the language server to receive incremental file updates when text is being modified in an editor.
bump: Inkwell beta.2 and LLVM11 [PR#303]

Updates our entire codebase to LLVM11, which contains our fix for LLD. This will clear the way to build a fully statically linked version of Mun (except for libc) on Linux. (See issue#191)
fix: parser performance issues [PR#307]

This improvements affects all operations, but in particular we noticed that it caused completions in a large file to go from 300ms to 3ms.

We have a couple more changes that we want to get in before we start preparing for the release of Mun v0.3. In particular, runtime linking and one outstanding review on our language server. After that we’ll start the process of testing our Rust & C++ bindings, adding missing documentation and examples, and squashing bugs. Can’t wait? Please help us test the latest version of Mun by building from source.

For more details, please check out our high-level roadmap on Github that details new features for the upcoming three releases - Mun v0.3, v0.4, and v0.5 - as well as a backlog of features that are still to come.

Community

This Month in Mun - January 2021

Fri, 05 Feb 2021 00:00:00 GMT

Revitalized from the holiday break, the core team got cracking, resulting in half a dozen completed pull requests and even more in review. What’s more, some fresh blood is dipping their toe in the Mun pond, as we kick off the new year.

Mun v0.3 progress

It’s been a while since we had as much progress as in January, so to refresh your memory: Mun v0.3 is a tock release. This means that we focused on improvements to the user experience - for people writing and embedding Mun - and enhancements to the developer experience - for people contributing to Mun. In particular, a lot of work went into providing a better editing experience with more additions to the language server.

feat(language server): integrated new vfs [PR#294]

Previously we used ra_vfs from Rust Analyzer to manage all file handling in our language server. Rust Analyzer moved away from that crate and implemented a custom solution. With the introduction of Rust 1.49 we encountered some clippy errors in our use of ra_vfs. We followed suite and implemented a (much simpler) custom solution. This PR introduces a virtual filesystem that keeps a consistent state of all files currently used in our analysis in memory. It also provides a way to monitor the filesystem for changes and atomically applies these changes to the in-memory state. In the future the goal is to use this same functionality for our watch mode, when building the source.
feat(language server): removed async code and switched to lsp_server [PR#295]

async is a great feature of Rust. We’ve used it a lot in our implementation of the language server. However, this was also really the only place that actually benefited from async IO. A lot of our asynchronous code consists of fire-and-forget computations, which don’t really benefit from Rust’s async approach and instead work very well in a simple thread-pool. Besides that, our async implementation required a lot of boilerplate code because most of our dependencies are not async compatible (e.g. salsa).

Therefore, we decided to remove our async code and instead use a simple thread pool. This also allowed us to switch to an existing crate for our Language Server Protocol implementation, consequently making the code more readable.
feat(cli): add option to emit IR [PR#296]

Mun always emits platform-dependant shared objects. These are hard to debug if our code generation behaves incorrectly. This PR adds the ability to output Mun assemblies as LLVM IR files, which are much easier to debug since we can easily translate them to a human-readable format.
feature(lsp): adds document symbol provider [PR#297]

More work on the language server implementation. This PR adds the ability to visualize the symbols inside a document by inspecting the Abstract Syntax Tree of the file.
feat(book): describe how to install/build LLVM [PR#304]

The Mun compiler source code makes heavy use of LLVM. We install most of our dependencies through cargo but - as LLVM is a system dependency - it as to be installed manually. Installing LLVM is a tedious task, not made easier by the fact that we also require a specific version. We receive a lot of questions about how to install this dependency. This PR adds an explanation on how to install LLVM for different operating systems.
fix: manually extract llvm release to get more output [PR#302] and misc: adds logging to windows llvm install [PR#301]

We’ve had some annoying issues with our Windows CI pipeline for a while. For unknown reasons it kept failing sporadically. When we thought we had fixed the issue, it would pop back up a few days later. With these PRs we tried to investigate why this failure occurred. It helped us find the issue and implement a fix, which will hopefully nip the problem in the bud.

There are currently also a number of open Pull Requests in review that we hope to integrate soon. Part of those focus on enabling the use of multiple source files in the form of a Mun project. Specifically, we worked on runtime linking of multiple assemblies, which brings all of the features of the past few months together.

Community

Our requests for new contributors were answered this month. Only just getting up to speed, they were already able to create their first PR - that is still in review.

If you are also interested in helping develop Mun - but are not sure where to start - feel free to take a look at our good first issues or reach out to us on Discord or Twitter. To support our cause, please consider donating to our Open Collective or Github Sponsors.

Exciting times! Stay tuned for more!

This Month in Mun - December 2020

Tue, 05 Jan 2021 00:00:00 GMT

December - again - was a slow month; holidays and day jobs keeping the core developers busy. We did finally manage to work together during the holiday break.

As stated in last month’s update we are looking into the possibility of funding a third
developer ourselves - albeit a token amount. Sadly, none of our existing contributors can dedicate more of their precious time either, so we are on the lookout for new talent.

Tell me more!

As the reward is commensurate of an internship allowance, we’re targetting a similar audience. So, if you’ve been working on your own Rust projects and want to take the next step on a bigger, community-driven project; or have always been interested in honing your compiler, language, or garbage collection skills; this is an opportunity to do so alongside two industry veterans. An added bonus is that all of our code is - and will always remain - open-source, so you can show off all of your work on Mun during future job interviews.

If you are interested in helping develop Mun - but are not sure where to start - feel free to take a look at our good first issues or reach out to us on [Discord][discord], Twitter, or the Contact Us link at the bottom of our website.

Mun v0.3 progress

feature: use statements language support [PR#290] The language side of things to support multi-file projects is about to be wrapped up with the introduction of use statements. We implemented use statements similar to how they work in Rust, including support for wildcard imports.
```
use package::foo::Bar;
use package::bar::{self, Baz, *};
```
The next step for our project management epic is to support runtime linking between assemblies.
bump: rust 1.49 [PR#291] and bump: rust 1.48 [PR#289] We updated our codebase to work with the latest versions of Rust. This also included fixes for new clippy warnings.

This Month in Mun - November 2020

Mon, 07 Dec 2020 00:00:00 GMT

This Month in Mun is a little different from our usual posts. There’s a very simple reason for that; we didn’t manage to do much.

Apart from being the two Core contributors on Mun, we (Bas & Remco) have our day jobs in the robotics and games industries; which means that all of Mun’s development happens in our spare time. We knew that would form a bottleneck for Mun’s growth, so with the help of @erlend_sh we’ve heavily invested in our community from the start. We actively engage with the Mun and wider open- source community to collaborate on shared problems; we open-source the Core team’s discussions on Github, such that anyone can pitch in and execute on our plans; and much more.

Since our Mun v0.1 release a year ago, this strategy has paid off in many ways. We received a $15K MOSS grant from Mozilla in part because of our contributions to the community; more than half a dozen people have been generous enough to sponsor our development with their private funds on Open Collective and Github Sponsors; over double that number of contributors have improved, fixed or otherwise worked on the Mun codebase; and we’ve had a lot of community engagement on our Discord.

There’s still a lot that we can improve though. As we don’t have enough funding to dedicate part of our own workweek to open-source development, we’ve been looking into the possibility of funding a third developer ourselves - albeit a token amount. Sadly, none of our existing contributors can dedicate more of their precious time either, so we are on the lookout for new talent.

Tell me more!

If you are interested in helping develop Mun - but are not sure where to start - feel free to take a look at our good first issues or reach out to us on Discord, Twitter, or the Contact Us link at the bottom of our website.

Mun v0.3 progress

If your take away from this blog was, “Really?! You didn’t manage to do anything for an entire month?!”, there is one thing that we can share. Several of our PRs were blocked by a bug in cbindgen. We upstreamed a fix, allowing us to continue work on the following PRs:

refactor: make type-specific data (such as StructInfo) part of TypeInfo [PR#287] [PR#10] [PR#9]

This Month in Mun - October 2020

Sat, 31 Oct 2020 00:00:00 GMT

When Mun takes part in Hacktoberfest, there’s one thing you can be sure of; lots and lots of pull requests. This month saw us finalise some big new features and refactors that inch us ever closer to a Mun v0.3 release.

Community

This month Mun partook in the DigitalOcean Hacktoberfest - a great event aimed at supporting the open source community. Our goal was to get as many members to contribute at least 4 pull requests, such that they could win either a limited edition T-shirt or plant a tree. That led to the following contributions

feat: add mdbook plugin for testing mun code in book [PR#263] This allows testing of Mun code in mdbook, guaranteeing that the Mun book remains up-to-date when we update our Mun compiler and runtime.
docs: fix broken book link and CoC link [PR#284]

We are very thankful for your contributions and we hope to see more of them in the future!

Mun v0.3 progress

This month we finally landed the long-awaited compiler and language-server support for multiple files in a single project:

feature: adds modules and visibility [PR#283]

  // mod.mun
  struct Foo;
  fn main() -> self::Foo {
      Foo
  }
  fn bar() -> Foo {
      super::Foo  // undefined value
  }
  fn baz() -> Foo {
      package::Foo
  }
  // foo.mun
  struct Foo;
  fn bar() -> Foo {
      super::Foo  // mismatched type
  }
  fn baz() -> package::Foo {
      super::Foo
  }
  fn nested() -> self::Foo {
      package::foo::Foo
  }

Those familiar with Rust conventions will notice that Mun:

uses mod.mun instead of lib.mun for the top-level file; and
does not require you to add a mod foo; statement to the mod.mun file. Instead all files in the src folder are assumed part of the file tree.

feature: adds super self and package keywords [PR#8]

In addition, we laid most of the groundwork for runtime linking of multiple Mun libraries:

fix(codegen): alignment of struct fields [PR#285]

feat(codegen): add AsValue macro support for enums [PR#286]

#[derive(AsValue)]
#[repr(u8)]
pub enum TypeInfoData<'ink> {
    Primitive,
    Struct(StructInfo<'ink>),
}

Together with soon to be merged PRs, that should bring us within earshot of the Mun v0.3 release:

refactor: make type-specific data (such as StructInfo) part of TypeInfo [PR#287] [PR#10] [PR#9]
WIP: refactor: replace TypeInfo with TypeRef for runtime linking of types [PR#268]

Finally, we also performed some fixes and bumped the supported Rust version:

fix: dont run mun tests on CI [PR#278]
bump: rust 1.47 [PR#279]
fix: 7zip issues [PR#280]

This Month in Mun - September 2020

Thu, 01 Oct 2020 00:00:00 GMT

The community and core team worked together on improvements to bring Mun closer to a new release. Work is also progressing to support multiple source files.

Community

A community member whom we welcomed last month picked up another good first issue and also fixed some deprecations:

build: pin rust version to 1.46.0 [PR#269]
improvement: bump smol_str dependency to 0.1.17 [PR#270]

We are very thankful for your contributions and we hope to see more of them in the future!

More community contributions came from a contributor who tried out our C++ bindings and immediately fixed some issues:

fix: resolve compiler error in MunGuid equality operator and add assignment operators to RuntimeFunction [PR#9]

Thanks for your contributions, and welcome to the Mun community!

If you are also interested in helping develop Mun - but are not sure where to start - feel free to reach out to us on Discord or Twitter. To support our cause, please consider donating to our Open Collective or Github Sponsors.

Mun v0.3 progress

This month we again focused on some big refactors to create a more stable and maintainable codebase. This includes some bug fixes which were found by the Mun community as well as more high level documentation about our use of Salsa.

fix: never return type in let initializer [PR#264]
refactor: use Idx instead of macro in arena [PR#266]
misc: split database and added docs [PR#267]

Work is still underway to support multiple files in a single project but supporting PRs have already landed.

feature: adds fixtures to support multiple files from string [PR#272]
feature: refactored RawItems into ItemTree [PR#271]

With the work done for project configuration in July, we are focusing on compiler support for use statements and accessibility specifiers.

Last month we talked about wanting to release Mun v0.3 but we are not quite there yet. We chose to delay the release a little bit to give ourselves some time to achieve the level of polish that we aspire to deliver in every release.

This Month in Mun - August 2020

Sun, 30 Aug 2020 00:00:00 GMT

This month brings some big community and core team updates, paving the way for the release of all Mun crates - including the compiler - to crates.io.

Community

We welcomed a new community contributor, who immediately took on a big good first issue:

feat: type alias [PR#251] [PR#7]

Thank you for your contributions, and welcome to the Mun community!

Mun v0.3 progress

This month we mainly focused on some big refactors that improved ergonomics and will allow us to add runtime type dependencies - a core component for project management.

improvement: shared diagnostics between compiler and language server [PR#239]
refactor: generate C ABI from Rust code [PR#255] [PR#8] [PR#8]

An ergonomic improvement that allows us to use Rust’s algebraic data types (or ADTs), while remaining C ABI compatible.
refactor: move library loading logic to separate crate [PR#252]
refactor: move test utility functions to separate crate [PR#253]
refactor: upgrade to official inkwell [PR#254]

Thanks to this refactor we were able to move to an official release of inkwell, allowing us to release the Mun v0.3 compiler crates on crates.io in the future.

For now, we are still stuck on LLVM 8, due to a bug in the LLD linker - that was introduced in later versions. We’ve created a fix that has been merged, so we should be able to upgrade to future releases of LLVM again.

Having finished project configuration last month and runtime type dependencies well underway, we’ll be focussing on compiler support for use statements and accessibility specifiers next.

It’s been over three months since we started work on Mun v0.3. Whereas it took us six months to release Mun v0.2, our goal is to shorten our development cycle to 3-4 months, going forward. As such, we’ve moved several “nice to have” issues to the next tock release - Mun v0.5 - to make sure that we can release Mun v0.3 in about a month.

This Month in Mun - July 2020

Thu, 30 Jul 2020 00:00:00 GMT

A long list of community contributions, big marshalling performance improvements, technical debt flying out of the window, and a Rustacean Station podcast with the two Mun Core Team members. That can only mean one thing: yet another month of Mun development has come and gone.

At the end of last month, Rustacean Station released a podcast about Mun in which we sat down with host Jeremy to talk about why we chose Rust to develop Mun. If you are interested in having an inside look into Mun’s origins and evolution, we recommend you check it out - or any of Rustacean Station’s other podcasts for that matter!

Community

This month we had some new and exciting community contributions:

feature: initial LSP support [PR#236]
feat: add Spaceship example [PR#1] After having received a lot of Break It contributions, this Spaceship game marks the first Make It contribution for season 1 of our Make It or Break It contest, pushing the limits of Mun to Rust marshalling.
improvement(tools): bump bindgen dependency to 0.54 [PR#242]
fix(parser): parsing of unmatched right curly braces (’}‘) [PR#243]
fix: removed outdated comments [PR#245]
feat(cli): Implement mun new and mun init [PR#246]

Thank you for all of your contributions, and a warm welcome for our new community contributors!

We have added one additional good first issue on Github, which is a good starting point for anyone who wants to get involved with Mun:

Pin Rust version [issue#247]

If you are interested in helping develop Mun - but are not sure where to start - feel free to reach out to us on Discord or Twitter. To support our cause, please consider donating to our Open Collective or Github Sponsors.

Mun v0.3 progress

The Mun Core Team has been making steady progress on other improvements and refactoring for our Mun v0.3 release. With this tock release we hope to improve the user experience for people writing and embedding Mun, as well as enhance the developer experience for people contributing to Mun.

improvement(runtime): add benchmarks for and optimise struct field marshalling [PR#238] Based on feedback from the Veloren Team we started some guided optimisation of our struct marshalling code, which has resulted in huge improvement:
misc(ci): build binaries for release branches [PR#240]
refactor: upgrade to salsa 0.15 [PR#244]

In the coming month we’ll be finishing up our Inkwell upgrade, allowing us to release our compiler crates in the future while cleaning up some technical debt in the process. At the same time, we are adding support for multi-file projects to our ABI, compiler, and runtime.

For more details, please check out our high-level roadmap on Github that details new features for the upcoming two releases - Mun v0.3 & v0.4 - as well as a backlog of features that are still to come.

This Month in Mun - June 2020

Tue, 30 Jun 2020 00:00:00 GMT

After the dust settled of the Mun v0.2 release, the focus of this month has been on fixing several issues found by community members, improving the overall quality of the code base and working towards our next release: Mun v0.3.

Community

A few important community PRs landed during this month:

improvement: added combatibility check between munlib and runtime [PR#226]
refactor!: Replace deprecated failure crate with thiserror and anyhow [PR#213]

In honour of the Mun v0.2 release we launched the Make It or Break It contest in which we invite both content creators and developers to use Mun v0.2 and make or break something with/in Mun. The best Make It or Break It entry will be showcased on the front page of the Mun website.

We’ve already seen several issues being posted which break Mun v0.2 in interesting ways. We are very glad that these issues surfaced and we’ve been working hard on fixing them:

fix: fixes a lot of llvm assertions [PR#233]
fix: fixes issues #225 [PR#232]
fix: fixes issue #228 [PR#229]
fix(codegen): crash on missing nested private function [PR#221]

June also marks the month in which the mun-lang organization has been admitted to the Github Sponsorship program. We saw a influx of sponsors on both our Github sponsors as well as on our Open Collective. We can’t thank you enough!

We also added another good first issue:

Implement mun new or mun init [issue#237]

Mun v0.3 progress

We work with a tick-tock verison model. With a tick version we implement important new features whereas with a tock version we improve on the last version. Mun v0.2 was a tick version so Mun v0.3 will be a tock version. We have defined milestones on GitHub, on which you can follow the progress of the upcoming release.

A lot of work has been put into the next release:

feature: foundation for projects [PR#223]

This PR introduces the concept of projects as described in the Project Management tracking issue. Instead of building Mun files by listing individual source files you now build an entire project (similar to a rust crate).
feat: language server setup [PR#210]

Work on our language server has slowly been progressing. The basic foundation has been implemented but no actual language server features have been implemented yet. We are working hard on implementing the first basic features:
refactor(codegen): type safe inkwell types [PR#202]

A major thorn in our sight was the use of partially untyped inkwell types in our codebase. When dealing with a StructValue there is really no way to ensure that the underlying struct value is actually of the type you’d expect. To that end we implemented the Value<T> type which wraps an inkwell type but retains the Rust type information. With this, we already found some glaring issues which have now been fixed.

There is still a lot more work to do for Mun v0.3, so stay tuned!

This Month in Mun - May 2020

Sun, 31 May 2020 00:00:00 GMT

This month marked the release of a new version of Mun. It took us quite some time but after almost half a year, Mun v0.2 is out now! The most important feature of Mun v0.2? We now support hot reloadable structs.

Community

After the release of Mun v0.2 we saw an influx of community members, who pulled together to fix some of the issues in the release:

fix(docs): remove return-blocking semicolon from ch01 listing 01 [PR#192]
fix(docs): code blocks in ch02-02-functions of the book [PR#194]
fix(docs): missing arg for fibonacci fn [PR#197]

Our Discord also saw a spike in user activity and we have had some really fruitful discussions there. We hope to include the community more and more in the entire design & development process. To that end we have added several tracking issues for new features that we want to develop in the coming months.

Besides tracking issues we have also added additional good first issues on Github, which is a good starting point for anyone who wants to get involved with Mun:

Implement compatibility checks between munlib and runtime [issue#188]
Test Mun examples in the book [issue#209]

v0.2

At the start of this month we were able to put the finishing touches to the second release of Mun. As mentioned, the Mun v0.2 release features hot reloadable data structures that are automatically memory mapped, but that’s far from all new goodieness. Some other interesting features that were added this month are:

feat: implements number type inferencing [PR#154]

fn integer() -> i32 {
    0 // inferred as i32
}
fn large_unsigned_integer() -> u128 {
    0 // inferred as u128
}
fn with_let() -> u16 {
    let b = 4;    // inferred as u16
    let a = 4;    // inferred as u16
    a
}

misc: removed float, int, uint [PR#157]

Now that we have sized scalar types, there was no longer a need for generic int and float types. As they were only confusing for new users, we removed them.
feat(book): add book to main repository [PR#182] We integrated the Mun book into the main repository, such that we can automatically test all its examples during CI builds - in the future. With the release of Mun v0.2, a lot of content was added to the book. The book of Mun v0.2 is available here.

The complete list of changes for Mun v0.2 can be found in the release notes.

VSCode Plugin

We launched an official Visual Studio Code plugin that adds full support for syntax highlighting of Mun v0.2 code. Our goal is to extend this plugin to better integrate with VSCode through the language server protocol. This will hopefully also benefit other editors in the future. The plugin is available on the VisualStudio Marketplace and on Github.

Fun fact: The plugin also drives syntax highlighting on this website.

v0.3

Now that Mun v0.2 is out of the door, we can focus on developing the next version of Mun. We work according to a tick-tock release cycle. During a tick release we implement new language features, whereas a tock release focuses on bettering the status quo by removing technical debt, fixing bugs, and improving overall ergonomics. Since Mun v0.2 was a tick release, Mun v0.3 will be a tock release.

We try to be as transparent as possible, so to that end we posted a high-level roadmap on Github that details new features for the upcoming two releases - Mun v0.3 & v0.4 - as well as a backlog of features that are still to come. We also assigned milestones to and labelled all issues to make them more insightful. The milestones can be reviewed in this overview.

Our goal is to release Mun v0.3 a lot sooner than Mun v0.2. Hopefully after a few months instead of half a year. Please stay tuned!

Release - Mun v0.2.0

Sat, 16 May 2020 00:00:00 GMT

After half a year of hard work by the Mun Community and Core Team, we are happy to present Mun v0.2.0. With the addition of hot reloadable structs, this forms a big step forward in terms of hot reloadability for the language.

What’s Mun?

Ahead of time compilation - Mun is compiled ahead of time (AOT), as opposed to being interpreted or compiled just in time (JIT).
Statically typed - Mun resolves types at compilation time instead of at runtime, resulting in immediate feedback when writing code and opening the door for powerful refactoring tools.
First class hot-reloading - Every aspect of Mun is designed with hot reloading in mind. Hot reloading is the process of changing code and resources of a live application, removing the need to start, stop and recompile an application whenever a function or value is changed.

What’s new?

Mun v0.2 brings a ton of updates. For a full list have a look at the changelog, but the main new features are:

Hot reloadable data structures
Marshalling of data structures to Rust, C, and C++
Garbage collection for data structures (with opt-out at the struct-level)
loop, while, break and explicit return expressions
Full operator support for numeric and boolean types
Incremental compilation
Benchmark support

What’s next?

Mun is still in early development, so there is a lot to do. The Mun Core Team operates according to a tick-tock release cycle. Development of a tick release (Mun v0.2) focuses on implementing new features, whereas a tock release (Mun v0.3) focuses on using and improving existing features.

In particular, we’ll focus on making a Rust+Mun game demo that showcases Mun’s hot reloading capabilities and we’ll be working on a cargo-like application for better Mun project management. For a complete roadmap, please visit our GitHub Milestones.

As Mun consists of a separate language, runtime, and an ABI that forms the communication protocol between the two; any language can benefit from the Mun Runtime’s hot reloading capabilities. This leaves room for others to integrate the Mun ABI with (a semantic subset) of other languages such as Rust.

How can I learn more?

To get started, read the Mun Book and have a look at our Rust and C++ examples.

If you are interested in helping develop Mun feel free to reach out to us on Discord or Twitter, or pick up one of our good first issues on GitHub.

If you cannot personally contribute but would still like to support our cause, please consider donating to our Open Collective.

Acknowledgments

This release would not have been possible without the incredible contributions from the Mun Community and the generous support of Mozilla - in the form of the MOSS grant. We are extremely grateful to all of you!

This Month in Mun - April 2020

Sat, 02 May 2020 00:00:00 GMT

In our efforts to finalise Mun v0.2, we’ve made a big push for the finish line. Through the combined efforts of the Mun Community and Core Team, we were able to release a record amount of new features, bug fixes, and improvements; the most anticipated new kid on the block being struct hot reloading!

Community

This month we had another exemplary case of community contribution. Someone ran into problems while writing Mun code, logged corresponding issues, and - with our help - created several pull requests to resolve the issues themselves:

refactor: use ’->’ instead of ’:’ for fn return types [PR#123]
```
  fn foo() -> i64 {
      0
  }
```

feat: add 128-bit integers (i128 and u128) [PR#124]

  fn foo() {
      let _a = 100_000_000_000_000u128;
      let _b = -100_000_000_000_000i128;
  }

misc: lock cbindgen dependency to 0.14.0 [PR#126]
style: add a missing space to invoke_fn15’s definition [PR#132]

feat: remainder operator [PR#135]

  fn remainder(a: i64, b: i64) -> i64 {
      a % b
  }

feat: unary operators [PR#136]

  fn negate(a: i64) -> i64 {
      -a
  }

As our Core Team only consists of two part-time members, this greatly helps us scale our output! Another new contributor has picked up one of our good first issues. Hopefully we will be able to merge their PR soon.

We have added one additional good first issue on Github, which is a good starting point for anyone who wants to get involved with Mun:

refactor(abi): move privacy and name from FunctionSignature to FunctionInfo [issue#146]

v0.2 progress

The last checkbox we needed to tick for the Mun v0.2 release was struct hot reloading:

refactor: remove TypeInfo and StructInfo from StructRef [PR#109]
feat: memory mapping [PR#117]

[blog]

fix(runtime): ensure loaded Assemblies can be linked [PR#139]
feat: add casting of fundamental types to memory mapping [PR#140]
refactor: cleanup runtime/memory code [PR#142]

Apart from that we focused on bug fixes, quality of life improvements, and brushing up our documentation for the upcoming release:

fix: infer invalid struct type [PR#111]
fix: fixes #113 [PR#114]
misc: updates to official cbindgen crate [PR#115]
docs(readme): new Arch Linux install instructions [PR#116]

improvement: better literal support [PR#122]

  fn main() {
      let a = 1i8;
      let a = 0x3a_u32;
      let a = 0o71234;
      let a = 1_000_000_u32;
      let a = 5i64;
      let a = 3.0f32;
      let a = 1_000_123.0e-2f32;
  }

feat: add support for extern functions without a return type [PR#127]

  extern "C" fn foo(a: i64) {
      println!("{}", a);
  }

fix: fixes #128 [PR#130]
misc: merged file and group ir snapshots [PR#131]
fix(codegen): only generate exposed functions [PR#134]
fix: color output on linux terminal [PR#138]
chore(ci): split artifact generation into separate workflow [PR#141]
feat(runtime): add cloning of StructRef [PR#143]

feat: add assignment, bit, and boolean operators [PR#144]

  struct Foo {
      a: bool,
  }

  struct Bar(Foo);

  fn main() {
      let b = true;
      let foo = Foo { a: !b };
      foo.a |= (b ^ true) && (b ^ false);

      let bar = Bar(foo);
      let foo2 = Foo { a: b };
      bar.0 = foo2;
      let a = 2 >> 1;
  }

With struct hot reloading completed, we are now putting the final touches to our documentation and C++ bindings - before releasing Mun v0.2. Please stay tuned!

Hot Reloadable structs: Memory Mapping

Fri, 01 May 2020 00:00:00 GMT

The Mun v0.2 release is on the horizon, so we wanted to take this opportunity to delve a little deeper into this release’s big newcomer: hot reloadable structs. Being able to effortlessly hot reload data was what we originally set out to do when designing Mun, so we are excited to share how we brought this feat about.

At its core Mun leverages function and type information - known as symbols - that are generated by the Mun Compiler. When changes to a source file cause a recompilation, the runtime detects this and attempts to hot reload; swapping out old functions and types with their new counterparts, without stopping the host application. Whereas hot reloading of functions can be easily done in most languages (e.g. by swapping shared libraries with a fixed API), hot reloading data is more complicated because it requires information about the data layout.

struct OldLayout {
    foo: f32,
    bar: i16,
}

struct NewLayout {
    foo: f64,
    bar: i16
}

Given the old and new layout of a struct, we can memory map field values from an old struct instance to a new instance’s memory locations. Thanks to Mun’s symbols we can now deduce this mapping - albeit nontrivial. The remainder of this blog will explain the algorithm we’ve developed to create a “correct” memory mapping from an old list of types to a new list.

Myers Diff

Another way of thinking about the problem is: given a starting state S and goal state G, we can make a sequence [c₁, c₂, .. c_n] of changes to S - in any order - such that we arrive in G. In an ideal world we’d know all of the changes c_i; instead we only know S and G. Thus, we need to deduce the “correct” set of changes ourselves.

Note: It might be possible to obtain all changes c_i by means of an IDE integration that converts all key strokes into a change set, but as we cannot assume that everyone will use our integration - nor that it is perfect - we need a good algorithm for the simplest use case.

Analogous to our problem is git diff, which determines the set of changes between two lists of files. By default, git uses Myers diff algorithm to calculate the set of insertions and deletions to go from a start state S to a goal state G. For a thorough explanation of the Myers diff algorithm, I recommend this blog.

enum Diff {
    Insert,
    Delete,
}

Myers diff algorithm serves as a good starting point to determine what is different, but we need to refine its result to figure out how two structs might differ.

Refined Diff

At this point, it’s good to ask ourselves what possible differences could occur between two lists of structs. Given an old list of struct types,

struct LayoutA {
    a: f32,
    b: i16,
    c: u8,
    d: bool,
}

struct LayoutB {
    e: u128,
    f: i64,
}

struct LayoutC {
    g: bool,
}

and a new list,

struct LayoutBB { // Rename struct + Move struct
    e: u128,
    f: i64,
}

struct LayoutA { // Move struct
    c: u8,    // Move field
    a: f64,   // Convert field type + move field
    bb: i16,  // Rename field + move field
//  d: bool,  // Delete field
    e: i16,   // Insert field
}

//struct LayoutC { // Delete struct
//    g: bool,
//}

struct LayoutD { // Insert struct
    z: i64,
}

you’ll notice two types of annotated differences: changes related to structs or to struct fields. The observant reader might already have recognised that in some cases, there are multiple possible annotations. E.g. the change to LayoutA::bb could also be classified as a newly inserted field, causing the old LayoutA::b field to be deleted. Both would be valid conclusions, but when designing our algorithm we decided to prefer any choice that would allow for data retention. We’d rather have a user do extra steps to add a new (reset) field, than have them easily lose data that they actually wanted to retain. There is no recovery from the latter, after all.

So, how do we come up with the “correct” mapping? By adding some assumptions and restrictions, we are able to avoid most (if not all) ambiguous cases. The assumptions we’ve made are:

If an old struct type and a new struct type have the same name, they must be the same type. In this case, we accept any and all changes to the struct and its fields.
LayoutA is an example of this; the struct name remained the same but it was moved down by one position and all of its field were edited.
If an old struct type and a new struct type have different names but their fields are all the same, then the struct must have been renamed and can optionally be moved.
LayoutB is an example of this; the struct was renamed to LayoutBB and it was moved up by one position, but all of its fields remained the same.
If an old field and new field have the same name and type, they must have remained unchanged. In this case, the field can be moved.
LayoutA::c is an example of this; the field name and type remained the same but it was moved up two positions.
If an old field and new field have the same name, they must be the same field. In this case, we accept a type conversion and the field can potentially be moved.
LayoutA::a is an example of this; the field name remained the same but it was moved down by one position and underwent a type conversion.
If an old field and new field have different names but the same type, the field could have been renamed. As there can be multiple candidates with the same type, we accept the renamed and potentially moved field that is closest to the original index of the old field.
LayoutA::b is an example of this; the field was renamed to bb and it was moved down by one position. Another candidate would have been the newly inserted field e which also has the same type i16, but would have been moved 2 positions - making bb the closest candidate.

Some restrictions can be derived from these rules:

A struct cannot simultaneously be renamed and its fields edited. This is intended to prevent cases such as LayoutC from being renamed to LayoutD and their fields being edited accordingly.
A struct field cannot simultaneously be renamed and its type changed. This is intended to prevent cases such as LayoutA::d from being renamed and undergoing a type conversion to LayoutA::e.

In both of the above cases, the difference will be recognised as two separate changes: an insertion and a deletion of the struct/field.

Based on the above assumptions, we can make two enums to classify changes. For memory mapping, renaming of a struct won’t affect the memory’s layout, so we don’t have a separate variant for that case.

enum StructDiff {
    Insert,
    Edit { diff: Vec<FieldDiff> },
    Move,
    Delete,
}

enum FieldDiff {
    Insert,
    Edit { kind: FieldEditKind },         // in-place edit
    Move { edit: Option<FieldEditKind> }, // move & optional edit
    Delete,
}

enum FieldEditKind {
    ConvertType,
    Rename,
}

With this knowledge we can create a refine(insertion: Diff, deletion: Diff) -> Option<StructDiff> function that tries to map pairs of Myers diff insertions and deletions to a StructDiff::Edit or StructDiff:Move. If a Diff cannot be refined, it is respectively labelled as StructDiff:Insert or StructDiff::Delete. The pseudocode of our hot reloading algorithm would look something like this:

fn hotreload(old_lib, new_lib) {
    let diff = myers::diff(old_lib.struct_types(), new_lib.struct_types());
    let refined_diff = {
      let (insertions, deletions) = diff.split();
      for insertion in insertions {
          for deletion in deletions {
              // try to find an optimal pair using `refine`
          }
      }
      // add unused insertions & deletions
      result
    };
    map_memory(old_lib.struct_instances, refined_diff);
}

To find an optimal pair we first calculate the number of changes necessary to convert a deleted struct’s fields to an inserted struct’s fields - for all possible pairs - using Myers diff algorithm. Then we perform a greedy search for (insertion, deletion) pairs with the least number of changes; until there are no viable candidates left. When a pair does not require any changes to its fields, the struct was merely moved; otherwise it was edited.

For an edited struct we need to also determine how its fields differ from the old struct. This is where our assumptions come into play:

fn field_diff(old_fields, new_fields) -> Vec<FieldDiff> {
    let diff = myers::diff(old_fields, new_fields);
    let (insertions, deletions) = diff.split();
    let (insertions, deletions) = {
        for insertion in insertions {
            for deletion in deletions {
                // find all fields with the same name and type;
                // i.e. `FieldDiff::Move { edit: None }`
            }
        }
        // Continue the search with all unused differences
        (unused_insertions, unused_deletions)
    };
    let (insertions, deletions) = {
        for insertion in insertions {
            for deletion in deletions {
                // find all fields with the same name
                // If moved, `FieldDiff::Move { edit: Some(FieldEditKind::ConvertType) }`
                // else, `FieldDiff::Edit { kind: FieldEditKind::ConvertType }`
            }
        }
        // Continue the search with all unused differences
        (unused_insertions, unused_deletions)
    };
    let (insertions, deletions) = {
        for insertion in insertions {
            for deletion in deletions {
                // find all fields with the same type
                // choose the pair with the shortest *move*
                // If moved, `FieldDiff::Move { edit: Some(FieldEditKind::Rename) }`
                // else, `FieldDiff::Edit { kind: FieldEditKind::Rename }`
            }
        }
        // Continue the search with all unused differences
        (unused_insertions, unused_deletions)
    };
    // add unused insertions & deletions
    result
}

Step 2 takes priority over step 3 because the uniqueness of field names in a struct allows us to assume with reasonable certainty that the fields were intended to be mapped.

Memory Mapping

That wraps up the calculation of a refined diff between an old and new list of struct types. Using the refined diff and Mun’s symbols we can now trivially create a mapping that maps old to new memory addresses for all fields, and apply this mapping to all heap-allocated struct instances.

Hopefully I was able to convey the algorithm clearly, but in case you have any questions feel free to ask them on Discord or Twitter. You can also dive directly into the Myers diff, struct diff, field diff, diff to mapping conversion, or memory mapping source code on our Github.

This Month in Mun - March 2020

Thu, 02 Apr 2020 00:00:00 GMT

A lot of things that we cannot fully control are currently going on in the world. The Mun community and Core Team are trying to make the best of the situation and have once again made great strides; the recently obtained MOSS grant giving us an additional productivity boost!

Community

Our community has made great progress on the integration of the annotate-snippets crate. Hopefully we will be able to merge their PR soon.

We have added new good first issues on Github, so if you want to get involved with Mun please check them out:

Replace return type annotation : with -> [issue#105]
Implement slab allocator to store ObjectInfo<T> [issue#106]
feat: add type aliases [issue#110]

v0.2 progress

We still had two major features left on our v0.2 roadmap: garbage collection and struct hot reloading. This month we were able to finish the former and started on foundational work for the latter; with a projected release date of Mun v0.2 by early May:

feat(runtime): add marshalling of value structs [PR#93]

  struct(value) Foo {
      x: int,
      y: int
  }

  pub fn foo_new(x: int, y: int): Foo {
      Foo { x: x, y: y, }
  }

  pub fn foo_add(foo: Foo): int { foo.x + foo.y }

  fn main() {
      let lib_dir = env::args().nth(1).expect("Expected path to a Mun library.");
      let mut runtime = RuntimeBuilder::new(lib_dir)
          .spawn()
          .expect("Failed to spawn Runtime");

      // The Mun compiler automatically generates a wrapper for `pub fn`s that
      // contain `struct(value)` arguments or return types, which allocates the
      // marshalled data in the runtime's allocator.
      let mut foo: StructRef = invoke_fn!(runtime, "foo_new", 1i64, 2i64).wait();
      let x = foo.get::<i64>("x").unwrap();
      let y = foo.replace("y", x + 1).unwrap();
      foo.set("x", y).wait();
  }

feat: extern functions [PR#96]

  /// This is a function that does not have an implementation in Mun but instead is linked 
  /// dynamically when loading the assembly
  extern fn tick_the_system();

  fn main() {
    // The extern functions can be called like any other Mun function
    tick_the_system()
  }

feat: object ptr indirection [PR#97]
feat: size and alignment in type info [PR#98]
feat: garbage collector (defaults to mark&sweep) [PR#99]

Quality Assurance

Our unceasing efforts to improve code coverage have resulted in several PRs focussed on new tests (and consequent fixes) - including our 100th PR!! 🎉

Replace grcov with tarpaulin for test coverage [PR#100]
fix(code_gen): incremental compilation [PR#101]
test(code_gen): add incremental compilation test [PR#102]
fix: name of type table global [PR#108]

We are always trying to improve metrics for objectively tracking quality as we progress. We’ve previously talked about how unit and integration tests are a big part of our development process. This month we’ve added performance benchmarks using Criterion, allowing us to do our first optimisations in the Mun Runtime.

The violin plot above compares function invocation overhead of embedded languages (Mun, LuaJIT, Wasm) with the raw performance of Rust by invoking an empty function that merely returns the input argument. The Wasmer runtime was used to execute Wasm.

Please note that Rust takes around 675 ps and is thus not visible on the above scale. For clarity, below you can see the respective PDFs of function call times in order of speed (less is better); i.e. for Rust, Mun, Wasm, LuaJIT (from left to right, top to bottom).

To test arithmetic and logic performance, we needed to minimise the function invocation overhead; enter Fibonacci. The line chart below shows the mean measured time for each language as the input argument increases (100, 200, 500, 1000, 4000, 8000). Even at this early stage, Mun’s dependence on LLVM as compiler backend allows us to achieve performance comparable to Rust.

All benchmarks were run on an Intel(R) Core(TM) i7-6700HQ CPU @ 2.6 GHz with 16 GB DDR4 RAM.

The benchmark source code is included with the Mun repository. Feel free to give it a try, add additional benchmarks, and share your findings with us on Discord, Twitter, or Github.

Last but not least, some miscellaneous quality of life improvements were also merged:

feat: only create symbols for public functions [PR#92]
fix: removed the codecov token [PR#94]
improvement: bump parking_lot dependency to 0.10 [PR#103]
improvement: bump failure dependency to 0.1.7 [PR#107]

This Month in Mun - February 2020

Tue, 10 Mar 2020 00:00:00 GMT

Mun awarded MOSS grant

We are very proud to announce that Mun has been awarded a $15K grant as part of the MOSS Mission Partners track. Its an honour for an established open-source company like Mozilla to put their faith in our mission and capabilities. With Mozilla’s generous support, we are able to boost the Core Team’s efforts to finish hot reloadable data structures during the coming months.

Our goal is to support Mun code with both stack-allocated and heap-allocated data structures, which can be hot reloaded from Rust, C, and C++. A garbage collector will be used to manage heap-allocated structs. Major milestones include:

Language support for structs (records, tuples, unit structs)

  struct Record { a: float, b: int }
  struct Tuple(Record)
  struct Unit;

Language support for structs with different memory management models

  struct(gc) Gc(int);         // Garbage collected
  struct(value) Value(int);   // Passed by value
  struct Default(Value);      // Defaults to `struct(gc)`

Marshalling of structs to Rust, C, and C++

  let mut value: StructRef = invoke_fn!(runtime, "value_new", 5i64).unwrap();
  assert!(value.set("0", 10i64).is_ok());
  assert_eq!(Ok(10i64), value.replace("0", 15i64));
  assert_eq!(Ok(15i64), value.get::<i64>("0"));
  let default: StructRef = invoke_fn!(runtime, "default_new", value).unwrap();

  auto value = mun::invoke_fn<mun::Struct>(*runtime, "value_new", 5).unwrap();
  assert(value.set("0", 10));
  assert(10 == *value.replace("0", 15);
  assert(15 == *value.get<int64_t>("0"));
  auto default = mun::invoke_fn<mun::Struct>(*runtime, "default_new", value).unwrap();

Our complete roadmap for the MOSS grant milestones can be found on Trello.

Acknowledgements

We would also like to thank Erlend for introducing us to and encouraging us to apply for the MOSS grant. If it weren’t for his confidence in Mun - at an early stage - we would not have thought ourselves ready to apply.

Next steps

The MOSS grant marks a great achievement for our team, but we don’t plan on stopping here. We want to keep improving and expanding Mun; and need your help to do so. Are you interested in contributing to Mun or do you just want to receive the latest updates? Then join us on Discord, follow us on Twitter, or watch us on Github. If you care about our mission but cannot aid in the development, please consider becoming a sponsor on our Open Collective.

This Month in Mun - January 2020

Fri, 31 Jan 2020 00:00:00 GMT

The dawning of a new year is often marked by reflection and the conception of resolutions. We felt that the goals we had previously set for Mun v0.2 were still true, so with the help of our community we pushed forward with our plans.

Community

The first PR of the year was made by a new community contributor. Welcome! Their PR was quickly followed by some PRs from a recurring contributor. These are some examples of good first issues that we hope will invite new contributors into our community, while helping improve the quality of life for our users and developers:

refactor: renamed public to pub and removed some un-used functions [PR#26]
test: add test to check if compiler output strings is valid utf8 [PR#67]
refactor: replace CStr::from_ptr(ptr).to_str() with from_utf8_unchecked [PR#66]
feat: compiled libraries have munlib extension instead of dll/so [PR#75]
fix(hotreloading): no more ‘successfully compiled’ message if code has errors [PR#78]
fix(diagnostic): move console cursor to new line after error log [PR#79]
test: add unit tests for LineIndex::line_str [PR#86]

A community member independently wrote a VSCode plugin for Mun syntax highlighting (source), for which we are very grateful!

The decision to call hot reloading-enabled libraries *.munlib is another great example of our community’s involvement. It was coined by one of our community members on our Discord and consequently received most upvotes.

If you like our vision of a hot reloading-powered world and would like to be a part of our journey, then join us on Discord, follow us on Twitter, or watch us on Github.

v0.2 progress

In december we had already implemented language support for data structures, but [PR#64] was not merged until earlier this month. That allowed our focus to shift to integrating structs with the Mun runtime, support for external (non-Mun) functions, Mun-Rust interoperability, and Mun-C interoperability:

feat: use extern functions in dispatch table [PR#90]

  intrinsics! {
      /// Allocates a chunk of memory in the runtime.
      pub fn malloc(size: u64, alignment: u64) -> *mut u8;
  }

feat: add marshalling of structs [PR#83]

  struct(gc) Foo {
      n: int,
      b: Bar,
  }

  struct(gc) Bar;

  fn foo_new(bar: Bar): Foo {
      Foo { n: 1, b: bar, }
  }

  fn bar_new(): Bar { Bar }

  fn main() {
      let lib_dir = env::args().nth(1).expect("Expected path to a Mun library.");
      let mut runtime = RuntimeBuilder::new(lib_dir)
          .spawn()
          .expect("Failed to spawn Runtime");

      let bar: Struct = invoke_fn!(runtime, "bar_new").wait();
      let mut foo: Struct = invoke_fn!(runtime, "foo_new", bar).wait();
      let n1 = foo.get::<i64>("n").unwrap();
      let n2 = foo.replace("n", n1 + 1).unwrap();
      foo.set("n", n2).expect("Failed to change `Foo::n`");
  }

refactor: dynamically include struct information in type information [PR#84]

feat: add struct as marshallable field type [PR#87]

  fn main() {
      let lib_dir = env::args().nth(1).expect("Expected path to a Mun library.");
      let mut runtime = RuntimeBuilder::new(lib_dir)
          .spawn()
          .expect("Failed to spawn Runtime");

      let bar1: Struct = invoke_fn!(runtime, "bar_new").wait();
      let mut foo: Struct = invoke_fn!(runtime, "foo_new", bar1).wait();
      let bar2: Struct = invoke_fn!(runtime, "bar_new").wait();
      foo.set("b", bar2).expect("Failed to change `Foo::b`");
  }

feat(runtime_capi): add functions for interoperability [PR#88]

Some bug fixes and miscellaneous quality of life improvements were also merged:

feat: add manual generation of abi, runtime-capi [PR#69]
feat: better error message printing when signature is missing [PR#80]
fix: struct initialization fix for non constants [PR#81]
fix(struct): prevent erroneous caching of struct types [PR#89]

Roadmap

Next up on our TODO list are language support for external functions, wrapping up Mun-C interoperability, hot reloading of struct data, and garbage collection.

This Month in Mun - December 2019

Wed, 01 Jan 2020 00:00:00 GMT

December is often perceived as a month that emphasizes family and togetherness. The Mun community for one really did pull together, allowing the core contributors to focus on making data structures a reality. This month, we’ve implemented:

Parsing of tuple data structures
```
  struct Baz(float, int);
```

Parsing and type inferencing of data structure literals

  struct Foo;
  struct Bar {
      a: float,
  }
  struct Baz(float, int);

  fn main() {
      let a: Foo = Foo;
      let b: Bar = Bar { a: 1.23, };
      let c = Baz(1.23, 1);
  }

Indexing of data structure fields

  fn main() {
      let foo = Foo { a: 1.23, };
      foo.a
      let bar = Bar(1.23, 4);
      bar.0
      bar.1;
  }

Generation of LLVM IR for data structure declarations, literals, and field indexing

Add data structure information to the Mun ABI

  typedef struct
  {
      /// Struct name
      const char *name;
      /// Struct fields' information
      const MunTypeInfo *field_types;
      /// Number of fields
      const uint16_t num_fields;
  } MunStructInfo;

Loading data structure information into the Mun Runtime

We also made some minor fixes for the latest version of Rust and added type checking of binary operations:

fn foo() {
    let b = false;
    let n = 1;
    let _ = b + n; // error: invalid binary operation
}

Meanwhile, the Mun community has not been standing by idly:

We welcomed our first community contributions (PRs #66 & #67) for two of our good first issues. This is a great way for community members to gain an understanding of our codebase and workflow, while helping us implement important fixes and improvements.
A community member who works on Veloren, created a proof of concept for Mun-powered hot reloading inside the game:

Are you interested in contributing to Mun or do you just want to receive the latest updates? Then join us on Discord, follow us on Twitter, or watch us on Github.

This Month in Mun - November 2019

Tue, 31 Dec 2019 00:00:00 GMT

November marked the first milestone release of Mun, providing the Mun community with a first chance to experiment with native hot reloading. Leading up to the release we mainly focused on CI, improving documentation, and bug fixes; but also made a few more additions:

Statically link mun against the liblld linker [PR#37] This allows us to release Mun binaries without any external shared libraries.

return expressions [PR#38]

  fn main(a:int):int {
      if a > 4 {
          return a;
      }
      a - 1
  }

Start functions that return native types from the CLI [PR#45]

Community

We strongly believe that close community collaboration is needed to achieve our goal of natively supported hot reloading. To that end, we’ve published a contributing guide, a code of conduct, and good first issues. We’ve also seen an influx of active users on our Discord server, whom we try to include as much as possible when making design decisions; e.g. when brainstorming or through polls. If you are also interested in contributing to (or even just observing) this process, feel free to join. No restrictions on experience level or whatsoever. We welcome everyone and anyone!

Roadmap

Having released Mun v0.1, we set out to plan our next releases. Instead of setting ourselves hard deadlines, we work with to do lists that need to be completed before we release the next version. This means that we do not release Mun versions at a fixed cadence, but it does allow us to implement features and improvements with the care that we think they deserve.

We are also strong believers in the philosophy of using what you make, so henceforth we’ll be adhering to a tick-tock release schedule; i.e. major feature releases are followed by improvement and bug fix releases during which we’ll be making demos that showcase the new Mun features while helping us discover flaws in our own designs.

For the next version, we are planning to add language and hot reloading support for data structures, loops, and external C functions. For the full roadmap of Mun, have a look at our Trello board.

v0.2 progress

Some of these language features are already available on our master branch:

loop expressions [PR#60]

  fn fibonacci(n:int):int {
      let a = 0;
      let b = 1;
      let i = 1;
      loop {
          if i > n {
              return a
          }
          let sum = a + b;
          a = b;
          b = sum;
          i += 1;
      }
  }

break expressions [PR#62]

  fn fibonacci(n:int):int {
      let a = 0;
      let b = 1;
      let i = 1;
      loop {
          if i > n {
              break a;
          }
          let sum = a + b;
          a = b;
          b = sum;
          i += 1;
      }
  }

while expressions [PR#63]

  fn fibonacci(n:int):int {
      let a = 0;
      let b = 1;
      let i = 1;
      while i <= n {
          let sum = a + b;
          a = b;
          b = sum;
          i += 1;
      };
      a
  }

The most anticipated addition that Mun v0.2 will bring are data structures. As it is a big change that spans across the entire codebase, we maintain a separate branch and work-in-progress PR to track progress. So far we’ve implemented:

Parsing of record and unit data structures

  struct Foo;
  struct Bar {}
  struct Baz {
      a: float,
      b: int,
  };

Name resolution for data structures

  fn main() {
      let foo: Foo;
      let bar: Bar;
      let baz: Baz;
  }

If you want to receive regular updates about our progress, join us on Discord, follow us on Twitter, or watch us on Github.

Rust 2020: Scalability

Thu, 14 Nov 2019 00:00:00 GMT

After the Rust Core Team’s call for blogs, all of my open-source time was being consumed by the Mun v0.1.0 release. This put me in the unique position to draw inspiration from other 2020 blogs, before deciding to add my own perspective.

To give some background, my Rust experience is mostly limited to the periphery. I am an active member of the Rust Gamedev WG, co-creator of and contributor to the Mun language - written in Rust - as well as some other crates relating to IO, web development, and C<->Rust bindings generation. As such I’d classify myself as a Rust language user.

Following in the footsteps of repnop, I want to take a moment to acknowledge this years achievements. In particular I’d like to highlight the expansion and hard work of the Rust community by listing 2019’s newly created working groups:

Localization (community): Working on localization of compiler, documentation and websites.
Rustfix (devtools): Improve cargo-fix and be a point of contact for other teams.
async-await (compiler): Implementing async-await.
LLVM (compiler): Working with LLVM upstream to represent Rust in its development.
Meta (compiler): How compiler team organizes itself.
MIR Optimizations (compiler): Write MIR optimizations and refactor the MIR to be more optimizable.
Parallel rustc (compiler): Making parallel compilation the default for rustc.
Profile-guided optimization (compiler): Implementing profile-guided optimization for rustc.
RFC 2229 (compiler): Make a closure capture individual fields of the variable rather than the entire composite variable.
RLS 2.0 (compiler): Experimenting with a new compiler architecture tailored for IDEs.
Self-Profile (compiler): Improving the -Z self-profile feature.
Governance (core): Working on improving Rust Governance.
Learning (compiler): Make the compiler easier to learn by ensuring that rustc-guide and api docs are ‘complete’.
Triage (release): Triage repositories under rust-lang organisation.
Secure Code: Making it easy to write secure code in Rust.
Resources (embedded): Managing various resources owned by the embedded WG.
Polonius (compiler): Experimental work on a new borrow-checker implementation.
Game development: Focusing on making rust the default choice for game development.

When you list all newly registered¹ working (sub-)groups like this, it’s quite an extensive list. And there are even more! E.g. the Rust Allocators WG is not officially listed on Rust’s team repository. These are efforts done by both Rust core and edge teams. It’s great that the Rust language, its ecosystem, and community contributions are growing rapidly, but this inherently comes with risks.

In the words of Bilbo Baggins, “I feel thin, sort of stretched, like butter scraped over too much bread.” When a userbase grows, so do the number of requests for features and support. As such, the scalability of a product (in this case the Rust language) is bound by the size and efficiency of the product team / community.

XAMPPRocky’s blog points out that Rust contributors are at risk of burnout or have already fallen prey to burnout, and calls for 2020 to be a year dedicated to making the Rust community efforts more sustainable. I couldn’t agree more, but would go a step further in saying that there are also other factors to consider when sustainably scaling Rust.

At its core, Rust is a systems language pursuing the trifecta: safety, concurrency, and speed. Its versatility has also attracted the attention of firmware, web application, and game development - to name a few. Community members spearheading Rust adoption in those fields probably contributed to the influx of new working groups. Whereas a lot of the sub-working groups have overlap in members, it seems that these new edge teams are comprised of new domain experts. If we don’t take care to keep the lines of communication short, this puts the Rust ecosystem at risk of fragmentation. A fragmented community would greatly diminish its effectiveness.

Unfortunately, Rust is still at a tipping point where most contributions happen on a voluntary basis. This means that contributors have at most a couple of hours a day to spend on Rust. Some large organisations are already using Rust, but it would be a huge influx of resources if the private sector would be more involved with the development of Rust itself.

Conclusion

In my Rust 2020 blog I tried to shy away from specific feature requests, instead zooming out to look at the Rust ecosystem as a whole. As a community, we’ve achieved great things but we should take care not to crumble under the weight of a scaling language and ecosystem. We all need to come together to ensure that Rust can sustainably scale - be it in large organisations, communities, or codebases.

¹ My sincere apologies if I missed any working groups. Please let me know and I’ll update the list.

Release - Mun v0.1.0

Mon, 11 Nov 2019 00:00:00 GMT

We are proud to present Mun v0.1.0 - our first milestone release. As a language, Mun is still far from production-ready, but this release gives you a glimpse of what natively supported hot reloading will look like in the future. The purpose of this release is to showcase our progress and gather feedback from those brave souls willing to try out Mun at this early stage.

To get started, read the Mun Book and have a look at our Rust and C++ examples.

Mun Language

So far, the Mun language supports boolean, integer and float native types, variable assignment, logical and arithmetic operators, function definitions and if-else control flow.

fn main() {
    let result = fibonacci(nth());

    // Comments: Mun natively supports bool, float, and int
    let is_true = true;
    let var: float = 0.5;
}

// The order of function definitions doesn't matter
fn fibonacci(n:int):int {
    // If-else statements are also expressions
    let fib = if n <= 1 {
        n
    } else {
        fibonacci(n-1) + fibonacci(n-2)
    }

    // Mun allows implicit returns
    fib
}

fn nth(): int {
   // Mun allows explicit returns
   return 5;
}

Mun Runtime

The compiler’s counterpart - the Mun Runtime - is capable of hot reloading functions and provides useful diagnostics when runtime errors occur. As the Mun Runtime is written in Rust, it can be easily embedded in Rust applications by adding the mun_runtime crate as a dependency.

use mun_runtime::{invoke_fn, RetryResultExt, RuntimeBuilder};
use std::env;

fn main() {
    let lib_path = env::args().nth(1).expect("Expected path to a Mun library.");

    let mut runtime = RuntimeBuilder::new(lib_path)
        .spawn()
        .expect("Failed to spawn Runtime");

    loop {
        let n: i64 = invoke_fn!(runtime, "nth").wait();
        let result: i64 = invoke_fn!(runtime, "fibonacci", n).wait();
        println!("fibonacci({}) = {}", n, result);

        // Hot reload code when there are changes
        runtime.update();
    }
}

Mun also exposes a C API and complementary C++ bindings for the Mun Runtime.

#include <iostream>

#include "mun/runtime.h"

int main(int argc, char* argv[]) {
    if (argc < 2) {
        return 1;
    }

    auto lib_path = argv[1];
    if (auto runtime = mun::make_runtime(lib_path)) {
        while (true) {
            auto n = mun::invoke_fn<int64_t>(*runtime, "nth").wait();
            auto result = mun::invoke_fn<int64_t>(*runtime, "fibonacci", n).wait();
            std::cout << "fibonacci(" << n << ") = " << result << std::endl;

            // Hot reload code when there are changes
            runtime->update();
        }
    }

    return 2;
}

Future

For the Mun v0.1.0 release, a lot of effort has gone into building the foundations of Mun’s Compiler, Runtime, test suite, and continuous integration. This will allow the core team and other contributors to quickly add new language and runtime features in the future.

For the next version, we are planning to add language and hot reloading support for data structures, loops, and external C functions. For the full roadmap of Mun, have a look at our Trello board.

This Month in Mun - October 2019

Mon, 28 Oct 2019 00:00:00 GMT

We started October with the launch of our website, Discord 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.

Stability

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 lexing, parsing, type checking, and code generation through the use of the insta crate, integration testing of the compiler and runtime, test coverage metrics, CI 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 calls, boolean operations, and if-then-else statements. With these features in place, we are able to demo Mun’s hot reloading capabilities using fibonacci:

fn fibonacci(n:int):int {
    if n <= 1 {
        n
    } else {
        fibonacci(n-1) + fibonacci(n-2)
    }
}

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.

Embedding

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.

fn equal(a:int, b:int):bool {
    a==b
}

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:

use mun_runtime::{invoke_fn, MunRuntime, RetryResultExt, RuntimeBuilder};
use std::env;

fn main() {
    let lib_dir = env::var("TARGET_LIB_PATH").expect("Expected path to a Mun library.");

    let mut runtime = RuntimeBuilder::new(lib_dir).spawn().unwrap();

    let a: i64 = 52;
    let b: i64 = 764;
    let c: bool = MunRuntime::invoke_fn2(&mut runtime, "equal", a, b).unwrap();
    println!("{} == {}? {}", a, b, c);

    let c: bool = invoke_fn!(runtime, "equal", a, b).wait();
    println!("{} == {}? {}", a, b, c);

    let c: Result<_, _> =
        MunRuntime::invoke_fn2::<i64, i64, bool>(&mut runtime, "equal", 52, 764).retry();

    if c.is_ok() {
        println!("{} == {}? {}", a, b, c.unwrap());
    }
}

#include <iostream>
#include <string>

#include "mun/runtime.h"

int main(int argc, char* argv[]) {
    if (argc < 2) {
        return 1;
    }

    if (auto runtime = mun::make_runtime(argv[1])) {
        int64_t a = 2;
        int64_t b = 3;

        bool result1 = mun::invoke_fn<bool>(*runtime, "equal", a, b).unwrap();
        bool result2 = mun::invoke_fn<bool>(*runtime, "equal", a, b).wait();
        auto result3 = mun::invoke_fn<bool>(*runtime, "equal", a, b).retry();

        std::cout << "Result1: " << std::to_string(result1) << std::endl;
        std::cout << "Result2: " << std::to_string(result2) << std::endl;

        if (result3.is_ok()) {
            std::cout << "Result3: " << std::to_string(result3.unwrap()) << std::endl;
        }
        return 0;
    }

    return 2;
}

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

Going live

Sun, 06 Oct 2019 00:00:00 GMT

After a successful first Mun jam, our ideas had advanced far enough that we felt ready to share our vision for Mun with the world. What started as experimentation with hot reloading in Rust, has culminated in Mun: a programming language empowering creation through iteration.

Why another programming language?

It was never our goal to write a new language. We want to achieve quick developer iteration through natively supported hot reloading for data and functions. As no other language - that we know of - supports this, the easiest way to proof its feasibility is through a novel language. We are happy for existing languages to incorporate our findings in the future, and in that case would consider our goal achieved too.

Digital presence

Over the course of this week we launched several initiatives to inform, interact with, and muster support from the community. Our website - mun-lang.org - serves as a starting point for anyone who is new to Mun. To directly ask questions or provide feedback to the Mun Development Team we launched the Mun Discord server.

Support Us

Mun’s development is being done in our core contributor’s spare time. To further advance the project, we welcome any and all donations on Open Collective. We are proud to be partnering with the Amethyst Foundation as our fiscal sponsor, to ensure that your donations benefit Mun as much as possible.

Mun Jam #1

Sun, 22 Sep 2019 00:00:00 GMT

As we finally found ourselves in the same country, our two-man team decided to get together for a Mun Jam. Our goal? Define an ABI for sharing function and type information between the Mun compiler and runtime, allowing us to integrate both components into a single pipeline. In Mun, a single file or group of files is compiled into - what we call - an assembly that can be hot reloaded at runtime. To guarantee that argument and return types of functions in different assemblies correspond, we need to expose their function and type information. The Application Binary Interface (ABI) that is used to express these so-called symbols adheres to the C ABI, to make it easier to integrate Mun with other programming languages.

#ifndef MUN_ABI_H_
#define MUN_ABI_H_

#include <stdint.h>

typedef struct
{
    uint8_t b[16];
} MunGuid;

typedef struct
{
    MunGuid guid;
    const char *name;
} MunTypeInfo;

typedef enum
{
    MunPrivacyPublic = 0,
    MunPrivacyPrivate = 1
} MunPrivacy;

typedef uint8_t MunPrivacy_t;

typedef struct
{
    const char *name;
    const MunTypeInfo *arg_types;
    const MunTypeInfo *return_type;
    const void *fn_ptr;
    uint16_t num_arg_types;
    MunPrivacy_t privacy;
} MunFunctionInfo;

typedef struct
{
    const MunFunctionInfo *functions;
    uint32_t num_functions;
} MunModuleInfo;

#endif

LLVM vs C ABI

Every assembly contains a get_symbol function that returns symbols for the top-level module as a MunModuleInfo. As the Mun compiler already has a syntax tree of all function signatures and types in the assembly, we can easily generate the required symbols. Or so we thought. When we tested our compiled assembly in the Rust-written runtime, the returned MunModuleInfo contained corrupted data. After a search down the internet rabbit hole, we discovered the cause. Take this function:

MunModuleInfo get_symbols()

Based on our understanding of LLVM, we generated the following IR:

define %struct.MunModuleInfo @get_symbols()

To discover possible discrepencies with C-style IR we ran clang (clang -S -emit-llvm main.c), resulting in this output:

define void @get_symbols(%struct.MunModuleInfo* noalias sret)

It turns out that the sret identifier is the culprit here. sret - which stands for StructReturn - is apparently the way structs larger than the native pointer size should be returned from C-style functions.

Type GUIDs

To communicate and recognize types across compilations, we need to specify a globally unique type identifier - or GUID. The GUID is generated by creating an MD5 hash from the type name and module path. Built-in types are a special case; for those we use the @core module path. E.g. for the float type, we generate an MD5 hash using the "@core::float" string.