折腾过这么多语言，最后留下来当心头好的居然是Lua，挺意外的。它最打动我的是真轻，解释器塞进C/C++项目里也就不到300KB，零依赖零负担，直接编译进去就能当脚本引擎使。早些年那些C++老项目想加点新功能，本来得动核心代码重新编译一遍，现在挂一段Lua脚本就完事了，热更新一下当场生效，老程序照样续命。
更舒服的是它的数据结构，全靠一个table打天下。数组、字典、对象全用同一套东西表达，学起来不费劲，写的时候脑子也不用在不同类型之间来回切。不少人嫌它功能少、标准库薄，可恰恰是这份克制让它能安静待在角落里当胶水，把十年前的老代码和今天的新需求无缝缝起来。这种不抢戏的语言，反而最长情。
热更新那块我倒想补一句。Lua 当嵌入式脚本确实轻巧，解释器塞进 C 项目也就那么点体积，但"挂段脚本就完事、热更当场生效"在真跑着的老项目里没那么丝滑。其实已经在跑的 closure、upvalue，还有活着的 coroutine，不会因为重新 require 一遍就自动换掉，旧状态怎么接、旧引用怎么失效都得自己安排。我见过好几个项目偷懒直接 dofile 覆盖，结果线上行为悄悄漂移。这层 glue 的隐性成本，其实挺值得在动手前算清楚。
想当年我也偏爱热闹的，后来才懂，不抢戏的那位反倒留得最久。
你说到热更新我就想起以前写游戏脚本那会儿，改完直接生效不用重新编译，老项目是真能多撑好几年。就是标准库薄这点，有时候补轮子补得人挺累的。
热更新这步得补个前提：Lua 的 reload 不会替你清掉旧模块的 upvalue 和 package.loaded 缓存，直接 dofile 新脚本，老闭包还攥着旧状态，看着热更了其实没切换。正经做法是先把 package.loaded 里对应项摘掉再 require，状态清理也得自己接管。
300KB就能当引擎使 现在这些App动不动几百兆真是白胖得慌
等等，这个"老程序续命"的说法我太有画面感了。我听说不少团队当年是被 legacy 代码绑架——核心那坨C++谁碰谁挨骂，最后全靠塞个Lua进去当救命稻草，热更新一挂，老代码不用动，新需求照填。
呢
你们知道吗，游戏圈最早就是这么玩起来的，WoW插件、后来一堆手游逻辑层全扔Lua里，本质都是"线上改东西不用重新发版"。我怎么听说的版本是，大多数人不是真心喜欢Lua，是实在没辙才投靠它的。
我反而好奇你那项目啥来头？能让你把Lua当心头好，我赌你核心代码至少十年往上，当年没少被重新编译折磨过吧。有个事不知道该不该说，我认识一哥们也是这么被"续命"的，结果Lua越挂越多，现在整个项目反被Lua绑架了，哭笑不得哈哈
之前听人聊起Lua，印象里它老待在游戏脚本那个角落，没想到拿来给老C++项目续命这么顺手，被你说的这些用法打开了眼界。
最戳我的是那句"不抢戏的语言，反而最长情"。嗯嗯，深以为然。是呢我发现身边让人想一直留在旁边的东西，往往都不是最热闹、功能最全的那个。就像有些关系，不黏人、不折腾，平时几乎感觉不到它的存在，可真要用到的时候它一直都在，这种踏实感比什么都珍贵。
你提到的table打天下我虽然写不来，但光听着就觉得舒服，脑子不用在不同类型之间反复横跳，这种"少操心"的设计哲学挺动人的。标准库薄这点被好多人吐槽，可正因为它克制，才守得住那份轻。
不过话说回来，胶水再好，底子还是那摊老代码得靠谱，Lua只是让它喘了口气。你们做老项目维护的，平时改起来应该还是挺费神的吧？~
老程序靠lua续命 我靠奶茶续命 本质上都是打补丁活着哈哈hh
300KB这个数，往一个C++引擎里塞Lua的时候我也专门量过，确实就这么点东西，编译进去连个水花都溅不起来。
早几年做游戏那阵，底层引擎是C++，上面玩法数值全交给Lua跑。最舒服的也是你说的那点——改个掉率不用重编译，hotfix一下当场生效。不过table一把梭听着省心，真到项目大了，满屏table套table，定位一个nil到底从哪冒出来的，够人发半天呆。
克制确实是它的长情之处，但我后来慢慢觉得Lua更适合当配角。它把老程序缝得妥妥帖帖，缝久了，底下那块布原本长什么样反倒没人记得清了……
等等，这个热更新当场生效听着真香，但我怎么听说有人拿它绕过发版流程，偷偷改线上逻辑，运维到出问题才知道？你们见过这种操作吗
300KB那个数得看怎么算。简单说PUC-Rio Lua 5.4 把解释器加标准库静态编进二进制，release下确实200多KB，你说不到300KB基本对。但有个坑：换LuaJIT，解释器更小、跑起来快一个数量级，可语言特性停在5.1还自带一堆扩展。两条路选哪条，对"续命老项目"的影响比你说的要大。
table打天下这点完全认同，补一句实现细节：Lua的table内部是数组段+哈希段的混合体，连续整数键走数组、稀疏或字符串键走哈希。所以同样是table，你当数组用和当字典用，内存布局和缓存命中差很多。热路径上这个区别能让程序快几倍或慢几倍，不能真当成"完全无差别"用。
热更新那块你说"挂一段脚本当场生效"，实际没那么省心。在C里重新dofile一遍，全局表是新的，旧状态全丢。要真·热更得自己管Lua state、做upvalue替换或套个reload框架，状态迁移才是工作量大头。把解释器塞进去容易，把老状态平滑接上才麻烦。
我个人更看重LuaJIT的FFI——不用写一行C binding，Lua里declare一下C函数就能直接调。比起"嵌个解释器当脚本引擎"，FFI才是把十年前的C库和今天需求缝起来的真胶水。
不过"克制让它最长情"这点我得补个反例：标准库太薄，真干点活就得引入一堆第三方小库，LuaRocks上质量参差，版本兼容又是个新包袱。克制省下的依赖，往往从别的地方还回去了。