First off: This is a random thought and may be completely off-base. But:
In the context of our performance discussions on IRC yesterday, Graydon mentioned one of our performance costs over C++: that our method dispatch is always virtual, through a vtable. This is potentially significant: this is cited as one of the major problems of Objective-C in high-performance environments, for example (despite its dispatch mechanism being heavily tuned [1]).
But there's another problem with objects, and one that's potentially far more severe than the performance problem: sending them over channels. As I understand it (and feel free to correct me here), it's not clear that we're going to be able to send objects over channels at all, because they (along with functions) belong to the opaque typeclass, which means that we can't tell statically whether they contain mutable, shared data. At a type level, all we know about an object is the interface it exports.
So objects have these two significant drawbacks. This leads me to think that perhaps we shouldn't be using objects in the standard library as much as we are. The buf_reader, buf_writer, and rng classes in the standard library are fine as objects; these are clearly abstract interfaces. But hash maps and deques are the kinds of things that we may well want to be able to send over channels (either frozen, or as unique pointers). Right now, in order to do that, I believe we'd need some flavor of "serialize" and "deserialize" functionality, which would be both a pain to implement and a pain to use.
In my view, making our hash maps into Plain Old Data instead of objects would both improve performance (by eliminating vtable dispatch) and give us a nice story for concurrency (just use a unique pointer and send your hash map away on a channel when you're done with it). And we could still have the object forms if we wanted to, layered on top of the lower-level functions! It's possible that people might want to write functions that operate on abstract collections. But I'm in favor of YAGNI here: when we see code that operates on abstract collections, then we can think about exposing an interface in the standard library.
Note that I'm absolutely in favor of keeping objects in the language; they're a powerful tool for abstraction. But in a high-performance language lacking mutable state like Rust, they're a double-edged sword.
Patrick [1]: http://www.friday.com/bbum/2009/12/18/objc_msgsend-part-1-the-road-map/ _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
