Some subjective thoughts on Rust

[ogeon]

@raizam

Descriptive and well categorized To me, ideally, Types should self-describe precisely what their nature/function is, lying in their module organized in categories. Which would follow the pattern

{source}::{category}::{TypeName}

Ok, that makes sense. Rust modules works differently than in many other languages and hierarchies that are deeper than one level can actually make sense, but it's of course better if they are as shallow as possible. Anyway, categories are among the hardest problems I know, and you have lost as soon as you make a category called "other".

@raizam

I mentioned earlier core types used should have syntax shortcuts, this is still the case here, but average types should keep an intuitive description.

Fun fact: Rust did once have "syntax shortcuts", but they were removed in favour of keeping the smart pointers in std. ~T was the same as Box<T>, @T was essentially the same as Rc<T> and ~[T] was the same as Vec<T>. I don't think that these types are common enough to justify a special syntax. Rust makes it very easy to keep almost everything on the stack, with a few exceptions. It feels like Vec is the most common heap allocated type and maybe the only one to deserve its own syntax, but that's also why we have the vec![...] macro.

@raizam

Also looking at a trait like std::convert::AsMut is named after the operation as_mut it exposes. A trait being by essence an addable capability should be reflected it in its name. In .NET, interfaces (traits here) tend to use the "-able" suffix, which is intuitive for "This trait adds a capability".so I would have preferred something like std::converters::Mutable (or AsMutable or MutConvertable). For Drop it might be Dropable.

I don't think the -able suffix add anything more than more letters and restrictions to what you can name things. The trait concept itself is all about the abilities of the types and I think that's enough. That's why they are traits and not just interfaces. Also, what about Into? Intoable? Or rename to Transformable? I understand what you mean, but I think the current system makes sense. You can now use names like Run (as in moving forwards), Jump, Decoder, Console, AsRgb, etc. They are traits, and thereby properties of the types.

@raizam

Just to precise, the overall philosophy I'm describing is not something I'm inventing, but what D, C# and Java and third party C++ libraries are using, the OOP world in fact. but indeed I have no idea how Python, Ruby, Scala, Haskell, look like.

Some of the things you are describing are conventions and the reason for why multiple communities have the same conventions are not always because they are the best conventions. It's important to question why things are as they are and think about the possibility of other conventions. For example:

• Do we camelCase things in C++ because it's what we did somewhere else and got used to it, or is it because we give things long names and want to save some space?
• Do we add the -able suffix because it feels like natural language or because it prevents naming collisions?
• What if we can make the module system better, to make it possible to avoid long names and collisions?

The formulation of those questions are quite sloppy, but it's only for illustrative purposes. I think you'll get the point. Taking inspiration from other languages is good, both for the sake of familiarity and to avoid past mistakes, but it's just as important to question old habits. This is part of the basics when designing something new or redesigning something old.

I'm not saying that you are stuck in old habits, but rather that it's important to give new conventions an honest chance. Toy around some more with Rust, build something fun, try to let go of the OOP/inheritance thinking and embrace the composition thinking. It will be odd at first (it was for me, too), the lack of inheritance will be a challenge if you are more used to it, and the borrow checker will be all over the code with its strict rules.

Once again, I'm not saying that you are wrong. I'm just trying to say that Rust is not just C++ with a funny syntax and more static checking. It's even more different than that. Rust is an other way of thinking.