10 ms·

Why Lua?

232 points by tlowrimore 15y ago

alanfalcon 15y ago
I took some Visual Basic programming courses in high school, some PASCAL courses in college, and then didn't program anything other than basic HTML/CSS for the next eight years. Last year I programmed an iPhone game in Lua (using the Corona SDK) and it was easy as Tau. Sure a better programmer would have finished the programming aspects in a quarter the time it took me, but I started by looking at Objective-C and I'm not sure I ever would have picked it up without some kind of formal training. Contrast with Corona/Lua, where I watched a few eight minute videos on YouTube and could turn around and make simple but complete programs, and more importantly completely understand what was going on within them. Reading the Lua documentation was a revelation, reading Apple's was a headache. Why Lua? http://itunes.apple.com/us/app/beat-boxes/id460798042 http://itunes.apple.com/us/app/beat-boxes/id460798042
- sixcorners 15y ago
  Doesn't Apple forbid applications built using things like this?
  - deleted 15y ago
    [deleted]
  - evgen 15y ago
    As long as you are not running code that is downloaded after app install (e.g. either embedded in the app itself or entered by the user from the keyboard) you are good to go. This mod to the previously ominous app store policies is used by quite a lot of applications.
hythloday 15y ago
I love Lua, but when I read statements like this: >>> In Python, you might __import__('...')' some module and then the variables of the return value would be accessed like vars(module) it makes me wonder if the author is just unfamiliar with Python (and by extension, any language other than Lua) or if they're deliberately misrepresenting other languages to make Lua look good (which it definitely doesn't need).
- ktr 15y ago
  Sorry, I would actually consider myself quite proficient in Python. What I was trying to [unsuccessfully] show was that the underlying mechanics of Python's import mechanism are different then, say, Python's dict or list implementations. Whereas in Lua everything really is just a table. I ran into this (in Python) when I was trying to dynamically import code based on command line arguments and access the functions in said script as strings. So in Lua, you just `x = require"script" ; x["fn"]` whereas in Python you sort of need to know this information up front unless you go through the machinations I outlined in the article. But this was obviously a poorly written part of the article that could use improvement. [EDIT] typos [EDIT2] less arrogance :)
  - hythloday 15y ago
    Hey, thanks for the reply, I do see your point now--I thought you were referring to the usual case of importing modules. It's true that Python modules aren't implemented in terms of dicts or lists and that Python is a larger language than Lua, so I think I completely agree with the point you were making. :) For future reference, I'd implement your dynamic module importer like this: def dynamic_import(name): import imp return imp.load_module(name, *import.find_module(name)) os = dynamic_import("os")
    - ktr 15y ago
      Thanks for the pointer! I'll have to keep that in mind.
groovy2shoes 15y ago
Good article, but one nitpick: not everything in Lua is a table. Tables are a versatile data structure that can be used as arrays, dictionaries, objects, etc. However, Lua provides many types besides tables: numbers, booleans, closures (functions), strings (which are interned), coroutines, and something called userdata (which are typically pointers to something implemented in C). Another cool thing about Lua, which was mentioned only briefly in the article, is proper tail-call optimization (TCO) like you'd find in Scheme. TCO makes expressing recursive algorithms nicer because you don't have to worry about blowing your stack. Lua's design philosophy -- giving the programmer a handful of basic yet powerful features -- makes it somewhat Schemy. I suspect that Lua is about as close as you can get to a ball of mud before becoming Lisp.
- silentbicycle 15y ago
  Lua has a lot of depth to explore (TCO, coroutines, prototypes, ...), but the language has been carefully designed to only really be like JSON, if that's all you need. The advanced parts stay out of the way.
