Hacker News Reader

Comment by nly | Hacker News Reader

C++. Too many other languages get wrapped up in ideology. D comes pretty close. I can't get past Rusts unreadability. I'd like to give Nimrod a try... especially since it can be compiled to C and presumably integrated in to C++ projects.

[Edit] Read Nimrod tutorials and ported a few toy programs. It's encouragingly clean and doesn't seem to shy away from features... I wonder if Alex Stepanov knows that, in Nimrod, "if you overload the == operator, the != operator is available automatically and does the right thing" ;)

View on HN

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

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?

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.

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.

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

A good test for me is whether the simplest possible implementation works:

    template <typename Range>
    void draw_all (Range r) {
       for (e : r) { draw(e); }
    }

There are no magical symbols here at all. It's not efficient, but it's completely memory safe... breaks with unique_ptr though, which is a good indication for me that unique_ptr is the wrong choice. Here's the less safe 'borrowing' version:

    template <typename Range>
    void draw_all (Range const& r) {
       for (e const& : r) { draw(e); }
    }

and a sane compromise:

    template <typename Range>
    void draw_all (Range r) {
       for (e const& : r) { draw(e); }
    }

How would you write all of these in Rust?

The reason for use of a unique pointer is that if the caller had an array of unique pointers to Drawables, then you want the caller to be able to call draw_all() without recreating the array.

You could come up with a generic function that doesn't require unique ownership (for example, one that takes an Iterator<&Drawable>), but the function in that example wasn't generic because making everything generic just in case is overengineering.

You seem pretty confused about how borrowing works. Borrowing is tangential to that function.

I'm not confused about borrowing, what I'm saying is is that borrowing, plain refs in C++, are a performance hack in both languages. In my final version above, I have assumed copying a range is cheap, and copying a Drawable is expensive and unnecessary... seems perfect to me, and it will not compile passing a vector of unique_ptr's, which is what I would want

References are not a performance hack; they're a fundamental way to avoid lots of moves, which obscure algorithms and cause a lot of mutation. (In Rust they are memory safe.)

Anyway, if you wanted a generic reference-taking version:

    fn draw_all<I:Iterator<&Drawable>>(iterator: I) {
        for drawable in iterator {
            drawable.draw();
        }
    }

And a generic move version:

    fn draw_all<I:Iterator<Drawable>>(iterator: I) {
        for drawable in iterator {
            drawable.draw();
        }
    }

Internal moves make no sense. You can't move an object out of a container that has invariants, like an ordered map. This is why it only makes sense for the caller to move a container in to the function. This is efficient. I've edited my 3rd version appropriately, as moving from a const& was clearly bogus.

    template <typename Range>
    void draw_all (Range r) {
       for (e const& : r) { draw(e); }
    }

Using the container's iterator to move allows the container to enforce those invariants.

I've totally lost track of what we are arguing about. Anything containing a unique element has to be logically unique itself, right?

In C++, which defaults to value semantics, it's required that you move your container if it contains a non-copyable (unique) element. So you only need to move into the draw_all function in this case, which is why taking the range by value is not just efficient, but semantically correct. If the caller moves in to the function, then when it returns the caller will no longer own any elements. The callers vector will be empty, and the elements themselves will still be unique having never been copied, moved or "borrowed".

If borrowing isn't a performance hack, then why not make everything you're ever likely to borrow shared? I'd argue anything you're drawing is shared between the draw routine and the caller. Drawing a distinction just because the caller is suspended, seems like an impediment to future change if, for example, you later switch to a coroutine or an asynchronous/threaded operation. Copying the range and sharing elements gets you this for free.

In summary, 'draw_all' as specified was a bad API because:

* It restricted the type of range/container passed to it

* It had unnatural ownership semantics (borrowing a box of unique things without saying you're borrowing those things is weird).

* The implementation, as was, required further borrows which were only implied. In C++ you take everything straight away.

> * It restricted the type of range/container passed to it

Yes, it did, but as I mentioned before, it's overengineering to make everything generic that could possibly be generic.

> * It had unnatural ownership semantics (borrowing a box of unique things without saying you're borrowing those things is weird).

No, it's not, it's quite natural. `&[&Drawable]` is not a subtype of `&[~Drawable]`, so if your caller has an array of `&[~Drawable]`, then they would have to recreate the array to pass it to that function.

> * The implementation, as was, required further borrows which were only implied. In C++ you take everything straight away.

I don't understand what this means, but in any case C++ and Rust don't differ substantially on ownership/reference/move semantics.

Why is it a problem to "require further borrows which are only implied"? Borrows are compile-time only, and they conceptually happen anyway in your C++ implementation. It's just enforcing the correct ownership pattern in the compiler.

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.

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.

I think lucian1900 was referring to & going on the right (`vector &foo`) instead of on the left (`&vector<foo>`).

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.

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.

It's an interesting time for native development with all these languages making some serious attempts to dethrone C++ when in comes to combining high/low level in one language.

I'm still using C++ myself until the dust settles a bit, but I've found that my C++(11) code is trending towards being less stateful and more functionl-ish.

It's cool to see things changing in this space after feeling like it would be old style C or C++ forever.

Reply on news.ycombinator.com