| > Pony does fearless concurrency better IMO Pony is garbage collected. Most of the reasons why Rust async/await are the way it is boil down to the fact that Rust is memory safe without using GC. > Forty2 shows how we can expand on Pony to be faster and more flexible I can't tell from a glance, but that also looks garbage collected. > For example, one can apply Loom's memory techniques to most memory management approaches to eliminate the coloring problem Assuming you're referring to the JVM Project Loom, that's just M:N threading. This was tried in Rust almost a decade ago. Nobody used it because the performance was not appreciably better than 1:1 threading. > There are also languages which separate threads' memory from each other which allows them to do non-atomic refcounting You mean like Rust? Like, that's exactly why Rust can have both Rc and Arc and still be safe. > relying on copying for any messages crossing thread boundaries (though that's often optimized away, and could be even less than Rust's clone()ing elsewhere). Ancient Rust did this, but it was removed because with the current immutability and borrow checking rules there is no need for copying anymore. Why would you want copying if you don't need it? I'm also not going to just accept that clone() could be faster. I mean, I'm sure the clone codegen could be improved by better register allocation or whatever, but I don't think that's what you mean. > One could also apply that technique to a language using generational references, if they want something without RC or tracing GC. Why would you want to copy if you don't have to? > Sometimes I wish Rust waited just a few more years before going all-in on async/await. Alas! I haven't seen anything here that is better than Rust's async/await, and a lot that's either worse or doesn't fit with the rest of Rust's design. |