7 ms·

A well articulated paper by a great thinker. That said, switching from C++ to Go made my life so much easier and more enjoyable that I do not see myself going

• hrh 5y ago
  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 loaded with historical baggage, that it is only pragmatic to use newer languages that learn from those successes and mistakes However, I've heard, but can't confirm so don't quote me that it is impossible to appreciate Go and Rust at the same time.
  • 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]
• pkolaczk 5y ago
  I tried Go and I have an opposite experience. To me Go looked like a very limited, incomplete and non-principled language that makes easy things look easy but hard things ugly or (near) impossible. I put it on the same shelf as Python and Basic. Things like using product type instead of sum type for returning errors really put me off. But that's probably due to past experience and personality type. I mostly enjoy working in powerful and expressive languages: e.g. Rust, Scala, C++. // edit: oh, someone have already said that: can't love Rust and Go at the same time ;)
  • maccard 5y ago
    > Things like using product type instead of sum type for returning errors really put me off. Can you share some practical use cases where the sum type has an advantage? Personally I find go's explicit error type, along with the convention of it being called err everywhere to be really helpful and clear when working through the control flow of a program. What does a more "powerful and expressive" language give you day to day that golang doesn't? (Generics being the first obvious example, but I have to agree that there are a handful of use cases where they're useful)
    • dthul 5y ago
      The return types of fallible functions map naturally onto sum types. By using product types instead there is a semantic mismatch. You get an error and a value but only one of those is valid. So you need to follow certain code idioms to get back the sum type semantics whereas this is something the type system could handle for you. Go's reasoning for that might be that they didn't want to have the complexity of sum types in the language, which is fair but is a tradeoff.
    • pkolaczk 5y ago
      A product type forces the language to have a special "invalid" state for every type like Nil, and this reminds me of all the problems related to null handling I know from java - like forgetting to check for null / Nil. A product type also allows returning weird states: no error and no value, or both error and value. I strongly believe that invalid states should be unrepresentable, rather than allowed by the type system and then fought by discipline and tooling.
• maccard 5y ago
  Honestly, I use go for things I wouldn't use c++ for even if I had the choice. Do I want to do some file wrangling, text manipulation, async or web api calls? Even the "nicest" of c++ libraries (manu of which are poor wrappers around a C library) are really poor ergonomically where go takes the biscuit. I definitely don't see myself writing gameplay code in go though
• raverbashing 5y ago
  I wanted to like Go but to be honest it really seems to be trying hard to be unlikeable. Rust has some weird corners, but it seems they're good at explaining things. Go tries to make some things easier (though, sure, still easier than C++) but they make it in a opaque or weird way. Some changes also seem to change too fast, but that might just be me looking from the outside