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.
Well, so we didn't look far enough. On a quick inspection, neither of those look nearly as good as boost::Python, but that might be an aesthetic thing.
> 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.
I work almost exclusively in modern embedded systems. It's been a long time since I've come across one where either volatile or non-volatile storage is a serious constraint. Yes, we're careful about how we use it in deterministic code, but the actual amount available is almost never a constraint. There is still a lot of kit out there that does have these constraints, so maybe I'm lucky that I haven't been required to work with old hardware for a long time.
Regards,
Tom
