8 ms·

C++20 is coming into a world with much more competition than C++11 did (the last comparably sized standard). When C++11 came out Rust, Go, Zig, Swift were all e

C++20 is coming into a world with much more competition than C++11 did (the last comparably sized standard). When C++11 came out Rust, Go, Zig, Swift were all either in their infancy or didn’t exist yet. There was a huge desire for C++ to improve and improve fast given its centrality. That world is not today’s world. Projects that would have been written in C++ in the past are often written in a different language now. This leaves C++ being useful mostly for legacy codebases, of which adopting new standards quickly is not so important.

pjmlp 5y ago
None of those languages have the ecosystems that make C++ still relevant today.
qalmakka 5y ago
I think a large reason of why Clang lags behind in C++ standards is that Google and Apple don't really use modern C++ at all. Google has strict guidelines that prevent people to use half of the language (look at exceptions, for instance, without which most of the STL is crippled) and they use Abseil anyway, so they don't really care about the STL in the first place. Apple on the other hand mostly uses C++ in very restricted scopes such as DeviceKit which are very limited and can't safely use the entire language anyway. Xcode-shipped Clang and libcxx are often pretty old, too. They don't really need C++ that much above what C++03 already had, so it's clearly an afterthought for them.
- _0w8t 5y ago
  Chromium finally switched to C++17 this year. The switch to C++20 will happen much sooner given that PNaCL support will be finally removed this summer.
- gpderetta 5y ago
  That alone doesn't explain why clang conformance was very good till c++17 and then suddenly fell behind. The major clang contributors decided to focus their attention elsewhere, One guess is because they didn't get what they wanted within the committee.
  - pjmlp 5y ago
    Google basically withdraw from clang after they lost the ABI vote, and Intel is now taking care of what used to be mostly Google stuff. If I remember correctly some discussions on /r/cpp. As for Apple, OP is right, Metal Shaders are based on C++14 dialect, IOKit/DriverKit use an Embedded C++ dialect, and for everything else there is Objective-C/Swift, and they only need enough C++ to use LLVM to develop them.
    - 3836293648 5y ago
      Was google pushing for breaking the ABI?
      - codys 5y ago
        - a WG paper by a google employee regarding breaking the C++ ABI: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1863r1.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p186... - A post about a C++ ABI break being voted against: https://cor3ntin.github.io/posts/abi/ https://cor3ntin.github.io/posts/abi/ I would not be surprised if google (or others in favor of breaking the ABI for the c++ standard library) would refocus on their alternate non-std std-replacement-ish library implementations (like abseil) instead given the lack of willingness to fix things in std proper from the committee.
        3836293648 5y ago
        Yeah, I've seen both of those before, but was unsure if it was just the position of a single Google employee or the position of google as a whole, as you made it sound like Google the company had actually taken such a stand
    - lenkite 5y ago
      The permanent-ABI compatibility decision was effectively the death-knell for C++. Can't improve the standard library performance, making it effectively useless for the real world. Can't correct mistakes - the language and library warts grow and grow as the years pass by, making it impossible for beginners to pick up and learn the language. Frankly, Google should fork C++ and create a new language without the warts and a new standard library.
- mrpippy 5y ago
  Apple’s public/external-facing uses of C++ are restricted and odd (MSL, IOKit), but internally it seems pretty common in the OSes. Dyld, font rendering, and lower-level event handling (the remains of Carbon/HIToolbox) are all things I’ve seen in stack traces. And of course there’s also WebKit and LLVM.
  - pjmlp 5y ago
    WebKit standard requires C++17, while LLVM still on C++14, so no pressure from Apple side to move forward, https://webkit.org/languages-staged-08192020 https://webkit.org/languages-staged-08192020 https://llvm.org/docs/CodingStandards.html#c-standard-versions https://llvm.org/docs/CodingStandards.html#c-standard-versio...
- erwincoumans 5y ago
  C++ is great to have as much control over memory and performance as possible, while still providing more convenience than C. The C++ Standard Library and exceptions don't improve this control generally. Possibly an unpopular opinion, but personally I wish the C++ Standard Library was kept separate from the C++ language and have the C++ committee focus on the language features instead.
  - codeflo 5y ago
    My impression is that this is an opinion about the stdlib that many programmers concerned with performance share.
  - aninteger 5y ago
    > Possibly an unpopular opinion, but personally I wish the C++ Standard Library was kept separate from the C++ language and have the C++ committee focus on the language features instead. This is not an unpopular opinion.
