
What makes Lua tick? - da02
http://lua-users.org/lists/lua-l/2012-04/msg00331.html
======
sramsay
Lua is indeed very, very aweseome -- for all the reasons enumerated, and then
some.

But your average Rubyist/Pythonista shouldn't be fooled. The ecosystem of Lua
assumes you eat C for breakfast, and if you don't, you're going to be looking
around for easy, plug-and-play libraries and wondering why they don't exist.

They don't, because in Lua world, you either call C from Lua or embed Lua in
C. You don't throw something together in Lua using the happy friendly
libraries that others have written for your convenience (often, in C).

I see comparisons being made with Lisp here and there. The most truthful
comparison is sociological: as with the Lisp community, the Lua community
(which is very friendly, approachable, and helpful) largely assumes you're
smart enough to build it yourself. In C.

If that frightens you, you should probably go back to whatever you were doing
before.

~~~
compay
> The ecosystem of Lua assumes you eat C for breakfast

That's a bit of an exaggeration. There isn't anywhere near the number of
libraries that Python and Ruby have, nor anywhere near the general level of
quality, but you can do an awful lot without ever touching C. Reams of Lua
code have been written to script WoW by people who have no idea how to program
in C. In fact, one of the primary design objectives of Lua is to have a
language that's simple for non-programmers to learn.

> you're going to be looking around for easy, plug-and-play libraries and
> wondering why they don't exist.

That's very true. I spent the better part of a year working on open source web
development libraries in Lua but eventually gave up because nobody was using
them. There are fantastic libraries in Python and Ruby, at this point it's not
really worth reinventing the wheel just to do the same stuff, but in Lua.

The interesting thing about the Lua community is that very few people use Lua
as their primary day-in-day-out language, which leads to a distinct lack of
fanboyism. I think that's in part why so few libraries exist. The typical Lua
programmer attitude seems to be, "Why should I rewrite that in Lua when I can
just use the one written in <insert language here>?"

~~~
catwell
> The interesting thing about the Lua community is that very few people use
> Lua as their primary day-in-day-out language, which leads to a distinct lack
> of fanboyism. I think that's in part why so few libraries exist.

Yes. The fact that LuaRocks is close to its 300th library illustrates that :)

I am one of the few people who use Lua as their main language, but I still
turn to something else for things like Web development (Python + Flask). Maybe
this will change with the OpenResty + Lapis stack [1], which is IMO the most
interesting thing in Lua Web development since Mercury [2].

