News for hackers. Stuff that matters.

A comment on Why Discord is switching from Go to Rust. Parent comment

Re:Why Discord is switching from Go to Rust by ozten on Tuesday February 04, 2020 @01:45PM (#22239374)
Yes and no. You can get very clever by pre-allocating memory and ensuring it is never garbage collected, but at that point you're opening yourself up to new types of bugs and other performance issues as you try to scale your hack.

As you fight your language, you're GC avoidance system will become larger and larger. At some point you might re-evaluate your latency requirements, your architecture, and which are the right tools for the job.

[ Parent | on HN ]
Re:Why Discord is switching from Go to Rust by sascha_sl on Tuesday February 04, 2020 @01:55PM (#22239498)
Go has a tool for this job.

https://golang.org/pkg/sync/#Pool

[ Parent | on HN ]
Re:Why Discord is switching from Go to Rust by jhgg on Tuesday February 04, 2020 @01:58PM (#22239536)
checked in objects in a sync pool gets cleaned up on GC. It used to clean the whole pool, but now I think it does half each GC cycle. If you want to say "objects checked in should live here forever and not free themselves unless I want them to" sync pool is not the tool for the job.
[ Parent | on HN ]
Re:Why Discord is switching from Go to Rust by sascha_sl on Wednesday February 05, 2020 @07:11AM (#22246059)
Well, it's a start. In fact the existing interface lends itself really well to a rolling window on-demand (de)allocator, especially with that New function you can supply.

Just pool could've mitigated your problem at least partially, is what I'm saying.

[ Parent | on HN ]