Why we rewrote Lua in JS (2017)
hackernoon.com
hackernoon.com
> 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.
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.
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:
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
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.
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*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.
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.
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
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.
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.
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
"The Free Software Foundation does not claim copyright for this joke."
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.
Also if you have ever dealt with any babel/webpack craziness recently you know what I’m referring to :)
The author has moved onto working on titan: https://github.com/titan-lang/