- 主题:请教个rust基本问题，Rc<RefCell<T>>有啥坏处？
话说喂给原来的v8这种js运行时的是不是最终只有js，那编译成js的所有语言应该都快不了吧，除非像wasm这种能识别更多数据类型的运行时
【 在 eGust (十年) 的大作中提到: 】
: 标 题: Re: 请教个rust基本问题，Rc<RefCell<T>>有啥坏处？
: 发信站: 水木社区 (Tue Dec 7 10:31:01 2021), 站内
:
: 这用法就好比把 js 迁移到 ts，然后所有类型都声明成 any，有啥意义呢？
:
: 【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: : 之前业务是python写的，要加速，尝试了一阵子c++，受不了了，所以才转rust。。。
: : 哪怕rust里用Rc+RefCell很多，也比c++强吧？
:
:
: --
:
: ※ 来源:·水木社区 mysmth.net·[FROM: 203.211.111.*]
--
FROM 106.121.187.*
ts 只是加了编译期的类型检查，只有个别语法比如 enum 会生成额外的内容，如果目标版本设定为 esnext，基本上就是代码原封不动
另外快是怎么定义的？v8 目前不比 jvm/golang 差太多，常规 micro benchmark 几乎差不出2倍。本来就快不了多少，再加上通过 js 才能调用 wasm，所以实际上 wasm 几乎不可能做到比原生 js 实现快。另外，除了 native 语言，wasm 里面还得带个 gc，这种套娃实现怎么可能更快？
我说过很多遍了，wasm 的出现并不是 js 的替代品。相反的，对于想移植浏览器、但不想再写一遍代码更有帮助。wasm 根本就是对 js 的补充，两者的发展是相互促进的作用。
另外，ts 目前还是有点尴尬的。由于本来带类型信息，理论上编译器、runtime 可以做更激进的优化。然而实际情况却是擦除类型信息，而使用更保守、更通用的 js 优化
【 在 No1 () No1 () 的大作中提到: 】
: 话说喂给原来的v8这种js运行时的是不是最终只有js，那编译成js的所有语言应该都快不了吧，除非像wasm这种能识别更多数据类型的运行时
--
FROM 203.211.111.*
为啥不用go呢
你都说了，直接放堆里
go好歹还会做一下逃逸分析，大部分放在栈上
【 在 beep 的大作中提到: 】
: 之前业务是python写的，要加速，尝试了一阵子c++，受不了了，所以才转rust。。。
: 哪怕rust里用Rc+RefCell很多，也比c++强吧？
:
--
修改:littleSram FROM 111.203.35.*
FROM 111.203.35.*
看了这些神叨叨的概念还不如用c++，至少shared_ptr保你平安。
【 在 beep 的大作中提到: 】
:
: 团队正在迁往rust，有两种关于数据结构风格的意见：
:
: 1. 按照螃蟹书的风格建议，既然使用了rust，就需要先费心根据需求设计好所有权树，尽量少用Rc>，多用&和&mut解决问题
:
--
FROM 221.222.21.*
我们在做的东西有点特殊，eda相关的，之前只是用py做了个原型验证了idea，现在就是要把性能瓶颈部分改写成c或者rust，但是性能瓶颈部分的数据结构也很复杂。
然后用py来调用rust的模块，和调用c的模块是很类似的
【 在 Bernstein (Berns) 的大作中提到: 】
: 其实建议你profile一下性能，然后把瓶颈用c改写成python模块...
--
FROM 123.120.160.*
有意义啊
即使多用Rc+RefCell，一方面，和py比，还是要快很多很多的，另一方面，和c++比，好歹RefCell也提供了运行时的内存安全，读写指针冲突的时候会给你panic
【 在 eGust (十年) 的大作中提到: 】
: 这用法就好比把 js 迁移到 ts，然后所有类型都声明成 any，有啥意义呢？
--
FROM 123.120.160.*
我这个场景性能还是很重要的，之前选型就是只在c/c++/rust里面选，后来也有人说，滥用Rc+RefCell的话，性能会接近go和swift，写起来还简单一些。但是也没有一个benchmark说到底和go的性能差别有多大。
具体到堆和栈的问题，我提到的那部分使用Rc+RefCell的数据结构本来就应该进堆的，用啥语言也一样
【 在 littleSram (littleSram) 的大作中提到: 】
: 为啥不用go呢
: 你都说了，直接放堆里
: go好歹还会做一下逃逸分析，大部分放在栈上
: ...................
--
FROM 123.120.160.*
先Rc+RefCell跑起来，以后再慢慢重构成地道的Rust也好……
当然，也可能以后就没激情重构了^o^
【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 有意义啊
: 即使多用Rc+RefCell，一方面，和py比，还是要快很多很多的，另一方面，和c++比，好歹RefCell也提供了运行时的内存安全，读写指针冲突的时候会给你panic
--
FROM 125.119.232.*
shared_ptr 就是 rust 的 Rc
【 在 xieyf (绿蚁新醅酒，红泥小火炉) 的大作中提到: 】
: 看了这些神叨叨的概念还不如用c++，至少shared_ptr保你平安。
--
FROM 123.120.160.*
嗯，如果之后用一段时间发现需求稳定了，不需要Rc的地方应该是可以把Rc撤掉换成普通引用的
【 在 adoal (阿豆) 的大作中提到: 】
: 先Rc+RefCell跑起来，以后再慢慢重构成地道的Rust也好……
: 当然，也可能以后就没激情重构了^o^
--
FROM 123.120.160.*