←back to thread

43 points frou_dh | 4 comments | | HN request time: 0.934s | source
1. jedisct1 ◴[] No.42481244[source]
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.

replies(1): >>42482106 #
2. sjrd ◴[] No.42482106[source]
(I don't work on Moonbit, but I am a compiler engineer.)

> 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.

replies(2): >>42483491 #>>42491406 #
3. pjmlp ◴[] No.42483491[source]
Early compilers predate C by a decade, and it took another one for using C as intermediate target became common, other than that the rest is alright.
4. bitwalker ◴[] No.42491406[source]
I'll disagree only a tiny bit here: To me (also a compiler engineer), a transpiler is shorthand for source-to-source translation from one language to another at a similar level of abstraction (e.g. Lua to Ruby, Java to C++). The implementation of a transpiler meeting that definition is generally a simpler project than a compiler, by virtue of the fact that you get to offload a lot of things to the compiler of the target language. That doesn't mean they aren't incredibly complex in their own right though - compilers are just enormously complex projects for anything approximating a production-ready toolchain. Anyone using the term as a pejorative should be laughed out of the room.

In any case, I 100% agree that this is obviously a compiler. The fact that the compiler emits WASM as text, i.e. WAT, doesn't mean it is source-to-source translation - the output is still assembly code for the target machine.

And as an aside, does it really emit WAT? or is that just a debugging view of its output? If you can emit WAT, there is zero reason you can't emit WASM too.