Sorry for the slow reply, I did mean to get back to this: On 13-06-07 02:25 PM, Bill Myers wrote: >> Every >> single reviewer I showed a "no cycles" variant of rust to told me >> it was unacceptable and they would walk away from a language that >> prohibited cycles in all cases. All of them. We tried limiting it >> within subsets of the type system rather than pervasively: it still >> irritated and confused everyone. > > Interesting, are these versions online anywhere?
No. They'd be in ocaml and many ages ago. I might be able to dig up a source dir but it'd be meaningless by today's standards. The last version I bothered shopping around used a simpler rule than anything we've looked at in this thread: @ just always meant acyclic and RC. The compiler would reject any mutable recursive-typed @ edges, and we were careful that enum was the only way you could introduce ownership recursion. This rule was ... not popular :) > True, in fact fragmentation might be as bad or worse as the dead objects > living on in GC. Possibly. One can synthesize benchmarks that show either thing. I tend to support your belief that tracing-GC resident set will be larger and more cache unfriendly than (say) RC. But I also know that for browsers, code size, fragmentation over days-long browsing sessions, and especially cycle formation and collection are all real issues too. >> We tried this; various strategies for it. Ownership cycles even just >> within subtrees of well-organized ownership trees are not a rare >> occurrence. They are a result both of normal patterns within common data >> structures, and normal levels of coupling between subsystems in large >> applictions. Especially web browsers. > > How about, however, something like (hypotetically) rewriting the Linux > kernel in Rust? (with limited amounts of unsafe code) I think it's a bit unfair that in your example, you insist on wanting fine-grained global RW locks, when in fact linux has been systematically backing away from those in favour of RCU. Indeed, the docs on the RW locks[1] say: NOTE! We are working hard to remove reader-writer spinlocks in most cases, so please don't add a new one without consensus. (Instead, see Documentation/RCU/rcu.txt for complete information.) RCU, as you know, is very different, and .. I actually don't know if it's easy to encode in rust's current rules or not. But I think it's neither helped by the rules you were proposing either. I think kernels are dealing with way more complication than we can encode into any set of rules: weird IO memory mappings and barrier rules[2], per-CPU structures, interrupt safety, custom allocators and lifetime patterns, all sorts of stuff that we can't handle "optimally". I would expect a kernel written in rust to involve a lot of looking at our type system for tools-that-might-help, but ultimately when facing a performance-vs-safety trade, or a hardware-reality-vs-rust-types trade, to go with performance and reality, and larger blocks of supporting "unsafe" code they've reasoned carefully about. That's what they do now and, somehow, they manage to code with a level of attention-to-detail and minimalism wherein it seems to mostly work. -Graydon [1] https://www.kernel.org/doc/Documentation/spinlocks.txt [2] https://www.kernel.org/doc/Documentation/memory-barriers.txt _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
