Fengari – Lua for the Browser • Hacker News Board

Re: Fengari – Lua for the Browser

#141

Post by aa-jv » Mon, Feb 21, 2022, 1:29 PM UTC

friedturkey wrote: post #26

Lua is the only language I can truly say I love. If more people used it (and used it responsibly, not letting it become a mess of odd libraries), the world would be a better place.

Cannot agree with you more. It is just so elegant and powerful, and yet simple.

Easily one of the most productive tools in my suite, and I made a lot of money as a Lua developer last year, using Lua in a realtime analysis application.

Would love to see a Lua-only browser arise from these efforts. Its just such a delightful language to code in ..

Re: Fengari – Lua for the Browser

#142

Post by aa-jv » Mon, Feb 21, 2022, 1:34 PM UTC

scruple wrote: post #82

harpiaharpyja wrote: post #57

Earlier quoted context omitted.

The Lua interpreter is really lightweight, and for decades has been the go to choice for when you need dynamic code and speed (for example, it's been popular in the games industry for this reason). Probably someone else can shed light on exact numbers, but Lua is faster than Python.

It's also very small. We used it extensively on embedded Linux devices in the 2000s for these reasons as well as easy interop with C/C++.

I'm still using Lua on embedded Linux devices, and in fact completed a project last year that was deemed impossible by the Java devs, but easily within our memory/time budget as a Lua group. The success of that embedded Lua project converted a large number of Java diehards into Lua accolytes...

Folks who sniff at putting a scripted/interpreted language into an embedded environment really need to think twice with Lua. It is fast, tight and highly performant - and if you bundle it along with LuaJIT and Turbo.lua, it'll give you the best of all worlds - aynsc i/o, coroutines, very, very fast performance and a great execution environment upon which to build truly useful apps.

Re: Fengari – Lua for the Browser

#143

Post by [deleted] » Mon, Feb 21, 2022, 3:07 PM UTC

BiteCode_dev wrote: post #68

I was pleasantly surprised it loaded so fast. So I wanted to check the size of it. I opened the firefox debugger, and it went blank O_o Chrome was ok with it: it's about 220kb, which is not bad at all for a whole runtime + stdlib. Python pyiodide ( https://pyodide.org/en/stable/ ) is several Mb. 220kb is still too much to pay upfront, since I usually want my webpages to be under 1Mb, and I can't justify burning 1/4 o…

[deleted]

Re: Fengari – Lua for the Browser

#144

Post by otikik » Mon, Feb 21, 2022, 9:56 PM UTC

upofadown wrote: post #35

Lua did a language fork at version 5.3. I think this supports the 5.3 fork but it would be good to make this explicit.

That is much less important than you might think.

Lua is not a general-purpose language. Its main usage is embedded inside a bigger "host" app, usually in C, for which it provides a higher level language. But the features available are completely defined and dependant on the host app. On top of that, Lua (or at least, its vanilla implementation) is very easy to tweak and understand.

As a result, you can find Lua inside a car, a videogame or a web server ... and each incarnation of the language is incompatible with other versions of the language out there. Instead of a big continental platform, Lua is a fragmented archipelago of islands. You can still swim from one to the other, but you have to get wet.

Re: Fengari – Lua for the Browser

#145

Post by oscargrouch » Mon, Feb 21, 2022, 10:26 PM UTC

dannyobrien wrote: post #124

oscargrouch wrote: post #118

Earlier quoted context omitted.

Foe anyone interested, there was a port of Webkit/Blink where the web objects retained by javascript are garbage collected outside of V8, using blink GC to destroy those objects. The way it works its through smart pointers, where for instance you say how the reference to that object is retained according to the object that it references. The good side of this is that other programming languages besides Javascript can…

Is this still possible in Blink? Or was this feature abandoned?

It's there. For instance if you want to retain a reference to a 'WebFrame' for instance, you can create a wrapper object which is the one you directly control the lifetime and have a 'Persistent' as a property of your wrapper to hold the blink reference.

As long the smart pointer is not destroyed (with the destruction of your wrapper or holder) the web frame object is guaranteed to retain a reference, making the object alive.

Otherwise you can retain Weak and Member smart pointers for things that your object dont own, and of course, in the case of Weak you can expect it to be collected in the next scheduled GC job (or anytime). And in the case of Member is not a strong reference to the object as in Persistent so you dont own the object's lifetime, but you retain a reference so the object should not go away while you hold it.

To see how serious is the commitment to this scheme, you can just explore the Blink codebase to see that this scheme is actually used internally as a way to control lifetime between objects, and not just as a API thing to be used from consumer projects (unlike V8 which vends a different API for consumers of the VM from the one it uses internally).