Luvit 3.0 #1166
Replies: 34 comments 9 replies
-
Luvit was reborn as version 2.0 in March 2015. I joined the community a year later in early 2016 when I leveraged luvit as a niche solution to developing Discord bots in Lua, out of which I grew a small sub-community of Discord users. Since then, I've been an occasional contributor to the project and luvit has become my go-to framework for almost anything related to Lua. I consider myself an amateur programmer, so I do not claim to have any sort of well-informed professional opinion on what luvit is or should be. This is just my opinion based on my experience using luvit. Luvit as a Node.js cloneWhen luvit 2.0 was released in March 2015, node was on version 0.12, io was on version 1.5, and JavaScript was ES5. By the end of the year, node and io had re-merged to become node 4.0 and ES6 was finalized. Since then, node has undergone changes sufficient to bring it to version 15.8, while callbacks have given way to promises and async/await-style coding with annual updates to JS/ES. In the same time, luvit advanced to version 2.17 with minimal API changes and today it is still based on the old callback-style of coding. I think that if luvit is intended to be a node clone, then some effort should be made to bring it up-to-date with respect to the current node APIs and modern JavaScript (or TypeScript). Alternatively, the connection to node can be loosened and we can make luvit more of its own framework. Maybe there are some other frameworks or runtimes that we can look towards for inspiration? Deno is an obvious alternative, although I have not had the chance to look closely at it. The only other dedicated async I/O framework that I am remotely acquainted with is vibe.d. There is Python that has async I/O in its standard libraries, plus languages such as Julia and Janet that use libuv, but I'm not sure to what extent these may serve as inspiration for a Lua framework. Regardless of whether we continue the node-clone approach or redesign luvit into its own framework, I think that coroutines should be emphasized over callbacks. As shown by Tim's "coro" libraries, coroutines can be used to make a robust async/await-style API. Luvi and luvI think that the modularization of luvit into luvi and luv was a fantastic idea and this should stay the way it is. I don't think that there are any critical issues that need to be addressed here, but there are some points worth mentioning. Luvi loads The idea of switching to xmake or zig to build luvi or luv has been thrown around recently, which may involve making changes to the way we use certain libraries. I can't comment much on this, but I think @truemedian can. He's already made some progress using GitHub Actions and zig. Additionally, @creationix has suggested moving luv from a callback API to a polling API. See polluv as an experiment. We can't easily break luv's current code because its versioning is bound to libuv's and because it is also a LuaRocks package, so any major changes to luv will have to be carefully considered. Lua source filesWe are maintaining Lua source files across three repositories. Some of them have multiple copies (for example, Custom module systemOne of the major defining features of luvit is its custom module system with relative requires, deps and libs resolution, lit packaging, and luvi bundling. It is a departure from standard Lua's module system and has several standing issues. I think that some of these issues are addressed by switching to luvit-loader, but that switch was put on hold due to the necessity for breaking changes (#932). Bumping luvit to 3.0 would give us an opportunity to revisit these issues. DocumentationNot much to say about this one. Luvit's documentation is weak, but at this point, I think our time would be better spent updating luvit's 6 year old code instead of documenting it. We could then document the new code as its developed or immediately after. LuaJIT vs PUC LuaLuaJIT is great. It's fast, it has a nice FFI, it's popular, and it is based on Lua 5.1. Despite being 15 years old, Lua 5.1 is still a common and capable language today. At the same time, Lua 5.1 is now 3 major versions removed from the current Lua 5.4, and there are no plans to update LuaJIT's feature set to include anything beyond 5.2. I think that it would be worthwhile to offer a "PUC Lua" version of luvit and luvi. |
Beta Was this translation helpful? Give feedback.
-
This is a great write-up @SinisterRectus! I'll make my own post with some proposals later, but first some quick feedback:
I agree. I instantly regretted making luvit a node clone as soon as the 2.0 rewrite was done. The virgo project that sponsored the luvit 2.0 rewrite used node style APIs extensively and it allowed us to be lazy about documentation by simply pointing people to node's website. But none of that is important or relevant anymore. If someone really wanted to have an updated node clone, it could be done in userspace easy enough. But I feel it's not a good use of our limited resources for the core team to maintain such an API. We should instead focus on use cases where luvit is a good technology and make those better while embracing Lua's strengths. The coro-* and weblit libraries, for example were a great experiment and could be made into a very robust framework with some polish and good documentation.
This was because they were non-trivial libraries and keeping them in userspace with magic hooks in the luvi binary made iterating on them a lot easier. Also it allows people to make really lean luvi based binaries that don't use them at all since they were optional. We can consider having a small set of libraries like this that are baked into luvi and official core APIs.
I also think this is a great idea, but haven't had the time to dig into the technical details about what is needed.
If we did this, it wouldn't be a new version of luv, but an entirely new library. The entire purpose of this is to allow luajit's FFI to have better access to libuv. There would be virtually zero shared code between this approach and the luv bindings. For now this should probably stay a userland experiment. The binary extension mechanism allows this to be done completely externally if desired.
Agreed, but this is a tricky bootstrapping problem. For example, luvi needs the path joining algorithm for it's primitive vfs APIs. This would be another reason to consider simply moving these core libraries into luvi instead of making them optional with magic hooks. The luvit 2.0 rewrite focused on the most minimal and flexible core possible, but I think we've reached a point in the years since where we can pick a few libraries to include with core that make sense there.
1000
Sounds good to me. As long as we do write docs afterwards.
These have diverged to the point that it's really hard to support both equally. And some things don't even make sense in both. For example the polluv experiment doesn't make any sense for PUC Lua since it doesn't have the fast JIT based FFI built in. I'm fine with spending some time and seeing exactly how much effort/compromise is required to support both. There is a similar dynamic with supporting luarocks and lit at the same time and stock lua/luajit vs luvi based builds. We kind of went crazy making luvit 2.0 be super flexible and can probably keep a lot of those qualities in the 3.0 version as long as we're aware of the tradeoffs and think they are worth it. |
Beta Was this translation helpful? Give feedback.
-
One thing I would like to explore in a breaking change is find out if it's feasible to remove the openssl dependency, but still have access to common hashing algorithms and TLS (1.3 at least). The hashing algorithms could probably be done in lua and be fast enough for most things with luajit. But TLS is a bit more work. This desire is mostly out of pain from building openssl and trying to get cross compiling working better. |
Beta Was this translation helpful? Give feedback.
-
The issue with dropping openssl for better cross compilation capabilities is that none of the TLS libraries I know of support cross compilation with the ease we're looking for. If we were willing to drop server TLS capabilities, we could use a pure-zig approach: alexnask/iguanaTLS. However it is only TLS 1.2 and only client side. It is very easy to cross compile though. |
Beta Was this translation helpful? Give feedback.
-
Hmm, only client-side and 1.2 will work for a lot of use cases. Very few web service APIs are TLS 1.3 only and very few don't support 1.2. For servers, I tend to use nginx as my TLS terminator and proxy to the luvit server speaking plain HTTP. I think it's safe to say that we can't drop openssl completely since I'm sure there are some people who need it. But maybe we don't provide prebuilt binaries with openssl on the platforms where it's difficult and then encourage most people to use the new and improved tiny version that has a working TLS client. |
Beta Was this translation helpful? Give feedback.
-
Having more bindings makes luvi (since in reality this is what has to be tackled first) 3.0 a bigger project, but I suppose that's unavoidable. |
Beta Was this translation helpful? Give feedback.
-
Here's my 2 cents for whatever it's worth. My inclination would be to lean much harder into the existing Lua ecosystem:
I have a feeling this might not work as well in practice as it does in my imagination, but I thought I'd at least throw it out there. |
Beta Was this translation helpful? Give feedback.
-
Our custom A more streamlined solution for using Luarocks modules would be cool. I think this kind of goes hand-in-hand with the I agree with your vision of luvi. This reminds me of ninite where you check only what you want. It would be more work on our end to provide various iterations of luvi, but I think it would be nice if it works. |
Beta Was this translation helpful? Give feedback.
-
I think the largest issue with |
Beta Was this translation helpful? Give feedback.
-
Yeah I agree that relative-requires, plus libs/deps/bundle-requires, are super useful. One thing I thought of is having a totally new system that complements |
Beta Was this translation helpful? Give feedback.
-
I like the idea of not reusing |
Beta Was this translation helpful? Give feedback.
-
@SinisterRectus that aligns with my past experience in LuaRocks as well: in LuaRocks 1.x, I shipped a patched For LuaRocks 2.x, we switched to providing an optional package loader that you can load with Ultimately, very recently in 3.4, we introduced dependency version lockfiles (a la yarn and others), which allow users to extract their full dependency tree into a plain list with fixed versions and be able to see what exactly is going on and avoid surprises. In my experience, Lua people more often want to avoid having multiple versions of things installed rather than having something manage them. I'm not sure if that's the expectations are the same for people coming from the Node world (I'm assuming the expectation there is more like So yeah, 1 to keeping more advanced behavior separate from
The question would be how to keep the advanced behavior "hidden" from Lua end-users, so they could I'm not very familiar with the libs/deps specifics in the Luvit world (I was invited into this thread by @creationix to share the LuaRocks experiences), but if there's some advanced logic that's not supported by LuaRocks, such as a Since LuaRocks 3.0 there's a Still, I ended up not 100% happy with the ergonomics of using LuaRocks 3.x in this model, precisely because I didn't want to touch In general, Lit seems to me like a much leaner and cleaner package manager. LuaRocks carries a lot of baggage from being very old, assuming almost nothing about its environment, and trying to be all things for all people. If you have a solution that works, I think it's unlikely that you'd get a nicer experience by switching over to LuaRocks today, honestly, apart from gaining access to the luarocks.org collection of packages. It seems that the changes in LuaRocks 3.x have brought it a bit closer to Lit in functionality, though not quite there yet — still, it would be interesting to know what else is missing and if there are ways we could bring the projects closer together for mutual benefit. Perhaps by having Lit learn how to read dependencies from the luarocks.org repository? (that would be the opposite approach, "wrap LuaRocks packages as Lit packages", essentially.) |
Beta Was this translation helpful? Give feedback.
-
I think this could work well. The biggest difference between using luarocks and lit to install packages is where it puts them. If lit could pull from the luarocks repository and install them in deps folders (which is identical logic to node_modules btw), they should work without needing package authors or luarocks.org to change anything. Also at the same time, I'm still feeling like separating the "smart" require from the built-in require and renaming luvit require logic to a new function like import will clear up a lot of misunderstandings. |
Beta Was this translation helpful? Give feedback.
-
Actually I misspoke. If we rename |
Beta Was this translation helpful? Give feedback.
-
Disclaimer: I'm not an expert on the technology Luvit is based on, and I almost didn't want to participate in this dicussion as it feels like the "big boys table" and I'm certainly not qualified enough to give much input here. However, perhaps you will find it enlightening to hear a random user's perspective :) Some more background: I've worked with Lua for the past five years or so, and for the past two I've been using both Luvit and NodeJS in parallel. As a result, I can describe my experience, especially that of someone trying to learn, and that might be of interest when you think about the future of this framework (as it's vital to get new people on board). Let's talk about first impressions, because they matter, a lot. Whenever someone is looking for a Lua-based framework that might make their lives easier, they will probably pay attention to at least some of the following things:
Ultimately, users want to know: Can the framework solve their problems, and Is it likely to be a liability or an asset? Now, let's go back in time about two years, when I first heard about Luvit. What was my initial impression then, and has it changed now?
TL;DR: The only reason I'm following the project still is because I'm way too stubborn for my own good. Most people will not stick around after an experience like the one I just described! And could anyone blame them when there are so many other technologies and programming languages around that are easy to use? The obvious conclusion from this is that how Luvit is currently represented simply doesn't inspire confidence. It looks like using it will be a liability, much like the rest of the Lua ecosystem, which frequently suffers from similar issues... and that's a shame because I think providing a Node-like experience in Lua (which doesn't have to mean a direct clone) is in actuality a really cool idea. Speaking of Node, I later went and did what I sought to do with Luvit, using NodeJS. It took me mere minutes until I had a basic prototype of the app, a WebSockets-based server, running. When I first tried to do this in Luvit it took an entire day and a lot of help from someone in the Discord just to achieve the same basic thing, but there were still a lot of question marks / stuff that didn't really work the way I wanted it to. I guess what I'm saying is, Luvit does a very poor job of explaining what it is, how to use it, and users are likely going to have a bad experience overall. All of these things are crucial to get right for any Open Source-project if it is to ever be successful (assuming success equals people using the software you spent so much time creating), and all the amazing technology behind it will go underappreciated if UX is completely ignored. The good news is, there are people out there who like Lua enough to potentially use Luvit over Node, if the state of the ecosystem in general hasn't yet scared them off, and they might be willing to help. I know because I'm one of them. However, their life should be made easy and not needlessly difficult, as is currently the case. It takes a concerted effort but a little goes a long way already. Finally, my thoughts about some of the more technical points you made:
I hope no one takes offence at what I wrote. I'm ardently campaigning for a better user experience because it plays directly into one of the main strengths that Lua as a programming language has, and also because most developers (in any language) don't seem to value it nearly highly enough. I understand why and I don't blame them, but I think it's unfortunate because the purpose of any software is to be used, by users who often don't want to know all the details. It follows that using it should be as simple as possible, to the point of being foolproof even. If you would like to help Luvit become a true equivalent to NodeJS in spirit, then you should IMHO focus much more on making things "just work", making it work intuitively, and making sure that the technology can be used by almost anyone on any platform with as few stumbling blocks as possible. Software that people don't understand they won't use, and software that isn't used is literally a waste of time to create and maintain. Node is extremely easy to use; that's one big reason why people use it in the first place. The large amount of libraries are just a side effect of it filling a real need in my eyes and if Luvit was more user-friendly it might have more actively-maintained packages, too. The same could be said about LuaRocks, too, but that's besides the point. Given the power of LuaJIT and the accessibility of Lua, I think with Lua one could achieve what Node/JS managed to do, but better, if there was any project that prioritized accordingly. Luvit seems to be the one best suited to it from what I can see, so the question is... is this something you actually want? If so, I'm happy to help. Of course I'm not really sure what the project's vision and goals are (or were), so perhaps I'm envisioning something very different from what you set out to do. Defining that and then featuring it prominently somewhere might be a good first step. |
Beta Was this translation helpful? Give feedback.
-
I've been thinking over a few technical challenges associated with a Luvit 3.0 and the opinions that have been stated above. Current ModularizationObviously, the modularization of luvit, lit and luvi has caused a few separate problems (luv is not part of this consideration, and should remain separate). A small portion of luvit libraries has been duplicated in multiple different places, and while not a huge problem, it makes maintenance a nightmare. Additionally, most issues with luvit tend to span more than one repository in my experience. Ideally, things wouldn't be this way. My proposal to fix this specific problem is merge luvit, luvi and lit into one single monorepo where all luvit development is centralized, and libraries can be shared throughout to prevent duplication. This would solve the below issue.
Cross CompilationLuvi is currently build hell (partially thanks to CMake, partially because of all the libraries it includes, and all of the options it supports) and can only output executables for it's native platform. First, replacing the build system without also remaking Luvi from scratch in order to deal with all of the external libraries is a non-trivial job. Zig has been thrown around as an option, but I will not overtly recommend it because of my involvement. Zig would support cross compiling luvi to essentially every platform and it's build system is more comprehensive than CMake. Second, allowing Luvi to cross compile should be rather easy if luajit is the only Lua backend that we support. Luajit supports outputting bytecode for all of it's architechtures from any native platform, the only issue would be with including every version of Luvi in a single binary so that it could be actually cross compiled. However, as long as luvi could be cross compiled, we would be able to use it to bootstrap the lit and luvit builds (as it does currently). However, rewriting Luvi is a much larger endeavour, and would require a lot of effort (probably from multiple community members). The Luvit "Official" LibrariesLuvit's libraries are birthed from the idea behind a Node.js code, but this lead to all of Luvit's built-in libraries becoming object and callback oriented. Object orientation is a special case, because a few of Luvit's structures did benefit from it. However, callbacks are not idiomatic Lua, and I believe that they should be removed (unlikely) or at least hidden (the creationix/coro-* libraries are a good example of how this looks). As far as where I stand, a rewite of all of the libraries is not a horrible option, even if it is a lot of work. The Require Situation
DocumentationLuvit's documentation sucks. And on top of the lack of documenation, a large portion of Luvit's library source code is uncommented. My proposal to fix this is either to either retrofit, or simply include in a library rewrite, documentation inline with the code as comments, this would use a tool (like ldoc or similar) to simply run over all of the code and generate the respective documentation for every library. Keeping documentation right alongside the code would allow anyone modifying the code, and the reviewers signing off on pull requests to verify that whatever changed in the code is reflected in the documentation accordingly. |
Beta Was this translation helpful? Give feedback.
-
When you say mono-repo, luvit, luvi, and lit would still be separate applications, yes? |
Beta Was this translation helpful? Give feedback.
-
Correct, it would just put all of the code in single place, so that things that need to be shared between all of them, can be. Edit: for some clarification that I didn't provide above, moving luvit, luvi and lit into one place would also serve to link their versions together, so luvit 3.1 uses luvi 3.1 and lit 3.1. |
Beta Was this translation helpful? Give feedback.
-
I really would love to drop openssl in luvi. Also several of the libraries that were added over the years aren't really used much. If there was a way to handle TLS clients without including all of openssl, I'm all for it, especially if it's portable. Part of me wonders how hard TLS 1.3 only would be in pure lua or if there is a self-contained library for only TLS 1.3. Most API servers support this by now I think so lots of use cases would stay viable. |
Beta Was this translation helpful? Give feedback.
-
I know TLS 1.3 is easier to implement, but that also means either finding another library or also implementing all of the cryptographic functions that it uses behind the scenes. Alas, any crypto library in C land is usually a pain to implement, harder to cross compile, and might not support all of the targets we want to. I'm definitely shilling Zig here, but it both has the cryptographic primitives in it's standard library (which means support for a lot more targets than we can hope to [because of libuv]) and already has a working TLS 1.2 client library which is relatively easy to deal with. If TLS 1.3 is a target, then effort would have to be made, but at least TLS 1.3 is easier to deal with. |
Beta Was this translation helpful? Give feedback.
-
I've thought about this too. It's been done in JS. For example, https://github.com/digitalbazaar/forge is a whole crypto suite. I don't know of any in Lua. I think no one is that ambitious. |
Beta Was this translation helpful? Give feedback.
-
We might want to consider rustls and see if we can bind it to luv. Rustls uses ring for crypto. We would get a modern crypto and TLS 1.2 1.3 stack. I worry about creating our own homegrown libraries and the maintenance that would bring. |
Beta Was this translation helpful? Give feedback.
-
No complaints here, especially if we end up using it as our cmake replacement. I wonder if supporting only TLS 1.2 would be good enough for now. That's more widely deployed than 1.3 anyway I think. |
Beta Was this translation helpful? Give feedback.
-
That looks like a good option too, I especially like that option if it also gives us modern crypto primitives similar to what libsodium exposes.
Agreed. It's one thing to implement sha256 in pure lua because there is almost zero maintenance for that, but all the algos needed for TLS brings the surface area big enough that there are bound to be problems that need addressing. |
Beta Was this translation helpful? Give feedback.
-
Here's my opinion, although I'm also just a random user, and I'm not sure how much this helps (most of this comment is just reiterating other people's posts). My background: I originally started using luvit because I wanted to write a discord bot in Lua, but after a while I started using it as "Lua with many nice batteries included". Following sections are roughly in order of most important/relevant to me first. Documentation
I very strongly agree with this. Additionally, I think it would be beneficial for this documentation to have some kind of machine-readable type information. This would allow users to automatically generate definitions for IDE completion (e.g. EmmyLua annotations) and/or for typed languages that transpile to Lua (e.g. TypeScriptToLua). When writing or debugging code, I find myself quite often searching for the code for libraries I'm using, but I rarely know whether they might be in lit or luvit, or even one of creationix's GitHub repositories. A lit/luvi/luvit mono-repo would definitely help here. The luvit librariesRight now, the first step to any project for me, as a luvit user, is installing the luv/dependenciesI sometimes use luvi or Honestly, I never use any Lua runtime other than LuaJIT, even when not using luvi(t), so keeping it as the only runtime seems very reasonable to me. I don't have much experience with the rest of the subject, although I can say that HTTPS client capability was a requirement for a good portion of my projects using luvit, but any HTTP server I wrote (mostly using weblit) was either only for local use or behind nginx. |
Beta Was this translation helpful? Give feedback.
-
I agree that a version of Luvi and Luvit that supports PUC Lua would be nice for anyone who might happen to need it, but it means that we would have to get rid of the assumption that code is running on LuaJIT in luvit's libraries. From a quick search: However, I do also think that luvit's libraries should undergo a refactor or rewrite to cleanse the code of the callback-oriented mess that they currently are. Doing so would also allow us to get rid of any luajit assumptions that are currently in place and either remove them entirely, or use them as optional optimizations if available. |
Beta Was this translation helpful? Give feedback.
-
change list
|
Beta Was this translation helpful? Give feedback.
-
It's been a while since any movement here, so I've decided to take some initiative and start with throwing around ideas about how a Luvit 3.0 would look. I'm specifically focusing on what exactly is going to happen to luvit's libraries. I've decided that the package split between luvit/luvit and luvit/lit is serving nobody (especially when we have the same package in both repos with one a full major version ahead) and that they should be merged into some sort of "luvit standard library". I've also taken the liberty of typing out a style guide that can keep code throughout the project consistent, mostly just to add a bit more explicitness with regards to keeping different kinds of things separated (classes, namespaces, etc.) For now all I am doing is mapping out how functions, classes, etc. should be laid out (with a little bit of type information) but I'm sure the prototypes will eventually start having actual code. I would also like to take the chance while prototyping these libraries to at least document each function with some form of inline documentation (currently EmmyLua) so that even if we don't end up hosting documentation, we don't fall into the pit 2.0 has where the effort is a monumental task. This effort is documented in https://github.com/truemedian/luvit-api-design and contributions would be welcome, especially towards:
If you have a proposal, please create an Issue about it. If you would like to contribute to the growing list of prototyped libraries, PRs are welcome. I would like to use the current state of luvit as a template, but there are obviously some things that need to change. |
Beta Was this translation helpful? Give feedback.
-
My day job for the last 2 years has been an extremely challenging role maintaining a massive openresty based hosting platform. It's given me a lot of perspective on one of the main luvit alternatives for server-side lua and how things are done and the kinds of tooling you need when working on a team of professionals keeping massive enterprise systems online. I think for luvit 3.0 to flourish we need to first agree on the problem that it's trying to solve. Some ideas of architectural/product directions we could take luvit (apart from the general cleanups discussed here already):
These are just ramblings, feel free to ignore anything you find whack or offensive and keep on doing whatever makes you happy. The one takeaway is I think we need a clear mission for whatever direction(s) this project goes. Do we optimize for quick scripts for fun, do we optimize for discord bots, do we optimize for webservers? Do we target teams of professionals with strict software engineering processes or do we target individuals hacking on stuff during nights and weekends for fun? Do we really want luajit or even lua? Do we want to integrate with existing package ecosystems or maintain or own? Where do we want to innovate, what's the value proposition? |
Beta Was this translation helpful? Give feedback.
-
Hey all, Another lurker here with some thoughts. Thanks for all your hard work on the luvit ecosystem! Background: my relevant professional experience is mostly in Node and Go, but I've also used Lua/Fennel with Neovim and Love2d as well as Deno and Bun.
I would probably lean towards focusing on LuaJIT unless the effort to support both LuaJIT and PUC Lua was insignificant. The performance and FFI of LuaJIT is such a big pull that it seems to still be the preference for most of the major Lua projects (OpenResty, Love2d, Neovim).
I don't have enough context on this but it seems like documentation, examples and tutorials are probably the number one pain point. Would it not be more pragmatic to do an incremental move to 3.0 that includes documenting and cleaning up 2.0? I feel like major re-writes always take more time than expected, but the value of some documentation, tutorials and examples is immediate. I would be happy to spend some regular time contributing to this myself. I think the suggestion to use EmmyLua/LuaCATS annotations would be a good place to start.
I definitely have to second this. The ease of installation and the ability to easily build and package applications are part of the value add that Deno and Bun provide over Node, and what makes Go and Love2d appealing.
I can understand this. I would also be interested as a potential contributor to know how I could help the project and take some of the maintenance burden off. Do you accept contributions to the luvit.io repo?
I'd second this along with keeping the versions in sync.
I think would be a great addition (but possibly a lot of work and not for now). I'd definitely use lit over luarocks if I could use existing luarocks dependencies. In general, given that the lua community is small, I think playing nicely with the rest of the ecosystem is pretty important so reduce friction for those coming to luvit (e.g. LuaLS, luarocks, etc).
I can offer one perspective on this. I think the appeal of luvit is that it's expressive as Javascript but as performant and resource efficient as go. The tradeoffs with Lua are:
I think one killer feature that luvi/lit could offer would be a way to unify some of these things (like building and dependency management). I would be extremely happy with a situation where I could install love2d as a lit library and build a game or install luvit as a lit library and build a server or build a neovim plugin and publish with lit (I'm aware that this is likely a massive undertaking). |
Beta Was this translation helpful? Give feedback.
-
The idea of releasing a new major version of luvit with breaking changes to fix outstanding issues or to address some of its shortcomings comes up occasionally. We recently chatted again about this in Discord. I think it would be good to have a place here for people to share any thoughts on the subject.
I will share my ideas in an independent post below this one. Please do not hesitate to share your own. Thanks.
Beta Was this translation helpful? Give feedback.
All reactions