How does MoonScript compare to Wren? https://github.com/munificent/wren
MoonScript, a programmer friendly language that compiles to Lua
71–80 of 171 posts
Re: MoonScript, a programmer friendly language that compiles to Lua
#72Hey all, I made MoonScript about 6 years ago. I used it to build a ton of opensource stuff in addition to the company I founded. I use it every day and I'm very happy with how it's turned out. I regret not updating the language more frequently, but I've been busy building a bunch of stuff in it. The biggest open source project is a web framework for Open Resty: https://github.com/leafo/lapis It's used for the followi…
Are you aware that TIC-80 supports moonscript? It's one of the better PICO-8 "clones" out there. https://nesbox.itch.io/tic https://github.com/nesbox/tic.computer/wiki#cartridge-metada...
I am, and I'm pretty exited about it. I haven't had a chance to work with it yet but I might mess around with it next ludum dare.
Re: MoonScript, a programmer friendly language that compiles to Lua
#73I was on a team that used Lua in production on tens of thousands of machines running 24/7. The Lua interpreter was the weak link in the system, requiring at least daily restarts. Squashed so many bugs over the years, and still found more and more all the time. What I'm saying is, the Lua interpreter itself is flawed and I can't imagine using it as a runtime if I had the chance to avoid it. That said, the language was…
This page lists every known bug in the Lua interpreter for the last 14 years, along with its fix: https://www.lua.org/bugs.html
The average is 8 bugs per year, most fairly obscure. Every Lua release fixes all known bugs.
Roberto, the chief architect, is kind of fanatical about quality: https://www.youtube.com/watch?v=yU5QNKpATxk
I do not believe the interpreter is as flawed as you claim.
Re: MoonScript, a programmer friendly language that compiles to Lua
#74Earlier quoted context omitted.
This is basically Lua, excluding type annotations. Lua's form of OOP is very strange in that methods aren't bound to a parent context, but instead take the object as a value. For example, `object:method()` is the same as `object.method(object)`, and `function object:method()` is the same as `function object.method(self)` - the only difference being calling the function via `object:method()` is a bit more optimized. T…
And the size of the Lua runtime is nothing short of beautiful. I have yet to find a use for Lua though, so I'm still waiting for an opportunity to work on something with it.
I'm using it at work to parse SIP messages (with LPeg) for one of our customers (one of the cellphone carriers). Between LPeg for parsing, and coroutines in Lua, the code is pretty easy to read and follow.
Re: MoonScript, a programmer friendly language that compiles to Lua
#75Lapis + MoonScript + OpenResty looks like a lot of fun, so I was just starting to get a local environment running for it and immediately ran into the Lua 5.1 and 5.2+ divergence. For someone who has just been a casual observer of the Lua ecosystem over the years, can someone talk about the community's feelings towards that divergence? The OpenResty docs basically state it's not worth the effort to support anything bu…
This is my problem as well. I just installed 5.3 on my system but it looks like nobody really supports 5.3. There really is no clear guidance on what to do - do I just not use the latest version of the language?
If you really need to use LuaJIT, then you best stick with Lua 5.1. Otherwise, use Lua 5.3---it supports 64-bit integers (unlike Lua 5.1/5.2, which only use floating point) and if you are doing any parsing of binary data, string.pack() and string.unpack() are worth using (Lua 5.3).
Yes, there are issues with some Lua modules not supporting Lua 5.3, but the major modules support it, and LuaRocks makes installing modules rather easy.
Re: MoonScript, a programmer friendly language that compiles to Lua
#76Earlier quoted context omitted.
This is my problem as well. I just installed 5.3 on my system but it looks like nobody really supports 5.3. There really is no clear guidance on what to do - do I just not use the latest version of the language?
If you really need to use LuaJIT, then you best stick with Lua 5.1. Otherwise, use Lua 5.3---it supports 64-bit integers (unlike Lua 5.1/5.2, which only use floating point) and if you are doing any parsing of binary data, string.pack() and string.unpack() are worth using (Lua 5.3). Yes, there are issues with some Lua modules not supporting Lua 5.3, but the major modules support it, and LuaRocks makes installing modul…
Well, in the context of this thread, MoonScript, Lapis, and OpenResty don't support 5.3.
Re: MoonScript, a programmer friendly language that compiles to Lua
#77Earlier quoted context omitted.
I see it as a toy language. The only person I think would find it useful is leafo himself since he can edit it however he wants. But everyone else should stay away from it. Plain Lua is so much better.
Can't agree with that. Having used both Lua and Moonscript quite a bit I think Moonscript is what most dynamic scripting languages should be. Simple, succinct and does what you need for a scripting language. I really enjoy using it.
Care to give an example?
Re: MoonScript, a programmer friendly language that compiles to Lua
#78How does MoonScript compare to Wren? https://github.com/munificent/wren
System.print("Hello world")
It kind a looks like someone wanted to make actual Java-script. To me these are way too different to even compare, unless you are talking about performance, but then you are just comparing Lua with wren and there seems to already be some benchmarking of these on wren.io
Re: MoonScript, a programmer friendly language that compiles to Lua
#79Lapis + MoonScript + OpenResty looks like a lot of fun, so I was just starting to get a local environment running for it and immediately ran into the Lua 5.1 and 5.2+ divergence. For someone who has just been a casual observer of the Lua ecosystem over the years, can someone talk about the community's feelings towards that divergence? The OpenResty docs basically state it's not worth the effort to support anything bu…
The reason is that the _ENV feature added in 5.2 would significantly slow down LuaJIT if it were supported. It's possible that Luac and LuaJIT will re-converge when Lua 6.0 is released, but arguments about this between Mike Pall amd Roberto Ierusalimschy have been unproductive so far. Until then, LuaJIT compiles Lua 5.1 with support for a few 5.2 and 5.3 features, particularly goto.
You have any references to these arguments between the two gods?
Re: MoonScript, a programmer friendly language that compiles to Lua
#80Earlier quoted context omitted.
Except that arrays start on 1, right?
Exactly. It's more intuitive and you have less `x-1`'s in your code.
Arrays starting at 1 and being closed intervals is mostly just worse than starting at 0 and being half-open intervals.
Here's an expression to take an integer b and "mod it" into an interval from a to c, given the normal convention from C++ or Python or whatever where intervals are [a, c):
(b-a)%(c-a)+a
(b-a)%(c-a+1)+a
n % array.length
(n % #array) + 1