[sshumaker]

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 void * source, size_t num );
  ]]

You also get the ability to add metamethods and finalizers to returned C objects (so you can use Lua's built-in GC to clean up after, for example, your FILE*).

As for the speed, there's no reason that a lot of dynamic languages couldn't be as fast as LuaJIT. But none of them are even close. I wish LuaJIT was still up in the computer language shootout. The LuaJIT interpreter (with JIT turned off) is 3x faster than V8 on the PC, and faster than Java on Android. And that's the interpreter - the JITed code is way faster.

Of course, macros are awesome, and a huge point in Guile's favor. On the plus side, Lua is very easy to understand, especially if you're coming from Javascript.

[cmf028]

"As for the speed, there's no reason that a lot of dynamic languages couldn't be as fast as LuaJIT. But none of them are even close. I wish LuaJIT was still up in the computer language shootout. The LuaJIT interpreter (with JIT turned off) is 3x faster than V8 on the PC, and faster than Java on Android. And that's the interpreter - the JITed code is way faster."

[Citation Needed]

I know of old benchmarks (pre Crankshaft) that showed the interpreter being faster than V8, but my own tests using the same benchmarks from the computer language shootout show V8 to be about 1.5x faster than luaJIT now.

I did some searching, and the most recent (though still way out of date) comparison I could find was this: http://attractivechaos.github.com/plb/

[sshumaker]

You can compare v8 to vanilla lua on the computer language shootout benchmarks page, and then compare luajit to lua on the luajit page. V8 has definitely made up some ground, and the luajit interpreter isn't generally faster than v8, but the jit is still way faster on almost all tests. The one area where luajit isn't great is on tests that stress garbage collection, since luajit still uses vanilla lua's GC. I think that's luajit's next area of focus.

[whatajoke]

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.