111–120 of 142 posts
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 h…
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
"Lua chosen as new template scripting language" http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/20...
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. Th…
The simplicity of any code is really underrated. Like 4 orders of magnitude underrated: 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.)
I reserve judgment till I see an actual proof of that.
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/
Earlier quoted context omitted.
There are several server side Lua options with coroutines.
Could you name a few, alls I see are kepler based ones..
Earlier quoted context omitted.
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.
Yes, but the point is that once you've loaded FFI you have to trust 100% of the Lua. With a Lua C extension you have to trust the extension, but not the Lua that loads it.
Earlier quoted context omitted.
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…
Thanks for the info. Very informative reply. Sounds like the network handling stuff should be in the C layer. And pass the parsed message/objects back to Lua is the way to go.
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/
Earlier quoted context omitted.
Yes, but the point is that once you've loaded FFI you have to trust 100% of the Lua. With a Lua C extension you have to trust the extension, but not the Lua that loads it.
You can still sandbox it and not provide direct access to ffi to user code, only some tested ffi calls. Just like native in that way.
I even asked Mike Paul (LuaJIT author this question, and he said "That's not a viable approach for sandboxing.") http://lua-users.org/lists/lua-l/2011-02/msg01582.html