> I am in strong support of your idea to add an option for this. Even if some > consider atomic refcounts > too slow to use for performance critical > application, it's a great tool for prototyping without having > to worry > about manual memory management.
The atomic reference counts are indeed more expensive, however with compile time optimizations and and lent/sink can help removing unnecessary inc/dec. Lobster claim a roughly 95% reduction of these and with such reduction the performance impact between atomic and non atomic becomes less important. One problem with concurrent access to references is that any borrow/checker will stop working as there might be another thread accessing the same resource. This also ties to how to make the concurrent primitives. We have Lobster but Swift will have a ownership model together with atomic reference counts. I think Swift will demand exclusivity to a resource from one thread. I'm not sure how that will look like right now. Memory management is a moving target today and we will probably see more development when it comes to that. What Nim should provide is a platform so that we can investigate memory management ideas. Nim has historically done well in this department.
