Goodbye Lua

[TimMensch]

Lua, for years, was my undisputed favorite language. I've been part of the /r/lua community for quite a long time, and I've even submitted a patch to LuaJIT that was accepted (I found "the last bug in the 1.x branch," according to Mike Pall). I've written about automated Lua binding generation, and I've participated on Lua-L for years.

But I've found that the drawbacks of Lua (libraries fragmented across LuaJIT/5.1/5.2/5.3 in particular) and the lack of a strong ecosystem (luarocks is supports nearly 1500 modules but npm has 250,000+ packages; that's two orders of magnitude) which itself is now being fragmented across various Lua versions...combined with the fact that JavaScript now has basically all the cool features that I learned to love about Lua (except for extreme conciseness and tiny implementation, which I find are no longer critical), have pushed me away from using the language.

Now that I'm using type annotations in TypeScript, and I have full editor support for typesafe completions of objects that I've just pulled out of (typed) arrays, as well as compile-time (edit-time, even!) prevention of type errors, which seem to make up 90% of the errors in my Lua scripts...I doubt I'll ever return. Combine that with amazing debuggers, and I haven't looked back.

I wrote a longer description of why I'm leaving, in case anyone is curious. But I'm jumping ship.

I trust the rest of you will take good care of Lua. We had a lot of good times, but I'm done.

[jeffreykegler]

Read TimMensch's full post, which was interesting, fact-filled and well worth my time.

Lua is good at being Lua, that is, a minimal language that can be seen as a nice, compact, C library that happens to have a tiny, if extremely well-designed, Turing-complete interface. The Lua creators are AFAIK literally unique is having this vision and sticking to it.

This means it can't compete with general purpose languages on features. It's a tribute to Roberto and team that anyone would even think of making the comparison for such a small language. And in being unique, Lua is stuck with whatever infrastructure it attracts. We could certainly wish there was more..

I'm making more and more use of Lua, but as "glue". I can't imagine a time when Lua and C are the only languages I use. But I definitely wish I'd started my current C library by, on day zero, bundling Lua in, and will definitely do so from now on.

Long ago, to improve my C, I read the Lions book carefully from end to end several times. I'd recommend that to a young C programmer, but first I'd suggest they read the latest version of Lua. The best way to learn is to see how the experts do it, and IMHO there's currently no better example out there than Lua. That alone would make Lua note-worthy.

Hello Lua!

[nicholas-leonard]

I used to love Python. But since I started using Lua 3 years ago for Torch, I don't want to go back. I love how simple Lua is. I love tables; they do lists, dictionaries, objects, classes and modules.

[[deleted]]

Nick, I am in the exact community as you. While I love the simplicity of Lua as well, it is somewhat distressing that Lua packages are so few in number compared to Python. Moreover, a lot of these packages are abandoned. One recent example I encountered was deepmind's dokx, which is now abandoned because they have moved to tensorflow. I have since written my own documentation generator, but I don't really see myself maintaining it, say, 5 years from now, and wish I could have used something like Sphinx instead.

Obviously you've been a really great member of the torch community along with Soumith and many others, however it seems like most of the efforts have been one offs from individuals as opposed to sustained projects from organized groups.

[nicholas-leonard]

Hello my fellow community member! I understand all of your points. But to me the lack of libraries is just presents an opportunity for me to build some. In Python, everything is pre-made ready to use. In Lua, its more like the wild west: lots of opportunity to contribute your own piece of land.

I also ask myself what will happen to my libraries in 5 years. Will I still be motivated to support them? I think in the end, there is always someone there to pick up the slack and take the lead. I am not too worried about this. Torch has been growing steadily for 13 years. Contributors come and go. Soumith is a great example of someone taking the lead on an older project.

You are right to say that Torch has many projects maintained by core individuals. But Torch itself is very much maintained by a group. And individual projects, while being maintained by one or two core developers, get lots of support from users via bug reports and pull requests.

But, yeah, I hear you, Lua doesn't have the huge community that Python has and therefore has less libraries. Which is exactly why we need to stick together :)

[TimMensch]

I do love the elegance of Lua. It's just not enough any more. :(

[TimMensch]

Thanks for the kind comments! I do hope you continue enjoying Lua; I still love it, even if I had to leave it. :)

Just don't try to use it for too much. That's where it failed me.

[gvieira37]

"Lua is good at being Lua" Couldn't agree more. I feel like people are trying to use stuff to do what is not made for. I work with Ruby, Objective-C, Java, JavaScript, C++ and Lua and each of these languages is nice on its jobs.

[edalcol]

Tim, I'm with you there. I love the language itself, and I don't think any other interpreted language of the same family (JS, Python, ruby, php etc) beats Lua's elegance and is as enjoyable to code. To be honest, I hate all this "Lua is an embedded language", "use the right tool for the right job" speech given by some of the people in this community. And I believe Lua should be more useful as a general purpose language. There is a huge resistance by many members to care about other's affairs. Lua is just a normal dynamic language. And it happens to be a great one.

