Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Lua?

blog.datamules.com

Post reply on HN
Print view View original

61–70 of 142 posts

Re: Why Lua?

#61

Post by haberman »

sshumaker wrote: post #55
haberman wrote: post #51

Earlier quoted context omitted.

FFI is extremely cool and impressive, no doubt, but a major downside of it is that you give up memory safety. Once you import it your Lua program can SEGV the interpreter and read/write arbitrary memory in your process. Freedom from memory errors is a major motivation for using high-level languages, so this should not be given up lightly. Also, from a security standpoint it means your Lua is less sandboxed.

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.

Re: Why Lua?

#62

Post by nilved »

leafo wrote: post #24

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/

MoonScript is just fantastic. List comprehensions and OOP are very welcome additions to Lua.

Re: Why Lua?

#63

Post by marshray »

groovy2shoes wrote: post #27
marshray wrote: post #20

Earlier quoted context omitted.

I'm fine with C-style strings, but once in a while there are things for which a bit of UTF-8 tagging would be good enough.

Lua strings aren't C-style: they're prefixed with the string length. Lua's strings are suitable enough to store UTF-8 encoded data, but none of Lua's built-in functions are equipped to process it. Unicode libraries don't need to provide a special Unicode string type, they simply need to provide Unicode-aware string processing functions.

Right. I meant "C-style" in the sense of Lua being oriented around the kind of single/multibyte encodings used with ANSI C (as contrasted with kind of the UCS-2 and UTF-16 stuff you get with Win32 and Java).

Re: Why Lua?

#64

Post by whatajoke »

sshumaker wrote: post #53
whatajoke wrote: post #49

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…

Not sure if I'd agree that Guile's FFI bindings are better than LuaJIT's FFI. It's certainly easier to declare a function in LuaJIT - you can take the definition directly from the header file, rather than transcoding it into s-exps. Compare: (define memcpy (let ((this (dynamic-link))) (pointer->procedure '* (dynamic-func "memcpy" this) (list '* '* size_t)))) vs. ffi.cdef [[ void * memcpy ( void * destination, const v…

My definition of an FFI was simply about fully supporting native threads. Simplifying FFI definitions has not been a big deal for me. It is either a few hours of work, or if more than that, then I simply use Swig.

As for finalizing arbitrary objects, please see http://community.schemewiki.org/?guile-guardian

I agree on the speed part. But guile 2 is getting better. The reason guile cannot be as blazing fast as say gambitc is their need to inter-operate with all sorts of C code. Native threading included.

Re: Why Lua?

#65

Post by groovy2shoes »

whatajoke wrote: post #49

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…

> Can't get more functional than scheme :)

Try telling that to the Haskell guys!

Re: Why Lua?

#66

Post by esrauch »

marshray wrote: post #19

To echo chubot: Why isn't Lua more widely used? * It lacks an easy-to-use symbolic debugger. * It lacks a first-rate IDE. * It lacks a standard way for people coming from OO/Java to define objects and interfaces. * It lacks a GUI toolkit. * It has a great set of manuals. It lacks an O'Reilly book with a woodcut animal on the cover. * Arrays indexes start at 1. Except for the last item, these are all relatively small…

> It lacks a first-rate IDE

That is an interesting claim. What are the first rate IDEs for Javascript, Python, Ruby or C++? That isn't a rhetorical question I mean vim, emacs, textmate all seem equally good for Javascript and Lua. I know people use Eclipse for Javascript but it hardly seems like a killer integration.

Re: Why Lua?

#67

Post by batista »

sshumaker wrote: post #55
haberman wrote: post #51

Earlier quoted context omitted.

FFI is extremely cool and impressive, no doubt, but a major downside of it is that you give up memory safety. Once you import it your Lua program can SEGV the interpreter and read/write arbitrary memory in your process. Freedom from memory errors is a major motivation for using high-level languages, so this should not be given up lightly. Also, from a security standpoint it means your Lua is less sandboxed.

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.

OK, native code can crash. Not much of a problem. He have been running servers written in C/C++ since the ancient times for more critical tasks than your average Lua program. From Apache to Nginx and from Qmail to MySQL to MongoDB. So what if a Lua program has the "potential" to crash if you interface with C?

You do the interfacing because there is a need to do it, anyway. It's not like you go FFI for fun.

Re: Why Lua?

#68

Post by whatajoke »

groovy2shoes wrote: post #65
whatajoke wrote: post #49

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…

> Can't get more functional than scheme :) Try telling that to the Haskell guys!

Scheme community frowns upon mutating code. R6RS even forced that by default, though the rest of the specification was a mess.

So, scheme style these days is all about pure functions, tail calls and continuations. To think about it, that really is setting it apart from common lisp.

Re: Why Lua?

#69

Post by rlander »

leafo wrote: post #24

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/

I was about to mention how cool Moonscript is, but you beat me to it. =) Thanks for the awesome project!

Re: Why Lua?

#70

Post by groovy2shoes »

whatajoke wrote: post #68
groovy2shoes wrote: post #65

Earlier quoted context omitted.

> Can't get more functional than scheme :) Try telling that to the Haskell guys!

Scheme community frowns upon mutating code. R6RS even forced that by default, though the rest of the specification was a mess. So, scheme style these days is all about pure functions, tail calls and continuations. To think about it, that really is setting it apart from common lisp.

Th Scheme language allows, and the Scheme community encourages, functional style, but it's still up to the programmer to write their programs that way. In Haskell, there is no other way -- even imperative programs in Haskell are functional!
Post reply on HN