1. 23
  1. 20

    My view on this is that Rust and C++ aren’t that much different in their evolution, it’s just that Rust came later.

    A lot of C++ language features came out of necessity or common culture: when C++ came up, object orientation was coming up as the way to modularise software. The knowledge about practical issues of the concept came up later.

    The other thing is that static languages, especially with an eye for performance, have the tendency to grow features - one day, it’s an abstraction over SIMD, tomorrow is CHERI. So you end up in a situation where the language is ever extended and some features stop being “en vogue”.

    And we’re seeing this in Rust: it’s a perfectly usable programming language, still, there’s work on features to e.g. avoid Boxing return types in async. For most programming languages, that would be no problem and if you want to improve the situation, you try to fix it in the runtime (e.g. through a clever JIT).

    Even as someone who is deep into Rust, my view is that in 20 years, we’ll probably read this blog post with Rust vs. some other language.

    C++ has been breaking ground and it’s important to see its evolution as something that did involve the thoughts of many contributors.

    1. 3

      Glad to see a balanced take. I’ll write in Rust vs C++ any day, but I really dislike seeing the Comment Section blasting C++ for complexity when Rust has enough complexity of its’ own. Rust, at least, actively tries to file that down, but the space these languages aim for pretty much necessitates it.

      And there are some things that you cannot express easily in Rust, such as a precise GC that doesn’t require explicit rooting. (It is possible someone could figure out a way to do this, and there are lots of good work here!) However, I freely concede they are a small, small subset of the types of things you’d want to write, generally.

      1. 4

        Ha, thanks, such feedback means much to me! I’m very interested why languages are like they are and my conclusion is that the explanation that takes their authors, creators and communities very seriously often leads to the most coherent results.

        I’ve also spent my time around language creators (previously in Ruby, but also at conferences like ACCU) and I’m very annoyed how they usually have an intimate understanding of the problems everyone else in the space is sharing. Curiosity rules there. When I joined the Rust community, one of the first things I read was “If Rust is a criticism of C++, it comes from a position of respect”. And that was certainly true.

        The point that not everything is easy to expressed in Rust is very true - and sometimes, that’s a choice. Mostly on focus - other things need more work at the moment. My personal thing is that I would not write a (large) UI in Rust at the moment. Maybe a window or 2, but not a large, complex system.

        I hope in general, our community gets more curious, or at least calm.

        One last thing: the late Russel Winder sent me emails for 3 years to speak at ACCU about Rust. When I arrived there, he caught me and we had a very short conversation. He stated that he’s happy to see that systems programming is becoming a hot topic again and he sees the future of ACCU as a conference and meeting spot for systems programmers. And he introduced me to 1-2 C++ hotshots and told me to not feel small. And gosh, did I have great conversations! So even if most talks were about C++, there was Swift, Go, Rust, Zig etc. at this conference. And how is that not a privilege - we’re out here, can compare implementations, look at the source, express our thoughts and ideas and… how can we choose dismissal?

        Okay, enough rambling :).

        1. 1

          blasting C++ for complexity when Rust has enough complexity of its own. Rust, at least, actively tries to file that down, but the space these languages aim for pretty much necessitates it.

          I agree on a basic level, but I think there generally is a difference between complexity and complexity.

          For one aspect, I think zero-cost abstractions in particular is what this space demands. Zero-cost abstractions are forever, whereas other abstractions gradually get replaced by better and better ones until one or typically many zero-cost abstractions are reached.

      2. 10

        Just thinking about the headline, I don’t think the number of features bothers me that much. For me its more important how many footguns a language has, and how easy it is to avoid or spot them.

        For example (Posix) Shell and C have relatively few features compared to e.g. Python, C++. But a shell script often has much more quoting and error checking issues than a Python script. Some features in C++ allow me to avoid footguns present in both C and C++.

        So I’m not looking for a language with a low total number of features. I’m just looking for a language with fewer bad features (and good documentation).

        1. 2

          Footguns-per-feature seems like a worthwhile metric. :)

          Sometimes I think small languages get away with more footguns because it is easy to rationalize them away in exchange for the concept of being small in a user’s head.

        2. 6

          I definitely think so; it’s what’s driving my latest programming language experiment: the realization that I wanted a smaller, simpler language with fewer features.

          1. 2

            That’s beautiful. If you haven’t submitted it to Lobste.rs already, you should.

            1. 2

              oh thank you! One of the blog posts I wrote was submitted, and once I have one more of the “stuff” behind the scenes I’ll submit a 0.1 release. I’d be curious to hear your thoughts if you have some time at some point as well!

          2. 3

            I will just leave this here https://metacpan.org/dist/perlsecret/view/lib/perlsecret.pod

            And yeah, i have seen some of these in production code base

            1. 3

              A thing is not finished when there is nothing left to add, but when there is nothing left to take away.

              1. 2

                I was getting troubled by the slicing problem example with Complex and Quaternion and then it hit me: his inheritance hierarchy is upside-down, which is why this is a problem. A Quaternion is not a Complex and so the Quaternion class shouldn’t inherit publicly from Complex (if anything, it should be the other way around; and then you wouldn’t have the slicing problem anyway since you’re not adding fields in the subclass).

                This is not to say slicing is never a real problem, but I feel like the particular example is bad.

                1. 2

                  Rust is hardly a panacea. It expresses a cleaner set of domain concepts than C++, sure, but that’s not hard to do 😉

                  A programming language is a system, defined by its composite parts i.e. its features, and judged by the consequences of the interactions of those features in the compositional whole. A language feature by itself is value-neutral; its value can only be measured as it exists in relation to other features.

                  Yes, you can absolutely have too many features. The value of a feature is a function of the benefit it delivers, minus the cost it demands, as applied against all other features in the language in which it exists. If a new feature interacts non-deterministically with other pre-existing features, then its cost almost certainly dominates its value, and it shouldn’t be added.

                  Rust in particular asserts that specific properties of memory and ownership management should be lifted into the application domain. That’s useful in some circumstances, but it’s absolutely not a given that it’s useful in all, or IMO even most, circumstances.