From: Hans Hagen via ntg-context <ntg-context@ntg.nl>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>
Cc: Hans Hagen <j.hagen@xs4all.nl>
Subject: Re: Any initial thoughts on luau?
Date: Fri, 5 Nov 2021 21:14:52 +0100 [thread overview]
Message-ID: <92df8ab4-2999-83ce-8dda-7049f45e7e24@xs4all.nl> (raw)
In-Reply-To: <CAMD5SRNcGmSHabQqFrDmLx127mbZ5RttLb-05VK_KVdGEubXiQ@mail.gmail.com>
On 11/5/2021 6:23 PM, Ramkumar KB via ntg-context wrote:
> Hello,
>
> Yesterday, Roblox announced - Luau - https://luau-lang.org/why
> <https://luau-lang.org/why> - mainly adding linting and type-checking
> features.
>
> Being compatible with Lua 5.1 is probably a bummer but nonetheless would
> be interesting to hear about this from this community.
for sure i need more than an email to give a real answer (and some can
be read between the lines of the history documents / articles that we
ship); that said:
the main reasons for choosing lua for luatex has been that it is
relatively small, has no dependencies, doesn't need tons of libraries to
make it useful, is made for embeded usage, evolves in a proper academic
setting, has long-term dedicated (nice) developers, is not part of some
religious programming language war/competition, reminds me (in a
positive way of pascal and modula), is pretty fast, ... so, no regrest
and no need for something else
now, the link you point at mentions 'typing', 'multipass bytecode
generation', 'possible jit'
to start with typing: i suppose that a more explicit integer / float
separation can give better performance, although on modern cpu's one can
wonder (personally i don't see the current mix of integer / float as a
benefit over all numbers being floats - which had some charm due to the
consistency - but who an i to complain; at least we now have bitwise
operators (for a specific application like roblox it makes sense but
using a dedicated / patched / extended lua machinery in luatex doesn't);
there are articles by the lua authors about typing but these are behind
publisher firewalls
multipass compiling costs time and would actually not be that
benificial: in luatex we rely a lot on instant and frequent compilation
(\directlua, \latelua) which is real fast; i bet that there are some
optimizations possible in the vm but at the cost of more granularity and
therefore it could bring limitations too (unless one goes wider memory
wise) .. i think many lua applications actually assume fast realtime
compilation; we simply don't stay long enough in a run to have an
advantage (apart maybe from embedded bytecode for which an optional
bytecode optimizer could make sense and i actually have been thinking
about that)
jitting also costs time and for a single pass process like tex there is
no gain (we established that long ago alreadY); the only reason why
luajittex is faster than luatex for a tex run is that the vm is faster
due to some limitations (that one can actually hit but in context we got
around it) ... jitting also is cpu dependent and therefore more fragile
futurw wise (more and more complex code too)
i'd read about the roblox vm project some time ago and was curious how
it would work with the latest lua but then, but for good reason they
stick to 5.1; if you look at the lua vm code i guess that some gain can
come from less type-checking (maybe the <const> prefix in 5.4 is some
indication that there are thoughts about this but currently that has no
significant gain)
if better performance is an objective: there are probably spots in the
current code that are candidates and one can see from updates that
occasionally optimizations happen (keep in mind that lua has to run on a
wide range of hardware: small embedded to fast single core)
so, I'm pretty okay with lua as it is now (but any influx from spin off
languages / engines can be interesting, but i think the authors are
aware of all that) ... and ... who knows what (side effects) pallene
will bring
(also about performance: i know pretty well how to write fast lua code
but no one ever comes around asking so that means everyone is satisfied)
Hans
-----------------------------------------------------------------
Hans Hagen | PRAGMA ADE
Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___________________________________________________________________________________
next prev parent reply other threads:[~2021-11-05 20:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-05 17:23 Ramkumar KB via ntg-context
2021-11-05 20:14 ` Hans Hagen via ntg-context [this message]
2021-11-06 16:19 ` Michal Vlasák via ntg-context
2021-11-06 18:38 ` Hans Hagen via ntg-context
2021-11-09 1:35 ` Ramkumar KB via ntg-context
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=92df8ab4-2999-83ce-8dda-7049f45e7e24@xs4all.nl \
--to=ntg-context@ntg.nl \
--cc=j.hagen@xs4all.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).