> pick up the general style just by reading "generic" material. Whether > they'll be sold on it is another question...
Well that's the point ;). They will often not be sold because the initial time you need to invest to understand and appreciate rusts "novel" choices will be too high. Just think about most people are working 40 hours a week and they don't have much spare-time (doh it was nice to be a student xD)... They won't spend a few weekends to find out themselfes if rust is a good bet (except they really want to, like me ;) ). There is basically a need for taking up all those tons of C++, etc programmers and show them why this novel design is a lot better than what they were doing for decades maybe even... For me, right now the primary point of sale are traits and impl which for me at the moment classify under "C# extension classes" which don't exist :D. But the concept seems really close. Instead of adding methods to types you don't own, you are adding interfaces and implementations, which is really awesome and something that needs to be done in so many cases. In C# we then endup using extension methods or worse Ad-hoc interfaces, creating instanciations of interfaces at runtime that dynamically cast any class into any interface as long as the class provides those methods... But rust also has made other great design choices, interesting ones too. But mostly I think it's a revolutionary approach to C++ (which is why such tutorials are so important), while D was more just an evolution. Just the type system really needs more in-depth "conversion" tutorials that help people make the transition. The rest is pretty natural, like tasks, no exceptions, memory safety, green threads, etc... I don't need tutorials there to tell me how much better it is ;). > This has nothing to do with pointers/references and everything to do Yes I meant that I return a Box<> ;). That wasn't really thought through. Just came into my mind at that moment, like std::make_shared<>(). > For example, if MyClass implements a serialization trait that the web > framework uses internally, then none of my code needs that trait or Hmm yeah that makes sense of course. I think I just have to read more rust code and try to figure out better ways of doing the above example and making it more rusty ;). > existing conventions) exception of C++. To re-export, just "pub use" > it: http://doc.rust-lang.org/tutorial.html#reexporting-names Huh... Hmm yeah reading public code doesn't mean you see all the details, even if they are right in front of you ;). I think rust can be read quite well so far and if I compare the compiler code and also the standard library with C++ then it is just a sign of how good rust really is, because never in my life so far I could just "look" at a compiler's source and say "Hey that totally makes sense"... With rustc you can really see what the code is doing inside the compiler. I can't particalrly say that about Mono C# (which I wrote a backend for) or Clang, for which I also wrote plugins etc... > Auron recently started an effort in that general direction, though > concerning many many topics beside file organization take precedence: > https://mail.mozilla.org/pipermail/rust-dev/2014-July/010735.html Thanks, I will definitely have a look! > have one file per class. The boundaries of a module are a balance > between small files, keeping tightly related code together (this can > mean up to tens of small classes per module), and exposing a Well, the problem is bad atm because rust doesn't have any sort of IDE as C++, Java or C# have. Without all the search & navigation features it is really annoying to navigate large files. Also this is more of a personal preference I guess. I generally find smaller files easier to grasp and it is also psychologically helpful, because you are not drowned in code when you want to understand the file ;). Also I don't think that tighly related code should be in the same file for the reason of being related. I don't defend Java's "single class per file" either becuase in practice it can be really annoying at times and create a flood of tiny files, which is probably as bad as having large monolythic files. If you have 10 classes that are really tighly related it often means you might have "made" them too tightly coupled and they could be more decoupled ;). When you force yourself into small files and small classes combined with extensive Unittests, decoupling comes pretty natural. But I don't want to discuss that either, since it's not rust specific but rather philosophic. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
