Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fengari – Lua for the Browser

fengari.io

Post reply on HN
Print view View original

91–100 of 145 posts

Re: Fengari – Lua for the Browser

#91

Post by [deleted] »

DonHopkins wrote: post #62
webmobdev wrote: post #53

Earlier quoted context omitted.

Isn't it LuaJIT that's really fast? Last I remember reading about it, there was some version fragmentation going on with Lua advancing and LuaJIT stuck on an older version? (That was a long time ago, and I don't know what been happening since.)

And LuaJIT has historically been extremely fast (initially much faster than JavaScript's early JITs) because it didn't have nearly as many optimizer-busting design flaws to work around as JavaScript JITs did, because Lua's language design is so much simpler and cleaner than JavaScript's, which wasn't originally designed to be compiled ( cough cough "with" cough "this"). But because JavaScript was the "Chosen Language…

[deleted]

Re: Fengari – Lua for the Browser

#93

Post by scgtrp »

naasking wrote: post #90
_huayra_ wrote: post #73

Earlier quoted context omitted.

iirc, one other confusing element is that tables (hash tables? I don't remember what they're called) return null when a lookup is done for a nonexistent key. This is not necessarily a bad choice. Exceptions and such can be a real pain. However, accidentally getting a null value because you didn't check and then have it propagate much further in your program is extremely difficult to debug. Instead of blowing up at th…

Storing a null value is a legitimate operation. How do you distinguish "never stored a value under key K", and "stored null under key K"?

I'm pretty sure you're agreeing with them. Current Lua does this, which is wonky:

    > t = {}
    > t['a'] = nil
    > t['a']
    nil
    > t['b']
    nil

Re: Fengari – Lua for the Browser

#95

Post by zamadatix »

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…

57k post Brotli. Measuring the decompressed size of your page's static text content is like measuring your static image content by the size of the decompressed bitmap the browser generates instead of the size of the PNG (or whatever format). Server side both examples should be precompressed as they are static assets.

Re: Fengari – Lua for the Browser

#96

Post by upofadown »

shakna wrote: post #49
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.

I'm not entirely sure what you mean by "language fork", but all versions of Lua have incompatibilities. 5.1, 5.2, 5.3, and 5.4 are all major versions, with features that aren't completely compatible with any of the others. For example, 5.2 brought in major changes for how environments were handled, and 5.3 brought in integers, and 5.4 brought in changes to how number overflow is handled.

At 5.3 the behaviour of the basic arithmetic operations were changed in a fundamental and non-backwards compatible way to bring in those integers. That certainly counts as a language fork, as opposed to the other two examples.

Re: Fengari – Lua for the Browser

#98

Post by throwawayboise »

CollinEMac wrote: post #71
chii wrote: post #37

Earlier quoted context omitted.

> basically no confusing elements. the one confusing element - one-based indexing of arrays! that is something i found hard to adjust, as it makes off-by-one errors more prominent... but otherwise it's a nice language.

Same here. It's not a big deal once you get used to it but after years of always having indexes start at 0 it just seems... off.

If you learned arrays in C where indexing is the same as pointer arithemetic then zero-based arrays seem natural. If you are coming from the real-world concept of "a list of things" then the "zero-th item" in the list seems odd; one-based indexing feels natural.
Post reply on HN