- jballanc 15y ago
  To nitpick your nitpick: in Lua tables are the only composite data structure. Everything you listed is either atomic or opaque (you can hide composite datatypes in userdata, but you can't introspect the values). If you think about it, this is very similar to C where the only composite datatype is a struct (arrays are just sugar on pointer arithmetic). In fact, I think if you wanted to make a scriptable dialect of C, you'd create Lua. Of course, by being simple, add in dynamic typing and first-class functions, and Lua does feel a bit like Scheme's kid brother. Or, rather, Lua (in my mind) reveals how C and Scheme aren't so far apart after all!
  - groovy2shoes 15y ago
    Yes, tables are the only composite data type in Lua. But it's not fair to say that everything is a table. Compare with Smalltalk or Ruby where everything is an object, even types that are not usually viewed as composites.
simon 15y ago
The article seemed a little short for me, but then I am actively trying to select between Lua and TCL for some personal scripting projects. There are many fine features with each language and few downsides, so the selection process is hard. Of course, that's a nice problem to have. TCL is ahead by a nose at this point with Unicode support baked in (vs. using a library) and file system handling built in (again vs. using a library).
- groovy2shoes 15y ago
  Tcl is an interesting little language as well, and the niche it was created for is similar to the one Lua was created for. The biggest advantages that Lua has over Tcl, off the top of my head, are speed and lambdas. Tcl's semantics make it very hard to optimize because it is stringly typed (with some bytecode and value specialization in the background, but with conversions between strings and other values as needed). Tcl's file system interface is definitely an advantage if you're trying to avoid third party libraries. However, depending on what you need to do with Unicode strings, Lua's strings are "8-bit clean" and have no difficulty storing Unicode characters; Lua's string functions (the pattern-matching functions in particular) aren't Unicode aware.
  - bch 15y ago
    Tcl has lambdas (anonymous functions): http://wiki.tcl.tk/4884 http://wiki.tcl.tk/4884. As of 8.6 (currently in beta), it also has coroutines, and has a non-recursive engine (stackless) among other niceties.
    - groovy2shoes 15y ago
      Shows how long it's been since I last used Tcl! Still, Tcl's anonymous functions aren't quite what many people consider to be lambdas: % set inc {x {expr $x + 1}} % apply $inc 1 2 % apply $inc 1 2 % $inc 1 invalid command name "x {expr $x + 1}" % inc 1 1 This works fine with `apply`, but if you treat it like a normal function, it does some strange things. Conversely, functions that are defined with `proc` aren't compatible with `apply` unless you wrap them up. I'm not saying it's inadequate, just that the anonymous functions don't quite work how you expect lambdas to work.
chubot 15y ago
Why isn't Lua more widely used? One reason is a consequence of it being an embedded language. Lua has had 5 major versions which are very incompatible with each other. You're just supposed to stick with the previous version until you upgrade your code. I read all the Lua papers, and they are quite fond of "getting it right" (which is refreshing). They will break things to get it right, whereas other languages stick with all their old design warts in the name of compatibility. I like this approach, but it comes at the expense of popularity. Compare Lua with Python, which has had basically 1 major version for 20 years Python 1.x are all compatible with 2.x -- that was a license change; and Python 3 is having adoption troubles which proves the same point. Python 3 was the chance to "get things right", or fix old design warts, but you can see what a big impact it's having on adoption, fragmentation of libraries, etc. The other reason is that embedding a language isn't as common a use case as a scripting language. I've tried to write stuff in Lua rather than Python, but really Python's "batteries included" philosophy just kills any advantage Lua has. The main reason I would like Lua is so you can distribute stable (small) executables... but when you're starting out Python is a lot easier. You don't want to download LuaSocket or whatever and mess with the build system.
- 6ren 15y ago
  Is ability to break compatibility due to being embedded? I recall that MS ships with each game the exact version of DirectX it need, so they are free to improve it without being hamstrung by back-compatibility.
- silentbicycle 15y ago
  It's easier to break reverse compatibility when your whole language is a 200k DLL and MIT Licensed. If people need to stick with version 4.0, it's realistic to maintain an in-house fork.
- moe 15y ago
  Why isn't Lua more widely used? I think the major, overwhelming reason is because it has no standard library, much less a package-ecosystem such as RubyGems or Python eggs.
gregholmberg 15y ago
Speed& Simplicity LuaJIT speeds can rival code written in C. And if you are still not getting the speed you want, see my 1st point above (Integration with C and C++ for that matter). The simplicity of Lua is, I think, really underrated. It is a good learning exercise to write some small benchmark / utility / tool in Lua so you can get an idea of how quickly you can develop, and how fast the resulting code will be. Then read through the Lua source [0] to see just how little code is required to give you that platform for your ideas. [0] http://www.lua.org/source/5.1/lua.c.html http://www.lua.org/source/5.1/lua.c.html
- loup-vaillant 15y ago
  The simplicity of any code is really underrated. Like 4 orders of magnitude underrated: http://www.vpri.org/html/work/ifnct.htm http://www.vpri.org/html/work/ifnct.htm (Long story short: a typical mainstream desktop weights more than 200 millions lines of code. The guys at the Viewpoint Research Institute can simplify it down to 20.000 lines.)
  - groby_b 15y ago
    "We have a technique to reduce the complexity by four orders of magnitude, but unfortunately can't even give a summary of that technique here". I reserve judgment till I see an actual proof of that.
    - loup-vaillant 15y ago
      The proof is not far. See their last report here: http://www.vpri.org/pdf/tr2011004_steps11.pdf http://www.vpri.org/pdf/tr2011004_steps11.pdf Also, a good deal of their code is accessible here: http://vpri.org/fonc_wiki/index.php/Installation_Guide http://vpri.org/fonc_wiki/index.php/Installation_Guide As far as I can tell, several things can explain how they fit a whole library in a single book (assuming 50 lines per page, 400 page books, 10.000 books in a library). First, the use of dedicated languages instead of C and C++ seems to explain 2 orders of magnitude. The 2 remaining ones are explained by feature creep and plain lack of reuse (in the Franck system for instance, they use a single library to draw everything, from characters in a word processor to the frames of the windows.) They also claim specific achievements: a full self-implementing compilation stack in less than 2Kloc, on top of which implementing something like Javascript or Prolog takes less than 200 lines (see http://piumarta.com/software/maru http://piumarta.com/software/maru for actual code). A Lex/Yacc equivalent in 400 lines or so (see http://www.tinlizzie.org/ometa/ http://www.tinlizzie.org/ometa/ for actual code). A Cairo equivalent that run with acceptable performance in about 500 lines. A TCP-IP stack in 160 lines, stable enough to run a web site. If half of that is true, we can effectively talk about a silver bullet. That bullet won't kill the complexity werewolf of course, but it will seriously cripple it.
meric 15y ago
In lua, the metatable is the killer feature that python doesn't have.
- gregholmberg 15y ago
  When my main language was C, I used to feel that dynamically mutating or self-modifying data structures were somewhere between black magic and heresy. I have found that being able to place arbitrary constraints on the way my programs store things in (seemingly simple) data structures has been very, very powerful.
  - sshumaker 15y ago
    metatables don't involve dynamically mutating / self-modifying data structures. They're more equivalent to javascript's prototype, except slightly more general-purpose. You can easily use them to build an OO system, among other things.
    - gregholmberg 15y ago
      Yes, I agree that Lua metatables / metamethods look and work a lot like JavaScript's prototype property. I should have been more specific when mentioning self-modifying data structures and Lua metatables in the same post. Consider: it is possible for a table to be its own metatable, and for that table to contain (pointers to) some functions that govern storing data in the table. For the non-Lua reader, these tied-to-an-event-on-a-table functions are called table-access metamethods [0], and they allow for some dangerous shenanigans. If these particular metamethods knew how to add to, rearrange, or delete from the set of callable functions already stored in the table, the subsequent layout and contents of the table could change in a non-deterministic way. Something that looks like a simple assignment/update (__newindex/__index, insert/update, or your favorite pair of terms) t[0] = "command phrase" x = t[0] could trigger wholesale reorganization of the table, including deletion or addition of new metamethods. [0] "Programming in Lua 1ed (Chapter 13. Metatables and Metamethods, 13.4 – Table-Access Metamethods)" http://www.lua.org/pil/13.4.html http://www.lua.org/pil/13.4.html edit: incomplete example
ammmir 15y ago
lua (the language and core libraries) is stable and small. many developers are attracted to node.js or rails due to the community ("look, everyone else is doing it!"), ecosystem (abundance of modules/gems to choose from), and rapid release cycles. lua seems to have more of a relaxed, niche community among game developers and scripting language embedders. i've been using lua for about a week so far, for a music player i'm building (http://cloudplay.fm/ http://cloudplay.fm/) and i'm writing the song search/ranking system in lua. it's wonderful to be able to prototype it outside the application and not have to deal with the integration until you need to. i would consider using lua on the server-side (see http://luvit.io/ http://luvit.io/ for a node.js-style interpretation, although i'd prefer coroutines instead of callbacks) but there needs to be more work on the library front. to help lua grow, i'd fix these things: - add unicode support - bring the CLI up to par with node.js (i use node as a calculator, too) - build a modern distribution that includes frequently used luarocks
- jacques_chester 15y ago
  > add unicode support This won't happen soon. Lua targets ANSI C and only ANSI C. C11 includes new character types to support unicode, but I imagine that the Lua implementers will take their time. Plus there's implications for embedded situations. If you need unicode (and most do), there are libraries and patches that do a reasonable job.
  - marshray 15y ago
    I'm fine with C-style strings, but once in a while there are things for which a bit of UTF-8 tagging would be good enough.
    - groovy2shoes 15y ago
      Lua strings aren't C-style: they're prefixed with the string length. Lua's strings are suitable enough to store UTF-8 encoded data, but none of Lua's built-in functions are equipped to process it. Unicode libraries don't need to provide a special Unicode string type, they simply need to provide Unicode-aware string processing functions.
Hexx 15y ago
On the integration front, one thing I will also add is that in .NET integrating Lua with your program feels pretty close to being a first-class citizen. Very nice.
pheon 15y ago
The reason its not so popular? IMHO because we live in a society that favors 1sec landing pages, customized per individual options, complexity that rivals air skyscrapers and shrinked wrapped ready-to-go solutions. This is not LUA. LUA is just one tool in the tool box - its not the tool box.
haberman 15y ago
The more I learn about Lua's design and implementation, the more impressed I am. It's very rare to see software that does so much with so little code. The design is extremely clean and the code is extremely fast. The C API is easy to use and gives good performance, and yet encapsulates enough of the VM's implementation that C modules are source and binary compatible with both Lua and LuaJIT, two very different implementations of Lua. Note that the C API was designed before LuaJIT was even written, so this API was designed without the benefit of seeing how different implementations of Lua might vary. The source is very readable for the most part; my only stumbling block is that their naming of types and variables is extremely terse at the cost of readability sometimes, and the extensive use of macros can sometimes can require a lot of jumping around. But Lua is an impressive achievement that I frequently refer to for design inspiration.
- sshumaker 15y ago
  Lua has great C integration, but LuaJIT's is even better. You can natively interface with C code without a recompile, just by defining the C function prototype in Lua, and using it like you would any normal lua function. Better still, LuaJIT can frequently inline the calls to C code, so there's no cross-language marshaling penalty. Check out http://luajit.org/ext_ffi_tutorial.html http://luajit.org/ext_ffi_tutorial.html
  - haberman 15y ago
    FFI is extremely cool and impressive, no doubt, but a major downside of it is that you give up memory safety. Once you import it your Lua program can SEGV the interpreter and read/write arbitrary memory in your process. Freedom from memory errors is a major motivation for using high-level languages, so this should not be given up lightly. Also, from a security standpoint it means your Lua is less sandboxed.
    - sshumaker 15y ago
      Yes, but you use it to interface with native code. Normally, you'd write Lua_Cfunctions to achieve the same behavior - and those can crash your app just as easily, since they're native code. Perhaps more so, since it's easy to screw up the stack manipulation.
munchor 15y ago
The worst problem with Lua is that arrays start at 1. That is way too bad for me to use it. I only use it to configure Awesome WM, but it sucks for everything else IMO because of "tables" starting at 1.
- sshumaker 15y ago
  It's annoying, especially if you switch between languages frequently. My first task in Lua was to build a solid collections library (modeled after Ruby's), so this issue comes up far more infrequently for me now. (e.g. I use :first(), :last(), :push(), etc instead of [1], [#length], [#length + 1])
- marshray 15y ago
  It is a minor mind shift. The kind I find alternately annoying, or a fun challenge, unpredicatbly. When I was doing Lua stuff I ended up writing some FP-style helpers and other functions for iteration. This cut down on the number of times I had to think about the table indexes (and was helpful in general).
- aeturnum 15y ago
  I've done a lot of work in Lua and haven't really found it to be an issue. As long as you stick to doing things the "lua way" (i.e. pairs / ipairs), the specific indexes matter very little. Every once in a while I'll have an, "oh yah," moment where I use the wrong index and something doesn't work, but I don't see how it's a deal breaker for anyone. There are many features of Lua that have caused me more problems (the somewhat inconsistent string conversion, for instance).
marshray 15y ago
To echo chubot: Why isn't Lua more widely used? * It lacks an easy-to-use symbolic debugger. * It lacks a first-rate IDE. * It lacks a standard way for people coming from OO/Java to define objects and interfaces. * It lacks a GUI toolkit. * It has a great set of manuals. It lacks an O'Reilly book with a woodcut animal on the cover. * Arrays indexes start at 1. Except for the last item, these are all relatively small things that are simply waiting for someone to come along and do them. This is a testament to the great design of the language. And many of these things do exist, it's just the Lua style seems to be to understate the achievements to the point that folks can't tell the big new stuff from the abandoned projects.
- corysama 15y ago
  Additionally, it is explicitly a batteries-not-included system. There are lots of libraries for Lua all over the net, but many people stop at "Python's standard library has hundreds of modules including the four I want. Lua's doesn't have the four I want." Lua's goal is to be no-fat and customizable to only what you need for your unique situation. It's even common practice for systems to cut out stuff like the standard library file I/O module if it's not appropriate for your situation.
- aeturnum 15y ago
  I also think that Lua has a perception of being an embedded-only language (which it's very good at). The biggest code bases are World of Warcraft interface modifications and other plugin architectures. The features Lua would need to be really competitive as a stand-alone language (ex: good library management[1]) are still developing. I think it has the potential to be very powerful, though. If you want to have some fun with Lua, check out LÖVE[2]. [1] http://lua-users.org/wiki/LuaModuleFunctionCritiqued http://lua-users.org/wiki/LuaModuleFunctionCritiqued [2] https://love2d.org/ https://love2d.org/
- fab13n 15y ago
  > * It lacks an easy-to-use symbolic debugger. > * It lacks a first-rate IDE. <plug>This is changing http://eclipse.org/koneki/ldt/</plug&#62 http://eclipse.org/koneki/ldt/</plug> > * Array indexes start at 1. This sounds dangerously similar to "I can't use Python because it has significant whitespaces". Developers might like or dislike it, but if you can't get over _that_, you either lack important cognitive abilities, or you're suffering from a very serious case of Asperger's/OCD. I can't imagine that someone seriously hampered by _that_ could ever digest any large API. However, I'll admit it's a bit irritating when you're frantically switching between C and Lua. > the Lua style seems to be to understate the achievements to the point that folks can't tell the big new stuff from the abandoned projects. You're right, organizing the efforts of the Lua "community" would probably be trickier than herding cats, and the Lua core team doesn't seem very interested in helping that happen. I sometimes suspect that even Lispers form a tighter community than Lua hackers...
leafo 15y ago
Lua is a great platform, but I think there are a lot of areas where it can be made more programmer friendly. That's why I wrote http://moonscript.org/ http://moonscript.org/
- nilved 15y ago
  MoonScript is just fantastic. List comprehensions and OOP are very welcome additions to Lua.
- rlander 15y ago
  I was about to mention how cool Moonscript is, but you beat me to it. =) Thanks for the awesome project!
- evanlong 15y ago
  THE FOUNDER OF APEDICK.COM. YOU ARE MY HERO!!!
- zvrba 15y ago
  Yet another language with significant whitespace and otherwise python-ish syntax. No thanks. I would have used Python if I wanted to. Plus, any source->source translator makes debugging a pain.
timmaxw 15y ago
I've used Lua for a couple of personal projects. My main objection to it is that accessing an undefined variable or member returns nil rather than throwing an exception. If you make a typo, you don't find out until you try to call or perform arithmetic on your nil value. Since inserting nil into a table just deletes that key of the table, the use site might be several steps away from the typo. Other than that, I agree with the other posters here. It's an impressively lightweight and elegant language. It's especially good for embedding: its C integration is next to none, it's easy to sandbox if you want to run untrusted code, and the interpreter doesn't use any global variables.
- sshumaker 15y ago
  You can fix that easily with a metatable. function nilguard(tbl) tbl = tbl or {} local mt = { __index = function(t,k) error("Invalid key: " .. tostring(tbl) .. "[" .. k .. "]") end } setmetatable(tbl, mt) return tbl end local myObj = nilguard({foo=10}) myObj.crap -- should raise For undefined global variables, just require("strict")
- silentbicycle 15y ago
  You can set __index on the global table's metatable. Basically: "run this hook whenever I try to access an undefined field". setmetatable(_G, {__index=function(global_env, name) print("unknown: " .. name) end})
whatajoke 15y ago
Not criicizing lua, but worth comparing to guile. > Integration with C (and C++ for that matter) Guile does it better. You can use shared memory threads in guile without any penalty. Atmost you have to allow for the garbage collector to run when inside FFI functions. But that is a small price to pay in case you need to use multiple parallel-concurrent threads with a single heap. Guile was built with FFI in mind and has an impressive history. Just take a look at guile gnome bindings. > Speed and Simplicity Guile 2 is extremely fast. Not as fast as LuaJIT, but it no reason it won't get there. As for simplicity, take a look at the partial evaluator in trunk of guile 2. > Education Guile is good old scheme. > Functional Can't get more functional than scheme :) > Everything is a Table Well, almost everything is a pair in guile. Vectors and hash-tables are trivially available. Though I recommend to sticking to functional programming in scheme style. > Consistent As before, can't get more consistent than scheme. > Portable Guile is available on n900. So there. To continue, guile has continuations (delimited or otherwise), and macros (hygienic or otherwise), both of which are effectively missing in lua. And guile offers all of this while supporting native threading with a single heap. Sweeet.
- sshumaker 15y ago
  Not sure if I'd agree that Guile's FFI bindings are better than LuaJIT's FFI. It's certainly easier to declare a function in LuaJIT - you can take the definition directly from the header file, rather than transcoding it into s-exps. Compare: (define memcpy (let ((this (dynamic-link))) (pointer->procedure '* (dynamic-func "memcpy" this) (list '* '* size_t)))) vs. ffi.cdef [[ void * memcpy ( void * destination, const void * source, size_t num ); ]] You also get the ability to add metamethods and finalizers to returned C objects (so you can use Lua's built-in GC to clean up after, for example, your FILE*). As for the speed, there's no reason that a lot of dynamic languages couldn't be as fast as LuaJIT. But none of them are even close. I wish LuaJIT was still up in the computer language shootout. The LuaJIT interpreter (with JIT turned off) is 3x faster than V8 on the PC, and faster than Java on Android. And that's the interpreter - the JITed code is way faster. Of course, macros are awesome, and a huge point in Guile's favor. On the plus side, Lua is very easy to understand, especially if you're coming from Javascript.
ww520 15y ago
Does anyone know how good is Lua's support for async IO? Especially the handling of large amount of connections and the memory footprint for each connection?
- marshray 15y ago
  I'll spare you the exact results of my recent web search, but my impression is that it seems to be a rapidly developing area. There are definitely some good libraries out there of varying scope and maturity. Lua seems to be such a good fit for this paradigm that I would bet the community is going to produce some outstanding frameworks. (Was kicking around the idea of implementing something myself.)
  - ww520 15y ago
    It would be interesting to monitor. Lua is a good fit for async programs with its coroutine support.
- ansible 15y ago
  Luvit is a port of Node.js ideas to Lua: http://luvit.io/ http://luvit.io/
- silentbicycle 15y ago
  Luasocket does async IO. It uses poll or select on Unix (calling it 'select'); I'm not familiar with what it uses on Windows. It's not "web scale", but is very easy to use, and works well enough for a couple hundred simultaneous connections. Lua's convenient C API means that wrapping libev, libuv, or libevent is really not hard, if you want to go that route. (I have a libev wrapper on github, FWIW.) The thing to keep in mind is that if you're writing high-throughput servers, you probably want to avoid parsing the network IO via Lua. While Lua strings are fine with arbitrary binary data (i.e., \0s are fine), it interns all strings; you'll have the overhead of converting every read into an atom/symbol, and it will spend a lot of time garbage collecting. (Lua makes this daring trade-off because it's usually a net win, and when it isn't, you still have the option of doing things in C instead.) Lua's great for handling all the control logic, though. Coroutines are particularly applicable there. In a nutshell: If you're good with C, and understand the issues involved with performant async IO, Lua can work very well.
forrestthewoods 15y ago
If you want fast Lua I'd recommend checking out Havok Script (http://havok.com/products/script http://havok.com/products/script). Technically it's not Lua, but rather an extremely fast virtual machine that is compatible with Lua. I worked with it when it was Kore prior to Havok's acquisition, but it was substantially faster than the base Lua. It has some excellent debugging functionality as well. No idea what it costs these days, but if you're writing Lua code and it's need to be fast I'd recommend checking it out.
JoshTriplett 15y ago
For a different perspective, take a look at http://julien.danjou.info/blog/2011/why-not-lua http://julien.danjou.info/blog/2011/why-not-lua (submitted to HN as http://news.ycombinator.com/item?id=3536131 http://news.ycombinator.com/item?id=3536131 ).
gregholmberg 15y ago
Why Lua? Because the Wikimedia Foundation has decided to use it? "Wikipedia chooses Lua as its new template/macro language" http://news.ycombinator.com/item?id=3534649 http://news.ycombinator.com/item?id=3534649 "Lua chosen as new template scripting language" http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2012-01-30/Technology_report http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/20...
deleted 15y ago
[deleted]
Angostura 15y ago
For anyone with an iPad who wants to tinker with Lua, there's there really rather nice Codea. http://twolivesleft.com/Codea/ http://twolivesleft.com/Codea/
bitcracker 15y ago
I was first disappointed ... then amazed! Disapointed because the author's link to the benchmark website lead me to the wrong impression that Lua would be almost 30 times slower than Java 7. Then I googled around and discovered the awesome LuaJit which seems to be able to compete even with C++ in performance. What I really like is Lua's code density (see samples in the Shootout's benchmarks). Very impressive! http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=lua&lang2=java http://shootout.alioth.debian.org/u32/benchmark.php?test=all... As an old LISPer and Schemer I would like to know if Lua Macros are really as expressive and powerful as Lisp macros. Some people claim this but I am not convinced (I would like to be convinced). The expressive power may be theoretically equivalent but this is also true for C and Assembler :-) The question is: Are Lua macros as easy to handle as Lisp and Scheme macros? http://stackoverflow.com/questions/323346/what-can-lisp-do-that-lua-cant http://stackoverflow.com/questions/323346/what-can-lisp-do-t...
johnx123-up 15y ago
Ask HN: 4-Lua JVM implementations, which is best? http://news.ycombinator.com/item?id=3536996 http://news.ycombinator.com/item?id=3536996

232 points by tlowrimore 15y ago

I took some Visual Basic programming courses in high school, some PASCAL courses in college, and then didn't program anything other than basic HTML/CSS for the next eight years. Last year I programmed an iPhone game in Lua (using the Corona SDK) and it was easy as Tau. Sure a better programmer would have finished the programming aspects in a quarter the time it took me, but I started by looking at Objective-C and I'm not sure I ever would have picked it up without some kind of formal training. Contrast with Corona/Lua, where I watched a few eight minute videos on YouTube and could turn around and make simple but complete programs, and more importantly completely understand what was going on within them. Reading the Lua documentation was a revelation, reading Apple's was a headache. Why Lua? http://itunes.apple.com/us/app/beat-boxes/id460798042 http://itunes.apple.com/us/app/beat-boxes/id460798042

sixcorners 15y ago
Doesn't Apple forbid applications built using things like this?
- deleted 15y ago
  [deleted]
- evgen 15y ago
  As long as you are not running code that is downloaded after app install (e.g. either embedded in the app itself or entered by the user from the keyboard) you are good to go. This mod to the previously ominous app store policies is used by quite a lot of applications.

hythloday 15y ago

I love Lua, but when I read statements like this: >>> In Python, you might __import__('...')' some module and then the variables of the return value would be accessed like vars(module) it makes me wonder if the author is just unfamiliar with Python (and by extension, any language other than Lua) or if they're deliberately misrepresenting other languages to make Lua look good (which it definitely doesn't need).

ktr 15y ago
Sorry, I would actually consider myself quite proficient in Python. What I was trying to [unsuccessfully] show was that the underlying mechanics of Python's import mechanism are different then, say, Python's dict or list implementations. Whereas in Lua everything really is just a table. I ran into this (in Python) when I was trying to dynamically import code based on command line arguments and access the functions in said script as strings. So in Lua, you just `x = require"script" ; x["fn"]` whereas in Python you sort of need to know this information up front unless you go through the machinations I outlined in the article. But this was obviously a poorly written part of the article that could use improvement. [EDIT] typos [EDIT2] less arrogance :)
- hythloday 15y ago
  Hey, thanks for the reply, I do see your point now--I thought you were referring to the usual case of importing modules. It's true that Python modules aren't implemented in terms of dicts or lists and that Python is a larger language than Lua, so I think I completely agree with the point you were making. :) For future reference, I'd implement your dynamic module importer like this: def dynamic_import(name): import imp return imp.load_module(name, *import.find_module(name)) os = dynamic_import("os")
  - ktr 15y ago
    Thanks for the pointer! I'll have to keep that in mind.

groovy2shoes 15y ago

Good article, but one nitpick: not everything in Lua is a table. Tables are a versatile data structure that can be used as arrays, dictionaries, objects, etc. However, Lua provides many types besides tables: numbers, booleans, closures (functions), strings (which are interned), coroutines, and something called userdata (which are typically pointers to something implemented in C). Another cool thing about Lua, which was mentioned only briefly in the article, is proper tail-call optimization (TCO) like you'd find in Scheme. TCO makes expressing recursive algorithms nicer because you don't have to worry about blowing your stack. Lua's design philosophy -- giving the programmer a handful of basic yet powerful features -- makes it somewhat Schemy. I suspect that Lua is about as close as you can get to a ball of mud before becoming Lisp.

silentbicycle 15y ago
Lua has a lot of depth to explore (TCO, coroutines, prototypes, ...), but the language has been carefully designed to only really be like JSON, if that's all you need. The advanced parts stay out of the way.
jballanc 15y ago
To nitpick your nitpick: in Lua tables are the only composite data structure. Everything you listed is either atomic or opaque (you can hide composite datatypes in userdata, but you can't introspect the values). If you think about it, this is very similar to C where the only composite datatype is a struct (arrays are just sugar on pointer arithmetic). In fact, I think if you wanted to make a scriptable dialect of C, you'd create Lua. Of course, by being simple, add in dynamic typing and first-class functions, and Lua does feel a bit like Scheme's kid brother. Or, rather, Lua (in my mind) reveals how C and Scheme aren't so far apart after all!
- groovy2shoes 15y ago
  Yes, tables are the only composite data type in Lua. But it's not fair to say that everything is a table. Compare with Smalltalk or Ruby where everything is an object, even types that are not usually viewed as composites.

simon 15y ago

The article seemed a little short for me, but then I am actively trying to select between Lua and TCL for some personal scripting projects. There are many fine features with each language and few downsides, so the selection process is hard. Of course, that's a nice problem to have. TCL is ahead by a nose at this point with Unicode support baked in (vs. using a library) and file system handling built in (again vs. using a library).

groovy2shoes 15y ago
Tcl is an interesting little language as well, and the niche it was created for is similar to the one Lua was created for. The biggest advantages that Lua has over Tcl, off the top of my head, are speed and lambdas. Tcl's semantics make it very hard to optimize because it is stringly typed (with some bytecode and value specialization in the background, but with conversions between strings and other values as needed). Tcl's file system interface is definitely an advantage if you're trying to avoid third party libraries. However, depending on what you need to do with Unicode strings, Lua's strings are "8-bit clean" and have no difficulty storing Unicode characters; Lua's string functions (the pattern-matching functions in particular) aren't Unicode aware.
- bch 15y ago
  Tcl has lambdas (anonymous functions): http://wiki.tcl.tk/4884 http://wiki.tcl.tk/4884. As of 8.6 (currently in beta), it also has coroutines, and has a non-recursive engine (stackless) among other niceties.
  - groovy2shoes 15y ago
    Shows how long it's been since I last used Tcl! Still, Tcl's anonymous functions aren't quite what many people consider to be lambdas: % set inc {x {expr $x + 1}} % apply $inc 1 2 % apply $inc 1 2 % $inc 1 invalid command name "x {expr $x + 1}" % inc 1 1 This works fine with `apply`, but if you treat it like a normal function, it does some strange things. Conversely, functions that are defined with `proc` aren't compatible with `apply` unless you wrap them up. I'm not saying it's inadequate, just that the anonymous functions don't quite work how you expect lambdas to work.

chubot 15y ago

Why isn't Lua more widely used? One reason is a consequence of it being an embedded language. Lua has had 5 major versions which are very incompatible with each other. You're just supposed to stick with the previous version until you upgrade your code. I read all the Lua papers, and they are quite fond of "getting it right" (which is refreshing). They will break things to get it right, whereas other languages stick with all their old design warts in the name of compatibility. I like this approach, but it comes at the expense of popularity. Compare Lua with Python, which has had basically 1 major version for 20 years Python 1.x are all compatible with 2.x -- that was a license change; and Python 3 is having adoption troubles which proves the same point. Python 3 was the chance to "get things right", or fix old design warts, but you can see what a big impact it's having on adoption, fragmentation of libraries, etc. The other reason is that embedding a language isn't as common a use case as a scripting language. I've tried to write stuff in Lua rather than Python, but really Python's "batteries included" philosophy just kills any advantage Lua has. The main reason I would like Lua is so you can distribute stable (small) executables... but when you're starting out Python is a lot easier. You don't want to download LuaSocket or whatever and mess with the build system.

6ren 15y ago
Is ability to break compatibility due to being embedded? I recall that MS ships with each game the exact version of DirectX it need, so they are free to improve it without being hamstrung by back-compatibility.
silentbicycle 15y ago
It's easier to break reverse compatibility when your whole language is a 200k DLL and MIT Licensed. If people need to stick with version 4.0, it's realistic to maintain an in-house fork.
moe 15y ago
Why isn't Lua more widely used? I think the major, overwhelming reason is because it has no standard library, much less a package-ecosystem such as RubyGems or Python eggs.

gregholmberg 15y ago

Speed& Simplicity LuaJIT speeds can rival code written in C. And if you are still not getting the speed you want, see my 1st point above (Integration with C and C++ for that matter). The simplicity of Lua is, I think, really underrated. It is a good learning exercise to write some small benchmark / utility / tool in Lua so you can get an idea of how quickly you can develop, and how fast the resulting code will be. Then read through the Lua source [0] to see just how little code is required to give you that platform for your ideas. [0] http://www.lua.org/source/5.1/lua.c.html http://www.lua.org/source/5.1/lua.c.html

loup-vaillant 15y ago
The simplicity of any code is really underrated. Like 4 orders of magnitude underrated: http://www.vpri.org/html/work/ifnct.htm http://www.vpri.org/html/work/ifnct.htm (Long story short: a typical mainstream desktop weights more than 200 millions lines of code. The guys at the Viewpoint Research Institute can simplify it down to 20.000 lines.)
- groby_b 15y ago
  "We have a technique to reduce the complexity by four orders of magnitude, but unfortunately can't even give a summary of that technique here". I reserve judgment till I see an actual proof of that.
  - loup-vaillant 15y ago
    The proof is not far. See their last report here: http://www.vpri.org/pdf/tr2011004_steps11.pdf http://www.vpri.org/pdf/tr2011004_steps11.pdf Also, a good deal of their code is accessible here: http://vpri.org/fonc_wiki/index.php/Installation_Guide http://vpri.org/fonc_wiki/index.php/Installation_Guide As far as I can tell, several things can explain how they fit a whole library in a single book (assuming 50 lines per page, 400 page books, 10.000 books in a library). First, the use of dedicated languages instead of C and C++ seems to explain 2 orders of magnitude. The 2 remaining ones are explained by feature creep and plain lack of reuse (in the Franck system for instance, they use a single library to draw everything, from characters in a word processor to the frames of the windows.) They also claim specific achievements: a full self-implementing compilation stack in less than 2Kloc, on top of which implementing something like Javascript or Prolog takes less than 200 lines (see http://piumarta.com/software/maru http://piumarta.com/software/maru for actual code). A Lex/Yacc equivalent in 400 lines or so (see http://www.tinlizzie.org/ometa/ http://www.tinlizzie.org/ometa/ for actual code). A Cairo equivalent that run with acceptable performance in about 500 lines. A TCP-IP stack in 160 lines, stable enough to run a web site. If half of that is true, we can effectively talk about a silver bullet. That bullet won't kill the complexity werewolf of course, but it will seriously cripple it.

meric 15y ago

In lua, the metatable is the killer feature that python doesn't have.

gregholmberg 15y ago
When my main language was C, I used to feel that dynamically mutating or self-modifying data structures were somewhere between black magic and heresy. I have found that being able to place arbitrary constraints on the way my programs store things in (seemingly simple) data structures has been very, very powerful.
- sshumaker 15y ago
  metatables don't involve dynamically mutating / self-modifying data structures. They're more equivalent to javascript's prototype, except slightly more general-purpose. You can easily use them to build an OO system, among other things.
  - gregholmberg 15y ago
    Yes, I agree that Lua metatables / metamethods look and work a lot like JavaScript's prototype property. I should have been more specific when mentioning self-modifying data structures and Lua metatables in the same post. Consider: it is possible for a table to be its own metatable, and for that table to contain (pointers to) some functions that govern storing data in the table. For the non-Lua reader, these tied-to-an-event-on-a-table functions are called table-access metamethods [0], and they allow for some dangerous shenanigans. If these particular metamethods knew how to add to, rearrange, or delete from the set of callable functions already stored in the table, the subsequent layout and contents of the table could change in a non-deterministic way. Something that looks like a simple assignment/update (__newindex/__index, insert/update, or your favorite pair of terms) t[0] = "command phrase" x = t[0] could trigger wholesale reorganization of the table, including deletion or addition of new metamethods. [0] "Programming in Lua 1ed (Chapter 13. Metatables and Metamethods, 13.4 – Table-Access Metamethods)" http://www.lua.org/pil/13.4.html http://www.lua.org/pil/13.4.html edit: incomplete example

ammmir 15y ago

lua (the language and core libraries) is stable and small. many developers are attracted to node.js or rails due to the community ("look, everyone else is doing it!"), ecosystem (abundance of modules/gems to choose from), and rapid release cycles. lua seems to have more of a relaxed, niche community among game developers and scripting language embedders. i've been using lua for about a week so far, for a music player i'm building (http://cloudplay.fm/ http://cloudplay.fm/) and i'm writing the song search/ranking system in lua. it's wonderful to be able to prototype it outside the application and not have to deal with the integration until you need to. i would consider using lua on the server-side (see http://luvit.io/ http://luvit.io/ for a node.js-style interpretation, although i'd prefer coroutines instead of callbacks) but there needs to be more work on the library front. to help lua grow, i'd fix these things: - add unicode support - bring the CLI up to par with node.js (i use node as a calculator, too) - build a modern distribution that includes frequently used luarocks

jacques_chester 15y ago
> add unicode support This won't happen soon. Lua targets ANSI C and only ANSI C. C11 includes new character types to support unicode, but I imagine that the Lua implementers will take their time. Plus there's implications for embedded situations. If you need unicode (and most do), there are libraries and patches that do a reasonable job.
- marshray 15y ago
  I'm fine with C-style strings, but once in a while there are things for which a bit of UTF-8 tagging would be good enough.
  - groovy2shoes 15y ago
    Lua strings aren't C-style: they're prefixed with the string length. Lua's strings are suitable enough to store UTF-8 encoded data, but none of Lua's built-in functions are equipped to process it. Unicode libraries don't need to provide a special Unicode string type, they simply need to provide Unicode-aware string processing functions.

Hexx 15y ago

On the integration front, one thing I will also add is that in .NET integrating Lua with your program feels pretty close to being a first-class citizen. Very nice.

pheon 15y ago

The reason its not so popular? IMHO because we live in a society that favors 1sec landing pages, customized per individual options, complexity that rivals air skyscrapers and shrinked wrapped ready-to-go solutions. This is not LUA. LUA is just one tool in the tool box - its not the tool box.

haberman 15y ago

The more I learn about Lua's design and implementation, the more impressed I am. It's very rare to see software that does so much with so little code. The design is extremely clean and the code is extremely fast. The C API is easy to use and gives good performance, and yet encapsulates enough of the VM's implementation that C modules are source and binary compatible with both Lua and LuaJIT, two very different implementations of Lua. Note that the C API was designed before LuaJIT was even written, so this API was designed without the benefit of seeing how different implementations of Lua might vary. The source is very readable for the most part; my only stumbling block is that their naming of types and variables is extremely terse at the cost of readability sometimes, and the extensive use of macros can sometimes can require a lot of jumping around. But Lua is an impressive achievement that I frequently refer to for design inspiration.

sshumaker 15y ago
Lua has great C integration, but LuaJIT's is even better. You can natively interface with C code without a recompile, just by defining the C function prototype in Lua, and using it like you would any normal lua function. Better still, LuaJIT can frequently inline the calls to C code, so there's no cross-language marshaling penalty. Check out http://luajit.org/ext_ffi_tutorial.html http://luajit.org/ext_ffi_tutorial.html
- haberman 15y ago
  FFI is extremely cool and impressive, no doubt, but a major downside of it is that you give up memory safety. Once you import it your Lua program can SEGV the interpreter and read/write arbitrary memory in your process. Freedom from memory errors is a major motivation for using high-level languages, so this should not be given up lightly. Also, from a security standpoint it means your Lua is less sandboxed.
  - sshumaker 15y ago
    Yes, but you use it to interface with native code. Normally, you'd write Lua_Cfunctions to achieve the same behavior - and those can crash your app just as easily, since they're native code. Perhaps more so, since it's easy to screw up the stack manipulation.

munchor 15y ago

The worst problem with Lua is that arrays start at 1. That is way too bad for me to use it. I only use it to configure Awesome WM, but it sucks for everything else IMO because of "tables" starting at 1.

sshumaker 15y ago
It's annoying, especially if you switch between languages frequently. My first task in Lua was to build a solid collections library (modeled after Ruby's), so this issue comes up far more infrequently for me now. (e.g. I use :first(), :last(), :push(), etc instead of [1], [#length], [#length + 1])
marshray 15y ago
It is a minor mind shift. The kind I find alternately annoying, or a fun challenge, unpredicatbly. When I was doing Lua stuff I ended up writing some FP-style helpers and other functions for iteration. This cut down on the number of times I had to think about the table indexes (and was helpful in general).
aeturnum 15y ago
I've done a lot of work in Lua and haven't really found it to be an issue. As long as you stick to doing things the "lua way" (i.e. pairs / ipairs), the specific indexes matter very little. Every once in a while I'll have an, "oh yah," moment where I use the wrong index and something doesn't work, but I don't see how it's a deal breaker for anyone. There are many features of Lua that have caused me more problems (the somewhat inconsistent string conversion, for instance).

marshray 15y ago

To echo chubot: Why isn't Lua more widely used? * It lacks an easy-to-use symbolic debugger. * It lacks a first-rate IDE. * It lacks a standard way for people coming from OO/Java to define objects and interfaces. * It lacks a GUI toolkit. * It has a great set of manuals. It lacks an O'Reilly book with a woodcut animal on the cover. * Arrays indexes start at 1. Except for the last item, these are all relatively small things that are simply waiting for someone to come along and do them. This is a testament to the great design of the language. And many of these things do exist, it's just the Lua style seems to be to understate the achievements to the point that folks can't tell the big new stuff from the abandoned projects.

corysama 15y ago
Additionally, it is explicitly a batteries-not-included system. There are lots of libraries for Lua all over the net, but many people stop at "Python's standard library has hundreds of modules including the four I want. Lua's doesn't have the four I want." Lua's goal is to be no-fat and customizable to only what you need for your unique situation. It's even common practice for systems to cut out stuff like the standard library file I/O module if it's not appropriate for your situation.
aeturnum 15y ago
I also think that Lua has a perception of being an embedded-only language (which it's very good at). The biggest code bases are World of Warcraft interface modifications and other plugin architectures. The features Lua would need to be really competitive as a stand-alone language (ex: good library management[1]) are still developing. I think it has the potential to be very powerful, though. If you want to have some fun with Lua, check out LÖVE[2]. [1] http://lua-users.org/wiki/LuaModuleFunctionCritiqued http://lua-users.org/wiki/LuaModuleFunctionCritiqued [2] https://love2d.org/ https://love2d.org/
fab13n 15y ago
> * It lacks an easy-to-use symbolic debugger. > * It lacks a first-rate IDE. <plug>This is changing http://eclipse.org/koneki/ldt/</plug&#62 http://eclipse.org/koneki/ldt/</plug> > * Array indexes start at 1. This sounds dangerously similar to "I can't use Python because it has significant whitespaces". Developers might like or dislike it, but if you can't get over _that_, you either lack important cognitive abilities, or you're suffering from a very serious case of Asperger's/OCD. I can't imagine that someone seriously hampered by _that_ could ever digest any large API. However, I'll admit it's a bit irritating when you're frantically switching between C and Lua. > the Lua style seems to be to understate the achievements to the point that folks can't tell the big new stuff from the abandoned projects. You're right, organizing the efforts of the Lua "community" would probably be trickier than herding cats, and the Lua core team doesn't seem very interested in helping that happen. I sometimes suspect that even Lispers form a tighter community than Lua hackers...

leafo 15y ago

Lua is a great platform, but I think there are a lot of areas where it can be made more programmer friendly. That's why I wrote http://moonscript.org/ http://moonscript.org/

nilved 15y ago
MoonScript is just fantastic. List comprehensions and OOP are very welcome additions to Lua.
rlander 15y ago
I was about to mention how cool Moonscript is, but you beat me to it. =) Thanks for the awesome project!
evanlong 15y ago
THE FOUNDER OF APEDICK.COM. YOU ARE MY HERO!!!
zvrba 15y ago
Yet another language with significant whitespace and otherwise python-ish syntax. No thanks. I would have used Python if I wanted to. Plus, any source->source translator makes debugging a pain.

timmaxw 15y ago

I've used Lua for a couple of personal projects. My main objection to it is that accessing an undefined variable or member returns nil rather than throwing an exception. If you make a typo, you don't find out until you try to call or perform arithmetic on your nil value. Since inserting nil into a table just deletes that key of the table, the use site might be several steps away from the typo. Other than that, I agree with the other posters here. It's an impressively lightweight and elegant language. It's especially good for embedding: its C integration is next to none, it's easy to sandbox if you want to run untrusted code, and the interpreter doesn't use any global variables.

sshumaker 15y ago
You can fix that easily with a metatable. function nilguard(tbl) tbl = tbl or {} local mt = { __index = function(t,k) error("Invalid key: " .. tostring(tbl) .. "[" .. k .. "]") end } setmetatable(tbl, mt) return tbl end local myObj = nilguard({foo=10}) myObj.crap -- should raise For undefined global variables, just require("strict")
silentbicycle 15y ago
You can set __index on the global table's metatable. Basically: "run this hook whenever I try to access an undefined field". setmetatable(_G, {__index=function(global_env, name) print("unknown: " .. name) end})

whatajoke 15y ago

Not criicizing lua, but worth comparing to guile. > Integration with C (and C++ for that matter) Guile does it better. You can use shared memory threads in guile without any penalty. Atmost you have to allow for the garbage collector to run when inside FFI functions. But that is a small price to pay in case you need to use multiple parallel-concurrent threads with a single heap. Guile was built with FFI in mind and has an impressive history. Just take a look at guile gnome bindings. > Speed and Simplicity Guile 2 is extremely fast. Not as fast as LuaJIT, but it no reason it won't get there. As for simplicity, take a look at the partial evaluator in trunk of guile 2. > Education Guile is good old scheme. > Functional Can't get more functional than scheme :) > Everything is a Table Well, almost everything is a pair in guile. Vectors and hash-tables are trivially available. Though I recommend to sticking to functional programming in scheme style. > Consistent As before, can't get more consistent than scheme. > Portable Guile is available on n900. So there. To continue, guile has continuations (delimited or otherwise), and macros (hygienic or otherwise), both of which are effectively missing in lua. And guile offers all of this while supporting native threading with a single heap. Sweeet.

sshumaker 15y ago
Not sure if I'd agree that Guile's FFI bindings are better than LuaJIT's FFI. It's certainly easier to declare a function in LuaJIT - you can take the definition directly from the header file, rather than transcoding it into s-exps. Compare: (define memcpy (let ((this (dynamic-link))) (pointer->procedure '* (dynamic-func "memcpy" this) (list '* '* size_t)))) vs. ffi.cdef [[ void * memcpy ( void * destination, const void * source, size_t num ); ]] You also get the ability to add metamethods and finalizers to returned C objects (so you can use Lua's built-in GC to clean up after, for example, your FILE*). As for the speed, there's no reason that a lot of dynamic languages couldn't be as fast as LuaJIT. But none of them are even close. I wish LuaJIT was still up in the computer language shootout. The LuaJIT interpreter (with JIT turned off) is 3x faster than V8 on the PC, and faster than Java on Android. And that's the interpreter - the JITed code is way faster. Of course, macros are awesome, and a huge point in Guile's favor. On the plus side, Lua is very easy to understand, especially if you're coming from Javascript.

ww520 15y ago

Does anyone know how good is Lua's support for async IO? Especially the handling of large amount of connections and the memory footprint for each connection?

marshray 15y ago
I'll spare you the exact results of my recent web search, but my impression is that it seems to be a rapidly developing area. There are definitely some good libraries out there of varying scope and maturity. Lua seems to be such a good fit for this paradigm that I would bet the community is going to produce some outstanding frameworks. (Was kicking around the idea of implementing something myself.)
- ww520 15y ago
  It would be interesting to monitor. Lua is a good fit for async programs with its coroutine support.
ansible 15y ago
Luvit is a port of Node.js ideas to Lua: http://luvit.io/ http://luvit.io/
silentbicycle 15y ago
Luasocket does async IO. It uses poll or select on Unix (calling it 'select'); I'm not familiar with what it uses on Windows. It's not "web scale", but is very easy to use, and works well enough for a couple hundred simultaneous connections. Lua's convenient C API means that wrapping libev, libuv, or libevent is really not hard, if you want to go that route. (I have a libev wrapper on github, FWIW.) The thing to keep in mind is that if you're writing high-throughput servers, you probably want to avoid parsing the network IO via Lua. While Lua strings are fine with arbitrary binary data (i.e., \0s are fine), it interns all strings; you'll have the overhead of converting every read into an atom/symbol, and it will spend a lot of time garbage collecting. (Lua makes this daring trade-off because it's usually a net win, and when it isn't, you still have the option of doing things in C instead.) Lua's great for handling all the control logic, though. Coroutines are particularly applicable there. In a nutshell: If you're good with C, and understand the issues involved with performant async IO, Lua can work very well.

forrestthewoods 15y ago

If you want fast Lua I'd recommend checking out Havok Script (http://havok.com/products/script http://havok.com/products/script). Technically it's not Lua, but rather an extremely fast virtual machine that is compatible with Lua. I worked with it when it was Kore prior to Havok's acquisition, but it was substantially faster than the base Lua. It has some excellent debugging functionality as well. No idea what it costs these days, but if you're writing Lua code and it's need to be fast I'd recommend checking it out.

JoshTriplett 15y ago

For a different perspective, take a look at http://julien.danjou.info/blog/2011/why-not-lua http://julien.danjou.info/blog/2011/why-not-lua (submitted to HN as http://news.ycombinator.com/item?id=3536131 http://news.ycombinator.com/item?id=3536131 ).

gregholmberg 15y ago

Why Lua? Because the Wikimedia Foundation has decided to use it? "Wikipedia chooses Lua as its new template/macro language" http://news.ycombinator.com/item?id=3534649 http://news.ycombinator.com/item?id=3534649 "Lua chosen as new template scripting language" http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2012-01-30/Technology_report http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/20...

deleted 15y ago

[deleted]

Angostura 15y ago

For anyone with an iPad who wants to tinker with Lua, there's there really rather nice Codea. http://twolivesleft.com/Codea/ http://twolivesleft.com/Codea/

bitcracker 15y ago

I was first disappointed ... then amazed! Disapointed because the author's link to the benchmark website lead me to the wrong impression that Lua would be almost 30 times slower than Java 7. Then I googled around and discovered the awesome LuaJit which seems to be able to compete even with C++ in performance. What I really like is Lua's code density (see samples in the Shootout's benchmarks). Very impressive! http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=lua&lang2=java http://shootout.alioth.debian.org/u32/benchmark.php?test=all... As an old LISPer and Schemer I would like to know if Lua Macros are really as expressive and powerful as Lisp macros. Some people claim this but I am not convinced (I would like to be convinced). The expressive power may be theoretically equivalent but this is also true for C and Assembler :-) The question is: Are Lua macros as easy to handle as Lisp and Scheme macros? http://stackoverflow.com/questions/323346/what-can-lisp-do-that-lua-cant http://stackoverflow.com/questions/323346/what-can-lisp-do-t...

johnx123-up 15y ago

Ask HN: 4-Lua JVM implementations, which is best? http://news.ycombinator.com/item?id=3536996 http://news.ycombinator.com/item?id=3536996