lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Mon, Feb 5, 2018 at 4:56 AM, Tom Cook <tom.k.cook@gmail.com> wrote:
> Lua was almost the only choice for scripting in the real-time context
> because it's about the only scripting language that has a non-stop-the-world
> garbage collector.

Lua's GC stops the world. All garbage collectors do. Lua's is just
reasonably well-behaved and tries to avoid big sweeps as much as
possible by doing smaller collections more often. It's also easier to
write Lua code that generates less garbage. And if you're doing
one-state-per-thread (the recommended way of doing it) then you're
only blocking one thread instead of the world.

> Perhaps the biggest difference is that integrating C++ code with Python is
> light years easier than integrating C++ code with Lua.  Boost::Python makes
> it all so, so easy, while trying to keep a ten-deep stack straight in your
> head on the Lua side was an endless source of defects.  Again, there might
> be something out there that does all this for you in Lua too, but we didn't
> know about it or find it.

You just didn't look far enough. There are several Lua frameworks for
C++ integration. lua-primer and luabind come up as the first two hits
in a Google search.

> Regarding some of the accusations of "bloat" against the Python libraries
> above - of course this is perfectly true.  But I'm not sure why it matters.
> That "bloat" doesn't cost you at runtime unless you use it - when it becomes
> useful library, not bloat.  So unless you're trying to install this on
> decades-old computer where disk space is a serious issue, what is the cost
> of that bloat?

Embedded systems are modern but have serious disk space constraints.
Also the presence of those libraries as "standard" means the ecosystem
depends on them, so you never know when one of your dependencies is
going to pull those in and start using up RAM as well. It's not a
horrible cost, but it's something to be aware of, and Python is a
fairly slow language to begin with. It's still a fantastic tool, but
if you're comparing it to Lua, then that's one of the things to look
at.

/s/ Adam