4 ms·

Lua is very similar to Python (with more Javascript and Scheme, perhaps), but with real lambdas and tail calls. It's a different language with different trade-o

Lua is very similar to Python (with more Javascript and Scheme, perhaps), but with real lambdas and tail calls. It's a different language with different trade-offs (it's standard library is tiny; embedding is its primary niche), but its dev team very much shares Guido's sentiment of "keep it simple and don't clutter the core language trying to make it everything to everyone". If you want to see the parallel evolution of language with very similar values but a slightly different set of features, it's a good one to check out.

stcredzero 17y ago
Lua is also impressively fast!
- silentbicycle 17y ago
  I think Lua's biggest assets are how easily it can be used with C (which is where a lot of the speed comes from), and how incredibly portable it is. The language is freaking tiny, it will run on anything with a C compiler, and it usually builds in just a few seconds. While it doesn't have a huge standard library, there are tons of C libraries, and writing Lua wrappers for them is dead easy. Also, LPEG (http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html) rules. Edit: That's what I meant, that you can move code over to C. That Lua itself is faster than the other major scripting languages is just a nice perk. :) (Also, there's LuaJIT, but only on i386.)
  - davidw 17y ago
    > easily it can be used with C (which is where a lot of the speed comes from) I don't think the two are necessarily related: Tcl has a great C API, but is middle of the pack in terms of its own speed. Of course a good C API is an essential 'out' for scripting languages, so that you can write stuff in C where needed. Indeed, the idea behind Tcl was to not care much about Tcl's speed, because performance critical stuff would be done in C anyway.
  - jnoller 17y ago
    Python has a good CAPI too
    - silentbicycle 17y ago
      Well, all the Lua state is contained in one Lua_state pointer, so you can run several concurrent Lua VMs without the sort of problems caused by Python's global interpreter lock. (Speaking of which, there's also ConcurrentLua (http://concurrentlua.luaforge.net/ http://concurrentlua.luaforge.net/), which adds Erlang-style message-passing concurrency.)
  - limmeau 17y ago
    AFAIK, Lua has only one numeric data type, double-precision floating-point numbers. That kind of scares me -- I like my integers integer and not approximated. Does that, in your experience, cause problems in practice? (Yes, I know that in principle, IEEE 754 Doubles can represent all 52-bit integers precisely (give or take a few bits), but still I don't feel comfortable).
    - silentbicycle 17y ago
      It hasn't been a problem for me. There are a couple arbitrary precision libraries for Lua, so I just use those when it would matter. I've used: * lbc: http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/#lbc * GMP wrapper: http://members.chello.nl/~w.couwenberg/ and there are more linked here, under "Math": http://lua-users.org/wiki/LibrariesAndBindings http://lua-users.org/wiki/LibrariesAndBindings Lua uses doubles by default, but you can change the numeric type quite easily via luaconf.h (http://www.lua.org/manual/5.1/manual.html#lua_Number http://www.lua.org/manual/5.1/manual.html#lua_Number), if you need to work on a platform for which doubles are too large, if you'd prefer to use 64-bit longs, etc. Lua is designed to be small enough that you can just include the whole language in your source tree as a library, if you need a custom version. Think of it as a 200k .dll/.so that gives your C program a scripting interface / config file parser, a generational garbage collector (for the Lua portion), and a great string and hash table library. (The standalone Lua interpreter is just a thin wrapper to add a REPL to the C API.) Lua code also works well as a data serialization format; it's very similar to JSON, and the Lua compiler has been tuned specifically for rapidly compiling data dumped as Lua literals.
      - limmeau 17y ago
        Thanks! I'll try that sometime.

stcredzero 17y ago

Lua is also impressively fast!

silentbicycle 17y ago
I think Lua's biggest assets are how easily it can be used with C (which is where a lot of the speed comes from), and how incredibly portable it is. The language is freaking tiny, it will run on anything with a C compiler, and it usually builds in just a few seconds. While it doesn't have a huge standard library, there are tons of C libraries, and writing Lua wrappers for them is dead easy. Also, LPEG (http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html) rules. Edit: That's what I meant, that you can move code over to C. That Lua itself is faster than the other major scripting languages is just a nice perk. :) (Also, there's LuaJIT, but only on i386.)
- davidw 17y ago
  > easily it can be used with C (which is where a lot of the speed comes from) I don't think the two are necessarily related: Tcl has a great C API, but is middle of the pack in terms of its own speed. Of course a good C API is an essential 'out' for scripting languages, so that you can write stuff in C where needed. Indeed, the idea behind Tcl was to not care much about Tcl's speed, because performance critical stuff would be done in C anyway.
- jnoller 17y ago
  Python has a good CAPI too
  - silentbicycle 17y ago
    Well, all the Lua state is contained in one Lua_state pointer, so you can run several concurrent Lua VMs without the sort of problems caused by Python's global interpreter lock. (Speaking of which, there's also ConcurrentLua (http://concurrentlua.luaforge.net/ http://concurrentlua.luaforge.net/), which adds Erlang-style message-passing concurrency.)
- limmeau 17y ago
  AFAIK, Lua has only one numeric data type, double-precision floating-point numbers. That kind of scares me -- I like my integers integer and not approximated. Does that, in your experience, cause problems in practice? (Yes, I know that in principle, IEEE 754 Doubles can represent all 52-bit integers precisely (give or take a few bits), but still I don't feel comfortable).
  - silentbicycle 17y ago
    It hasn't been a problem for me. There are a couple arbitrary precision libraries for Lua, so I just use those when it would matter. I've used: * lbc: http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/#lbc * GMP wrapper: http://members.chello.nl/~w.couwenberg/ and there are more linked here, under "Math": http://lua-users.org/wiki/LibrariesAndBindings http://lua-users.org/wiki/LibrariesAndBindings Lua uses doubles by default, but you can change the numeric type quite easily via luaconf.h (http://www.lua.org/manual/5.1/manual.html#lua_Number http://www.lua.org/manual/5.1/manual.html#lua_Number), if you need to work on a platform for which doubles are too large, if you'd prefer to use 64-bit longs, etc. Lua is designed to be small enough that you can just include the whole language in your source tree as a library, if you need a custom version. Think of it as a 200k .dll/.so that gives your C program a scripting interface / config file parser, a generational garbage collector (for the Lua portion), and a great string and hash table library. (The standalone Lua interpreter is just a thin wrapper to add a REPL to the C API.) Lua code also works well as a data serialization format; it's very similar to JSON, and the Lua compiler has been tuned specifically for rapidly compiling data dumped as Lua literals.
    - limmeau 17y ago
      Thanks! I'll try that sometime.