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