> That being said, I wonder if their team considered implementing a different language that was meant to work without GC overhead. Er, hold on there. As discus

> That being said, I wonder if their team considered implementing a different language that was meant to work without GC overhead. Er, hold on there. As discussed in the article, python only uses GC to cope with cases which the refcount can't handle. Which turns out in some situations to be a relatively small amount. The performance problem here didn't actually come from any "fundamental overhead" of GC, just an incidental implementation detail. Deciding to jump languages just because of a 10% performance gain which pointed them in that direction (which, as I've discussed above, it didn't) would be ill advised. > by turning off a selling point of safer languages I don't know if I'd say GC is a selling point of a safer language, it doesn't really have a lot to do with safety in itself and the authors certainly didn't manage to remove any language safety in disabling the GC.