[1] [http://leafo.net/lapis/](http://leafo.net/lapis/) [2]
[https://github.com/nrk/mercury](https://github.com/nrk/mercury)

Lua actually has lot of libraries dedicated to interoperability with other
languages in a system (protobuf, ZeroMQ, ...), which makes it usable as part
of a SOA, so you can write your web frontends in something else and still have
most of your backend in Lua.

~~~
fingerprinter
I primarily do web stuff, apis etc. I wanted to use Lua for a new project and
basically gave up. I looked at OpenResty and Lapis and really, really wanted
to use it but it was a pain to get working and pain to keep working. Not sure
if it has matured since the last time I looked at it (2-3 months ago), but at
the time I couldn't use it without quite a bit of mucking around.

That said, I would still _love_ to use it if it was even close to ready.

~~~
catwell
It is improving fast these days. If you have used it months ago it was 0.0.1
and now it is 0.0.3. Still, those version numbers should make it clear you
should not use it in production for something serious...

OpenResty itself, on the other hand, is perfectly usable and used in
production at large websites such as Taobao (the Chinese eBay / Amazon) and
CloudFlare.

------
NelsonMinar
My favorite thing about Lua is that the language is so simple, once you figure
out one way to do something it's probably the only way. Like, say, summing up
all the numbers in a list of strings. In Perl there are many ways, in Python
there are many ways but one is right, and in Lua there's probably only one way
so once you figure it out, you're done. Simplicity is a nice thing in an
embedded tool language.

~~~
eieio
As a huge Python fan, comments like this(and many others) have made me want to
check out Lua. Is there a canonical Lua introduction out there? I'd love to
give it a try.

~~~
gebe
The PIL, [http://www.lua.org/pil/](http://www.lua.org/pil/), is as canonical
as it gets, written by the creator of Lua.

~~~
oblique63
Alternatively, there's also [http://luatut.com/](http://luatut.com/) for a
quick useful intro

------
copx
Some things to add:

* Lexical scoping * Tail-call optimization * First class functions / closures

Lua is not a functional programming language but I tend to have a large number
of closures and recursive functions in my Lua code. Lua's limited feature set
means that you end up using closures as a replacement for things which are
special features in other language.

Here is an example of a closure doing the job of C/C++'s function-scope
static:

    
    
      View.Move = (function()
        local move = {
          [Direction.up]      = View.Up,
          [Direction.left]    = View.Left,
          [Direction.right]   = View.Right,
          [Direction.down]    = View.Down
        }
    
        return function(self, direction) move[direction](self) end
      end)()
    

Note that a closure is more efficient than function-scope static here. The
static requires a "is initialized?" check every time the function gets called,
the closure does not.

~~~
anonymoushn
The features mentioned, along with coroutines and coroutine.clone, allow the
creation of more or less any control flow the user could want. It's a total
breeze to use.

Is Closure(function ... end) really an improvement over the normal IIFE look
of (function ... end)()?

~~~
copx
>Is Closure(function ... end) really an improvement over the normal IIFE look
of (function ... end)()?

Now that you say it.. no, it's not. Changed.

~~~
pygy_
Better still:

    
    
        do
          local move = {
            [Direction.up]      = View.Up,
            [Direction.left]    = View.Left,
            [Direction.right]   = View.Right,
            [Direction.down]    = View.Down
          }
    
          function View.move(self, direction) move[direction](self) end
        end

------
vor_
One problem I have with Lua is that it silently returns nil when accessing
non-existent elements. There are a few hacks around this, but the most common
only protect global access. I have to wonder why the language reports no error
in that situation given that it does report an error when comparing values of
different types (no automatic conversion) or when attempting to index nil.

~~~
pixie_
Does that make it like Objective-C because I love how accessing a null object
doesn't blow up the application. So many trivial bugs in my iOS app that would
have caused the entire application to crash are totally avoided. Unless you're
creating software for the space shuttle, avoiding null exceptions entirely is
a god send for my users.

~~~
SimHacker
Strongly disagree. You should fix trivial bugs before you ship the app, and
Objective-C silently hiding them from you makes that much harder. It's one of
the things I hate about Objective C. Makes it seem more like PHP with warnings
off.

~~~
pixie_
Why is it programmers love crashing their users for the most trival things?
What if every javascript bug crashed the website you were browsing?

~~~
SimHacker
Ethical programmers don't want to deliver programs to users that are riddled
with unknown, undetectable bugs, that silently corrupt data and make mistakes,
without being caught by testers or warning the user.

That's why it's better to be bold and crash spectacularly, instead of trying
to cover up unexpected problem by guessing. If you have an unexpected null
pointer, there is a reason, and your expectations were wrong, so there's
something bad going on that you don't know about. By silently hiding the
problem, your program may be doing the just wrong thing, and you never know
about it.

That's the problem with PHP, which has it even worse than Objective C.
Ignoring errors and guessing what to do is PHP's way of life, and it's been
the cause of countless security holes, data corruptions, and hard to diagnose
bugs.

Use lots and lots of pedantic asserts, and test thoroughly, so the production
code does not have to be riddled with labyrinths of error handling and
mitigation guessing code. Assume the APIs obey their contracts, and write APIs
with strong contracts that do what they promise. If something might return a
NULL, then test for it and handle it properly, so whoever is reading and
maintaining your code knows that you considered the possibility and thought
through the solution, and the computer doesn't have guess what to do.

Computers are notoriously bad at guessing the programmer's intentions, so
programming languages should not encourage programmers to let the computer
guess what they meant.

~~~
pixie_
I don't purposefully release software with bugs. Bugs are inevitable no matter
how good of a programmer you are. Like I said, would you rather your browser
crash on every javascript bug? Because that's how a lot of client side
software operates.

~~~
SimHacker
You're not getting it through your head, or comprehending what I am saying, so
you obviously have no experience as a professional software developer. Your
software will have a lot more bugs in it, and is a lot more likely to corrupt
your users' data, if the language you use conceals the problems from you
during development and testing, and guesses at what you want. Go back and read
what I wrote, and address those points instead of ignoring them. You are
incorrect that it's better for a programming language to hide errors, guess
what you meant, and silently corrupt data. You may think that it's convenient
for you not to have to type the extra keystrokes to check for unexpected null
pointers, but that is because you are a lazy programmer who would rather save
time and cut corners than write reliable code.

------
thinkpad20
Big fan of Lua. I have only poked around at the language, and never really
done anything significant with it, but I love how simple and powerful it is.
Every time I break out the lua programming book I wish I were using that at
work instead of python. I don't agree with every choice they've made, but it's
a great language for sure.

~~~
PavlovsCat
Same here: I once wrote a bunch of simple plugins for Renoise in LUA which was
my first (and so far last) contact with it.. I forget everything about it
since then, other than that it was very fun! I spent time learning the Renoise
API and figuring out UI stuff, LUA itself just kinda worked. It was like
jumping into cold water and finding it rather warm and pleasant.

~~~
jacques_chester
Just FYI, it's "Lua", not "LUA". It's a word, not an acronym.

~~~
scardine
Lua means moon in Portuguese (the native language of the designers).

------
sker
The thing is indeed fast. Looking at these benchmarks[1], it always makes it
to the top 10 on the tests where it appears.

Edit: Apparently, OpenResty[2] is largely responsible for the impressive
performance in those benchmarks, and Lua may be secondary.

1\.
[http://www.techempower.com/benchmarks/#section=data-r6&hw=i7...](http://www.techempower.com/benchmarks/#section=data-r6&hw=i7&test=db)

2\. [http://openresty.org/](http://openresty.org/)

~~~
bhauer
Lua is quick. OpenResty and nginx are certainly providing a very high
performance ceiling, but the test is indeed Lua code [1]. Many test
implementations for other dynamic languages are similarly provided a high
ceiling by nginx but then fail to deliver on that potential.

[1]
[https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...](https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/openresty/app.lua)

------
rsiqueira
I love the fact that Redis database can run Lua scripts, allowing very
sofisticated queries.

------
clumsysmurf
For the JVM there is a native (no JNI) Lua port called luaj:

[http://luaj.sourceforge.net/](http://luaj.sourceforge.net/)

I would be interested to hear anyone's experience using luaj on Android (thats
where I plan to use it), and how it may compare to other options like Rhino.

~~~
e12e
I'd love to hear how that works out -- generally I'd think it wasn't the best
idea -- and that you'd be better off using actual lua (via the ndk):

[http://partiallyappliedlife.blogspot.no/2009/06/lua-on-
java-...](http://partiallyappliedlife.blogspot.no/2009/06/lua-on-java-on-
dalvikvm-on-android.html)

See also:

[https://groups.google.com/forum/#!topic/android-
developers/7...](https://groups.google.com/forum/#!topic/android-
developers/7PTpMTilY4E)

and:

[https://github.com/roscopeco/deelang](https://github.com/roscopeco/deelang)

~~~
dottrap
I concur it is probably not a good idea. I know from other benchmarks that
Dalvik in general has terrible performance and adding a layer on top of it is
just going to make it worse.

[3 days ago on HN] Dalvik vs. SpiderMonkey vs. Native
[https://news.ycombinator.com/item?id=6173757](https://news.ycombinator.com/item?id=6173757)

Appcelerator originally did Rhino on Dalvik and moved to V8 after benchmarks
showed Rhino was terrible.
[http://developer.appcelerator.com/question/133696/what-
is-v8...](http://developer.appcelerator.com/question/133696/what-is-v8-what-
is-rhino-what-is-android-runtime)

------
DigitalSea
I love Lua, it's definitely underrated. My first experience using Lua was via
Indigo Rose Setup Factory, it uses Lua for scripting installer logic and the
thing I love most is how easy it is to learn (even easier than a language like
PHP). A few hours and you've grasped most basic concepts and conventions, if
you already know another language you'll find the learning curve further
reduced once more.

------
frik
Does someone use Lua for system scripting? Replacing bash and perl script on
the server looks like a good fit. If so, can you share your experience?

~~~
chalst
It's used for some configuration/ scripting in NetBSD, after Marc Balmer
pushed the idea a few years back.

Some links:

\- The Lunatik GSoC project - [http://netbsd-
soc.sourceforge.net/projects/luakern](http://netbsd-
soc.sourceforge.net/projects/luakern)

\- Marc Balmer's FOSDEM'13 paper -
[http://www.netbsd.org/~mbalmer/lua/lua_config.pdf](http://www.netbsd.org/~mbalmer/lua/lua_config.pdf)

I gather that the principal virtues of Lua for this purpose are:

1\. Lua tables have a nice syntax

2\. Lua's load function is very fast

3\. Lua has a small, well-tested trusted code base

4\. It has a sane semantics for dynamic loading

------
cageface
If I needed an embedded scripting language for a project I'd reach for Lua
without a second thought.

I've been strongly tempted to use it for actual core app development but every
time I look at it the scarcity of common libraries compared to something like
Ruby or Python cools me off.

~~~
frik
It would be great if one could use Lua as general purpose language. The
missing part is the lack of a bigger official standard library. Several addon
libraries that try to fill the gap are outdated, unmaintained and/or not of
the same high quality code as Lua and it's official libraries. The Lua
community would also benefit from an website that has unified documentation
and comment functionality like php.net and Ruby Gems or Node.js NPN repository
functionality. (I know Lua has a Wiki and repository ...but sadly, they look
very dated, its features are from last century). Using Lua as embedded
language is great though, especially with LuaJIT2 it is top notch. Interfacing
with C is easy. C++ requires a bit of research as there are several
possibilities (e.g. third party wrappers).

~~~
justincormack
I don't think it needs an official standard library, just a community agreed
and supported one which is well maintained.

------
malkia
coroutines in lua a great for game development. Also the reference, luajit and
one more commercial that I've seen are all based on Lua state object, rather
than global data (python?).

And luajit is more alien technology than common lisp :)

~~~
da02
When you say "alien tech", do you mean "highly advanced" or "very
different/hard to understand"?

~~~
spc476
It just works (for code written to Lua 5.1; it's about 95% compatible with Lua
5.2, which changed how modules work) and can pretty much replace Lua (either
the standalone executable, or linking it as a library). The "alien tech"
probably comes from how it works, converting Lua to native code. I can't say
how difficult to understand, since I haven't really looked into the internals,
but from what I understand, Mike Pall created a new way of looking at assembly
language as part of LuaJIT.

~~~
da02
Thanks! It's also amazing how he did it with little resources compared to
other projects.

------
ANTSANTS
The title is misleading. I was expecting some kind of discussion of Lua's
implementation, not yet another list of reasons why Lua is cool.

------
ulisesrmzroche
I remember people used Lua to write WoW mods, but that's about it. Anything
significant written in Lua?

~~~
Elv13
VLC, MySQL (and MySQL Workbench), Wireshark, AwesomeWM, NMAP, NGINX, Ogre,
CEGUI (and most corporate game engines), OpenWRT, Recent TI calculator (bye
bye TI basic)

Many more, but it is what come to my mind right now

~~~
dottrap
Wikimedia Foundation (Wikipedia) just adopted and rolled out Lua for its
scripting language for MediaWiki end users.

~~~
justincormack
You can browse the Lua code on Wipkipedia here
[https://en.wikipedia.org/wiki/Special:PrefixIndex/Module](https://en.wikipedia.org/wiki/Special:PrefixIndex/Module):
- there is a visual editor, test runner and module system.

------
microcolonel
I prefer scheme for an extension and wrapping language, but I can see how
LUA's paradigm could be the fisher price buttons non-coders need.

~~~
snogglethorpe
Scheme's a very decent language too, but so far I haven't found any scheme
_implementations_ out there which are anywhere near as good as Lua—small,
portable, highly efficient, robust, easy to integrate [with the "underlying"
program], well maintained, good and active community, etc—for this space. The
most popular scheme implementations tend to be enormous, despite the
language's historical reputation as a "small" language.

Lua's a great language, but the amazingly good implementation is as much (or
more) a factor than the language itself.

------
oakaz
I wrote some Lua couple of years ago but can't see any reason to use it since
from that time.

