
Why we rewrote Lua in JS (2017) - polm23
https://hackernoon.com/why-we-rewrote-lua-in-js-a66529a8278d
======
yiransheng
The list of niceties of lua from the article:

> First class functions and closures

> A versatile data structure: the table

> Vararg expressions

> Lexical scoping

> Iterators

> Coroutines (see below)

Well, looking at modern day js:

* First class functions and closures, check

* the table: a combination of `Array`, `Map` and `Map<Number, T>` can prettify much cover typical usecases of lua tables, so js is close in this regard

* Vararg expressions, check

* Lexical scoping, check

* Iterators, check

* Coroutines, with libraries and abstractions on top of generator functions

In addition, in js land, other paradigms of concurrency exists, such as CSP
(goroutines), FRP (Rxjs and co). Of course, these can be implemented in Lua as
well, but the libraries may not quite as battle-tested.

The author also mentions a sane coercion system; this still true, but ever
since "use strict", unexpected coercions can mostly be avoided in js.

On the other hand, js has:

1\. Typescript and static typing (a bit unfair to consider this js, but ts
gets access to a large portion of high quality npm packages), flow is also
great

2\. Multiple mature echosystems of UI frameworks (React) - for instance if you
need a date picker or an autocompleter, it's just `yarn add` away; I doubt
enough such libraries exist for browser side lua yet

3\. Tooling support - webpack, prettier, postcss and so on

I like lua, but I feel it does not offer much in addition to what modern js
already provides. Of course bring more languages to the browser is always a
good thing, on the other hand I do feel this is a tough sell to the larger
community.

~~~
Dylan16807
Javascript generators make for painful coroutines, because a function called
by the generator can't yield all the way out.

~~~
yuchi
Yield * fn()?

~~~
Dylan16807
You can use that sometimes, but it really complicates return values in a way
Lua just doesn't have to deal with.

------
Shank
Initiatives like this make me really excited, but the biggest problem is
always long term maintainability and interoperability with the rest of the
browser ecosystem. Without a huge company backing the effort, it becomes
really risky to use this long term because development could drop off or never
gain traction.

If you don't have a huge open source community, you need one to push the ball
forward and keep things going. That's really hard to get without users, which
is a great catch 22. I'd almost suggest building a "killer web app" on Fengari
just to demonstrate it, or at least to indicate that its development effort
won't go the way of Moonshine.

I love Lua, and I would love to use this. The risk, however, is pretty high in
anything but an experimental context -- at least for me.

~~~
giancarlostoro
Sounds like you're yearning for WebAssembly. With WebAssembly you can write
your solution in any language it just needs to be compiled to WebAssembly.
Every major browser is backing WebAssembly.

As a result (and for example) Microsoft is making it possible to write front-
end code in C# which is compiled with a small .NET runtime into the browser
with WebAssembly. In theory efforts could be (and likely have been) made to
compile Lua to WebAssembly.

Quick search reveals at least two results:

