Looking for new LuaJIT maintainers

http://www.freelists.org/post/luajit/Looking-for-new-LuaJIT-maintainers

by espadrine • 11 years ago

213 36 11 years ago

freelists.org

dochtman• 11 years ago

Wonder what Mike Pall will be up to next...

logicchains• 11 years ago

Maybe he'll find some other language to make an order of magnitude faster.

dman• 11 years ago

Hoping he picks python :)

acqq• 11 years ago

Whatever it is, I guess that he leaves the role because the compensation for it was in long term not appropriate for him.

elisee• 11 years ago

Maybe, but after 10 years, maybe he just wants to spend his time doing something else.

CyberDildonics3• 11 years ago

Can anyone actually fill Mike Pall's shoes? I always got the impression that what he was doing came from a very rare combination of JIT and low level optimization knowledge.

jballanc• 11 years ago

Hmm...wonder what this means about the status of the Quad-color bitmapped arena mark-n-sweep collector Mike was planning for LuaJIT 3.0 (http://wiki.luajit.org/New-Garbage-Collector)?

I remember reading what he had researched so far a couple years back and being really excited, but it seems like the work was never really continued. I'd be interested to know if there was some fatal flaw that would've kept the collector from living up to its potential? or was it just a matter of the sizable effort required to write a new collector, more-or-less from scratch?

versteegen3• 11 years ago

AFAIK, he never moved beyond planning it, unless the GC64 work is also a prereq for it. E.g. almost no significant updates to the new GC wiki page or mention of GC in git commits since 2012.

BTW, previous HN discussion of the new GC: https://news.ycombinator.com/item?id=4053969

catwell• 11 years ago

I have mixed feelings about this.

On the negative side, Mike Pall is an impressive individual who has contributed a lot to the field of JIT-compiled languages, so losing him is obviously bad for the project. LuaJIT is also a hard codebase to get into, I myself tried to get into it and gave up (I blogged about it last month [1]). There are probably still parts of it that only Mike understands, I guess we will see how much in the next months.

On the positive side, this will forcefully increase the bus factor of the project and take it out of this situation. And maybe we will see it catch up with Lua 5.3 :)

[1] http://blog.separateconcerns.com/2015-06-18-love-hate-luajit...

ketralnis3• 11 years ago

And maybe we will see it catch up with Lua 5.3

For those that think that LuaJIT's 5.1 compatibility isn't too far behind 5.3, be aware that Lua changes a lot in its minor versions.

To give you an idea, 5.2 introduced changed how scope works (both some stuff with lexical/global scope, and by redoing environments), introduced the `goto` statement, finalisers, and changed how `break` works.

5.3 introduced integers (Lua was previously like Javascript with only one Number type which was backed by a `double`), and utf8 support.

This means that upgrading a Lua version can be a big deal and break all of the programs written in it. For instance, redis and WoW both still embed 5.1.

versteegen3• 11 years ago

Yes, 5.3 is not a "minor version" increment, it's a major version increment on 5.2. That's how Lua version numbering works.

Adding support for 5.3's integer subtype is probably going to be a very large project, I would guess that annoyed Mike.

People say that LuaJIT's source is difficult to understand, but I've seen source for several VMs with JIT compilers and this one certainly isn't the gnarliest; it's decently well commented. It only took me 30 min to add a new builtin function, with almost no understanding of the codebase beyond skimming a couple header files. As long as you don't want the JIT compiler to output asm for your language extensions, it's almost friendly.

buserror• 11 years ago

I'm a big fan of Luajit, I think it's ease of use of FFI makes it fantastic to integrate into bigger projects; all that 'glue' that I haven't had to write !! Hope someone pick it up; I can understand he wants to move to other things, and sometime a projects becomes a bit too 'big' and you can feel a bit shackled to it after a while...

deltheil• 11 years ago

There is this recent thread[1] where people are looking for resources to help them understand the project. There are interesting pointers[2] as well as a part of a PhD thesis[3] that covers it.

[1] http://www.freelists.org/post/luajit/how-to-read-the-source-... [2] http://www.freelists.org/post/luajit/how-to-read-the-source-... [3] http://www.freelists.org/post/luajit/how-to-read-the-source-...

pierrec• 11 years ago

This is a good initiative because LuaJIT development has been mostly halted since May 2014, when the following note was added to the LuaJIT Open Sponsorships page:

"The main LuaJIT author (Mike Pall) is working on unrelated projects and cannot accept new sponsorships at this time..." [1]

Since then, Mike has only made bugfix commits to the project.

I really hope that the features mentioned on that Open Sponsorships page start happening after these news, and CloudFlare seems like a good candidate to me: even without knowing how much resources they're ready to offer, I'm willing to bet it will be an improvement over the current situation.

Everyone was surprised when LuaJIT seized the position of "fastest scripting language in the west", and it would be awesome if they could manage to keep that status - or has it been taken over by Javascript already? JS implementations have been improving dramatically thanks to the competition between browsers, and V8/SpiderMonkey are implementing features from LuaJIT's TODO list right now (I'm thinking about vectorized SIMD instructions). A lot of people use benchmarks as a major factor for choosing a scripting language, and I'd rather see more projects using Lua/LuaJIT rather than JS as a scripting language. It will be interesting to see how this turns out. Go LuaJIT!

[1] http://wiki.luajit.org/Open-Sponsorships

meric• 11 years ago

    "fastest scripting language in the west"

Ironic - Since Lua's speed is most heavily used in Yahoo! China, Taobao, Alibaba and programmers hired by Cloudflare to work with Lua worked in those companies. (http://agentzh.org/#AboutMe) The use of Lua - openresty with nginx - Nginx is from Russia, too.

    "fastest scripting language in the east"

Might be slightly more appropriate.

But then again - Lua originated from Brazil and heavily used in game companies in the U.S. Not sure how much they use LuaJIT though.

mcpherrinm• 11 years ago

This is a reference to the trope of quickdraw duels and "Fastest gun in the west" referring to the western United States in the "Wild West". Not an east/west of the world like you're thinking.

felixgallo• 11 years ago

Mike Pall is an international treasure whose work on LuaJIT has been without parallel in the embedded/gaming world. I hope this move is born of desire and moving on to great new things rather than any type of necessity.

CyberDildonics3• 11 years ago

I've never heard any actual stories of LuaJIT being used in games as opposed to stock Lua, but I know it was ported to power processors. Have any big games claimed to use LuaJIT? It would certainly make sense if the memory and gc pauses were no worse than Lua.

jpfed• 11 years ago

No big games that I know of, but it's certainly used in games; the LOVE engine embeds LuaJIT.

Looking for new LuaJIT maintainers

Related Stories