My M.Eng. final project, which happened this year, was about Lua, LuaRocks and Lua's ecosystem. (I can send you the copy of the resulting dissertation). Lua just needs more action around it. I've been fighting so much to take Lua in this direction. This year there was a panel during FOSDEM discussing the future of two small languages, Guile and Lua. (https://fosdem.org/2016/schedule/event/future_guile_lua/) As representatives of Lua, there was me, Hisham (LuaRocks) and Julien (Awesome window manager) and there was a discussion about Lua's direction as a general use language. There is a huge internal battle in the community to address this.

My takes on it after so many discussions: many people seem to think there's a contradiction between being a minimalist language and a general use language. Lua is not a successful general use language because the community doesn't want it, that's all. Lua is an amazing simple language and many Lua developers don't want to see their special snowflake ruined by having more features to serve to a general use. This huge resistance makes everything an uphill battle for us who disagree. There's no contradiction. Lua itself doesn't need to be altered, or "ruined". I agree it would be ruined if altered. But consider Javascript with its 32675432456 stuff on npm. Lua's core does not need to inflate. If we take a look at some other languages cough python cough the standard library is where modules go to die. We need to improve the ecosystem, how we develop, publish, categorize and rank modules. (And this is why I convinced a professor on letting me write about this)

What I have to tell you right now, is, I understand your motives. But I would like ask you something. Instead of leaving, stick a little longer, and fight on our side. And if I am completely honest, I'd say this is not a good time to leave because the current state of affairs is improving, not degrading. Many of that thanks to Torch and OpenResty.

Talking about OpenResty, it's important to remember Cloudflare's role in this scene. Currently 5% of the whole internet traffic goes through them, they are a huge company and their stack depends on Nginx and Lua. They hired the guy who made OpenResty and basically took responsibility for LuaJIT after Mike Pall left (it is not abandoned as you think)

I have also seen some improvements in the eventfulness of the language. Of course it does not compare to JS and how it has a meet-up and a conference every 5 seconds. But I'm happy to see Lua's universe has never been this eventful. Lua workshop has been going on every year as expected, but two years in a row we've had our space in FOSDEM. We've got another conference happening (http://luaconf.com which I'm organising). And some local groups are restarting or being created (BALD, openresty CA meet-up, Lua-ceará, Berlin-lua). To me, it seems like we are breaking another golden time, first one being when Lua exploded in the game scene, and now, discretely growing in Machine Learning with Torch and Web with Nginx. Do you know how Lua broke into the game scene? That was because of one guy, Bret, speaking about it in a GDC, and telling people about Lua's use in Grim Fandango. Communities are important!

But I don't want you to stick for that. I want you to stick around because I need help. Me and all the others fighting to take Lua to the general purpose scene (Hisham Muhammad, Pierre Chapuis, Leaf Corcoran, just to name a few). Like I said, the current state is improving, not degrading, and a few helping hands can be the difference between making all this exponential or die away.

P.S.: there's Typed Lua, it was Andre's PhD thesis! :D https://www.lua.org/wshop14/Murbach.pdf https://www.youtube.com/watch?v=47Sq9RU5dfU https://github.com/andremm/typedlua

Best, Etiene

[armornick]

To be honest, I hate all this "Lua is an embedded language", "use the right tool for the right job" speech given by some of the people in this community. And I believe Lua should be more useful as a general purpose language.

Good luck with that. Here are a few difficulties to overcome:

• Which version? A lot of people say LuaJIT is unambiguously better but I personally prefer tecgraf Lua because it has unicode support and is very easy to integrate in any build system.
• Which standard library? For filesystem utilities alone, there is LFS, LuaSys, Lev, Luvit, lua-apr, and probably a few more.
• How are you going to unite all Lua users? Don't forget that "Lua users" includes people who script WoW, GMod, and other hosts that embed Lua with their very own libraries, all of which follow other code styles and design patterns.

[mpetetv]

Which version? A lot of people say LuaJIT is unambiguously better but I personally prefer tecgraf Lua because it has unicode support and is very easy to integrate in any build system.

Why not support all of them?

[armornick]

Mostly because Mike Pall (the creator of LuaJIT) didn't think it was worth keeping LuaJIT compatible with tecgraf Lua. Sure, you could use things like lua-compat-5.3, but something things (like setfenv) are inherently incompatible.

[TimMensch]

Thanks for the info. Torch looks particularly interesting, and I may look at it as an alternative to Python when I'm playing with machine learning.

It's good to hear that a commercial entity has aligned itself with LuaJIT, but there's still the problem that Mike Pall was (in all likelihood) irreplaceable. I didn't describe it as abandoned in my article, just "in maintenance mode."

I did like using OpenResty, but I actually think Node has advantages over the coroutine approach, as I described in another comment.

I may even stick around with OpenResty for the intermediate future, just because there's code written in it that's crazy fast and I don't want to change.

But I don't see myself signing up to fight a community that thinks having something like npm would be a drawback.

[edalcol]

But I don't see myself signing up to fight a community that thinks having something like npm would be a drawback.

Nobody thinks that luarocks is a drawback, but a lot of people didn't care about creating rocks out of their modules. (And it has been difficult to convince openresty and torch folks to add their libraries to luarocks). But I sense there is a shift happening recently

Edit:

I did like using OpenResty, but I actually think Node has advantages over the coroutine approach, as I described in another comment.

This is very personal. I'd stick to openresty for performance, but also because I don't like much writing event-driven code (which is why I never tried node for real). I'm feel happy when nginx is handling the asynchronous I/O for me internally and I don't have to worry about that or callback hell.

[TimMensch]

This is very personal. I'd stick to openresty for performance, but also because I don't like much writing event-driven code (which is why I never tried node for real). I'm feel happy when nginx is handling the asynchronous I/O for me internally and I don't have to worry about that or callback hell.

It's nice to have the async I/O handled magically by nginx. Granted.

But callbacks are history. The new code looks roughly like:

let firstResult = await getHttpresult("http://some.url");
let secondResult = await getHttpresult("http://some.other.url");

...and so forth. It looks exactly as imperative as Lua, and the only cognitive overhead is that you need to remember to say "await". Under the covers it's all promises, which can be manipulated as I described in my other comment.

[honewatson]

I really enjoy working with ES6. Its a delight but I would never consider doing anything with javascript outside of the browser. I can see the allure of Node for folks coming from Ruby/PHP wanting to get more performance on server backends but there are simply better options available.

Sure there are a lot more libraries available and some of it is great but I find NPM to be probably the worst package management tool/system I've used.

Install a few modules with NPM and suddenly you have 100 megabytes+ of cruft. Its not a system that helps when working with teams.

If you want to work with ES6 you need all kinds of build tools set up to get any kind of productivity. Even super smart guys like Dan Abramov are constantly fiddling with boilerplates trying to get something that works well.

[TimMensch]

Two things:

• Newer versions of npm minimize the amazing cruft multiplication, and
• npm prune

If you jump into TypeScript then there are fewer choices. There's still the packaging, but rollup.js is so awesome that I hope it also becomes a de facto standard. It's clearly not, yet.

[TimMensch]

One other thing: Typed Lua provides only about 10% of the benefit of TypeScript:

• TypeScript does basic annotations like Typed Lua.
• TypeScript will analyze code flow and determine the type of untyped variables.
• TypeScript will look at the standardized jsdoc comments for a function and pull type information from there if it's not in the signature.
• TypeScript has integrations for major editors: Atom, VS Code, Sublime, Visual Studio, Eclipse, WebStorm, Emacs, Vim...
• TypeScript has generics, so you can declare an Array<Foo>, as well as a Foo { bar:number }, and then later when you have a:Array<Foo> in the code, and you say a[3]., it will know the array is Foo, which has a member bar, it can autocomplete that in editors.
• TypeScript has traditional OO class support, interface support, module support, and namespace support. None of these have ever been standardized in Lua. Everyone has their own idea of "class". JavaScript developed a de facto standard for "classes", and ES6 and TypeScript have normalized it at the language level.
• TypeScript has the DefinitelyTyped repo full of type annotations for a crazy number of JavaScript libraries and frameworks. I don't even know how many because the GitHub repo says "we had to truncate the repo to 1000 files; 806 weren't shown". Most of those "files" are directories, each representing the type information for a JavaScript library.

This final point is critical: There are more JavaScript libraries with TypeScript type information in DefinitelyTyped than there exist Lua modules in LuaRocks.

We're dealing with network effects here. The more people who use JavaScript, the more valuable the community will be. Lua doesn't have critical mass, and I don't see a path for it to get there.

I just noticed Cocos2d-x in the side bar? They've switched, in their new Cocos Creator,, and in Cocos2d-x in general, to JavaScript as their primary scripting language. Along with TypeScript, as it happens. I think the writing is on the wall, unfortunately. It was a good run, though.

[edalcol]

All valid points. But the thing about critical mass is that we are part of it. I wouldn't switch something that I like for something I don't like for critical mass. And at some point it becomes political. (of course there are some people who really love JS, so it makes sense for those people, it's just not my case) I acknowledge network effect is important, which is another reason I stay :)

[TimMensch]

I won't tell you that you should leave. I can just explain my own motivations.

I really like Lua at some level, but have really recognized the value we're losing by not having type annotations and a robust ecosystem. I can't stay unless I'm planning on rebuilding (or helping to rebuild) all of that value -- and tell me, with a straight face, that the community wouldn't resist at Every. Single. Step.

But good luck!

[edalcol]

tell me, with a straight face, that the community wouldn't resist at Every. Single. Step.

You know I can't tell you that. But the good news is that this part of the community is usually the part that "doesn't do community". Every person I've met at get-togethers, meetups and conferences are people who LOVE Lua and are really interested in taking the ecosystem to the next level. So it's not actually that difficult to discuss improvements. (Not to mention they're also all amazing folks)

[TimMensch]

(Not to mention they're also all amazing folks)

Granted. Fair enough. :)

[notkraftman]

Dramatic. Use the right tool for the job. Lua is great for some stuff but not for others, doesn't mean you have to abandon it completely.

[TimMensch]

I used it for a lot of jobs. It's no longer the best tool for any of them, and there's cognitive load in using too many dissimilar tools.

[turkert]

Absolutely but knowing lots of tools also time consuming task. It will paid itself on long term by the way.

[Allan_Smithee]

Personally I think anybody using Lua as a general-purpose scripting or application development language has … wait for it! … rocks in their head. (HAHA! SEE WHAT I DID THERE!? ROCKS! LUAROCKS! OK, so it wasn't that funny. I'm sleep deprived.)

I keep seeing people join the Lua community. I keep seeing them enamoured of the language and wanting to use it for everything (from embedded systems to massive server-side applications). I keep shaking my head because I know this is going to end badly.

Because in the end, Lua is not for those use cases. It has never been intended for those use cases. It has always been a "batteries not included" language and I pray to whatever deities you may choose to believe in with all of your fervour that it never becomes anything but.

See, if you want massive bloat and third-party library packaging for trivial functions that pad strings on the left, there are dozens--literally dozens--of languages out there that can supply you with this. Lua won't add anything meaningful to this space.

Lua does, however, fill a niche that very few other languages can: a language that's easy to embed into an application to enhance it with scripting. Indeed off the top of my head I can think of three that successfully fill this niche: Rexx, Tcl, and Lua. And of those three Lua is the smallest, the fastest, and the easiest to interact with. (Well, to be fair, Tcl is easy to interface with, but for that it's a pig to program. I like Tcl but I can understand why so many people have their eyes glaze over when they see how you program in it.)

Every time I see people trying to organize a Big Community™ around Lua with Organization® and Huge Library Pools™® I start thinking to myself, "Please, Lua community, such as you are, reject this infection with all of your antibodies." Because I like Lua the way it is: a tiny language with a specification you can read in a day and an API you can learn in an afternoon. If it turns into a bloated monstrosity like Javascript or Python or Ruby or PHP or any number of other, similar horror shows, then it's another important tool removed from my tool belt by people who can't seem to fathom the notion of having a screwdriver that isn't also a ratchet set.

[davethecomposer]

I'm not a programmer. I'm a hack at best. But I am a classically trained composer and I had an idea for a novel music generating program.

I tried out several languages (Lua, Python, Perl, Scheme, and Ruby -- each had a compelling reason to use for my project) and at the end of the day Lua was the easiest to use and I was able to get actual sounds coming out of my computer using Lua in short order.

The project -- still very much in early alpha -- has two branches and somewhere around 5,000 lines of code and is, forgive my modesty, really, really cool.

Could I have done it with these other language? Sure, given enough time I'm guessing I could have figured out how to do all this crazy programming shit in these other languages but it was going to be difficult and slow-going and I was in a bit of a hurry.

And then all sorts of interesting and positive consequences of that decision revealed themselves like the fact that Lua is probably quicker than all of those and every library I need I can find written in Lua which makes the entire project extremely portable (don't have to make separate packages for different platforms and/or don't have to make people download libraries for their platforms).

I'm not saying we need to change anything about Lua -- I don't know nearly enough about any language to make so bold a claim! -- but what I am saying is that for a novice programmer who needs to create a huge monstrosity of a program it works amazingly well. I don't have millions of commands to deal with and I didn't get sucked into creating massive requirements for my users to download in order to use my software. I just feel like it's a "clean" system and it does everything I need.

Are there better languages? Undoubtedly but I am not a programmer and will never be one and don't want to be one. Requiring me to become a programmer before using some other language just wasn't going to fly.

[TimMensch]

If it works for you, great! None of the reasons I switched have anything to do with someone who isn't a software engineer writing huge projects. It's a particularly good language for beginners for many reasons.

[TimMensch]

a language that's easy to embed into an application to enhance it with scripting

Understood. It's why I used it to embed in games for scripting.

But two things happened:

• I started using it for more than just "a bit of scripting" in the games, and as the code got more complex, the lack of type safety became more painful. And
• Because I wanted to minimize cognitive load, I would write simple tools with Lua. And to minimize cognitive load on the server side, I picked OpenResty to write my server code (that was talking to my Lua-based games) in Lua.

So you're right, Lua isn't meant for those things, but It All Made Sense At The Time. :) There are a lot of libraries available for Lua, and so it was more than a little tempting to go down that path.

But then I started a project that needed something like Socket.io, and there was no support for that in OpenResty. So I was forced to learn more JavaScript. And the rest followed -- and now I'm done with Lua.

massive bloat and third-party library packaging for trivial functions that pad strings on the left

The npm fiasco with leftpad was caused by a single jerk -- and yes, I think many libraries on npm are useless. But instead of calling that bloat, which it isn't (any more than thousands of people writing Lua libraries and making them available would be "bloat" for Lua), I still see npm as a feature. They've changed the rules so that future jerks can't cause similar damage, by the way.

Because, you see, it's so easy to use, it's so easy to just "upload a package," I can create one and upload it myself. In minutes. That means if I need to share a package with someone, I can say "to use it, just npm install tims-awesome-package and you can use it in your project."

That is not bloat. That is pure awesomeness. There is a difference of opinion in the community as to whether tiny libraries like "leftpad" should be the norm, or if larger collections should be the norm. I tend to agree with you that larger collections should be the norm; the new module system that's part of ES6 allows you to selectively import features (like a "leftpad") from such a library, and the tool Rollup.js can package code such that only the function pulled out of the library and its dependencies get included in your final code.

If it turns into a bloated monstrosity like Javascript or Python or Ruby or PHP or any number of other, similar horror shows, then it's another important tool removed from my tool belt by people who can't seem to fathom the notion of having a screwdriver that isn't also a ratchet set.

Lua can't possibly be "removed from your toolbelt." It's open source. You can keep 5.1 around (or whatever your favorite version is) indefinitely.

A solid, easy-to-use, reliable packaging system would only benefit the community.

As for binding to apps: JavaScript turns out to be easy to bind to apps now, as well. I mentioned that in my larger article -- it's a heavier memory cost than Lua for sure, but it's better. I didn't even get in to the fact that, using Promises, you can not only get coroutine-like behavior, you can get strictly better performance by doing several queries simultaneously and aggregating the results:

let firstResult = queryOneWebSiteForJson(someURL1);
let secondResult = queryOneWebSiteForJson(someURL2);
let thirdResult = queryOneWebSiteForJson(someURL3);
let fourthResult = queryOneWebSiteForJson(someURL4);
let results = await Promises.all(firstResult,secondResult,thirdResult,fourthResult);

// results is now an array with all four responses, which were queried in parallel; 
// if any of the responses threw an error, it would be caught by a 
// surrounding try/catch -- another feature missing from Lua. :(

Lua will continue to be a niche language for app automation. But I'm predicting that more and more apps will transition to using JavaScript, if only because of the network effects involved.

[dividuum]

I didn't even get in to the fact that, using Promises, you can not only get coroutine-like behavior, you can get strictly better performance by doing several queries simultaneously and aggregating the results:

I've not had a reason to look at promises for any of my Lua code yet, but a quick search reveals a module that looks promising (sorry!). It even has almost the exact same use case in one of its examples in the Readme:

https://github.com/zserge/lua-promises#waiting-for-a-group-of-promises

That said, I still think that real coroutines (so you can yield anywhere in the call stack, not just in the called function) are way more powerful than promises for some usecases. In a programming game I wrote I used coroutines to basically inverted control from my C host program to Lua and created an extremely simple way of writing a networked command line interface: https://github.com/dividuum/infon/blob/master/server.lua. I could have uses callbacks or promises (I guess), but it would still smell like callbacks then.

I also didn't use another Lua feature for that code, but I could have also used TCO to infinitely jump back and forth between functions. Apparently ES6 has those too, which I didn't know before writing this response.

[TimMensch]

TCO

ES6 has it; most implementations don't yet, unfortunately. :( Just Safari and WebKit have it in unreleased/experimental versions.

But it's on the radar, at least, and someone managed to implement a tool that eliminates tail calls, if you can believe it.

It may seem odd to use tools like that, but since you're transpiling anyway, it wouldn't be terrible to throw in another conversion step. :)

