Re: Wikipedia Chooses Lua As Its New Template Language

[Tim Starling <tstarling@...>]

On 04/02/12 11:17, Axel Kittenberger wrote:
> Three things: Lua never looked back too much. This was also a good
> recipie to create a clean language, which releases did not break
> something? I think thats the options you get in language development,
> either you are always fully backward compatible like many others are,
> and after a while you just pile the dirt and binary gets larger and
> slower due to all compatibility checking or you get complaints about
> breaking. Compared to 4.0 to 5.0 breaking, current changes are
> negligible.

I'm not asking for much, just that math.log10 and table.maxn be
deprecated but not removed, and that they continue to be documented in
the manual. It doesn't seem unreasonable, given that Roberto
Ierusalimschy said in 2010 that 5.2.0 would be probably be released
with compatibility modes on:

http://article.gmane.org/gmane.comp.lang.lua.general/66133

> About the LuaJIT vs Lua5.2. It depends on how much CPU vs. IO impact
> you have. I suppose you might tend to the later where it JIT doesn't
> matter much, since the time gets burned in IO. Tim Caswell reported
> with his development of Luvit (https://github.com/luvit/luvit Like
> Node.JS just in Lua) that in most examples he did, he meassured twice
> as fast than Javascript due to smaller C barrier, but hardly any
> difference between vanilla Lua and LuaJIT.

I often hear that said, but I wouldn't analyse performance that way.
10ms waiting for a disk to seek doesn't cost you the same amount as
10ms of processing time. Maybe if your server costs are negligible and
all you care about is user experience, then it makes sense to optimise
for latency, but that's not the world I live in.

CPU user time is a proxy for compute cluster cost. IO latency isn't
really a proxy for cost, so it makes sense to analyse IO separately,
using different methods.

-- Tim Starling