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.
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.
from the readme
https://github.com/moonbitlang/minimoonbit-public
So, maybe not the official compiler but something else is already using it?
You can also email licensing@fsf.org with your use case and I am sure they will be able to help.
The HN devs omitting a dupe checker just has to be an explicit choice at this point
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.
> It's not really a compiler, but a transpiler to WAT.
That's still a compiler. What do you think many languages' early compilers were doing when they compiled to C source code? Heck, what do you think early C compilers were doing when they were compiling to .s files, before feeding them into assemblers?
These are all the same technology. We write compilers, with all the same skills, methodologies, practices. It doesn't matter the format that we output.
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.
It's just that supplying binaries to the web is less open than supplying html and js. It's not an especially strong argument, less so given how minified and uglified JS is nowadays, but that's what it is.