The traits just had an overhaul , they seem to have a good handle on how to handle OO vs type classes. They tried basic classes with type classes but after a reasonable amount of code there was little code using them so they cut them and expanded traits . Hence what you probably cant do well is just trivially port C++ code , though the nice thing is you can call C functions as part of the language ( not sure about calling C++) .
Its pretty hard to get the information as the documentation is a out of date as its changing pretty fast and the standard libs are not written for the new traits . Best info is the tutorial (about 6 months out of date) and on the blogs of some of the authors. http://pcwalton.github.com/blog/2012/08/08/a-gentle-introduction-to-traits-in-rust/ http://smallcultfollowing.com/babysteps/blog/2012/10/04/refining-traits-slash-impls/ http://pcwalton.github.com/ There is something to be said for a more mature product , tests , installers , multiplatform , greater use etc .. Rust seems to have a full time team paid for by Mozilla and its active eg https://github.com/mozilla/rust/graphs/contributors . That said i liked the Bitc constraints on types better and the natural types though these could be added to Rust..Bitc syntax was more modern , rust has a c "style". To me the killer is a JIT if you want a fast JIT and cant live with cached compiles than i don't think Rust will do the job as the type system makes it slow to compiler and LLVM doesnt hel. Its worth noting that with a really good GC , common rust code may end up more similar to bitC using more shared pointers but decent GCs are rare for static languages outside of Java / .NET and a significant effort . Anyway worth a look and id thought id let you know that its progressing / changing. At the very least its worth getting updates on there lessons / pain points . Ben On Sun, Jan 6, 2013 at 9:09 AM, Jonathan S. Shapiro <[email protected]> wrote: > I need to go look at Rust again in its current form, but based on what I > know about it's foundations, I'm dubious. Given LLVM, and the fact that we'd > be removing the hard parts from BitC, I'm not convinced about your time > estimate. > > But as I say, I should go look. > _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
