4 ms·
> declarations for global variables That's huge. I wish LuaJIT adopted this, or at least added a compile time flag to enable it.
by klaussilveira 10mo ago
> declarations for global variables
That's huge. I wish LuaJIT adopted this, or at least added a compile time flag to enable it.
- shmerl 10mo agoYeah, I wish someone would pick up LuaJIT development. From what I've heard it in practice isn't developed anymore and is stuck at Lua 5.1 still.
- dividuum 10mo agoNot true. It's getting a constant stream of bugfixes. It's also not "stuck" on Lua 5.1, but is deliberately not following Lua's path, except for some backports. There's also a recent post about how a LuaJIT 3 might work.
- shmerl 10mo agoOK, then I got some wrong info. If it's stuck at it deliberately, then it's worse. May be someone should fork it and bring it up to date with recent Lua versions. Why is this split needed?
- upofadown 10mo agoMy understanding is that there was a language fork after 5.1. One thing was a complete reworking of how math works. It used to be just floating point for everything but the new idea was to make it like Python 3. So most operations are float/integer with some weird exceptions. As with any language fork there will be some who stay and others who switch to the new thing. Often a fork will drive people away from a particular language as in my case.
- shmerl 10mo agoLanguage fork is unfortunate. Python situation isn't much of a fork really. Python 2 is basically EOL.
- kstrauser 10mo agoThere’s no “basically”. Stick a fork in it; it’s done: https://www.python.org/doc/sunset-python-2/ https://www.python.org/doc/sunset-python-2/
- shmerl 10mo agoWhich is better than this mess with Lua situation.
- shakna 10mo agoIt might not be supported by the consortium, but python2 still lives, slowly, in one place or another: > The RHEL 8 AppStream Lifecycle Page puts the end date of RHEL 8's Python 2.7 package at June 2024. https://access.redhat.com/solutions/4455511 https://access.redhat.com/solutions/4455511 At this point in RHEL it is only "deprecated", not "obsolete".
- wombatpm 10mo agoIn RHEL I would never touch system python at all, and would install what every version I needed in a venv and configure any software I installed to use what ever version I needed. I learned the hard way to never mess with system python.
- ksymph 10mo agoLua's nature as a primarily embedded language means backwards compatibility is not guaranteed between any version. If 5.2 was a language fork then so was 5.3, 5.4, 5.5, etc. (5.2 did have some more significant changes though) For that reason luajit staying at ~5.1 actually works in its favor. Rather than trying to follow the moving target of the newest version, it gives a robust focal point for the lua ecosystem, while modern versions can be developed and continue to serve their purpose in embedded systems and whatnot where appropriate.
- shmerl 10mo agoI don't see a reason not to update LuaJIT still. Changes in Lua aren't just version numbers, it should be improving something, meaning that would be missing in LuaJIT.
- electroglyph 10mo agothe beauty of open source is there's nothing stopping you! this might be your calling. best of luck
- ksymph 10mo agoLuaJIT does have some backported features from newer versions. But Mike Pall -- the mad genius behind LuaJIT -- has made it clear he doesn't agree with many of the changes made in newer versions, hence why it's staying where it's at.
- radiator 10mo agoIsn't it a bit naive to declare that, just because Lua created a new minor version, it should be somehow better? The author of LuaJIT has often written his arguments, including why he disagrees with the changes to the language, why they should have been implemented as libraries instead, that in his view LuaJIT is still more performant and more widely used than PUC Lua, and more. As for forking, you can try, but I would warn you that one does not simply fork LuaJIT. Required is deep expertise in tracing JIT compilers, in assembly and in many different computer architectures. Nobody was really up to the task when Mike Pall announced that he was searching for a maintainer, before his eventual return.
- ori_b 10mo ago> May be someone should fork it and bring it up to date with recent Lua versions. Why is this split needed? Good news, you're someone. If you care, you're welcome to go for it.
- ux266478 10mo agoThe language is different. The changes to environments in particular are a non-starter. Sandboxing is incredibly clunky in 5.2+, and we lost a lot of metaprogramming power and dynamic behavior.
- krapp 10mo agoI strenuously disagree. Not every language needs to chase trends and pile on unnecessary complexity because developers want the latest shiny language toys to play with. It's good to have a simple, stable language that works and that you can depend on to remain sane for the forseeable future. C is a language like that but I fear the feature creep is coming (auto? AUTO??.) JS is a lost cause.
- pjmlp 10mo agoLanguages are products as well, either they evolve to cater to new audiences, or they slowly die as the userbase shrinks away with the passing of each developer generation.
- fithisux 10mo agoWhere is that post?
- fweimer 10mo agohttps://www.freelists.org/post/luajit/Question-about-LuaJIT-v30-status,6 https://www.freelists.org/post/luajit/Question-about-LuaJIT-... Warning: Ridiculous cookie consent banner, needs dozens of clicks to opt out.
- loulouxiv 10mo agoThis cookie consent banner is handled in 0 clicks thanks to Consent-O-Matic Firefox extension
- deleted 10mo ago[deleted]