luajit VS joystick

> No offence, but have you written any compilers or interpreters?

I have, but nothing sophisticated.

> The points that you discuss [...] may be performance concerns for application developers [...] but they have very little to do with the optimisations you can make as a compiler/interpreter writer. [...] The only one that's somewhat relevant is 'global scope by default'

I didn't mean to imply that these where the three common traits that make both Javascript and Lua particularly hard to optimize, I just picked them as examples for how Javascript and Lua are closer to each other than most other dynamic languages.

But let's dig in a bit on your claim that things like all numbers being doubles or having a array cum map cum record type has very little to do with the optimizations you can make as a compiler/interpreter writer, because it sure seems to me that LuaJIT and V8 do a bunch of optimizations around these things. Both have dual number representations under the hood and will try to avoid representing numbers that remain in the domain of 32 bit integers as double values internally when that gives performance gains. The logic for figuring out if that's the case doesn't seem to be super-straightforward or target architecture independent from looking at the comments in <https://github.com/LuaDist/luajit/blob/master/src/lj_opt_nar...>.

LuaJIT furthermore uses NaN tagging (as do some JS engines, although not V8), which looks less attractive to me as a representation strategy if your numbers are not all/mostly notional doubles (as is indeed the case in newer version of Lua where 64bit integers are the dominant number type)

Also, as far as the super-flexible lua tables are concerned, I'm pretty sure LuaJIT goes through some amount of trouble to specialize various common use cases of tables, e.g. as arrays without holes, and surprise, so does V8 (https://v8.dev/blog/fast-properties#elements-or-array-indexe...). I don't think you'd find something equivalent in a high performance scheme implementation.

> but this doesn't touch the surface of the issues that make JS hard to optimise, such as the fact that your, say, memoisation of an object property or method may be broken by an `eval` call of an arbitrary runtime value somewhere else in the code (which, due to asynchronicity, could take place at more or less any time from the point of view of your given 'peephole').

Eval belongs to a core set of features that basically all popular dynamic languages share that presents headaches for high performance implementations. How is Javascript's eval particularly problematic in this regard, and specifically much more so than Lua's loadstring/load?

More generally what do you think makes (pre-ES6) javascript significantly harder to optimize than lua 5.0?

SEEKING WORK, Tennessee, United States

Remote: Yes

I'm a full-stack, JavaScript/Node.js developer and designer. I'm the creator of the Joystick JavaScript framework [1], Push deployment service [2], and Mod CSS framework [3].

I also have experience with MongoDB, PostgreSQL, and MariaDB (limited but competent) and devops (K8s + Docker and bare-metal linux admin, the latter preferred for simplicity/stability).

Currently looking to take on clients who are open to using Joystick, Push, and Mod to design and develop their app. Because it's still at a pre-release version, I'm willing to work out deals around pricing to get some more test-cases under my belt. Ideal client is a solopreneur w/ funding or entrepreneur with previous experience + funding. Open to working with startups (early or established), but only on greenfield projects where use of Joystick is ok.

Email: [email protected].

[1] https://cheatcode.co/joystick

[2] https://cheatcode.com/push

[3] https://cheatcode.co/mod

There is. I was frustrated by all of the chaos and built a solution [1]. Not too far of from an RC1 and then a 1.0 (which is being done slowly so I can freeze APIs and avoid the typical JS rug pulls).

[1] https://github.com/cheatcode/joystick

I've been (slowly) writing a new type of OSS license around this exact concept so it's easier to (legally) stop LLMs hoovering up IP [1] (under "derivative works not permitted").

[1] https://github.com/cheatcode/joystick/blob/development/LICEN...

Joystick [1] will let you go. No Stockholm syndrome. No lotion in the basket.

[1] https://github.com/cheatcode/joystick

If you share the sentiment of the author and want to get on the road to recovery, I submit Joystick [1]. I had similar frustrations to this and decided to do something about it [2].

[1] https://github.com/cheatcode/joystick

[2] Please give it an honest a look and save the XKCD "muh standards" comic and accompanying snark for after you've taken it for a spin.