7 ms·

There are probably dozens of us that really appreciate his clarity and writing and even his overall design goals for C++, but the language is so inherently load

• nly 5y ago
  Those newer languages will earn their share of historical baggage in time. C++ has the distinct ad/disadvantage that it inherited 15-20 years of baggage from C, as well as carrying 20-30 years of its own.
  • hrh 5y ago
    Totally. There's plenty of people that will argue that Go's historical baggage is in the form of being primitive, and Rust already is a large language. That's the fun thing about these design discussions.
  • pjmlp 5y ago
    Example, comparing C# 10 with C# 1.0, or Java 17 with Java 1.0, including the underlying runtime changes and multiple implementations during the last 25 years (for Java, 20 for .NET).
    • tonyedgecombe 5y ago
      C# has grown quite large over that period however there are large areas of the language that you can safely ignore. Your code might not be as elegant but you won't get tripped up like you would if you don't know C++ well enough.
      • pjmlp 5y ago
        In which C# version have the foreach variables changed their semantics? Just an example of a possible C# pub quizz question, I have other possible ones.
        • tonyedgecombe 5y ago
          I think it was 4.0 from memory. I'm not arguing that you don't need to think about your code. The early behaviour was what I would have expected, the change was sensible but it's a long way from what you have to deal with in C++. My experience with C++ was a lot of study and practice before I started my first project whereas with C# I was able to dive right in to a substantial piece of work and learn the language along the way.
          • pjmlp 5y ago
            Another example on how learning the language along the way gets to unexpected results, memory leaks in event handlers, or how HTTPClient doesn't really handle connection pool the way it should in the .NET Framework variant.
  • rramadass 5y ago
    >Those newer languages will earn their share of historical baggage in time. For some reason this truth seems to escape most new language fanboys, in particular; the Rust crowd on HN.
    • pkolaczk 5y ago
      Languages like Rust and Scala learned they lesson: they don't add features, but also remove or fix features. This is why you have editions or major versions, which are not 100% backwards compatible. E.g. Scala 3 comes with a major redesign of implicits, instead of adding a new way to do the same. Same for Python 2 vs 3. The biggest reason C++ and Java accumulate historical baggage is fixation on near 100% backwards compatibility. E.g. Java 5 added generics, but had to allow using non-generic erasures (List instead of List<T>) so older programs could still compile and run. And now we have to live with this ugliness even in Java 16. Of course dropping backwards compatibility causes a bunch of problems of their own and it is better to try to minimize the impact (Rust editions, Scala 3 vs 2) rather than do a big bang (Python 3 vs 2).
      • steveklabnik 5y ago
        The key to editions is that they don’t “drop backwards compatiblility”. We have to keep lots of things around forever! They let you opt in to small forms of backwards-incompatible changes while retaining inter—edition compatibility. This means they are backwards compatible in the strict sense of the term.
        • tialaramex 5y ago
          There are a few other cute tricks (not all of which were in Rust 1.0) to enable this. Rust's "raw" way to spell all symbols is clever. Maybe some day my function named weigh will be a problem because of a new "weigh" keyword. Rust gets to add the keyword but still talk about my function in new editions by just spelling the symbol awkwardly, as r#weigh. This forbids Rust from reserving such spellings (e.g. "r#weigh") as keywords themselves, but that would be so ugly nobody would want to do it. Overall the result is Rust 2021 could even make "new" a keyword if it wanted to, and the old code which uses that symbol name everywhere still works, it's just a little clumsy to talk to it from next edition code. Still, I think it's worth remembering that the edition changes in Rust so far have been much smaller than many changes contemplated for C++ Epochs (or any hypothetical actual C++ feature similar to Vittorio's proposal in spirit). C++ has a lot of problems, and understandably Epoch proponents want to do stuff like ban implicit narrowing coercions, or change how overflow works. Because of how sprawling C++ is these are surprisingly big changes to the whole language, and I don't think that you could pull off something like that with editions. I have a hopeful note though. Maybe C++ can inspire a much more powerful tool than editions, somehow enabling backward compatibility for C++ while also allowing new C++ to be written exclusively in Stroustrup's "subset of a superset" that keeps most of C++'s strengths but loses so much baggage like implicit coercions everywhere. If it's possible, the C++ community have the right people.
• casept 5y ago
  Oh, it's absolutely possible as long as your brain is flexible enough to appreciate both minimalist and maximalist language design. Same goes for C and Rust.
  • deleted 5y ago
    [deleted]