In all honesty, what's the point of this? I understand the point of compiling to JavaScript simply because that's the only language that runs on the most ubiquitous platform in the world. Why compile to any other high-level language?
Are there so many similar places where users are forced to use Lua, to warrant an extra layer? (with all the complexities such as debugging, a compile step, tracing errors back to MoonScript code, etc)
Note, I'm not commenting about the language's choices. Maybe coding in MoonScript rocks big time. I just don't get why it compiles to Lua.
I can understand your doubt. After writing a decent amount of Lua I really started to notice it lacking succinct ways to express things that I've become used to in other languages.
So I wrote the language for myself to use, but I've opened it up for other people because I think there is some potential for it. The use case for MoonScript is the same as the use case for Lua.
Also I have done a lot of mitigate the pains of compiling and debugging. It's actually pretty seamless, I've done stuff like automatic code compilation on require, and error line number rewriting. I urge you to check out the documentation: <http://moonscript.org/reference/#moonscript_api>;
Lua wins for in-game scripting and embedded devices. In these places, it's Lua, or hacking onto the C/C++ engine/framework code. Or, now, MoonScript with some extra fuss. Mind, Lua isn't terrible, so I think I'd stick to Lua and avoid the fuss. But others will disagree.
It'd make more sense to me if it were compiling a very different kind of language, such as a Constraint/Logic programming language. I really like Lua for scripting, as-is.
Lua's portability & smooth C integration make it an interesting code generation target (not to mention LuaJIT's performance). And however you feel about working in Lua, its code is straightforward to generate - the syntax is refreshingly free of odd corner cases.
It is odd the designer decided to compile to lua. It's probably because it's easier to knock out the language fast that way. Although usually when someone wants to do this they compile to C and use gcc from there (this is what go did in the beginning), but they also usually admit this is a hack, not a feature and that they will later compile directly to assembly.
Lua is significantly faster than most dynamic languages (LuaJIT is faster than most static languages as well), and the Lua runtime is small, portable, flexible and easily embeddable. Creating a runtime from scratch with these properties would be difficult, while targeting Lua makes it nearly free.
Many languages compile to an intermediate format of some kind. The complexities you cite are easily be hidden. MoonScript already makes compiling and error traceback invisible, and I expect direct debugging of MoonScript files will be doable at some point as well.
This is the first I've heard of MoonScript, but I've long wondered why more languages don't use Lua as a target.
I think it being difficult to read is entirely subjective. I don't know Haskell, and if I were to look at the code for a Haskell project I wouldn't understand it, but that doesn't mean that those who use it find it difficult to read.
After writing the majority of the compiler in MoonScript itself, and some other scripts, I've actually grown to like it and I find it perfectly readable. More readable than Lua in fact, because half of the text on my screen isn't the keyword `local` :). Try it out, if you code Lua then I think you might like it.
Are there so many similar places where users are forced to use Lua, to warrant an extra layer? (with all the complexities such as debugging, a compile step, tracing errors back to MoonScript code, etc)
Note, I'm not commenting about the language's choices. Maybe coding in MoonScript rocks big time. I just don't get why it compiles to Lua.