- 主题:Why Discord is switching from Go to Rust
感觉他这个场景，可以用对象池来 own 这些存储对象，LRU 淘汰的 struct 别扔了
这样就不会频繁的扔，GC，然后又去构造
【 在 keygen (失落灵魂之囚) 的大作中提到: 】
: 语言之争来了！
: Rust is becoming a first class language in a variety of domains. At Discord, we’ve seen success with Rust on the client side and server side. For example, we use it on the client side for our video encoding pipeline for Go Live and on the server sid
: The Read States service
: ...................
--
FROM 49.7.44.*
他这个场景可以用官方的 sync.Pool 试一把，成本低廉，立竿见影
需要更精确操控，可以再结合官方的实现撸一把
【 在 ilovecpp (cpp) 的大作中提到: 】
: 是可以，但手动内存管理的困难，比如内存泄漏，野指针，都会在对象池上面重现。
: 如果这个对象池占了内存分配的大部分，操作它的代码却只占全部代码的小部分，那是划算的。
: 否则，如果大部分代码都在操作这个对象池，那不如直接用无GC的语言了。
: ...................
--
FROM 123.58.117.*
如果达到 LRU 稳态后，都从 pool 里拿对象，没有新的alloc\free
GC 扫描是异步的，不阻塞用户协程，p99 不会这么变态
STW 是在扫描的间隙有新的 alloc
当然 golang 适合 IO 占用比较多的服务
这种要求 p99 10ms 以下的重存储服务用 go 不太合适，rust 用好了也挺香
再杠一下，感觉这个服务用 redis 挺好的，go 当成 service 前端即可
用了redis后，团队没有 KPI，没有折腾的价值
【 在 adu (阿杜) 的大作中提到: 】
: 跟对象池没有关系。
: 人家吐槽的主要槽点是2分钟一次的强制gc。
: 即使没有新的alloc/free，2分钟一次的强制gc扫描cache里面的大量对象导致latency，虽然这些对象都在用。
: ...................
--
FROM 123.58.117.*