这里关键考虑还是性能。

我原来的理解是，EDA这类场景只能从c/c++/rust里面选，这三个的速度基本是可比的。go也算快的，但是典型计算场景下还是会比第一档的语言慢几倍。你所说的swift慢不到哪里去，具体有benchmark可以参考吗？

只要有可能，当然是希望能写有gc的语言啊，但是这不是第一档语言里都没gc嘛。。。。。。c c++ rust 各有各的恶心之处。。

【 在 eGust (十年) 的大作中提到: 】
: 标  题: Re: 请教个rust基本问题，Rc<RefCell<T>>有啥坏处？
: 发信站: 水木社区 (Wed Dec  8 15:55:43 2021), 站内
:
: 我不懂 c++，但 reference count 的缺点放哪都一样，weak reference 的分析完全交给人肉。手动分配释放内存的话，至少上个世纪就有很成熟的技术，可以追踪内存泄露是在哪里分配的，重复释放的代码也很容易找。如果想追踪循环引用是如何产生的，难度不比实现一个 gc 更简单，反正我是不知道有没有成熟的技术可以用。
:
: 至于速度，swift 自然也没慢到哪去；virtual method 也一样有开销，绝大多数情况下都不会产生质的影响。所以还是那句老话，干嘛非要用一个看似更安全的技术，来写一个实际上更糟糕的实现呢？
:
: 【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: : 我目前的理解是，即使多使用Rc+RefCell，性能也基本会和c++ shared_ptr可比的。现代c++也已经是unique_ptr shared_ptr满天飞了。
: : 需求就是要快呀，传统上EDA软件基本都是c++写的，现在用rust我觉得是合理的，据我所知那几个EDA大厂比如s家里面也用很多rust。用golang反而很奇怪。。。
:
:
: --
:
: ※ 修改:·eGust 于 Dec  8 15:59:47 2021 修改本文·[FROM: 203.211.111.*]
: ※ 来源:·水木社区 mysmth.net·[FROM: 203.211.111.*]
--
修改:eGust FROM 203.211.111.*
FROM 123.120.160.*