16 ms·
CloudFlare starts discussion about LuaJIT project governance
- jgrahamc 11y agoI would have titled that as "CloudFlare starts discussion about LuaJIT project governance". We don't have a solution or prescription. We're happy to help Mike in the transition in any way possible and are taking baby steps as we do so.
- logicrime 11y agoLuckily, the thread isn't just about you!
- pygy_ 11y agojgc is the author of the linked email, and this submission initially had a title that implied Cloudlfare was laying out plans for the future governance.
- logicrime 11y agoYeah I know, the Silicon Valley/Gay area hivemind is downvoting my confronting JGC about all this.
- jgrahamc 11y agoWhat has gay got to do with this?
- pygy_ 11y agoObvious troll is trolling, I guess.
- logicrime 11y agoConsidering that people only know your name because of your obsession with Turing, I'd say it's merely an interesting coincidence.
- dang 11y agoA comment like this is a bannable offence on HN, especially when the account has made many previous comments that were uncivil or unsubstantive, as this one has. Your account has some great comments in its history too, though. You clearly know how to use HN as intended. Please just do that from now on.
- logicrime 11y agoWhat was the best case scenario (in your opinion) for this message? My mission is to speak the truth, ONLY the truth. I don't mind ruffling feathers along the way, especially in regards to JGC, who is actively taking steps to destroy the FOSS principles of the LuaJIT project. I'd sooner see myself banned than retract or apologize for a single character of anything I've said thus far, or plan to say soon.
- dang 11y agoI'm not sure I understand your question, but there are lots of ways to speak the truth, and on HN you're expected to do so civilly and substantively. Personal attacks are especially not allowed. Sometimes people justify their uncivil, unsubstantive comments by posing as warriors for the truth and so on, but this is silly, because the truth isn't served by such posturing at all, and rudeness makes a comment less persuasive.
- logicrime 11y agoRead that back and ask yourself how many commas you really needed.
- jgrahamc 11y agoAll this is being driven by Mike Pall who created LuaJIT. If you really think that I, personally, am "actively taking steps to destroy the FOSS principles of the LuaJIT project" then get involved on the Lua mailing list and ensure that whatever principles you want are maintained. The biggest disconnect I have with you is that you are asserting that I am messing up the FOSS nature of LuaJIT but I don't see how moving it to Github (with Mike's help), getting people involved as widely as possible etc. is doing that. What, specifically, are you concerned about in what I/CloudFlare are doing?
- dang 11y agoOk, we changed the title to that.
- bratao 11y agoMy impression is that LuaJIT is too perfect/complex to the GitHub collaborative model work, where developers uses the software, identify a bug/missing feature for his use case, dig in code for a day/week, and do a push. In LuaJIT the stakes are much higher, and a small change can have big repercussions. Relying on occasional open-source contributors seems like a direct path to abandonware.
- brandonwamboldt 11y agoI disagree, it lowers the barrier of entry for people to document code, clean up documentation, or just review the code and report issues (e.g. security related). Even if LuaJIT doesn't see a lot of random contributors, it makes it easier to review commits and what not.
- chrisseaton 11y agoI think it would be ok if you have a CI system that runs benchmarks. If a PR comes in you let the CI run and tell you if there are any regressions.
- gsnedders 11y agoGood benchmarking systems are few and far between, and so many unexpected factors can cause noise, before you even write your first performance test. I'd love a Travis CI for performance tests, but it's a seriously hard problem.
- thejosh 11y agoHow so? The benefits of GitHub benefit regular committers over fly-by PRs.
- jetm9 11y agoSo true. Some (increasingly rare) code does not translate into modern trends. actually it's more like craftmanship and LuaJIT is a craft. Just like Gigablast open source search engine.
- pierrec 11y ago
- sdf45 11y agoI don't know much about Lua and LuaJIT, so let me ask a naive question: If you would start out with a JavaScript JIT (like V8) what things would you have to add (i.e. things that are not required to JIT JavaScript) besides the obvious modifications in the parser? One point I can think of is support for efficient compilation of co-routines.
- wolf550e 11y agoThe reason people use LuaJIT instead of v8 is because LuaJIT is faster than v8 (on some code) and is smaller and is more easily embeddable. Or at least that is my impression, I have no personal experience with it.
- malkia 11y agoFor me the main reason was the FFI, even if back in the day it did not support re-entrance - e.g. something in the "C" land has to call back "lua" land. But the JIT in luajit is simply too impressive to skip it over. I was able to quickly prototype things with it, running almost at "C" speed, and some times even faster.
- camperman 11y agoThere's a in-depth discussion of those issues with respect to both LuaJIT and Javascript here: http://lambda-the-ultimate.org/node/3851 http://lambda-the-ultimate.org/node/3851
- yoklov 11y agoLua has goto (and JS does not), which means not all cfg's are well structured. That could impact the compiler in certain ways. Lua also has finalizers, which effect the GC's design. The Lua/C api also makes it impossible for the GC to move objects, which means pretty much every current JS VM's GC is out. Lua 5.3 has 64 bit integers, which would effect most JS VM's in a significant way (but to my knowledge LuaJIT doesn't support 5.3 so...) There are other issues too, but these are just off the top of my head.
- 11y ago
- kzrdude 11y agoMaybe the project can take inspiration from projects that use run tests for each pull request, before merging.
- logicrime 11y agoThe qualms I have with this dialogue are the same as before, because CloudFlare has little to no idea how they are going to handle this. JGC tweeted me about how 'Oh, we get so much benefit from LuaJIT being FOSS" but here we have CloudFlare walling LuaJIT into it's own entity on GitHub where I predict commit bits will be few and far between. More than that, I don't think there has been enough narrative between Mike and the 'new LuaJIT crew' (CF) to determine how the project should be structured. In this thread, agentzh had a fantastic idea to vet somebody through Mike, someone the community knows can be trusted and also is somewhat familiar with the LuaJIT internals, and that person could serve as a canary between the project and CF. I write a fair bit of Lua for game scripting, and I've even made a few bucks here and there helping folks with their custom plugin ideas etc, but I've never touched C before. Well, when the previous announcement was made, I immediately Amazon'd some C books, which I plan to devour in my free time. At which point I'll be learning Rust, and reimplementing LuaJIT in Rust, and hopefully convince Mozilla to host the git, such that it will be protected from FOSS corruption. My worst fear is CF taking this project into the shadows, developing it closed-source (which they absolutely have a right to do) and not sharing their insights with the community. I think everybody with any kind of invested interest in LuaJIT needs to be gearing up right now, such that we can do our parts to keep this project alive.
- jgrahamc 11y agoJGC tweeted me about how 'Oh, we get so much benefit from LuaJIT being FOSS" And we do. We paid Mike Pall to work on open source LuaJIT, we've contributed to NGINX, hired people to exclusively work on open source projects. Here's the harsh economic reality: it is simply better business for us to spend a relatively small amount of money on open source support to get what we need from fantastic projects like LuaJIT than to try to develop this stuff ourselves. My worst fear is CF taking this project into the shadows, developing it closed-source (which they absolutely have a right to do) and not sharing their insights with the community. How do we "have the right to do" that? Whatever makes you think us trying to closed source this would have any benefit to us? How is the Github account (of which Mike Pall is an owner) us walling it off? More than that, I don't think there has been enough narrative between Mike and the 'new LuaJIT crew' (CF) to determine how the project should be structured. I predict that if I hadn't sent an email to the list soliciting ideas and input and had announced a new structure you would have complained that everything had been done in the shadows.
- coldtea 11y agoI was exchited by what I was hearing about Lua and LuaJIT, speed and quality of code wise. And then I tried the language. While it's poweful in its "meta-programming" facilities and has some nicities, it has many uneeded bizarro decisions. This alone was enough to make me leave it: http://stackoverflow.com/questions/2705793/how-to-get-number-of-entries-in-a-lua-table http://stackoverflow.com/questions/2705793/how-to-get-number...
- tylerneylon 11y agoIf you have an array in Lua, which is a table used as a contiguous list of items, this is how you get the number of items: num_items = #my_array Your qualm, apparently, is that this # is not built for all use cases of tables. In C++, what operator tells you how many instance variables a class has? There is none, because that wouldn't make sense in many use cases. Lua tables, offering prototype-based inheritance, experience a similar conceptual ambiguity in the case where you want to take the length of an object. Lua has made a design decision that the built-in length operator only works on arrays = tables-used-as-a-list and on strings -- cases without ambiguity. If you want the length operator to make sense for a hash map usage, it's a few extra lines of work for you. It's consistent with the langauge being small and flexible, a theme which Lua embraces with elegance.
- coldtea 11y ago>Your qualm, apparently, is that this # is not built for all use cases of tables. My qualms are multiple: (a) this is an operator when it doesn't need to -- a function would do --, (b) this only works for contiguous list of items. (c) Lua, like PHP and JS, has the same type for "contiguous list of items" and hash tables, not even providing a builtin just for the first and/or the latter (e.g. ES6 now does with "Map"). I can understand the powerful metaprogramming capabilities of tables. I also understand that they are not needed, and are even a hidrance, in the tons of cases where all you want is a simple hashmap or a simple vector that wont change under your feet. >* In C++, what operator tells you how many instance variables a class has?* Nobody said C++ was well designed ever, too.
- pierrec 11y ago