[rust-dev] C++ to Rust - Is that about right?

Christoph Husse thesaint1987 at googlemail.com
Mon Jul 14 22:08:35 PDT 2014


> 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.


More information about the Rust-dev mailing list