I wish Lua 5.1 could become part of POSIX; there are a lot of implementations of it out there.
[–] ajross 1 day ago
[–] strenholme 1 day ago
Lua 5.1’s edge over Javascript and Python is that it’s a lot smaller and simpler.
[1] It’s possible to recompile Lua 5.1 to have the numeric data type be an int, but the standard compiles of Lua5.1 only have double precision floats for numbers. Bitwise operators are technically not part of Lua 5.1, but a library to add support is easy and is usually done: Most Lua5.1 forks including LuaJIT and MediaWiki’s version of Lua5.1 have such a library available. Later versions of Lua have both int and float support.
[–] ajross 13 hours ago
Yeah, but again you don't reach for C when you have a string or hash-based logic problem, which is the reason that other platforms are favored. You reach for Python[1] to solve those problems, and it works fine.
You reach for C when you care about cache footprint or memory layout. You reach for C when you need SIMD parallelism. You reach for C when you care about doing the math in single precision or 32 bit integers and will handle the precision worries yourself.
You emphatically don't reach for python (or Lua) in those situations. But notably you can reach for numba, and implement your small core of performance code in python next to the other logic you already have. And there's value there.
Screaming about using Lua instead is just nonresponsive. Lua is arguably better at performance code than Python. Lua is absolutely not faster than numba, nor will it ever be (absent a numba-like translation layer) and repeatedly trying to argue so is very much missing the point.
[1] Or fine, Lua or JS or whatever. But I'm trying deeply not to let this turn into a frothing language flame, and this is after all a python discussion.
[–] Dylan16807 5 hours ago
The point of those comments is not to hype Lua, it's to show what a JIT can do.
The idea is that a python JIT could be just as good as Lua for the parts that aren't suited to numba.
> Lua is absolutely not faster than numba, nor will it ever be (absent a numba-like translation layer) and repeatedly trying to argue so is very much missing the point.
Nobody is arguing that. People are agreeing that numba is fast, but they also want other non-number-crunching things to be fast. It's "yes, and". They're not missing the numba point, they're agreeing and you're missing the additional point they're responding with.
[–] Dylan16807 1 day ago
When OP wrote "inline Cython" they didn't seem focused on numerics, they talked about "proper C speed", and they mentioned modifying the language. I don't think it's getting off-topic to suggest a deeper integration that lets the JIT be very intimate with the interpreter and truly inline things in a way that bypasses language-crossing and type-dispatching overhead. As long as you're in the hot path, let it look up object fields in a couple instructions.
[–] ajross 1 day ago
Isn't that basically what I said? Lua isn't "proper C speed", nor is PyPy, the cancelled Python JIT in question, nor even V8. That's a different problem area with different technologies. The fact that you like coding backend stuff in Lua or whatever isn't really saying much about whether numba is great.
But it is. Numba is great.
[–] strenholme 1 day ago
Lua5.1 is much more stable by the virtue that the only updates it code gets are very minor changes to fix any lingering security issues it has (the last Lua5.1 CVE is from 2014).
[1] I guess these days a LLM can do the grunt work of converting a Python2 script to Python3.
[2] There is a project which converts Lua in to native code: https://github.com/samyeyo/clx
[–] Dylan16807 1 day ago
Numba is great at its niche. But OP directly said Numba is "not really" what they were looking for because it's so narrow.
The upthread comment was about an idea for "inline Cython", which was then hijacked because that's largely what numba is. These are technologies aimed at optimized native code running over native types to do stuff like numerics and ML and other HPC tasks. Lua isn't any more responsive to this domain than Javascript has been, it's not really the subject under discussion.