LLRT本身是亚马逊用在自己的基建上（serverless），并非通用设计。因为目前工作范围无重叠，我这边后续应不会投入资源测评或引入生产项目中。
值得说道的是实际用AWS Lambda的朋友反馈很不错，因为没有采用JIT策略，单纯执行特定函数时cpu和内存的消耗大大降低（和node相比10倍启动速度和2倍效率提升的宣传语，并不脱离实际）。于云服务成本角度，写工作或财务报告是很好的指标。
LLRT引擎用的是QuickJS，开发语言是Rust。
QuickJS引擎，个人前两年在部分物联网项目的上层开发很抱期待，这两年进展貌似趋于平稳。至于在UI混合渲染或游戏引擎脚本系统方面，QuickJS有无新的建树则不甚了解。
用Rust实现低延迟（LLRT中间前两个字母是Low Latency的缩写），社区没啥异见。C++的包袱有些重，Zig稳定度有待检验，Go有GC先天易引发质疑。
这两年JS/TS的新运行时层出不穷，都属于解决特定场景速度问题的补丁，LLRT显然也在此范畴内。不过要是为了硬件效率，在技术选型时就直接跳到某些静态语言，程序员团队的维护成本恐怕会立刻成为拦路虎。
经验里面，上限几万注册用户、每秒几百并发的IO密集型应用，全栈用JS/TS实现费效比较高。同种语言，在团队内部人员流动时摩擦低。
当然因为国情因素，如能在国内保证质量的前提下组低成本的Java团队，也很不错。
