Strings operations is a tricky part though.

It's easy to slow the code down with "obvious" coding - which is a bad thing in a language.

Some other operations like metatable lookup might not be always the fastest.

But overall the convenience of having a 700K source tarball that compiles on any ANSI C into a modern language blows all these concerns away for my use. And the performance-critical parts can be easily pushed down to C. If they are not premature optimizations to begin with.

How are string ops tricky in Lua? Patterns and table.concat can get a lot done, and when you need more power, there's LPEG (which is also quite speedy).

"Patterns and table.concat can get a lot done" - sure. but it is may feel somewhat backasswards :-)

$ time lua -e 's="";for i=1,100000 do s=s.."-";end'

real 0m1.292s user 0m1.029s sys 0m0.108s

$ time lua -e 't={};for i=1,100000 do table.insert(t,"-");end; s=table.concat(t,"")'

real 0m0.284s user 0m0.062s sys 0m0.077s

times are somewhat bogus since it is cygwin under win7, but they give the impression of what I am talking about.

I do not argue it is a feature very coherent with the design of the language, and the immutable strings have other good properties. But if you do intensive string ops you need to watch out not to fall into the trap of treating the strings as mutable objects.

Don't get me wrong - I like Lua a lot and use it almost on a daily basis. Just that I think the posts like this may attract some new folks to try Lua out - and they deserve to know the obvious ways they can shoot themselves in the foot in order to avoid some disappointment.

Context: Since Lua strings are immutable (and interned, like Erlang atoms, Lisp symbols, etc.), tables can be used as string buffers, and concatenation to large strings can be done in one step via table.concat. Appending to a string in a loop is slow, but that's true of any language with immutable strings.

$ time lua -e 't={};for i=1,100000 do table.insert(t,"-");end; s=table.concat(t,"")'

    0m0.05s real     0m0.05s user     0m0.01s system
    0m0.05s real     0m0.05s user     0m0.00s system
    0m0.05s real     0m0.04s user     0m0.02s system

(Times on OpenBSD/amd64 4.7, Lua 5.1.4.)

table.insert checks the table's length on each iteration, which dominates the string-handling time - len is O(lg n). If you just use the loop index (or otherwise cache it), it cuts the time in half:

$ time lua -e 't={};for i=1,100000 do t[i] = "-"; end; s=table.concat(t,"")'

    0m0.02s real     0m0.02s user     0m0.00s system
    0m0.02s real     0m0.02s user     0m0.01s system
    0m0.02s real     0m0.03s user     0m0.00s system

Changing to i=1,1000000 gave me an avg. of 0.54s and 0.22s respectively. LuaJIT is probably also considerably better. (You could also just do t = string.rep('-', 100000), but that's not the point of your benchmark.)

There is also the code reuse factor. Why learn/use yet other language if you can use javascript for both server and client?

Better yet, let's go back to using ALGOL or something. Imagine how many reusable components we could have mustered up. We'd best stop all this innovation right now before it's too late.

Hmm, browsers don't use ALGOL though, better stay with JavaScript.

Yes, but if the old geeks had been arguing like you did, the browsers would probably only support whatever language was popular on the server-side at that time.

problem is: you cannot use it for both server and client. if this were true you would've been right. with node.js you still need to be aware if you're coding client or serverside for some constructs.

Not really a problem; clients and servers always use different APIs in other languages. JavaScript is no difference.

The advantage is that you get to use the same tools for client-side development and server-side development. Testing tools, interactive development tools, editor tools, etc. When you don't have to build your toolchain twice, you can make your toolchain twice as good.

In theory. Javascript needs namespaces and modules before it will be useful for real work.

Without getting into a huge my language vs your language debate: I agree that this isn't the RIGHT attitude, but it's not about me learning Lua per say, it's a reality of writing code in the real world for real projects.

> I agree that this isn't the RIGHT attitude, but it's not about me learning Lua per say, it's a reality of writing code in the real world for real projects.

Lots of people write robust, real world code in languages they are only casually familiar with. That is how you learn a language well.

The other reality you're facing here is your career. While it is gradually slowing, our field moves quickly. You need to be constantly studying and reading and learning to be any good at it at all. The reality is: grow and keep up or stop and be left behind.

To me, a new language is an opportunity. “What insights do these people have?” “What new design patterns will I learn?” “What can I take from this to my daily coding jobs?” They excite me.

Again, I agree with you on all points. I can't count on my hands the number of languages I've tried out and written a decent bit of code in, learning things along the way. However, that doesn't translate into "I should use this platform for a business-critical application."

Seems strange to decide on node.js if that's the problem. Node.js is by far less proven than Lua.

No kidding. Lua has been used in production in industry for over 15 years.

http://www.lua.org/history.html

Is there a framework for writing asynchronous servers with Lua?

Working on it. Libev-based. It's a spare-time project of mine. I have the "portable but not particularly scalable" pure Lua and luasocket backend done (for easy development + light deployment on Windows), working on the error handling in the libev backend now.

Much of the complexity comes from error handling, not just the async IO. Erlang gets that right, too. I don't know how much error handling node.js does. (I plan on checking it out eventually, since my framework will be compared to it.)

I don't have a time frame yet. I'm also working on a compiler and a bunch of other stuff, and I'm really not a web developer, so it's been a fairly low priority.

I don't think that's what Tichy meant. That's just a wrapper library to make error handling easier in a coroutine-based event loop.

If you're not worried about being "web scale", it's not hard to write an async socket server using luasocket's sockets for nonblocking TCP IO and luasocket.select for scanning for active connections. It gets bogged down once you have > 100 or so idle connections (the usual trade-offs with select apply), but it's easy to write, very portable, and (on x86) LuaJIT is amazingly fast. Contact me if you want example code.

I've been working on an actual framework for async servers (libev-based), but haven't had much free time lately.