- kccqzy 5y ago
  The Google style guide is public: https://google.github.io/styleguide/cppguide.html https://google.github.io/styleguide/cppguide.html I think reading it would convince you that the statement Google doesn't use modern C++ at all is false. It talks about modern features like CTAD.
einpoklum 5y ago
> This leaves C++ being useful mostly for legacy codebases I'm pretty sure people said that about C++ when Java became popular. Rust seems like a fine language, Zig sounds interesting, and Go and Swift I'm not familiar with. But I don't really buy your argument.
- xedrac 5y ago
  Java could never fill all of the spaces that C++ is used for because of the JVM and garbage collection. Rust certainly could, and should, in my opinion as a long time C++ developer.
  - lelanthran 5y ago
    > Rust certainly could, and should, in my opinion as a long time C++ developer. I'm not a Rust dev, but I am curious how things like epoll would work in Rust. In C (or C++) I place a pointer to a structure in the epoll `event.data.ptr` field. When an event is returned by epoll_wait() all the caller has to do is run a function on that instance in `event.data.ptr`. It seems to me, that even with `unsafe`, you're not going to be able to do this in Rust unless all the code is unsafe. You cannot transfer ownership of the instance to `event.data.ptr`, can you mark the pointer or event structure itself as `unsafe`?
    - zbentley 5y ago
      > you're not going to be able to do this in Rust unless all the code is unsafe. Why wouldn't std::mem::transmute (plus a little bit of hand-managed lifetime emulation) work here? It is unsafe, but doesn't require the unsafe modifier to be present on code beyond where the transmute happens. Unless by "all the code is unsafe" you mean related code is conceptually at risk of unsafety due to bugs caused by erroneous reinterpret-casts, then I think transmute should work here.
    - adwn 5y ago
      I don't see why that would require making all code unsafe? You might want to take a look at mio's source code [1], which uses epoll on Linux [2], and which encapsulates epoll in a safe way. [1] https://github.com/tokio-rs/mio https://github.com/tokio-rs/mio [2] https://tokio-rs.github.io/mio/doc/mio/struct.Poll.html#implementation-notes https://tokio-rs.github.io/mio/doc/mio/struct.Poll.html#impl...
stingraycharles 5y ago
I think you’re blissfully unaware of just how many developers are still being trained in C/C++ this day. I agree with you that in the long run, Rust has everything going for it to replace C++, but these types of things happen in a span of several decades, not years.
- FpUser 5y ago
  I think Rust has the potential to coexist with C++. As for replacement - here is my shallow outlook (I only care about how new tech affects my own business). The safety offered by Rust is not a thing to ignore. However modern C++ and the tooling has made enough progress in the area. It is extremely rare for me to allocate explicitly and in the couple cases where I do I always write deallocator first. It is ingrained in my nature along with some other related habits. Invalid memory access is also less likely with modern constructs. Along with memory sanitizers and practical experience with my own products I feel that Rust memory safety at this point does not offer much from my practical point of view. I value very much time spent on compiling / building. From few experiments I made Rust is not any faster in this department. Rather the opposite. As for C++ being a monster impossible to comprehend in its entirety. Agree and do not give a flying fuck. I am not there to explore language to its utmost depths. It is just a tool for me and nothing more. I do not get hung up on tools. As long as the tool lets me do my job with the reasonable ease (and subset of modern C++ definitely does) the rest does not matter. I do not feel inferior for not willing to spend the rest of my life trying to become Alexandrescu.
  - qalmakka 5y ago
    I write C++ for a living and I admit I do like to push it to its limits (SFINAE, constexpr/type traits shenanigans, the more the merrier), but it must be acknowledged that it tends to become too much akin to magic the more you push the envelope. Stuff like having 10 kinds of initialization and name resolution being incredibly complex and convoluted is a bit more confusing than what should be considered acceptable in a programming language. Still I love the utter madness that there's behind C++, and the fact you can basically do everything you set yourself to, no matter how crazy and weird it is, as long as you accept to put up with the madness. You can emulate a good 90% of what Rust does with traits if you really want to.