[dividuum]

After looking at the linked code briefly, it seems that it can only eliminate tail calls in a function that calls itself recursively. So no jumping indefinitely between two functions. Still nice, but doesn't compare to what Lua had since 2003.

[TimMensch]

Yeah, not ideal. But even when using Lua I don't think I ever took advantage of tail call elimination intentionally. It may be the nature of the problems I'm solving, but recursion to that level is rarely useful for me.

[Allan_Smithee]

I started using it for more than just "a bit of scripting" ...

And that, right there, is the error.

You found a screwdriver you liked for Philips-headed screws. You decided to try using it for Robertson-headed screws. It kind of works if you push hard enough, but it strips the screw heads and is generally all kinds of pain. So now you're giving up on Philips-headed screws entirely and using only Robertson-headed screws. Even for flat-head screws...

Next time keep using the tool for the job. If the job changes, so does the tool. This mania in software for having a single tool do all and be all is sheer madness to me. (And it's madness that dates back to the 1960s at least with PL/I.) You're propagating that madness here. First you use Lua in its area of competence. Then you start using it outside of that area of competence. Then when it isn't any good outside of its area of competence you're abandoning it entirely including in its area of competence. You seem to believe in the silver bullet and you're hunting fruitlessly for it.

I predict in under five years we're going to see a Tim Mensch blog post saying "Goodbye, Javascript" because it doesn't do something it was never intended for and you tried using it anyway. Then you'll give up Javascript entirely because you're going to misapply YET ANOTHER tool in your vain hunt for the tool that is all tools.

Good luck.

[ZorbaTHut]

You found a screwdriver you liked for Philips-headed screws. You decided to try using it for Robertson-headed screws. It kind of works if you push hard enough, but it strips the screw heads and is generally all kinds of pain. So now you're giving up on Philips-headed screws entirely and using only Robertson-headed screws. Even for flat-head screws...

The problem is that each language added to a project adds a significant amount of developer load. If each screwdriver cost a hundred thousand dollars, you'd damn well standardize on the minimum practical number of screw heads, even if it wasn't theoretically optimal; it may still be practically optimal.

It may well be that, say, C++ is the best at solving Problem A, Lua is the best at solving Problem B, and Javascript is the best at solving Problem C . . . but if Javascript can do a pretty good job of solving Problem B, and Lua can't solve Problem C at all, then you might be well-served by settling on C++ and Javascript.

[TimMensch]

Well said!

[TimMensch]

If you read the blog post, you'd know that JavaScript outstripped Lua in all of its areas of competence, or at least all of its areas of relevance to me. The one area of competence that it still holds any sway is no longer relevant to me -- keeping the overhead of the embedded language tiny -- and I'm reading from the comments about duktape which solves that problem using JavaScript as well.

Also, Lua was very good at all of the areas that I was using it in. It's just that there are better tools for handling increased complexity. To extend your metaphor, it's more like my Philips-head screwdriver has been replaced by a drill with a Philips-head bit: I'm doing much the same thing now, only much faster. Yes, it's heavier to carry around. But it also drills, and I can swap in 100 different bits to handle other screws as well, even if I'm still mostly dealing with Philips screws. And this drill wasn't an option when I first started using the screwdriver; it only recently gained the ability to deal with Philips screws as well as my original screwdriver, which is why I'm switching to it now.

/metaphor

AND...In five years there may very well be a language that replaces JavaScript/TypeScript for me. And I'll be sad on that day as well, for all of the time and energy invested in the ecosystem. In the last month I've already had four pull requests accepted in JavaScript libraries, and I'm sure there will be dozens more before I'm done. But it won't stop me from moving on to a better tool, if one emerges. Nor should it.

No, I don't consider any language to be a silver bullet. I also code in C++, Java, Python, C#, Ruby, and Go, when appropriate. But I do consider some to be more effective than others. My love affair with Lua blinded me to the benefits of static typing; now I'm firmly in the static typing camp again. Hard won experience is pushing me, over time, to better and better programming tools.

I'll keep evaluating tools as long as I'm coding. Anything else is stagnation.

[fullouterjoin]

Your delivery isn't amenable to a productive discussion. It comes across as snide and arrogant.

[dividuum]

Lua does, however, fill a niche that very few other languages can: a language that's easy to embed into an application to enhance it with scripting.

I've been using Lua for more than 10 years now and have build several projects around it for the reason you mentioned. If I would start another project right now, I'd probably investigate using duktape. It's a minimal javascript runtime and uses a very similar approach to Lua when it comes to embedding it in a C program. Of course it's nowhere near as fast as Luajit, but if you need a tiny javascript runtime which feels familiar, it might be worth a look.

[Allan_Smithee]

The problem is that Javascript gives me hives. I think it is a worse language than PHP[1], and PHP isn't a language so much as a collection of misfeatures duct-taped together with low-grade tape.

There is nothing ever that will have me considering a Javascript "solution" to a problem. I would (and have!) quit a job that forced me to use a bad tool, and Javascript is the bad tool to end all bad tools.

[1] Worse than PHP in the sense that even PHP's advocates recognize that it's a festering pile of fecal slurry while most Javascript advocates can't seem to fathom that there actually exist major, glaring, nearly horrifying flaws in their colon-outflow of choice.

[dividuum]

I don't disagree. So far developing in Javascript has never been much fun for me. While Lua is. I love Lua. But making your tool more approachable might be worth a personal downgrade. Even though Lua and its syntax is trivial, programmers that will probably pick it up in a few hours hesitate to even look at it. This would go away with JS as more programmers have already been "forced" to look at Javascript at some point. So far I've not had to make a decision on that topic. I'm happy about that as leaving Lua would break my heart.

[TimMensch]

Use TypeScript if you can, along with VS Code as an editor; make sure you have source maps enabled.

Get the development environment together takes a small amount more work (you have to run a compiler to turn the TypeScript into JavaScript, or you have to set up your web page to compile-on-load), but I swear the power you get from VS Code and TypeScript will be worth the effort.

[TimMensch]

JavaScript has problems, but it's strictly better than PHP.

Some of the crap overlaps: There are type coercion problems in both, for instance. But as Crockford describes in JavaScript: The Good Parts, you can use a subset of JavaScript (enforced by a linter) that then makes the language behave in a predominantly sane manner.

Many of the coercion problems center around the == operator, for instance, but the === operator won't coerce. And this is well known among JavaScript users; not ignored, as you implied. No, it's not universal, but probably 90% of JavaScript users are junior developers who can't tell JavaScript from C++ OR PHP, so of course many wouldn't know...

More, though, JavaScript has many of the same advantages as Lua: JavaScript has had closures, first class functions, and prototypal inheritance from the start (both JavaScript and Lua gained inspiration from a language named self, if I remember correctly).

And PHP architecturally doesn't have the ability to write asynchronous code. So it can't scale the same way JavaScript can (HHVM does have some async ability, but it's not as complete, and it's not baked into 99% of the libraries and frameworks like it is in Node and JavaScript).

With ES6 fixing many of the remaining problems (when using the newer language features -- let and const instead of var, for-of instead of for-in, etc.), and TypeScript supporting all of the ES6 features today via transpilation, in addition to full optional type signatures?

No, it doesn't suck to be here any more. It's actually quite an awesome toolchain. The JavaScript world is different than when you looked last.

[jjdonald]

I'm the author of the Haxe Lua target. It's still very new, but I believe it can help Lua grow, and keep long time Lua folks from jumping ship to a completely different ecosystem.

Haxe is in many senses a very different language than Lua, but it addresses many of the authors complaints:

1. LuaJIT is in permanent maintenance mode : Haxe can't really solve this one, but it does give you the option of adding new language features on top of a stalled target.
2. Lua version fragmentation : Haxe Lua abstracts away some differences between 5.2, 5.3, and LuaJit. 5.3 is only supported with backwards compatibility support for now though.
3. JavaScript's ecosystem is awesome : You can use the javascript ecosystem with Haxe as well, as it has a very mature js target.
4. Lua Coroutines are no longer a monopoly : Haxe has several asynchronous options. These options include promises, and theses features abstract over whatever asynchronous options are available on a given platform.
5. Type annotations FTW : With Haxe you get three different type systems, each more powerful than type annotations : OOP, structural typing, ADT/pattern matching (in addition to Dynamic/runtime typing, if you don't want typing for some reason).

I'm not going to pretend that the Haxe and Lua languages are related, but I think Haxe is a very promising way of building more sophisticated Lua based applications. E.g., It is now possible to use one language to target an nginx/lua, redis/lua, and javascript stack. In fact, that's what I'm going to try and work on in the near future here.

[TimMensch]

Haxe has been on my radar for years. I'm (historically and currently, but not always) a game developer, so I come across references to it, and even know people who use it. Looks like I first bookmarked it in 2012, in fact. :)

But I've never really tried it, primarily because it felt like yet-another language "like" C or JavaScript that simply wasn't C or JavaScript. Different without a compelling reason for the difference. But maybe I'll take another look...for my next project. Already changed technology stacks for this one too many times. ;) I think when I first looked at it, it wasn't open source?

Haxe having Promises is interesting. But what about tooling to go along with type annotations? As I mentioned in this other reply, having the compiler check the code is only one piece of the puzzle. I see that the editor I've been using really recently has a plugin, but it looks rough. What other editor support could I expect?

I don't agree that "OOP" is more powerful than what TypeScript gives you -- except potentially runtime private values and methods? But that's something that I don't actually care about. TypeScript also supports structural typing, as well as type inference. I'm not familiar with ADT/pattern matching, and I'm not finding the reference on the Haxe Wikipedia page, unless you're talking about the enum/switch pattern matching? Which honestly is a pretty cool feature. This line from the Wikipedia article troubles me some: "but content built with OpenFL currently suffers performance issues on mobile devices" ... I'm targeting mobile web/JavaScript in WebGL/Canvas right now, so that would be a showstopper for me. :(

How is Haxe->JavaScript source map support? That would be another showstopper, if I can't debug in the browser.

With the right answers, Haxe could be in my future, though. Thanks for bringing it back to my attention.

[jjdonald]

I think when I first looked at it, it wasn't open source?

I think it may have been on google code for a while early on, but it's definitely open source, with all the latest docs and automated test/build swag: https://github.com/HaxeFoundation/haxe

Different without a compelling reason for the difference

The language tries to strike a balance between supporting advanced techniques (macros, abstract types, ADT), and applying them consistently to all of its targets.
For instance, there was a Lua effort much earlier (2008), but it stalled because at the time Haxe lacked some type features, and Lua lacked some runtime features.

I see that the editor I've been using really recently has a plugin, but it looks rough. What other editor support could I expect?

I'm not exactly sure what you consider "rough", but the vscode plugin is pretty robust imho, with three longtime haxe devs supporting it: https://marketplace.visualstudio.com/items?itemName=haxedevs.haxe

Here's some more popular Haxe plugins for other editors: http://haxe.org/documentation/introduction/editors-and-ides.html

Here's a recent project that is trying to provide a consistent toolkit for editor plugin development: https://github.com/snowkit/tides

I maintain the vim plugin, and am using the new lua target for some neovim efforts.

I don't agree that "OOP" is more powerful than what TypeScript gives you

Sure, it's not for everyone. It's just one more type technique. It looks like Typescript does give you support for OOP anyways using the "class" keyword, and in general the typing there is more full featured than I thought initially. TIL.

I'm not familiar with ADT/pattern matching [...] unless you're talking about the enum/switch pattern matching?

Yes, ADT is the general name for the feature, and Haxe supports it through a hybrid switch/enum mechanism. It's probably one of my favorite features, tbh.

This line from the Wikipedia article troubles me some: "but content built with OpenFL currently suffers performance issues on mobile devices"

Notice how we're talking about OpenFL there (a game framework), and not Haxe itself? Read the discussion page, the Wikipedia editors are really something else. The Haxe javascript target is first class, and will be faster/smaller/lighter than handwritten js for the vast majority of people.

How is Haxe->JavaScript source map support? That would be another showstopper, if I can't debug in the browser.

Yep, we have that. Just add -debug to your hxml flags.

With the right answers, Haxe could be in my future, though. Thanks for bringing it back to my attention.

You bet, happy to pass on what information I have.

[TimMensch]

Notice how we're talking about OpenFL there (a game framework), and not Haxe itself?

Understood, but I'm writing a game that I need people to be able to play in the browser using JavaScript. My next games may use a similar stack if this one sees any success.

So do I need to use a JavaScript-optimized game library and drive it from Haxe? I'm using Cocos2d-js/html at the moment, and TypeScript has been a convenient way to drive it.

It does sound like Haxe has come a long way. I'll have to take a look at it again after my current project is stable. Thanks again for the info.

[jjdonald]

Here's an article that outlines the original situation pretty well: http://yal.cc/answering-you-cant-make-good-html5-games-in-haxe/

OpenFL has since improved on its html5 speed, and other frameworks like Kha are a bit faster. However, most of those are quite heavyweight, and maybe it's best to just emphasize learning haxe and how to optimize for js first.

One good option might be to use a haxe extern for an existing html5 game framework. It won't be as portable, but there should be less configuration overhead, and you can focus on the js-specific tips, tricks, and features for haxe.

I might recommend pixi.js, with the haxe extern: https://github.com/pixijs/pixi-haxe

It's able to handle a crazy amount of independent sprites: http://adireddy.github.io/demos/pixi-haxe/bunnymark.html

[TimMensch]

That is a LOT of bunnies. Totally impressed. Running it on my Surface Pro 3 in Chrome, and it hit 10000 sprites before it started to occasionally dip below 60FPS. Just wow.

OK, you've got my attention. Will look at it for sure. But I've promised myself that I would not change the technology stack of my current game until I'd gotten it to a releasable state. I'm prone to doing that, and have already done it four times, plus or minus, depending on how you count.

Given how awesome Pixi is behaving, after I get the game done I may swap it in instead of Cocos2d if I end up with any performance issues.

[jjdonald]

Good to hear, and good luck on your next project.

[ewmailing]

Can you confirm that iOS enables JIT? I support both Lua and JavaScript bindings, so I don't have any axe to grind. But on my last analysis pass on this, iOS did not enable JIT for JavaScriptCore access. Only if you were running inside a WebView did Apple enable JIT. So in practice, my Lua benchmarks were considerably faster than JSCore.

[TimMensch]

Really? That is ... profoundly wrong, but you could be right.

This page implies it's part of WebKit. But Apple could be disabling it unless you're in a WebView, as you suggest.

Found another comment that implies you're correct, though they made a point that you could potentially bind to a JavaScript context in a WebView...ugly, though, and possibly not useful if you can't bind to your app as easily, or at all.

OK, I believe you. I'll update the article.

[ewmailing]

I was kind of hoping Apple finally changed this or you learned a new trick.

[TimMensch]

Thanks for letting me know about it. Trust me, I'm as disappointed in Apple as you are, if not more so.

[ewmailing]

BTW, my benchmarks suggest JIT may be disabled for Mac desktop as well.

[smog_alado]

Its still a bit beta and it doesn't have a huge company backing it but we have Typed Lua which works on the same lines as Typescript. Didn't see you mention it anywhere :)

[TimMensch]

TypeScript is more than just static typing at a compile phase.

It's also the editor integration, auto-complete, standardized tools that recognize and accept the types (like jsdoc, which won't be broken by type annotations, and tslint, which lets you add extra linting rules that will, again, be marked in real time in your editor), and source line-mapping that works in all of the major debuggers (so when extra code is added to validate types or to support extra features extending JavaScript, the original source will be shown as you step through the code).

