swift 的速度基本跟 java/go 一档的，通常情况下 java/go 换技术的原因也都是 gc，而不是速度。我不知道 EDA 是啥，只能从更一般情况的情况谈快慢

跟 c++ 一档又带 gc 的选项倒也不是没有，比如 d 语言基本上是能跟 c++ 战的。但是呢，一般来说，大多数技术从走入大众视野，发展到成熟期，一般都在10年左右。d 走入大众视野时，node 和 go 还都不存在，所以它注定是永远小众了。一般 micro benchmark 都不考虑 gc 的影响，我很久没关注过 d 了，不知道它的 gc 目前是什么样的状态。

内存管理就这样，不手动的话，一共就3种主流技术：gc、rc、raii。都是上个世纪就存在的技术，各有各的优缺点，但没有免费的午餐。

个人认为，rc 是最差的，比手动管还糟。因为理论上，手动和 gc 是要么全管，要么全不管。而 rc 是只有一部分要手动管，还不像 gc 那样界限很清楚，只有非内存的资源要手动。我不知道有没有工具可以协助发现循环引用的问题，所以个人结论就是，极度依赖人肉。而不想手动管理的出发点就是，只要是人就会犯错，不管多高的高手，总会有翻车的时候。既比手动更依赖人肉，又有 overhead，结合了两者的缺点，所以是最糟糕的。

raii 能处理的情况非常有限，所以 rust 给出了一系列的严格规定，目的就是满足它的范畴。一旦超过了，要么 unsafe，要么 rc，都放弃了 raii 的好处。我不懂 c++，论坛看到的，c++ 几乎能完成 rust 的全部 raii 功能，但缺少最重要的编译器的严格检查。

我的建议还是 rust，但不要用 Rc，一开始写起来肯定会头疼。但从论坛反馈来看，普遍经历一段痛苦期后就习惯了。而且回头再写 c++ 也会不自觉的意识到问题，写出质量更高的代码。我个人是一直想入坑，但一直停留于想法，所以没法给出个人体会。另外，rust 的主流用法也是偏 fp 的（iterators over for loops），想正经写好本来也要一定时间的适应，所以直接 hard mode 开搞吧

【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 这里关键考虑还是性能。
: 我原来的理解是，EDA这类场景只能从c/c++/rust里面选，这三个的速度基本是可比的。go也算快的，但是典型计算场景下还是会比第一档的语言慢几倍。你所说的swift慢不到哪里去，具体有benchmark可以参考吗？
: 只要有可能，当然是希望能写有gc的语言啊，但是这不是第一档语言里都没gc嘛。。。。。。c c++ rust 各有各的恶心之处。。
: ...................
--
FROM 203.211.111.*