1. 34

  2. 10

    This sadly feels like C++ will be bound by the part of the industry that just wants to live on legacy forever. So we’ll probably need to sacrifice C++ to them and use something new, if we want a modern C++.

    1. 8

      There are only two kinds of languages: the ones people complain about and the ones nobody uses.

      -Bjarne Stroustrup

      The commitment to backwards compatibility is one of the major reasons why C++ has gained such high adoption in industry. C++ is certainly not my favorite language, but being able to compile and run code from two or three decades ago without modification is massively important for infrastructure development, and few languages have demonstrated the same compatibility guarantees seen in C++.

      1. 4

        That Bjarne’s quote is annoying. It is obviously true (almost tautological), but completely sidesteps whether the complaints are valid or not.

        Backwards compatibility with problems of the past was already a hard constraint for C++98, and now there’s 20 more years of C++ additions to be backwards-compatible with.

      2. 6

        d and rust are both solid options for a modern c++ if you don’t need the backward compatibility. as others have noted, legacy support is one of the major selling points of c++; there is no reason for them to give that up.

        1. 4

          Explain please. Why do you think that? I only see new tools to use but my projects are my own.

          1. 6

            It’s regarding the non-breaking of the API and rather deprecation of std::regex etc. They’re not breaking it because apparently the industry will fork it otherwise. So we’re stuck with some bad decisions like forever.

            1. 2

              because apparently the industry will fork it otherwise

              Don’t they already fork it? Almost every C++ project seems to have some reimplementation of part of the standard library.

              1. 1

                There’s a really big difference between forking the standard (whatwg-style) and avoiding a few of the features of the standard library in favor of your own alternative implementations.

                1. 2

                  I very much doubt you’d see an industry fork. The companies with sufficient interest in C++ and the massive resources required to develop compilers are probably the ones pushing C++ forward.

                  What you would be more likely to see is some companies that just stop upgrading and stick with the latest release which doesn’t break compatibility.

                  If you did see any non-standard developments to said release, I expect they would be minor and not widely distributed. Those who are resistant to change are unlikely to be making big changes, and until relatively recently C++ has had very little in the way of a community that might coordinate a fork.

          2. 4

            Legacy code is code that’s worth keeping running. A significant part of C++’s value is in compatibility with that code.

            Causing an incompatibility that would be at the kind of distance from C++ that Python 3 was from Python 2 just isn’t worth it. If compatibility constaints are loosened more, Rust already exists.

            1. 3

              Legacy code is code that’s worth keeping running.

              Sure. The question is whether we have to keep punishing newly written code and new programmers (who weren’t even alive when C++’s poor decisions were made) with it.

              1. 2

                A language called “C++” but incompatible with the C++ that existing code bases are written in wouldn’t solve problems for new programmers working on those code bases. That is, you can’t change a language spec and fundamentally alter design decisions that existing code already was built on.

                Constraints on newly-written code depend in how the new code intermingles with old code. New code interleaved tightly into existing C++ code is constained by existing C++. For code that doesn’t interact with C++ at all or interacts with C++ through a sufficiently identifiable interface doesn’t have to be in a language called “C++”.

            2. 3

              Agreed. I believe that this kind of “modern C++” is Rust; there just has to be a way to keep C++ experts and their design mentality away from core development. Otherwise Rust will end up like C++.

              1. 3

                I’d disagree with a characterization that Rust is a modernized C++. I believe there are things in Rust that the people building C++ would love to have (epochs for example are a hot topic in that thread), but I don’t think it’s the language they would build if they could get out the chisel and compatibility break away not only ABI but maybe even syntactic decisions and more. Despite the lack of commitment so far to measly ABI breaks, with some of what’s seemingly in the pipeline really just transforming a lot of the day-to-day of working with C++, maybe all you’d need to end up with a “modern C++” is sort of a, uh “C+”. My personal choice for trimming to create a C+? Kill preprocessor directives with fire!

                1. 1

                  I could have said more precisely:

                  Rust is what C++ developers need. It’s not necessarily what they want.

                2. 2

                  …there just has to be a way to keep C++ experts and their design mentality away from core development. Otherwise Rust will end up like C++.

                  This comment makes me a bit sad. I understand the point that @soc is making, but I don’t think that the Rust community should ever be built on a foundation of keeping people out. The C++ community certainly struggles with a culture of complexity, but there is a lot that the C++ community can bring to the Rust community and vice versa.

                  1. 2

                    That and a lot of Rust’s core team are C++ experts already.

                    1. 1

                      Every language is built around a set of values that result in a self-selection process for potential adopters:

                      • The language has bad documentation? Keeps out people who think documentation is important. (See Scala.)
                      • The language keeps adding features? Keeps out people who think that adding more features does not improve the language. (See C++, C#, JavaScript, Typescript, Swift, Rust, …)
                      • Etc. etc.

                      For instance point number 2 – I have decided that Rust 1.13 is roughly the max language size I’m willing to deal with when writing libraries.

                      I have subsequently skipped all newer Rust versions and the features that were added in those versions. I can’t really “un-adopt” Rust, but I think I’m pretty far removed from usage that Rust devs would consider “mainstream”.

                3. 2

                  http://old.reddit.com/f47x4o for the nj peeps