sicp-enjoyer 5y ago
> C++20 is coming into a world with much more competition I question whether those are actually competing in this same realm, for large organizations. Language adopotion is not just about the language, but also tooling, libraries, standard, etc which organizations have built up and rely on. For example, at Apple C++ is used more internally than is exposed in public APIS. (I can't imagine the swift compilers performance scaling up to large code bases at this point.) Can you speculate on other reasons, besides competition for the slower rate of adoption? Is it not as helpful as previous standards? Is it more difficult to implement?
- worik 5y ago
  > (I can't imagine the swift compilers performance scaling up to large code bases at this point.) It struggles on medium sized code bases. And Xcode becomes flaky too, on medium code bases. Works absolutely brilliantly on the small examples that are used to market it. I have been using it for two years, and fundamental bugs in the system have not been fixed in that time. (The code inspection tools in the debugger are close to useless) The last time I updated it my computer spent over three hours with the installer running at 100%. What on Earth was it doing? Mining bitcoin? A whole lot of things are clearly going very wrong behind the scenes
  - sicp-enjoyer 5y ago
    I have had the same experience. This is one factor that leads me to believe Apple is mostly using C++ internally.
    - KerrAvon 5y ago
      Nah, C++ is mostly frowned upon inside Apple. The open source projects (clang and Darwin) contain most of the C++ in the OS. Objective-C is the ubiquitous implementation language in Apple's macOS/iOS/tvOS/watchOS userspace code. It will eventually be superseded by Swift as the Swift runtime improves. All userspace projects and some kernel projects are built in Xcode, and most developers internally use Xcode to edit the sources.
jandrewrogers 5y ago
If you are building high-performance, high-scale systems software (e.g. database engines), modern C++ is by far the preferred choice for new software projects and next generation systems. The notion of C++ being "useful mostly for legacy codebases" is not in evidence. The reality, for better or worse, is that there is no satisfactory replacement currently for C++ for important classes of software even if starting from a completely blank slate. I like some of those other languages, they just can't do the job in a reasonable way. The reason modern C++ is still the preferred language for some types of software is that it is significantly more expressive in critical ways, which has a substantial impact on software robustness, maintainability, and performance. You could use those other languages, but it would produce a substantially worse product and/or codebase. To put it another way, there is often no way to translate an existing elegant modern C++ codebase into those other languages without major compromises to either the codebase or performance. And for the kinds of applications where C++ is preferred, those compromises are largely unacceptable. Maybe some of those other languages will approach the practical expressiveness of modern C++ for this kind of software eventually, but not anytime in the near future.
- mbrodersen 5y ago
  There are literally millions of C++ developers out there. And that number is growing. There are new C++ projects started every single day. It will take a very long time for any other language to compete with C++. I agree that most biz software that doesn’t require high performance should be written in something else. But there are many application areas where C++ still completely dominates. Look at commercial games for example, browsers, JIT compilers etc. Yes Rust might be able to do a good job in those domains but it is hard to compare with the C++ momentum.
- seeekr 5y ago
  I would be very interested in hearing a few concrete examples!
- pcwalton 5y ago
  This is not true. Nor is the post you're replying to, for what it's worth. Rust and C++ are roughly equally expressive for high-performance, high-scale software. The reasons to use one or the other for new code have little to do with whether each language can do the job; clearly, both languages can. Rather, what dominates are factors like whether your build/deployment system is set up to handle one language or another, what your engineers are experienced in, whether you care about memory safety, etc. Source: I'm one of the maintainers of Rust at a large organization you have heard of that very much cares about high-performance, high-scale systems software.
LeFantome 5y ago
While I agree with the underlying point, I doubt that the statement “This leaves C++ being useful mostly for legacy codebases” is true. I see new projects started in C++ all the time in my industry ( automotive video essentially ). In the Open Source world, I see it a lot too. SerenityOS comes to mind. You can hardly call that a legacy code base. In Microsoft land, C++ still seems like the go-to language everywhere outside of .NET with new APIs still being created. There is some interest in Rust but it still seems early and it is not at all obvious that Rust will push C++ aside ( though I would love it to ).
- mbrodersen 5y ago
  Microsoft tried to convince all C++ developers to switch to C# and completely and utterly failed. It was amusing to see how quickly they switched back to supporting C++ after years of pretending that C++ had no future.
osigurdson 5y ago
>> When C++11 came out Rust, Go, Zig, Swift were all either in their infancy or didn’t exist yet I don't see Go as a natural C++ competitor. Go primarily competes with Java and C#.
_wldu 5y ago
C++0x is one of the reasons Go was created. C++ was getting far too complex: "For me, the reason I was enthusiastic about Go was just about the same time we were starting on Go, I read (or tried to read) the C++0x proposed standard. And that was the convincer for me." - Ken Thompson 17:45 mark here: https://www.youtube.com/watch?v=sln-gJaURzk https://www.youtube.com/watch?v=sln-gJaURzk
- pjmlp 5y ago
  And then most C++ developers didn't care, as Go isn't was they were looking for, https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html https://commandcenter.blogspot.com/2012/06/less-is-exponenti...

pjmlp 5y ago

None of those languages have the ecosystems that make C++ still relevant today.

qalmakka 5y ago

I think a large reason of why Clang lags behind in C++ standards is that Google and Apple don't really use modern C++ at all. Google has strict guidelines that prevent people to use half of the language (look at exceptions, for instance, without which most of the STL is crippled) and they use Abseil anyway, so they don't really care about the STL in the first place. Apple on the other hand mostly uses C++ in very restricted scopes such as DeviceKit which are very limited and can't safely use the entire language anyway. Xcode-shipped Clang and libcxx are often pretty old, too. They don't really need C++ that much above what C++03 already had, so it's clearly an afterthought for them.

_0w8t 5y ago
Chromium finally switched to C++17 this year. The switch to C++20 will happen much sooner given that PNaCL support will be finally removed this summer.
gpderetta 5y ago
That alone doesn't explain why clang conformance was very good till c++17 and then suddenly fell behind. The major clang contributors decided to focus their attention elsewhere, One guess is because they didn't get what they wanted within the committee.
- pjmlp 5y ago
  Google basically withdraw from clang after they lost the ABI vote, and Intel is now taking care of what used to be mostly Google stuff. If I remember correctly some discussions on /r/cpp. As for Apple, OP is right, Metal Shaders are based on C++14 dialect, IOKit/DriverKit use an Embedded C++ dialect, and for everything else there is Objective-C/Swift, and they only need enough C++ to use LLVM to develop them.
  - 3836293648 5y ago
    Was google pushing for breaking the ABI?
    - codys 5y ago
      - a WG paper by a google employee regarding breaking the C++ ABI: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1863r1.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p186... - A post about a C++ ABI break being voted against: https://cor3ntin.github.io/posts/abi/ https://cor3ntin.github.io/posts/abi/ I would not be surprised if google (or others in favor of breaking the ABI for the c++ standard library) would refocus on their alternate non-std std-replacement-ish library implementations (like abseil) instead given the lack of willingness to fix things in std proper from the committee.
      - 3836293648 5y ago
        Yeah, I've seen both of those before, but was unsure if it was just the position of a single Google employee or the position of google as a whole, as you made it sound like Google the company had actually taken such a stand
  - lenkite 5y ago
    The permanent-ABI compatibility decision was effectively the death-knell for C++. Can't improve the standard library performance, making it effectively useless for the real world. Can't correct mistakes - the language and library warts grow and grow as the years pass by, making it impossible for beginners to pick up and learn the language. Frankly, Google should fork C++ and create a new language without the warts and a new standard library.
mrpippy 5y ago
Apple’s public/external-facing uses of C++ are restricted and odd (MSL, IOKit), but internally it seems pretty common in the OSes. Dyld, font rendering, and lower-level event handling (the remains of Carbon/HIToolbox) are all things I’ve seen in stack traces. And of course there’s also WebKit and LLVM.
- pjmlp 5y ago
  WebKit standard requires C++17, while LLVM still on C++14, so no pressure from Apple side to move forward, https://webkit.org/languages-staged-08192020 https://webkit.org/languages-staged-08192020 https://llvm.org/docs/CodingStandards.html#c-standard-versions https://llvm.org/docs/CodingStandards.html#c-standard-versio...
erwincoumans 5y ago
C++ is great to have as much control over memory and performance as possible, while still providing more convenience than C. The C++ Standard Library and exceptions don't improve this control generally. Possibly an unpopular opinion, but personally I wish the C++ Standard Library was kept separate from the C++ language and have the C++ committee focus on the language features instead.
- codeflo 5y ago
  My impression is that this is an opinion about the stdlib that many programmers concerned with performance share.
- aninteger 5y ago
  > Possibly an unpopular opinion, but personally I wish the C++ Standard Library was kept separate from the C++ language and have the C++ committee focus on the language features instead. This is not an unpopular opinion.
kccqzy 5y ago
The Google style guide is public: https://google.github.io/styleguide/cppguide.html https://google.github.io/styleguide/cppguide.html I think reading it would convince you that the statement Google doesn't use modern C++ at all is false. It talks about modern features like CTAD.

einpoklum 5y ago

> This leaves C++ being useful mostly for legacy codebases I'm pretty sure people said that about C++ when Java became popular. Rust seems like a fine language, Zig sounds interesting, and Go and Swift I'm not familiar with. But I don't really buy your argument.

xedrac 5y ago
Java could never fill all of the spaces that C++ is used for because of the JVM and garbage collection. Rust certainly could, and should, in my opinion as a long time C++ developer.
- lelanthran 5y ago
  > Rust certainly could, and should, in my opinion as a long time C++ developer. I'm not a Rust dev, but I am curious how things like epoll would work in Rust. In C (or C++) I place a pointer to a structure in the epoll `event.data.ptr` field. When an event is returned by epoll_wait() all the caller has to do is run a function on that instance in `event.data.ptr`. It seems to me, that even with `unsafe`, you're not going to be able to do this in Rust unless all the code is unsafe. You cannot transfer ownership of the instance to `event.data.ptr`, can you mark the pointer or event structure itself as `unsafe`?
  - zbentley 5y ago
    > you're not going to be able to do this in Rust unless all the code is unsafe. Why wouldn't std::mem::transmute (plus a little bit of hand-managed lifetime emulation) work here? It is unsafe, but doesn't require the unsafe modifier to be present on code beyond where the transmute happens. Unless by "all the code is unsafe" you mean related code is conceptually at risk of unsafety due to bugs caused by erroneous reinterpret-casts, then I think transmute should work here.
  - adwn 5y ago
    I don't see why that would require making all code unsafe? You might want to take a look at mio's source code [1], which uses epoll on Linux [2], and which encapsulates epoll in a safe way. [1] https://github.com/tokio-rs/mio https://github.com/tokio-rs/mio [2] https://tokio-rs.github.io/mio/doc/mio/struct.Poll.html#implementation-notes https://tokio-rs.github.io/mio/doc/mio/struct.Poll.html#impl...

stingraycharles 5y ago

I think you’re blissfully unaware of just how many developers are still being trained in C/C++ this day. I agree with you that in the long run, Rust has everything going for it to replace C++, but these types of things happen in a span of several decades, not years.

FpUser 5y ago
I think Rust has the potential to coexist with C++. As for replacement - here is my shallow outlook (I only care about how new tech affects my own business). The safety offered by Rust is not a thing to ignore. However modern C++ and the tooling has made enough progress in the area. It is extremely rare for me to allocate explicitly and in the couple cases where I do I always write deallocator first. It is ingrained in my nature along with some other related habits. Invalid memory access is also less likely with modern constructs. Along with memory sanitizers and practical experience with my own products I feel that Rust memory safety at this point does not offer much from my practical point of view. I value very much time spent on compiling / building. From few experiments I made Rust is not any faster in this department. Rather the opposite. As for C++ being a monster impossible to comprehend in its entirety. Agree and do not give a flying fuck. I am not there to explore language to its utmost depths. It is just a tool for me and nothing more. I do not get hung up on tools. As long as the tool lets me do my job with the reasonable ease (and subset of modern C++ definitely does) the rest does not matter. I do not feel inferior for not willing to spend the rest of my life trying to become Alexandrescu.
- qalmakka 5y ago
  I write C++ for a living and I admit I do like to push it to its limits (SFINAE, constexpr/type traits shenanigans, the more the merrier), but it must be acknowledged that it tends to become too much akin to magic the more you push the envelope. Stuff like having 10 kinds of initialization and name resolution being incredibly complex and convoluted is a bit more confusing than what should be considered acceptable in a programming language. Still I love the utter madness that there's behind C++, and the fact you can basically do everything you set yourself to, no matter how crazy and weird it is, as long as you accept to put up with the madness. You can emulate a good 90% of what Rust does with traits if you really want to.

sicp-enjoyer 5y ago

> C++20 is coming into a world with much more competition I question whether those are actually competing in this same realm, for large organizations. Language adopotion is not just about the language, but also tooling, libraries, standard, etc which organizations have built up and rely on. For example, at Apple C++ is used more internally than is exposed in public APIS. (I can't imagine the swift compilers performance scaling up to large code bases at this point.) Can you speculate on other reasons, besides competition for the slower rate of adoption? Is it not as helpful as previous standards? Is it more difficult to implement?

worik 5y ago
> (I can't imagine the swift compilers performance scaling up to large code bases at this point.) It struggles on medium sized code bases. And Xcode becomes flaky too, on medium code bases. Works absolutely brilliantly on the small examples that are used to market it. I have been using it for two years, and fundamental bugs in the system have not been fixed in that time. (The code inspection tools in the debugger are close to useless) The last time I updated it my computer spent over three hours with the installer running at 100%. What on Earth was it doing? Mining bitcoin? A whole lot of things are clearly going very wrong behind the scenes
- sicp-enjoyer 5y ago
  I have had the same experience. This is one factor that leads me to believe Apple is mostly using C++ internally.
  - KerrAvon 5y ago
    Nah, C++ is mostly frowned upon inside Apple. The open source projects (clang and Darwin) contain most of the C++ in the OS. Objective-C is the ubiquitous implementation language in Apple's macOS/iOS/tvOS/watchOS userspace code. It will eventually be superseded by Swift as the Swift runtime improves. All userspace projects and some kernel projects are built in Xcode, and most developers internally use Xcode to edit the sources.

jandrewrogers 5y ago

If you are building high-performance, high-scale systems software (e.g. database engines), modern C++ is by far the preferred choice for new software projects and next generation systems. The notion of C++ being "useful mostly for legacy codebases" is not in evidence. The reality, for better or worse, is that there is no satisfactory replacement currently for C++ for important classes of software even if starting from a completely blank slate. I like some of those other languages, they just can't do the job in a reasonable way. The reason modern C++ is still the preferred language for some types of software is that it is significantly more expressive in critical ways, which has a substantial impact on software robustness, maintainability, and performance. You could use those other languages, but it would produce a substantially worse product and/or codebase. To put it another way, there is often no way to translate an existing elegant modern C++ codebase into those other languages without major compromises to either the codebase or performance. And for the kinds of applications where C++ is preferred, those compromises are largely unacceptable. Maybe some of those other languages will approach the practical expressiveness of modern C++ for this kind of software eventually, but not anytime in the near future.

mbrodersen 5y ago
There are literally millions of C++ developers out there. And that number is growing. There are new C++ projects started every single day. It will take a very long time for any other language to compete with C++. I agree that most biz software that doesn’t require high performance should be written in something else. But there are many application areas where C++ still completely dominates. Look at commercial games for example, browsers, JIT compilers etc. Yes Rust might be able to do a good job in those domains but it is hard to compare with the C++ momentum.
seeekr 5y ago
I would be very interested in hearing a few concrete examples!
pcwalton 5y ago
This is not true. Nor is the post you're replying to, for what it's worth. Rust and C++ are roughly equally expressive for high-performance, high-scale software. The reasons to use one or the other for new code have little to do with whether each language can do the job; clearly, both languages can. Rather, what dominates are factors like whether your build/deployment system is set up to handle one language or another, what your engineers are experienced in, whether you care about memory safety, etc. Source: I'm one of the maintainers of Rust at a large organization you have heard of that very much cares about high-performance, high-scale systems software.

LeFantome 5y ago

While I agree with the underlying point, I doubt that the statement “This leaves C++ being useful mostly for legacy codebases” is true. I see new projects started in C++ all the time in my industry ( automotive video essentially ). In the Open Source world, I see it a lot too. SerenityOS comes to mind. You can hardly call that a legacy code base. In Microsoft land, C++ still seems like the go-to language everywhere outside of .NET with new APIs still being created. There is some interest in Rust but it still seems early and it is not at all obvious that Rust will push C++ aside ( though I would love it to ).

mbrodersen 5y ago
Microsoft tried to convince all C++ developers to switch to C# and completely and utterly failed. It was amusing to see how quickly they switched back to supporting C++ after years of pretending that C++ had no future.

osigurdson 5y ago

>> When C++11 came out Rust, Go, Zig, Swift were all either in their infancy or didn’t exist yet I don't see Go as a natural C++ competitor. Go primarily competes with Java and C#.

_wldu 5y ago

C++0x is one of the reasons Go was created. C++ was getting far too complex: "For me, the reason I was enthusiastic about Go was just about the same time we were starting on Go, I read (or tried to read) the C++0x proposed standard. And that was the convincer for me." - Ken Thompson 17:45 mark here: https://www.youtube.com/watch?v=sln-gJaURzk https://www.youtube.com/watch?v=sln-gJaURzk

pjmlp 5y ago
And then most C++ developers didn't care, as Go isn't was they were looking for, https://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html https://commandcenter.blogspot.com/2012/06/less-is-exponenti...