> Rust fully supports this case with arenas. Please supply evidence (aka. code) to back your one-liners. I assume you're talking about libextra/arena.rs. It's

> Rust fully supports this case with arenas. Please supply evidence (aka. code) to back your one-liners. I assume you're talking about libextra/arena.rs. It's very straightforward; there's a big comment at the top of the file, so I don't have to point out how primitive or sophisticated it is. > And that's why the new scheduler is written in Rust. You're talking about libstd/rt/sched.rs. So it uses the UnsafeAtomicRcBox<ExData<T>> primitive (from libstd/std/sync.rs) to implement the queues. The event loop itself is a uvio::UvEventLoop. Looking at the rest of libstd/rt/uv, I see that your core evented io is libuv (aka. Node.js). For readers desiring an accessible introduction, see [1]. Otherwise, sched.rs is very straightforward. > There is a new GC that is basically written Unless you're expecting some sort of blind worship, I expect pointers to source code. I found libstd/gc.rs, so I'll assume that it's what you're talking about. Let's see what's "basically" done, shall we? You use llvm.gcroot intrinsic to extract the roots, and then _walk_gc_roots to reference count. You've also written code to determine the safe points, and have implemented _walk_safe_point. For readers desiring an accessible introduction to gc intrinsics in llmv, see [2]. The history indicates that nobody has basically touched gc.rs since it was written by Elliott a year ago, so I'm not going to investigate further. The reason it's not enabled enabled by default is quite simple: it's not hooked up to the runtime at all. You still have to figure out when to run it. > Graydon has a working tracing GC You're not understanding this: the whole point of running an open source project is so you can proudly show off what you've written and get others involved. Your one-liners are not helping one bit. > did you not see the mailing list discussions where we're discussing what needs to happen to get incremental and generational GC? No, and that should be the purpose of your reply: to provide links, so people can read about it. I'm assuming you're talking about this [3]. Okay, so you need read and write barriers, and you mentioned something about a hypothetical Gc and GcMut; readers can read the rest of the thread for themselves: I don't see code, so no comments. > TCP sending, for example, is faster than both node.js and Go 1.1 in some of our early benchmarks. TCP sending is libuv: logically, can you explain to me how you're faster than node.js? No comments on Go at this point. > And sequential performance is on par with C++ So you emit relatively straightforward llvm IR for straightforward programs, and don't do worse than clang++. Not surprising. > http://pcwalton.github.io/blog/2013/04/18/performance-of-sequential-rust-programs/ http://pcwalton.github.io/blog/2013/04/18/performance-of-seq... This is the one link you provided in your entire comment. Learn to treat people with respect: showing a programmer colorful pictures of vague benchmarks instead of code is highly condescending. Yes, I've seen test/bench. If you're hiding some code in the attic, now is the time to show it. [1]: http://nikhilm.github.io/uvbook/ http://nikhilm.github.io/uvbook/ [2]: http://llvm.org/docs/GarbageCollection.html http://llvm.org/docs/GarbageCollection.html [3]: https://mail.mozilla.org/pipermail/rust-dev/2013-July/004763.html https://mail.mozilla.org/pipermail/rust-dev/2013-July/004763...