5 ms·

Curious- what makes Rust unreadable for you? Abbreviations? Cryptic symbols?

• nly 13y ago
  Yes on both counts. The problem is that I can type faster than I can think. I don't believe that terseness inherently improves readability or encourages better design. I have felt this way since Perl. Consider this from the tutorial: fn draw_all(shapes: &[~Drawable]) { vs C++: draw_all (const vector<unique_ptr<const Drawable>>& shapes) { Transcribing that took a few seconds of thought, and all the terseness of a few symbols has accomplished is to obscure a poor choice of API and ownership semantics. That's just one symbol... how horrific can we make something without noticing with just a few more params and symbols?
  • lucian1900 13y ago
    To me, the C++ version seems entirely unreadable, though. Especially the cdecl inheritance of & going in the wrong place. In some instances Rust has removed syntax or its prevalence (@ turned into Gc/Rc; ~[] no longer grows, but Vec does). To each their own.
    • nly 13y ago
      The & being on the wrong place is a matter of style. I wrote it that way because it seems to be the popular convention. I'd usually write this myself: draw_all (vector<unique_ptr<Drawable>> const& shapes) { Now the const and ref at together.
      • pcwalton 13y ago
        I think lucian1900 was referring to & going on the right (`vector &foo`) instead of on the left (`&vector<foo>`).
        • nly 13y ago
          I don't see why either is right or wrong, but 'foo' is the reference and vector is the type. It seems logical to me the C++ way, but I'm not overly fussed.
          • lucian1900 13y ago
            Different parts of the type are in different places, merely for the space saving of being able to replace "var" or "let" with the type, like "int". While it made sense when C was created, this is horribly wrong this many years later.
  • pcwalton 13y ago
    Why is that a poor choice of API and ownership semantics? That's entirely natural. You use a range in order to provide the maximum convenience to your callers, and you use unique ownership to provide efficient memory management and reduce the amount of copying of data that has to be done when the backing store is resized. (Also, your equivalence is not quite correct: `&[T]` is more like a Boost range. In particular your transcription makes it look like the original code only accepted Vec<T>, which is not the case.) > That's just one symbol... how horrific can we make something without noticing with just a few more params and symbols? You've pretty much covered all the type-level symbols in Rust, except for * for unsafe pointers.
    • nly 13y ago
      If &[T] is somewhat generic already, why even have 'Drawable' in the signature? Also, doesn't having a borrowed array of unique references to Drawables mean the elements of the array are either now implicitly borrowed, or I have to borrow each of them before they're accessed? Just knowing the symbols don't make the semantics clear. In C++ all smart pointers are values in their own right. In my example I have a reference to an array of smart pointers, and there's no magic.
      • pcwalton 13y ago
        > If &[T] is somewhat generic already, why even have 'Drawable' in the signature? `&[T]` isn't generic: it's a bounds-checked slice. Two pointers: start and end. Presumably `Drawable` is in the signature so that methods specific to `Drawable` can be called. > Also, doesn't having a borrowed array of unique references to Drawables mean the elements of the array are either now implicitly borrowed, or I have to borrow each of them before they're accessed? They work like anything else: if you want to take a reference to a Drawable, you borrow it. > Just knowing the symbols don't make the semantics clear. Yes. Also true for C++'s symbols; e.g. `&`. > In C++ all smart pointers are values in their own right. Same in Rust. > In my example I have a reference to an array of smart pointers, and there's no magic. Same in that example.
        • nly 13y ago