[https://scriptinghelpers.org/lua](https://scriptinghelpers.org/lua)

[https://github.com/vvanders/wasm_lua](https://github.com/vvanders/wasm_lua)

~~~
nevir
WebAssembly is not a silver bullet, and is intended for lower level code than
I think you expect.

There's little to no interop with the front-end world as we know it (aka the
DOM), and any briding to it is still quite expensive. You'd have to re-
implement lua's garbage collector in wasm, etc.

wasm is great for high performance data crunching—aka why it's so attractive
for 3d engines, games, and the like.

It's less great for developing front end apps; unless you feel like building
much of a browser within it.

\---

It _will_ get to that point, but we've got a while before interop is a
realistic thing

~~~
giancarlostoro
I know currently it's nowhere near a silver bullet. As for not being able to
use it now I would say Microsoft has to disagree:

[https://github.com/aspnet/blazor](https://github.com/aspnet/blazor)

There's plenty of things to work on to get WebAssembly to the state where it
could be used as a JavaScript replacement, but none of it impossible. Blazor
shows you can build WebAssembly based web front-end applications today. It
definitely takes some resources but I'm glad Microsoft is there to work on it
to once again leave an example for the rest of the developers who may want to
follow a similar pattern for new language implementations.

To be fair, I'm not sure how much overhead their approach may have pertaining
to the DOM with the way they're handling things.

------
daurnimator
Fengari author here, we made our first release yesterday. See
[https://daurnimator.com/post/172451162334/fengari-v010-relea...](https://daurnimator.com/post/172451162334/fengari-v010-released)

------
Pfhreak
Summary: we like it better than JS.

------
nikki93
`React.createElement(...)` is p. nice with a table-y DSL:
[https://github.com/nikki93/fengari-react-
test/blob/9735deb78...](https://github.com/nikki93/fengari-react-
test/blob/9735deb78388bcd5dce281b236c3f55335ed344c/src/app.lua#L23-L49)

------
kilon
Earth’s Moon in Greek is actually “Feggari”, from the verb “feggo” which means
to radiate light. Moon in general in Greek is “Selini”, a natural satellite
orbiting a planet.

~~~
giann
Yes it’s feggari but I think that with two gammas, it’s pronounced fengari.
Could be wrong I’m not greek. But it’s too late to change :)

~~~
kilon
I am Greek and no it’s not , gg , is pronounce as g in gamma, and one g is
pronounced as y in yellow

~~~
giann
Reading the sources I used to search for the correct term, I think I may have
been fooled by ancient greek allophones. Ex. : ὁ ἄγγελος /ho áŋgelos/ Anyway
like I said, too late to change now!

~~~
daurnimator
IRC logs from last time it was discussed:

    
    
        2018-03-05 23:47:38     assos   in greek it pronounced fegari instead of fengari
        2018-03-06 00:12:41     RhodiumToad     assos: several modern greek dictionaries I checked give the "fengari" prononciation either alone or alongside "fegari" - are they wrong?
        2018-03-06 00:31:44     assos   RhodiumToad: after I checked you are right, the pronunciation depends based on the location in greek, the correct one is fengari. Btw, the word is a derivation of φεγγος which translates to light/brightness.
        2018-03-06 00:31:53     assos   in greece*

------
erikpukinskis
It’s interesting to me that people are pumped about async/await.

If we time travel back to when Node caqme out, the single most common reason I
saw cited for its success was something like: “JavaScript’s simple event-based
programming model is a natural fit for a server coordinating I/O from
different places”.

Back then we had callbacks and closures and it was just powerful enough you
could do almost anything, but simple enough that you were never truly lost.

Now I see developers pumped about a world where callbacks, promises, and
async/await are all mixed together in an NPM soup.

I wonder if that mixture might be the thing that finally pushes JavaScript out
of reach for beginners (if it’s not there already).

And maybe that opens a door for something like Lua, if it really can embrace
async functions without the baggage of Promises and callbacks spread
throughout public repos.

Even if that works out though, I do wonder about that original reaction to
Node. Maybe Ryan Dahl really hit on a good control flow model that the JS
community then threw away. I do think that platform devs sometimes try too
hard to make async “disappear” instead of trying to make it inspectable.

~~~
namelost
Anybody who has used node.js for more than 10 minutes knows that the callback
style makes code completely unreadable. Unreadable code is a breeding ground
for bugs.

Back in 2009, that was an acceptable trade-off, because there were advantages
to JavaScript, such as sharing code between client and server.

Now we have promises and we don't have to put up with callbacks anymore
(eventually!). FWIW async/await is the syntax, and promises are the runtime,
they are not competing features.

~~~
erikpukinskis
That’s a really insulting way to argue your point. I’ve been writing
JavaScript for 15 years. Full time for probably six years, when I dropped
Rails for Node and Ember.

Right now I am programming full time in a promise shop for work, so I am very
familiar with that. At home I write 100% callback style and find it superior.

The worst is when you have to mix the two, which is why NPM is such a shit
show, and why I think async/await will only make things worse.

If you’re willing to spend a few minutes considering an alternative
perspective to your own, you might read this:
[http://callbackhell.com](http://callbackhell.com)

You say promises are more readable. I do agree promises make it easier to read
and write awful code with gnarled architectures. Callbacks force you to name
things and separate concerns, which is helpful if your goal is to write good
code. If you just want to hack layer upon layer of garbage into the system, as
most employers would prefer you do, then promises will help you hold on for
that ride longer. Callbacks will break down faster.

I think that’s a feature, as it alerts me to architecture problems sooner. But
you may prefer less refactoring and a more additive-only programming model, in
which case promises will be a useful tool for you.

~~~
namelost
If your coworkers are so bad, wouldn't you rather get a nice message in your
console when they forget to handle an error? With callbacks, error handling is
entirely on the honor system.

There may well be some situations where callbacks are tolerable, but any time
you have to converse with an external synchronous resource like a filesystem,
database or REST API, it's just painful. Making a new function (named or
otherwise) for each line of code is not good style, in any language.

------
willvarfar
I really had to double-check the date to see that it wasn't an April Fools
joke :)

Historically, programming languages claiming rewrites in some other
'competing' language have been April Fools fodder e.g. Emacs in Perl
[https://www.gnu.org/fun/jokes/gnuemacs.en.html](https://www.gnu.org/fun/jokes/gnuemacs.en.html)

~~~
labster
Perl 6 on Javascript is real, though. Rakudo.js has come a long way, but it's
not passing all of the tests yet. It's a quite a bit bigger task to convert a
kitchen sink language than a smaller language like Lua.

[http://blogs.perl.org/users/pawel_murias/](http://blogs.perl.org/users/pawel_murias/)

------
giancarlostoro
I really hope they eventually push their efforts towards making Fengari a Lua
-> WebAssembly runtime. Every modern major web browser has WebAssembly
support, it might still be young in development, but it's a start.

~~~
daurnimator
WebAssembly still doesn't allow gc cooperation. It's still a long way away

------
matzy
I remember seeing the talk on this at Lua Workshop 2017. daurnimator gave a
great demo. Glad to see it get more publicity and an actual release - looks
really promising

------
kzrdude
Is Lua 5.x stable and reliable? Maybe it is, or promises to be now?

On the whole, Lua seems prone to redesign itself and make relatively big
changes, like the env changes from Lua 5.1 to 5.2.

I think that works well, since Lua is often embedded and version locked by the
application that uses it, but it is the opposite of a cautious and stable
evolution of the language.

~~~
giann
It’s stable relative to JS which is a nightmare in this regard.

~~~
allover
How so? JS is backwards compatible in the extreme, because browsers. New
features does not equal unstable.

~~~
giann
I’m talking about the cognitive load of the language. Learning JS is a real
complex task whereas learning Lua is not. Learning JS as is is hard since its
moving so fast. I think nobody can deny the confusion surrounding the
language. Lua is stable is the sense that 5 years from now you will still know
how to use it even if you don’t keep up with the latest updates.

Also if you have ever dealt with any babel/webpack craziness recently you know
what I’m referring to :)

~~~
Can_Not
So JavaScript _the language_ is "unstable" because you (for no discernable
reason) switch to every bleeding edge JS framework that gets posted to HN?

~~~
giann
I’m not talking about frameworks. I’m talking about ES5/6/2016/2017/7/8 ...
which all add new concepts and complexity.

~~~
Can_Not
You know those new concepts and complexities are optional? And backwards
compatible? None of my jQueries broke when generators came out. And that's not
even very fast at all. And people have been complaining for the longest time
that JS didn't have those features.

~~~
giann
This really is not a good argument. You can still write php like in 98, that
doesn’t mean you shouldn’t learn modern php if you want to work ever.

~~~
Can_Not
But isn't modern PHP moving too fast though? They also break BC with a proper
deprecation process. I don't know what you mean it's not a good argument, I've
just been casually pointing out that your points are completely invalid.
There's actually pretty good reasons to use lua over JS, you don't have to
make up reasons.

~~~
giann
I think I list a good amount of reasons to use Lua. The focus of the article
is far from being fixated on JS being bad.

------
skybrian
I wonder how Fengari does on code size and performance? I don't see any
benchmarks offhand.

------
pudebe
I am missing something ripe like typescript for lua.

~~~
daurnimator
typedlua was like typescript for lua:
[https://github.com/andremm/typedlua](https://github.com/andremm/typedlua)

The author has moved onto working on titan: [https://github.com/titan-
lang/](https://github.com/titan-lang/)

