温馨提示：为了内容更易读，下面就不涉及 JIT 部分了
开场
丹尼尔：蛋兄，编程语言是真多啊，10个手指都数不过来了，它们到底有啥本质区别啊？
蛋先生：这是个好问题。其实啊，所有编程语言都在做同一件事，只是各自的路子不一样罢了
丹尼尔：同一件事？说来听听
蛋先生：说白了就是
程序源码 > 中间表示 > 机器码 > CPU
丹尼尔：那区别是？
蛋先生：区别就在于"怎么走完这条路"。咱们按设计思路分几类聊聊，先从"极致性能型"说起
极致性能型
叠甲：并非说这类语言是为了追求性能而生的。性能只是因为把控制权交给程序员后，顺带产生的好处。性能能爬多高，主要看程序员能不能把这份控制权用到位
丹尼尔：极致性能型？听起来就很猛
蛋先生：没错，代表选手就是 C/C++。它的路线最直接，没有中间商赚差价
程序源码 > 机器码 > CPU
丹尼尔：没有中间商？那岂不是很快
蛋先生：等等，严格说也不算"零中间商"。用户程序里其实还链接着一个"辅助型 runtime"（CRT），它是程序的真正入口。程序启动时由它先干点初始化的活，干完再调用你的 main 函数；等你 main 跑完退场，它再回来收尾
丹尼尔：哦，所以是"迎宾员"那种角色，不插手正事
蛋先生：对！runtime 不接管你的逻辑
丹尼尔：懂了，那内存安全等谁来保证？
蛋先生：( ╯▽╰) 这就是代价了——"辅助型 runtime" 只管开门关门，不会去管你的屋里怎么闹，所以你写崩了它也不拦着
内存安全型
叠甲：这类语言的初衷不止是内存安全，但内存安全确实是引入"接管型 runtime"后，因收回部分控制权而得到的核心好处之一
丹尼尔：那想要内存安全咋办？
蛋先生：计算机界有句名言——没有什么是加一层搞不定的！那我们就在中间加一层专门的接管层，让它来处理底层这些麻烦事，就是个不错的思路
丹尼尔：哦？所以？
蛋先生：那就得请”接管型 runtime“出马了。它就像个微型操作系统，用户程序只是它的一个任务，需要借助它运行。所以路线变成了
程序源码 > 中间表示（可选） > runtime（机器码） > CPU
丹尼尔：怎么有个可选的？
蛋先生：别急，咱们分三代来看，一个一个聊（注意，这里的"代"不是按语言出现的时间先后，而是按我认为的设计思路的改进来分的）
❖ 初代：现场加工，现做现卖
丹尼尔：初代是谁？
蛋先生：JavaScript 是这类的代表。路线如下，源码在运行时直接交给 runtime
程序源码 > runtime（机器码） > CPU
丹尼尔：直接？
蛋先生：没错！程序运行时，runtime（比如 V8 引擎）会先读一遍字符串源码（即 parse 成 AST），再转成中间表示（根据 AST 生成字节码），之后就解释执行这些中间表示了
丹尼尔：等等，我有好多疑问啊
蛋先生：真是个好奇宝宝！你问吧
丹尼尔：什么是 AST？
蛋先生：AST 就是抽象语法树。字符串源码里的语法结构是隐含的，计算机难以直接处理，所以得把它解析成一棵树，层次和嵌套关系就一目了然了。比如 a + b * 2 这行代码，对应的 AST 大概长这样：
BinaryExpr(+)
/ \
Id(a) BinaryExpr(*)
/ \
Id(b) Num(2)
丹尼尔：哦！那有了 AST，计算机可以处理了，为什么还要字节码呢？
蛋先生：如果没有字节码，直接根据 AST 来执行，那每次执行都得重新递归遍历这棵树，开销很大啊。所以会在首次执行之前先把 AST 遍历一遍，"拍平"成一组线性的指令序列，这就是字节码。之后执行时直接按顺序读指令即可，不用再碰 AST 了。还是拿上面的 a + b * 2 来说，拍平后大概长这样：
LOAD_VAR a # 把变量 a 压入栈
LOAD_VAR b # 把变量 b 压入栈
LOAD_CONST 2 # 把常量 2 压入栈
MUL # 弹出栈顶两个(b 和 2)，相乘，结果压回栈
ADD # 弹出栈顶两个(a 和 b*2 的结果)，相加，结果压回栈
丹尼尔：确实，这样会快很多。那解释执行呢？我经常分不清编译和解释的区别
蛋先生：解释就是 runtime 早就为每种字节码指令写好了对应的实现。字节码只是一份数据，一份描述行为的数据。解释器逐条读取字节码，根据指令类型，执行对应的实现
丹尼尔：这不就是低码 DSL 的实现思路嘛
蛋先生：哈哈，小眼睛看得真准。然后 编译 可以不严谨地理解为把 A 翻译成 B，比如把源码翻译成字节码的过程
丹尼尔：Good！这下全搞明白了。感觉 runtime 在处理代码上做的事有点多啊？
蛋先生：是有点多。因为它在程序运行的时候，把代码编译的事给做了
❖ 第二代：先加工再上菜
丹尼尔：那说说第二代吧，有啥改进？
蛋先生：改进在于编译时机。在把代码数据给到 runtime 之前，会提前处理——把源码编译成字节码的中间表示。路线图如下
程序源码 > 中间表示（字节码） > runtime（机器码） > CPU
丹尼尔：代表选手是谁？
蛋先生：就 Java 吧，它会先把 Java 字符串源码编译成中间表示，也就是二进制的字节码。在程序运行时，JVM runtime 直接解释执行这些字节码即可
丹尼尔：突然想起一个比喻：初代是现场读菜谱做菜，第二代是提前把菜谱整理成标准工序，做起来当然快
蛋先生：这比喻很形象啊！
❖ 第三代：直接编译，打包同行
丹尼尔：那第三代又是啥思路？
蛋先生：路线演变成下面这样了，直接把源码编译成机器码，跟 Runtime 一起打包。Go 是这类的代表选手
程序源码 + runtime 源码 > 机器码 > CPU
丹尼尔：跟 C/C++ 比，就多了个 runtime 源码
蛋先生：对！但用户程序仍然只是 runtime 这个微型操作系统的任务。 用户程序的执行需要通过 runtime 来调度
丹尼尔：有个地方没想明白，既然用户程序最终也编译成了机器码，可以直接 CPU 执行，那 runtime 是怎么干涉的？
蛋先生：简单回答吧。首先程序的入口依然是 runtime，不是你的 main，所以调度天然被接管。其次是在编译期做手脚，把特定的代码替换成 runtime 内部函数的调用
丹尼尔：哇，这也行。那发展到这代，性能已经极限了吧
蛋先生：这里不再有字节码解释开销，全部是 CPU 直接执行机器码。但接管型 runtime 依然存在，对性能仍有影响
既要又要型
丹尼尔：所以并没有两全其美的方案是吧
蛋先生：还真有！Rust 就是这类的代表选手。它的路线如下：
程序源码 > 机器码 > CPU
丹尼尔：这不又又又回到原点了吗？
蛋先生：表面看是一样，但人家性能也要，内存安全也要！它像 C/C++ 一样，直接把源码编译成机器码，CPU 可以直接执行
丹尼尔：那它怎么做到内存安全的？不是说没有接管型 runtime了吗？
蛋先生：(≧∇≦) 这就是 Rust 的”骚操作“了
丹尼尔：快说快说！
蛋先生：我要回去做饭了，下次再聊～(￣▽￣)
写在最后
亲们，都到这了，要不，点赞 / 收藏 / 关注支持下呗 o(￣▽￣)ｄ