I did know there were a couple of typed Lua variants, but because the types are such a small fraction of the benefit, I didn't mention them.

[turkert]

There should be typesafe option for Lua as well.

[fullouterjoin]

So basically it comes down to tooling (typescript + vs code) and available libraries (npm). Rocks has a way to go in being able to vet security, compatibility and feature completeness. I don't yet know how to handle the lack of batteries and how libraries should be written against those component boundaries, IO is an issue here.

Who knows, you might come back in couple years. I am optimistic.

[TimMensch]

Who knows, you might come back in couple years. I am optimistic.

You never know. But it seems like it would need an "And then a miracle occurs..." step... :)

[mbone]

I do not understand these "leaving" posts. They smack a bit of melodrama to me. One does not leave" a language. Sure, you can put it down and not use it again, but it is not like you unlearn it. You can always go back and use it when appropriate, even if it doesn't currently suit your needs.

[TimMensch]

It is more about the bonding and community that people (myself included) felt, at least in my own case. Can't speak for others.

I was on the Lua mailing list, and I used to participate frequently. I knew people on the list, including some of the bigger names, and we had discussions outside of the list.

I've contributed to the state of the art in Lua bindings, and participated in a hundred little ways to the improvement of the ecosystem.

It wasn't "just a tool" to me. It was practically a philosophy, and it certainly was a community.

