[FoRK] Python, Re: The collapse of the .net ecosystem

Sean Conner sean at conman.org
Sun Jun 21 13:57:45 PDT 2015

It was thus said that the Great Stephen D. Williams once stated:
> Python is now the go to language for learning to program.  Like Java, 
> Visual Basic, etc. before, this is going to boost it.  With great 
> libraries, and easy ways to integrate C++ into it to create scripting for 
> powerful C++ code, and the ability to be embedded easily (which Java fails 
> at) while being better than a toy language (Lua), it is going to go strong 
> for a while. 

  I'm curious as to why you consider Lua a toy langauge.  It too, is easy to
embed (one of the main features, infact), has true tail-call optimization
[1], has coroutines [2], closures, first class functions, etc.  And while
Lua isn't thread-safe (that is, two threads can't use a single Lua instance
[3], you can easily give each thread its own instance of Lua [4].

  And least of all, while the stock Lua interpreter is one of the fastest,
it's not the fastest Lua interpreter---that goes to LuaJIT, an almost
seamless replacement [5] of stock Lua which can get you very close to C
speed, if not C speed entirely (I suspect for math-heavy code).  Also,
LuaJIT has a seamless FFI module that makes it even easier to call to C than
the stock Lua API interface to C.  

  About the only lack Lua has is an extensive standard library which I can
see as being a showstopper.  But I, among others [7], don't consider Lua a
toy language (heck, I'm using it at work to process SIP messages [6]).

  -spc (It's even been embedded in the NetBSD kernel ... )

[1]	Somethign that Guido absolutely refuses to add, becaues "it would
	make debugging harder." Sorry, don't buy that one.  Also, tail-call
	optimizations make writing state machines much nicer.

[2]	While not true threads, they do make writing asynchronous, event
	driven code much nicer than the call-back hell you get in

[3]	Technically, you can, if you recompile Lua and define an
	implementation for the functions lua_lock() and lua_unlock(), but
	then, you've just added the big GIL to Lua, something that Phython
	users have been wanting to remove for *years* if I understand

[4]	The entire interpreter context is stored in a single structure, and
	because of this, Lua *is* re-entrant.

[5]	If you are using stock Lua 5.1, then it's seamless.  If you are
	using Lua 5.2, then it's somewhat seamless, kind of.  If you are
	using Lua 5.3, then you probably can't use LuaJIT at all. 
	Unfortuantely, the author of LuaJIT doesn't care for some of the
	changes in Lua 5.2 and Lua 5.3 so the two implementations are slowly

[6]	Which mostly deals with parsing, and for that, I use LPeg, a
	Lua-based parser expression grammer.  It compiles to its own VM (a
	parsing-specific VM in fact) and because it's just expressions, you
	can compose gammars as needed.  It's quite nice.

[7]	http://lua-users.org/wiki/LuaUses

More information about the FoRK mailing list