from Hacker News

MoonBit compiler is available on GitHub

by frou_dh on 12/18/24, 1:30 PM with 27 comments

  • by ptx on 12/21/24, 3:06 PM

    The license seems a bit iffy. The blog says it's "open source", but the license is a modified version of the SSPL, which is not recognized as an open source license in the customary sense of the term.

    They also don't say explicitly what modifications they made compared to the SSPL. Some diffing shows that the changes consist of:

    1. Search/replace of license and publisher name.

    2. Renumbering sections with 1-based indexing.

    3. Adding the words "commercially or competitively" to section 13 (which is renumbered to 14).

    In the process of doing this, they seem to have accidentally replaced the publisher name with the license name in one place ("any version ever published by the MoonBit Public Source License") and introduced an off-by-one error where section 18 (which used to be 17) refers to sections 15 and 16.

  • by dartos on 12/21/24, 4:10 PM

    A friend of mine worked on https://github.com/libriscv/godot-sandbox

    Which uses libriscv as the sandboxed compute target.

    IIRC They tried for years to get a wasm backend to work and eventually abandoned it citing, among other reasons, something about how it was difficult to wrangle a stack machine with a register machine.

    I don’t really see what benefits wasm runtimes have over something like libriscv which is very fast and maps more closely to hardware.

  • by jedisct1 on 12/21/24, 6:21 PM

    I've used Moonbit a bit, and I find the language confusing.

    It's not really a compiler, but a transpiler to WAT. If I remember correctly, the intent is to support other backends such as Java. It doesn't do any optimization, even trivial things such as shifts by 0 bits don't get optimized away.

    The tool bundles a copy of Wasmtime (a webassembly runtime) to actually run the webassembly code. Moonbit comes with its own set of APIs, not WASI nor Emscripten, so the resulting Webassembly modules require the Moonbit tool to run.

    The tool itself includes everything: documentation generator, the wasmtime interface, a formatter, package manager, benchmarking tool, etc.

    The language already supports complexities like traits, etc. But here's the thing. Moonbit tries to develop tons of things simultaneously, including aggressive marketing, but doesn't seem to do anything well for now.

    The language is weird. It's described as something like Rust, but doesn't borrow much from Rust, except the bad parts (nonextensible build system, constants that can be reassigned, macros instead of comptime, etc). It ressembles Java more, IMHO, with, for example, no unsigned types.

    The problem is that Moonbit doesn't seem to be used except for simple examples and testing the features being implemented. So, its design is not driven by real-world applications. And this is very noticeable.

    I found it very confusing, and prone to foot-shooting. And it doesn't support any WebAssembly specific functions.

    I really want to like Moonbit, but I don't see the value for now. It feels like an old language, not something new. It doesn't bring any new idea. It doesn't feel modern.

    We'll see how the different backends go. Maybe it'll eventually become something like HaXe, but this is going to take a lot of time.

    His author did a terrific work, there are a lot of hours behind that project already. But IMHO, he should focus on making the language modern and nice to use. It's too early to implement all the bells and whistles, and even to advertise it as it is right now.

  • by zoezoezoezoe on 12/18/24, 5:16 PM

    I'm a little confused what this is, look interesting, I like the rust-adjacent language (I mean I dont like that fn main cannot have parenthesis, but other functions must have parenthesis, but pretty interesting), I'm just a little confused as to what makes it different. I see they seem to have their own compiler, so no LLVM overhead, but also no LLVM legacy, and they seem to be targeting small WASM compiles, is that just it? I'm just a little confused on what makes it special, I think it's stack based, there doesnt seem to be a concept of pointers as far as I can see in the documentation, it looks cool, but what makes it different?
  • by jacobp100 on 12/21/24, 1:58 PM

    A bit of background on this project: it was started by the guy leading BuckleScript (now ReScript), the OCaml to JS compiler.
  • by trollbridge on 12/21/24, 2:46 PM

    I noticed they chose the SSPL licence. I'm working on a similar sort of project and am evaluating AGPL3 vs SSPL. (If my project is successful, it has a high risk of cloud providers both large and small co-opting it, and I'd like to proactively head that off.)
  • by childintime on 12/21/24, 2:51 PM

  • by egonschiele on 12/21/24, 3:53 PM

    Not to be confused with Moonscript, which is a cool language that compiles to Lua: https://moonscript.org
  • by tinco on 12/21/24, 1:36 PM

    This looks like a fun language. I don't like the idea of wasm, but I do like the idea of moving away from JavaScript at some point. With big software like Figma using wasm to get proper performance in the browser the benefits of such a language are obvious in my opinion.

    Wasm is a move back to the flash days, though most developers nowadays probably weren't there to know why that sucked. Even 15 years later there still isn't a decent replacement for its main use case, it got sacrificed for the cause of the free and open web. Maybe the market for it disappeared with a certain early web culture. Most flash iconic content was probably created with pirated copies of Flash anyway.

    Since I'm in the old person yells at cloud rant mood, I'll just continue on and rant at OSI as well. This project is yet another example of a project that would have been and should have been proper approved open source if OSI had not failed to get with the times and protect the open source community against the large cloud providers, the very same cloud providers that are their largest sponsors and donors.