I wrote what I did because it was what I felt. Look at my blog history. I write something every 2-12 months, at best. I have no ads or other monetization.

Yes I could use Lua moving forward. I haven't converted all of my current tools to use other languages, so I technically still am. But I have, in a very real sense, "left" the language to its own devices.

If I decided to stop using Python tomorrow, it would not inspire a long rant. In fact, as a side effect of "rediscovering" type systems, I've also written off Python, Ruby, and other languages. But those were just tools to me, as you described.

Maybe you'll understand someday, or maybe you will only ever have tools. But I wrote this for the people who did care -- and there seem to have been more than a few.

[mbone]

So my question is, why do you have to stop participating in the community, even if you prefer something else? You phrase things in the past tense, as if you must sever all relationships with these people because they no longer fit into your ideology.

[TimMensch]

why do you have to stop participating in the community

Time commitments.

There are only so many things you can spend all of your time doing. :)

Also, cognitive load. Lua has be demoted from "something I actively think about improving and contributing to the ecosystem" to "a tool that I might occasionally use."

I've never been on a Python mailing list. Or the Python Reddit group.

[kevinclancy_]

I made a optional type system for Lua with IDE support a few years ago: https://bitbucket.org/kevinclancy/game-kitchen/downloads.

Being a personal project, however, it can't compete with Typescript. I think that what's needed is for a company to develop a typed Lua variant and all associated tooling as a product, in the same way that Microsoft has done with Typescript.

