I’m not sure if you’ve been following the update blogs, but basically, Lua speed is a known issue in Stonehearth. SH’s pathfinder used to be written in Lua. However, as part of a (big) upgrade to game speed and capacity, they rewrote the pathfinder in C++.
For games like Stonehearth, path-finding is single largest performance problem, and the fact that they’ve (been forced to?) shift path-finding to C++ shouldn’t surprise anyone (beyond the fact that they actually wrote it in LUA in the first place).
The second largest performance problem for games like Stonehearth is normally job control. Essentially, when a hearthling needs to find something to do you search through a list of jobs, filter out things the hearthling can’t do (e.g. only carpenter can make a wooden chair, cook can’t make a stew unless the raw ingredients are in inventory, etc), find the most important job they can do, then mark items needed for the job as “in use” (e.g. so that some other hearthling doesn’t eat the raw ingredients for the stew after a hearthing takes the “make stew” job) and either remove the job from the list or mark it as “in progress” (so other hearthlings don’t try to do the same job). Of course (for performance) this wouldn’t be a single master list of all jobs; but could/should be a list for each type of job (e.g. one list for carpenter jobs, one for cook jobs, one for mining jobs, one for hauling jobs, etc). This is currently all in LUA. Because it touches on a large number of things (all work done by all roles) it’s not easily separated from everything else and it would take significant amount of work to convert to C++.
Also note that for multi-threaded code some parts of job control (e.g. the “mark items needed for the job as in use”" part) need to be thread safe. Currently there are several bugs caused by this part either not being thread safe or not being done at all; and I suspect this is because LUA lacks any built in support for thread safety (and makes it virtually impossible to do properly, especially handling errors that occur while locks are held).
Following from this, I think it’s reasonable to say that as a small company, Radiant can commit their resources to only so much at a time. I do not presume to speak for them, but I do think that their priority right now is simply not on hearthling optimization. They want the game to run well with 20 hearthlings in every way – that is, combat, quests, gamemaster, progress, score, building, whatever.
Why 20 hearthlings? Why not 10 hearthlings? Why not 1 hearthling?
Currently for “end game” you need about 25 military, 5 farmers, 2 cooks, carpenter, blacksmith, engineer, herbalist, 3 or 4 trappers/shepherds, plus about 10 general workers for hauling/mining/building. That’s about 50 hearthlings.
With only 20 hearthlings the game is unplayable. Your military is too small so you get trashed by enemies, your workforce is too small so any kind of large scale project is like watching paint dry, etc.
To add new features, they need more quests with harder enemies (but you’d need more than 50 hearthlings for that), or new roles like geomancer (but each new role adds to the total workforce needed). Performance problems limit total number of hearthlings which limits scope for new features.
For some reason, the bit about Lua being for VBA-bored secretaries got to me. If it makes it any different, the Flame virus, aka the most sophisticated cyberwarfare weapon discovered to date, was mostly written in Lua.
I’m quite biased towards lower level languages - I’ve spent the last 10 years writing highly optimised/scalable code in C and assembly language (in a different field, not game development). I’m the sort of guy that would take 20 times longer to write the code, and then offer a very sincere apology if I can’t make it handle over 400 hearthlings simply because I know it wouldn’t take much to handle 200 hearthlings. While I don’t expect this level of optimisation for any game; to me, LUA really is scraping the bottom of the barrel - it’s a toy for people that just couldn’t handle real programming.