- 主题:请教个rust基本问题，Rc<RefCell<T>>有啥坏处？
那就大胆的用rust吧
希望之后能发点体验
【 在 beep 的大作中提到: 】
: 我这个场景性能还是很重要的，之前选型就是只在c/c++/rust里面选，后来也有人说，滥用Rc+RefCell的话，性能会接近go和swift，写起来还简单一些。但是也没有一个benchmark说到底和go的性能差别有多大。
: 具体到堆和栈的问题，我提到的那部分使用Rc+RefCell的数据结构本来就应该进堆的，用啥语言也一样
:
--
FROM 114.249.23.*
比 py 快的语言多了，而且 reference count 本身的缺点太多了，要不为啥 gc 是主流
【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 有意义啊
: 即使多用Rc+RefCell，一方面，和py比，还是要快很多很多的，另一方面，和c++比，好歹RefCell也提供了运行时的内存安全，读写指针冲突的时候会给你panic
--
FROM 203.211.111.*
对于绝大多数“正常”组织来讲，一旦代码处于能用的状态，就基本不会再改动了。所以一般如果有临时代码，那临时代码就成了永久代码了
【 在 adoal (阿豆) 的大作中提到: 】
: 先Rc+RefCell跑起来，以后再慢慢重构成地道的Rust也好……
: 当然，也可能以后就没激情重构了^o^
--
FROM 203.211.111.*
换个角度想，也可能是要求语言带 GC 的程序员有缺点。
大家用 gc 习惯了。其实应该思考一下 gc 是怎么来的，以及对 gc 的需求是否可以减免。
【 在 eGust (十年) 的大作中提到: 】
: 比 py 快的语言多了，而且 reference count 本身的缺点太多了，要不为啥 gc 是主流
--
修改:hgoldfish FROM 112.47.122.*
FROM 112.47.122.*
我目前的理解是，即使多使用Rc+RefCell，性能也基本会和c++ shared_ptr可比的。现代c++也已经是unique_ptr shared_ptr满天飞了。
需求就是要快呀，传统上EDA软件基本都是c++写的，现在用rust我觉得是合理的，据我所知那几个EDA大厂比如s家里面也用很多rust。用golang反而很奇怪。。。
【 在 eGust) 的大作中提到:
: 比 py 快的语言多了，而且 reference count 本身的缺点太多了，要不为啥 gc 是主流
--
FROM 123.120.160.*
最近有一篇文章讲了为啥go语言不需要使用JAVA那种分代等复杂的gc
其中一点就是go不太需要年轻代，通过逃逸分析，短生命周期的一般放在栈中。
【 在 hgoldfish 的大作中提到: 】
: 换个角度想，也可能是要求语言带 GC 的程序员有缺点。
: 大家用 gc 习惯了。其实应该思考一下 gc 是怎么来的，以及对 gc 的需求是否可以减免。
:
--
FROM 111.203.35.*
是的。go 语言很少有回调函数，更容易做逃逸分析。
【 在 littleSram (littleSram) 的大作中提到: 】
: 最近有一篇文章讲了为啥go语言不需要使用JAVA那种分代等复杂的gc
: 其中一点就是go不太需要年轻代，通过逃逸分析，短生命周期的一般放在栈中。
--
FROM 110.85.22.*
说实在的不带gc的语言写起来太操心了。。。
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 换个角度想，也可能是要求语言带 GC 的程序员有缺点。
: 大家用 gc 习惯了。其实应该思考一下 gc 是怎么来的，以及对 gc 的需求是否可以减免。
--
FROM 123.120.160.*
出书吧，这些经验都是很有价值的
--
FROM 114.249.233.*
不管是 gc 还是 reference count，上个世纪就已经出现在主流语言和技术里了。这都过去20多年了，还从来没思考过到底是为啥有这些东西？
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 换个角度想，也可能是要求语言带 GC 的程序员有缺点。
: 大家用 gc 习惯了。其实应该思考一下 gc 是怎么来的，以及对 gc 的需求是否可以减免。
--
FROM 203.211.111.*