回到主题,不限于 Rust,就是指通用目的语言的话,更长期的趋势不好说,但我预测应该迟早会“文艺复兴”——最终把 C/C++ 这样绝对意义上就不怎么好用而且可维护性怎么整都不咋地的方案给排除出包括系统编程领域在内的各个主流实现。
更长期地,DSL 可以从通用语言演化。我之前有粗略考虑过这方面的整体需求问题:
https://github.com/FrankHB/pl-docs/blob/master/en-US/calling-for-language-features.md#judgment-on-the-general-purposed-language我的结论是,要满足一般意义上的一桶浆糊的目的,基本上只能靠其它领域的通用语言实现,先从克服语言演进的障碍(更新和修改语言特性的现实工程问题)开始——像 Rust 这种被用户需求逼出来的包管理器这样的表面方案是远远不够的(现在依赖外部 shell 的整合方式也不是合理的方向)。根本地,这要求语言特性应能很大程度地“反射”语言 spec (注意,不说 Rust 这种连 spec 都没给的,大多数语言在这里仍然是用不靠谱的自然语言写的,原则上根本不可编程)和实现(比如允许用户自己给编译器补丁扩充语言且兼容性仍然可控; Rust 编译器插件的存在说明了设计者注意到了部分需求,但如 rustc::plugin 这种只关心 rustc 而不是 Rust 自身的流于实现细节的备胎解决方案仍然是不靠谱的),这脱离绝大多数现在的工业界语言既有设计的能力上限,因此被主流业界接受需要很久(可能到 Rust 自然嗝屁以后)。
所有之前在这个楼讨论的内容都不是这条路线。最近能看得到的绝大多数语言,包括 Rust 在内,甚至都不具备接近这条路线的创新。现在大概只有 Racket 这种预先强调 language-oriented programming 的做法和实现经验稍微能看一点,但 Racket 本身在技术上就有很多问题——例如从一个依赖 GC 的运行时剥离出来一个不依赖 GC 而具有显式所有权的核心语言,这基本除了回炉重造没有办法,而且 tooling 还是太弱了。
对应地,过于依赖传统的 AOT-central 的方案不可能是通用的实现方案——反省下 LLVM 这类的既有实现为什么连 libjit 都统一不了就能闻出点味道了。以 explicit SSA 作为核心 IR 的转换方案,使过程内和过程间优化的实现更加困难且难以自动化,迟早导致规模增加以后工程资源消耗的现实不可行(现在很多写编译器的赶鸭子上架已经超常发挥了,工作量规模一旦失控,加倍 996 也没用)。对应的前端实现也普遍比较粗放,很多都直接把什么 declaration 撸到框架内部,连翻译单元都没法做出和目标语言解耦的抽象,稍微跟 C-like 相差大点的就没法复用得整个重来,LLVM 撸成“库的集合”的好处很大程度被抵消了。
历史上比较能接近这里的长期目的的,大概只有 REFAL 这样的 metacompiling system,但这方面的研究几十年来一直相当初级,工业界接近这个目标的最先进的也就是 Graal/PyPy 这种类非典型的只能优化小部分类型开销的 partial evaluator ……所以可能得再等几十年业界才会认识到现在这条路走不通——不过这些都是超出主题的身后事了。