> 1. Interrupting the program to sweep, resulting in unpredictable performance. See my comment regarding "less predictable latency" (although new advances are

> 1. Interrupting the program to sweep, resulting in unpredictable performance. See my comment regarding "less predictable latency" (although new advances are making for much more predictable latency - see some of the work done in Java GCs for example) > 2. Possibility that a circularly linked group of variables could be impossible to sweep, resulting in memory leaks. That is not possible in a precise tracing collector, only in reference counting (Rc/Arc) > 3. Need to check reference counts (along with bounds checks) that degrade performance. I think you are referring to reference counting again. Both Rust and C++ have reference counting types as an add on. State of the art tracing collectors don't collect/check dead objects, they compact live ones, and often don't use reference counting directly. Most objects die young. > Lack of GC (and bounds checking) are factors that make C/C++ performant and then lead to the kind of bugs that result in programs that don't do what they're supposed to do (and at worst, result in security vulnerabilities.) Replace "performant" with "predictable performance" > I thought a key goal of Rust was to fix these problems without sacrificing performance. Rust, like C/C++, wants you to be able to predict performance and latency and without the baggage of a runtime. Nothing more than trade offs - neither is better or worse. GCs often do perform better with the trade off of latency predictability, but as always it depends on use case as to what is appropriate. Rust likely made the right choice for its domain.