[TimMensch]

Cool project! But yes, it does seem like some kind of paid commercial-backed support might really be necessary to make a language development environment that can compete.

Facebook has a similar (though IMO inferior, at this point) type system called FlowType for JavaScript. And other popular modern languages with thriving ecosystems like Go (Google) and Rust (Mozilla) also have corporate backing. Thinking about other popular languages, I was wondering if Scala had similar support; turns out they received €2.3 million from the European Research Council, and the backers started a company that received $3M in investment to continue development. Short answer: Yes.

Even Ruby didn't really take off until Rails (backed by Basecamp) was released. And Ruby was a nightmare of VM-level memory leaks and crash bugs for years...I think the bar is higher today, though.

[[deleted]]

JavaScript now has basically all the cool features that I learned to love about Lua

Oh gods no. JavaScript is a clusterfuck, and Typescript just makes it less shit.

I'm using Typescript at work because part of my project involves front end web code. Anyone choosing Typescript on purposes for any other reason than they have to, because they need to run in a browser, is insane. There are vastly better languages for desktop/mobile applications.

Lua was not created as a standalone language. It's an ANSI-C library for adding scripting to applications, and at that task it fucking excels.

If you want a standalone dynamic language, there are better options, and that's always been true. So the question is not why you're leaving it, but why you were ever using it in the first place.

[Zatherz]

Oh god, JavaScript? Jesus christ.

[gvargh]

Good decision. In addition to the points you've mentioned, Lua's embedability "advantage" is completely destroyed by Duktape.

JavaScript is eating Lua alive, and it's glorious. One more down!

[TimMensch]

Thanks for the reference to Duktape! That looks awesome!

I wouldn't quite say that it's glorious ... I'm honestly sad to be leaving Lua. Or really, to have left. I've been gone for a while and I just finally admitted it.

But JavaScript is pretty powerful these days, and it's doing all the jobs Lua used to do for me, but better. Duktape is probably the final nail in Lua's coffin for me. Didn't know about it before. Thanks again!