29 ms·

I think using this feature is the wrong advice. Frankly I think much of modern C++ should be rejected. If you want to use a language like with those features th

I think using this feature is the wrong advice. Frankly I think much of modern C++ should be rejected. If you want to use a language like with those features then fricken switch language! There are countless better alternatives today: Rust, Swift, D, Haskell etc. Many are stuck on C++ for legacy reasons. I have worked in such large C++ legacy systems for many years in the past. The average programmer simply cannot deal effectively with this modern C++. It is too complex. I’ve been down that road being exited about new C++ features only to realize that I’ve actually reduced the productivity of my co-workers. Often I wonder if C++ programmers all suffer a Stockholm syndrome. They have come to sympathize with their hostage taker C++, making up excuses for the many ways C++ abuse and terrorize them. I go to these C++ conference talks in occasion and I see people in ecstatic praise about how some genius C++ guru came up with an elaborate convoluted solution to something which is like two lines of code in a sane programming language. Seriously I think C++ has drained so much of their brainpower that they have simply not been able to look outside and see how the grass is greener everywhere else.

otabdeveloper4 6y ago
> There are countless better alternatives today: Rust, Swift, D, Haskell etc. These aren't alternatives and are strictly worse as far as language power and expressiveness goes. There is some value in simpler and dumber languages, but your post essentially boils down to an anti-intellectual "programming is hard, let's go shopping instead". Some people need complex tools to solve complex problems.
- dralley 6y ago
  Rust and D are not "strictly worse". They are better in some respects and occasionally worse in others, but even there the gap has been shrinking.
  - otabdeveloper4 6y ago
    The context makes it clear that what's meant is "strictly worse as a C++ alternative". Rust, like you said, isn't there yet. And I'd take issue with the claim that the gap has been shrinking - C++ right now is developing at a faster pace than Rust.
  - chromatin 6y ago
    Rust is excellent overall, but is lacking in interoperability (I mean, it is capable -- but iterop is burdensome, relatively). Related to the overall topic of sum types, there is ergonomic support in the form of built-in enum. D is excellent overall (and I think sadly under-recognized for this), but it is lacking in ecosystem. Related to the overall topic of sum types, there is an excellent library, `sumtype` which recently hit 1.0 status. I much prefer either of these to modern C++.
    - api 6y ago
      Interoperability is generally a disaster. Most languages can interoperate with C ABI functions, but even that is painful in some cases. It seems like most languages consider this an afterthought when it should be a central consideration. There will never be a time when everything is written in just one language.
      - jeltz 6y ago
        The only languages I know of with good C interoperability are C++ and Zig. This is definitely an area where Rust could improve.
        touisteur 6y ago
        Don't forget Ada where interop with C is baked in the language spec and interop with c++ has been muuuch improved some years ago.
        Silhouette 6y ago
        How would you define "good C interoperability"?
        api 6y ago
        Calling C functions with minimal fuss and good performance, which requires C header parsing and linking or DLL loading support. It also requires built in or standard library support for whatever convenience types and functions are needed to make using real C APIs pleasant and as safe as possible. Support for exporting functions and passing function pointers the other way is great too if it can be done. Go with CGo is okay from a usability perspective but performance is poor. I haven't looked much at Rust's implementation so I can't comment. I've also heard Python is not bad.
- geofft 6y ago
  The amount of complexity you can have in a system without it falling over is finite. You need to find simple tools, or at least comprehensible abstractions and simple compositions, to solve complex problems. You can only afford to use complex tools when solving simple problems.
  - otabdeveloper4 6y ago
    C++ is a simple tool with comprehensible abstractions. You just don't understand it because you don't have experience with how computers and compilers work under the hood of dynamic languages.
    - snazz 6y ago
      That’s a big assumption to make. I think it’s valid to say that C++ is complex and more difficult to understand than other compiled languages without resorting to ad hominem arguments.
      - detaro 6y ago
        To be fair, the root comment started by suggesting mental illnesses in C++ programmers, so charged responses are to be expected.
        nchi3 6y ago
        Stockholm syndrome isn't a mental illness, nor is it derigatory.
        detaro 6y ago
        Suggesting everyone using C++ isn't capable of properly evaluating it (which the comment author can clearly tell from the outside, for every use case) is "not derogatory"? (and from what I understand "Stockholm syndrome" is not classified as a medical condition because it's questioned if it actually exists as thing that can be usefully delineated, not because it wouldn't qualify) I'm certainly not claiming "C++ is perfect and everything else is useless" or "Rust doesn't stand a chance", but this "there has to be something wrong with you if you use it/ever consider it more suitable" is seriously annoying, and disappointing to see as the top comment here (even if it's not the worst pro-rust denigration of C++-users I've seen). And is damaging the chances Rust et al have in these spaces.
- api 6y ago
  It’s not complex problems. It’s being close to the metal. Rust isn’t bad but it’s still not as good as C or C++ if you need to get every last bit of performance or need to be really close to the OS and hardware. Rust is coming along though. It’s the first language I have seen that might unseat C++.
  - otabdeveloper4 6y ago
    > It’s the first language I have seen that might unseat C++. Doubtful, as C++ has language standards and a visible, comprehensible story on how they evolve. C++ has also been evolving faster than Rust. Right now Rust fills the "C++ with training wheels" niche - when you need a language in this space but don't have the energy or time to disentangle the sordid story of all the crufty legacy systems built around C++ after all this time. But in principle if somebody made a well thought-out onboarding story for C++ then there's be little point in Rust. P.S. But you say "my borrow checker" - well, sorry to disappoint you, people don't really care and actually view it as an impediment in learning Rust, not as a feature. If Rust had no borrow checker it'd be an even more popular language.
    - Cyph0n 6y ago
      The borrow checker is one of Rust’s selling main selling points, and was what got me into the language. If you don’t see the value of compile-time memory safety in Rust, you probably haven’t spent hours debugging subtle runtime memory safety errors in a large C application.
      - otabdeveloper4 6y ago
        Read my post again, please. The people who choose Rust over C++ aren't (generally speaking, there are of course exceptions) doing because of the borrow checker. They're doing because Rust has Cargo and C++ doesn't.
        steveklabnik 6y ago
        I think it is extremely hard to generalize here.
- nindalf 6y ago
  I’d love to read your detailed comparison of C++ with all of the languages you mentioned. You seem certain that they’re strictly worse. I can make the case that in some circumstances like low latency requirements, C++ is superior to a GC language like Haskell. But it’s harder to make the case that it’s “strictly” better.
  - knuthsat 6y ago
    Most abstractions discussed in the article have a runtime cost in Haskell and zero cost in C++.
- DerDangDerDang 6y ago
  Against massive initial skepticism, I’m becoming very impressed with Rust. I’m now going to be ‘that guy’ - apologies. After years of being annoyed by Rust people claiming C++ is dying or too unsafe or whatever, I expected this to be another C# - a sort of C-with-training-wheels for people who care more about productivity than perf. Something I could safely ignore. This ‘borrow checker’ stuff sounds great for kids, but for disciplined experienced C++ guys it’s at best a non feature and at worst would just get in the way, like GC, right? In fact, I’m finding the reduced mental overhead (not just from borrow, but from the language as a whole being smaller and more consistent) is a huge win. Even learning the language and stdlib as I go. I’ll still use C++ proudly where it’s the best choice, but I’d put some effort into trying Rust first. As a cpp-master-race guy, that surprised the crap out of me.
  - amelius 6y ago
    Have you tried writing self-referential data structures, like doubly linked lists?
    - nchi3 6y ago
      Self-referential data structures are a code smell in non-GCd languages, and I think I have neither used or written a doubly linked list since university. You can do both in unsafe rust though. But you probably shouldn't no matter what high level non-GCd language you use. /Another ex-cpp-master-race guy who has been impressed with Rust
      - cycloptic 6y ago
        I see doubly-linked lists and other self-referential structures all the time in low-level code. Boost even has a whole library dedicated to them: http://www.boost.org/libs/intrusive http://www.boost.org/libs/intrusive
        steveklabnik 6y ago
        For a really interesting take on this area, see http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performance-of-c-and-rust/ http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performa... Specifically, the discussion about intrusive vs non-intrusive data structures and their frequency.
FartyMcFarter 6y ago
Maybe there's some truth to what you're saying. But at the same time, there aren't many alternatives that tick all the boxes C++ does (performance, portability, maturity and stability). Together with the amount of C++ code that exists, I don't see C++ going away anytime soon. Ironically, if one wants all of those things, the best alternative at the moment may be the C language.
- jeltz 6y ago
  Rust has all of those other than portability. Rust's ecosystem while it is missing some things it also has things which are lacking in C++ like a good mature package manager.
  - User23 6y ago
    > Rust has all of those other than portability. That's crippling. Arguably the best use case for C++ is coding video games, and portability is huge there.
    - stu2b50 6y ago
      The modern video game platforms are: PC, Xbox Series, PS5, Xbox One, PS4, Switch, Android, iOS, Web Of which Rust has backends for all them, even the web via wasm. While Rust is not as portable, it's not like it's strictly limited to well functioning x86 boxes, it'll produce binaries for anything that LLVM supports, which is quite a lot by now.
      - FartyMcFarter 6y ago
        > Of which Rust has backends for all them, even the web via wasm. Are those backends officially supported on consoles? Do all those consoles have libraries and tools (profilers, debuggers, etc) that support Rust?
        stu2b50 6y ago
        Yep, like in C++ it's trivially easy to use the platforms C apis. And indeed the debugger does work on all platform.
porknubbins 6y ago
Its interesting to me that in between the irreducible complexities of hardware/ x86 ops and real world domains C++ has emerged as an middle level of complexity in this stack. You can explore C++ features and syntax for years and there are entire podcasts and conferences that mostly just talk about language features and never run out of things to say. I wonder if some programmers are attracted to this complexity either for the challenge or because they enjoy exploring abstract human made systems.
mlang23 6y ago
It is not only legacy reasons why people are "stuck" with C++. In embedded and real-time applications, using a high level (GC'ed) language like Haskell is totally out of the question. D and Rust might be feasable, but typically lack the FFI you need for integration. I mention this because I recently wrote a DSP program for a (eurorack) synthesizer module, and C++ was pretty much the only sensible option. And I actually used variant in that codebase, even sending a (trivially copyable) variant over a RT queue to separate RT thread from UI. And std::visit was pretty useful in that context. I dont think it makes sense to rant against particular language/library features. Almost all of them are there fore a reason. It might just be that you dont see the reason right now. The design space for code is huge.
- socialdemocrat 6y ago
  You are specifically describing being stuck with C++ for legacy reasons despite trying to disprove it. You say you cannot use D and Rust because of the FFI needed for integration. How is that not a legacy issue? You got existing C++ code you need to integrate with. How is that not a legacy issue? What I am talking about is that if you don't have to use a C++ library to solve your task, there is simply no sane reason to pick C++.
  - mlang23 6y ago
    From such a futuristic point of view, I guess you are right. However, it will likely take a few decades until your wish is granted and everything has been rewritten language X. Calling all interfaces your OS gives you legacy is pretty far stretched man :-)
rualca 6y ago
> The average programmer simply cannot deal effectively with this modern C++. It is too complex. I interpret this assertion with a high dose of incredulity and skepticism. You're specifically referring to a single class that's a part of C++'s standard library. C++'s standard library is extremely spartan when compared with other programming languages, such as Java. It's unbelievable that C++'s inclusion of stuff such as std::visit in its standard library renders it "too complex" when the extend and arcane nature of other standard libraries are incomparably higher. Hell, some toolkits and frameworks are incomparably far more complex and we don't see them accused of being unusable.
- socialdemocrat 6y ago
  I am talking about the total cognitive load of modern C++. Not one specific class. I highly doubt people express in public that a particular library is too complex. They simply choose not to use it. I remember some Boost Graph library once. What a a mess. I never expressed publicly that I couldn't figure out how do use it. Nobody does that, because nobody wants to appear stupid. Instead I just wrote a graph library in C++ from scratch myself. Discovered that was faster than figuring out the template insanity in that Graph library. I have worked on usability for a number of years and done usability testing on people. And rarely if ever do anyone ever blame the system. They blame themselves. Or they shut up because they don't want to appear stupid. That is why when you do usability testing you have to sit an observe people. You cannot rely on questionnaires because people seldom admit the system was complex. Actually observing a variety of people try to program modern C++, would likely have been a rather sad experience.
dkersten 6y ago
When I use C++ (for personal projects), it tends to be because of the libraries I want to use (eg EnTT[1] or Immer[2], both of which use templates so can't be easily used from other languages). Eventually something like Rust or D may have equivalents to all the libraries I want and I could use those for such projects instead, but for now, if I want to use those things, I need to use C++. You may also want to look at this talk: "What C++ got Right" [3], where the guy shows some nice things that C++ does that other languages don't. The other languages versions of the code he shows does tend to be simpler and nicer, but the C++ versions tend to give you more control. Some people value that control (rightly or wrongly) and other languages that don't provide it will never feel right to them. I do personally quite like Rust and I'm eagerly watching Zig and some of the other new contenders, so I'm all for moving to something more pleasant than C++, but modern C++ gives just enough new niceness that I don't feel pushed to jump ship until the alternatives check more boxes. [1] https://github.com/skypjack/entt https://github.com/skypjack/entt [2] https://github.com/arximboldi/immer https://github.com/arximboldi/immer [3] https://www.youtube.com/watch?v=bMSrNBcir4Y&t=1757s https://www.youtube.com/watch?v=bMSrNBcir4Y&t=1757s
- suby 6y ago
  I'm not replying to detract from your point, because I agree with you whole heartedly that competing ecosystems are not mature enough to dethrown C++ if you're someone who is pragmatic and wants to get things done. C++ has an enormous number of high quality libraries with often no equivalents in competing languages. There are some compelling ECS frameworks emerging in Rust if anyone is interested, though. Legion -- https://github.com/amethyst/legion https://github.com/amethyst/legion Hecs -- https://github.com/Ralith/hecs https://github.com/Ralith/hecs Shipyard -- https://github.com/leudz/shipyard https://github.com/leudz/shipyard Specs -- https://github.com/amethyst/specs https://github.com/amethyst/specs Bevy -- https://github.com/bevyengine/bevy https://github.com/bevyengine/bevy -- not strictly comparable as it's an entire game engine, but it's built around an (imo) more ergonomic fork of hecs. Some benchmarks -- https://github.com/rust-gamedev/ecs_bench_suite https://github.com/rust-gamedev/ecs_bench_suite
  - dkersten 6y ago
FpUser 6y ago
I consider myself good architect but I am miles away from being deeply familiar with all of the sourcery of its metaprogramming facilities. I have real things to do and prefer to invest most of my mental efforts to more practical and productive things. I however do use C++ to write servers and if I do not try to play language guru in my code modern C++ along with the STL feels incredibly easy to use.
jasode 6y ago
>I think much of modern C++ should be rejected [...] then fricken switch language! There are countless better alternatives today: Rust, Swift, D, Haskell etc. The reality is that many projects are enabled more by existing libraries & tools rather than blank slate clean language syntax. Some example domains of libraries & tools where C++ is the 1st-class client instead of Rust/Swift/D/Haskell: + deep learning: NVIDIA CUDA api is C++ + HPC High Perfomance Computing: Intel MKL math library is C++ + physics engine for video games: Unreal game engine is C++ + latest cpu chip : ARM Allinea dev tools for the new ARM/Neoverse chips (e.g. latest AWS Graviton2 servers) is C++ + Qt GUI is C++ Because of the extensive C++ ecosystem, you get a counter-intuitive situation where programming the latest cutting-edge apps requires a 35-year-old language from 1985 instead of the newer Rust language from 2012. I predict this delta of tools+libraries between C++ and Rust/Swift will continue to exist for 10+ years. Recommending/lecturing people to use Rust/Swift/D overlooks the reasons that many programmers use C++. It's not a random choice. E.g., a realistic starting point for a project might be: "What's a good game engine... oh, it's Unreal, and that's C++." -- instead of -- "Rust has clean syntax of ownership and borrow with "&" ampersand symbol instead of ugly warts of unique_ptr<T> and std::move() in C++ so I'll code a game in Rust." Sometimes, we look at the ecosystem first, and then work backwards from that to make programming choices. It's when you have the luxury of a greenfield project that doesn't need legacy dependencies that choosing alternative cleaner syntax of Rust/Swift is possible. Amazon AWS and MS Azure are examples of doing new bare-metal projects with Rust instead of C++.
- DerDangDerDang 6y ago
  All true. Ironically the main thing keeping C++ relevant is the lack of a standard cross platform ABI. The moment interop with the C++ ecosystem becomes easier, the newer languages look so much more attractive.
  - spaetzleesser 6y ago
    Very true. It also makes working with C++ harder. It’s so easy to use different libraries with C#, Java or Python vs the struggle it is to integrate a C++ library.
  - 6y ago

otabdeveloper4 6y ago

> There are countless better alternatives today: Rust, Swift, D, Haskell etc. These aren't alternatives and are strictly worse as far as language power and expressiveness goes. There is some value in simpler and dumber languages, but your post essentially boils down to an anti-intellectual "programming is hard, let's go shopping instead". Some people need complex tools to solve complex problems.

dralley 6y ago
Rust and D are not "strictly worse". They are better in some respects and occasionally worse in others, but even there the gap has been shrinking.
- otabdeveloper4 6y ago
  The context makes it clear that what's meant is "strictly worse as a C++ alternative". Rust, like you said, isn't there yet. And I'd take issue with the claim that the gap has been shrinking - C++ right now is developing at a faster pace than Rust.
- chromatin 6y ago
  Rust is excellent overall, but is lacking in interoperability (I mean, it is capable -- but iterop is burdensome, relatively). Related to the overall topic of sum types, there is ergonomic support in the form of built-in enum. D is excellent overall (and I think sadly under-recognized for this), but it is lacking in ecosystem. Related to the overall topic of sum types, there is an excellent library, `sumtype` which recently hit 1.0 status. I much prefer either of these to modern C++.
  - api 6y ago
    Interoperability is generally a disaster. Most languages can interoperate with C ABI functions, but even that is painful in some cases. It seems like most languages consider this an afterthought when it should be a central consideration. There will never be a time when everything is written in just one language.
    - jeltz 6y ago
      The only languages I know of with good C interoperability are C++ and Zig. This is definitely an area where Rust could improve.
      - touisteur 6y ago
        Don't forget Ada where interop with C is baked in the language spec and interop with c++ has been muuuch improved some years ago.
      - Silhouette 6y ago
        How would you define "good C interoperability"?
        api 6y ago
        Calling C functions with minimal fuss and good performance, which requires C header parsing and linking or DLL loading support. It also requires built in or standard library support for whatever convenience types and functions are needed to make using real C APIs pleasant and as safe as possible. Support for exporting functions and passing function pointers the other way is great too if it can be done. Go with CGo is okay from a usability perspective but performance is poor. I haven't looked much at Rust's implementation so I can't comment. I've also heard Python is not bad.
geofft 6y ago
The amount of complexity you can have in a system without it falling over is finite. You need to find simple tools, or at least comprehensible abstractions and simple compositions, to solve complex problems. You can only afford to use complex tools when solving simple problems.
- otabdeveloper4 6y ago
  C++ is a simple tool with comprehensible abstractions. You just don't understand it because you don't have experience with how computers and compilers work under the hood of dynamic languages.
  - snazz 6y ago
    That’s a big assumption to make. I think it’s valid to say that C++ is complex and more difficult to understand than other compiled languages without resorting to ad hominem arguments.
    - detaro 6y ago
      To be fair, the root comment started by suggesting mental illnesses in C++ programmers, so charged responses are to be expected.
      - nchi3 6y ago
        Stockholm syndrome isn't a mental illness, nor is it derigatory.
        detaro 6y ago
        Suggesting everyone using C++ isn't capable of properly evaluating it (which the comment author can clearly tell from the outside, for every use case) is "not derogatory"? (and from what I understand "Stockholm syndrome" is not classified as a medical condition because it's questioned if it actually exists as thing that can be usefully delineated, not because it wouldn't qualify) I'm certainly not claiming "C++ is perfect and everything else is useless" or "Rust doesn't stand a chance", but this "there has to be something wrong with you if you use it/ever consider it more suitable" is seriously annoying, and disappointing to see as the top comment here (even if it's not the worst pro-rust denigration of C++-users I've seen). And is damaging the chances Rust et al have in these spaces.
api 6y ago
It’s not complex problems. It’s being close to the metal. Rust isn’t bad but it’s still not as good as C or C++ if you need to get every last bit of performance or need to be really close to the OS and hardware. Rust is coming along though. It’s the first language I have seen that might unseat C++.
- otabdeveloper4 6y ago
  > It’s the first language I have seen that might unseat C++. Doubtful, as C++ has language standards and a visible, comprehensible story on how they evolve. C++ has also been evolving faster than Rust. Right now Rust fills the "C++ with training wheels" niche - when you need a language in this space but don't have the energy or time to disentangle the sordid story of all the crufty legacy systems built around C++ after all this time. But in principle if somebody made a well thought-out onboarding story for C++ then there's be little point in Rust. P.S. But you say "my borrow checker" - well, sorry to disappoint you, people don't really care and actually view it as an impediment in learning Rust, not as a feature. If Rust had no borrow checker it'd be an even more popular language.
  - Cyph0n 6y ago
    The borrow checker is one of Rust’s selling main selling points, and was what got me into the language. If you don’t see the value of compile-time memory safety in Rust, you probably haven’t spent hours debugging subtle runtime memory safety errors in a large C application.
    - otabdeveloper4 6y ago
      Read my post again, please. The people who choose Rust over C++ aren't (generally speaking, there are of course exceptions) doing because of the borrow checker. They're doing because Rust has Cargo and C++ doesn't.
      - steveklabnik 6y ago
        I think it is extremely hard to generalize here.
nindalf 6y ago
I’d love to read your detailed comparison of C++ with all of the languages you mentioned. You seem certain that they’re strictly worse. I can make the case that in some circumstances like low latency requirements, C++ is superior to a GC language like Haskell. But it’s harder to make the case that it’s “strictly” better.
- knuthsat 6y ago
  Most abstractions discussed in the article have a runtime cost in Haskell and zero cost in C++.
DerDangDerDang 6y ago
Against massive initial skepticism, I’m becoming very impressed with Rust. I’m now going to be ‘that guy’ - apologies. After years of being annoyed by Rust people claiming C++ is dying or too unsafe or whatever, I expected this to be another C# - a sort of C-with-training-wheels for people who care more about productivity than perf. Something I could safely ignore. This ‘borrow checker’ stuff sounds great for kids, but for disciplined experienced C++ guys it’s at best a non feature and at worst would just get in the way, like GC, right? In fact, I’m finding the reduced mental overhead (not just from borrow, but from the language as a whole being smaller and more consistent) is a huge win. Even learning the language and stdlib as I go. I’ll still use C++ proudly where it’s the best choice, but I’d put some effort into trying Rust first. As a cpp-master-race guy, that surprised the crap out of me.
- amelius 6y ago
  Have you tried writing self-referential data structures, like doubly linked lists?
  - nchi3 6y ago
    Self-referential data structures are a code smell in non-GCd languages, and I think I have neither used or written a doubly linked list since university. You can do both in unsafe rust though. But you probably shouldn't no matter what high level non-GCd language you use. /Another ex-cpp-master-race guy who has been impressed with Rust
    - cycloptic 6y ago
      I see doubly-linked lists and other self-referential structures all the time in low-level code. Boost even has a whole library dedicated to them: http://www.boost.org/libs/intrusive http://www.boost.org/libs/intrusive
      - steveklabnik 6y ago
        For a really interesting take on this area, see http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performance-of-c-and-rust/ http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performa... Specifically, the discussion about intrusive vs non-intrusive data structures and their frequency.

FartyMcFarter 6y ago

Maybe there's some truth to what you're saying. But at the same time, there aren't many alternatives that tick all the boxes C++ does (performance, portability, maturity and stability). Together with the amount of C++ code that exists, I don't see C++ going away anytime soon. Ironically, if one wants all of those things, the best alternative at the moment may be the C language.

jeltz 6y ago
Rust has all of those other than portability. Rust's ecosystem while it is missing some things it also has things which are lacking in C++ like a good mature package manager.
- User23 6y ago
  > Rust has all of those other than portability. That's crippling. Arguably the best use case for C++ is coding video games, and portability is huge there.
  - stu2b50 6y ago
    The modern video game platforms are: PC, Xbox Series, PS5, Xbox One, PS4, Switch, Android, iOS, Web Of which Rust has backends for all them, even the web via wasm. While Rust is not as portable, it's not like it's strictly limited to well functioning x86 boxes, it'll produce binaries for anything that LLVM supports, which is quite a lot by now.
    - FartyMcFarter 6y ago
      > Of which Rust has backends for all them, even the web via wasm. Are those backends officially supported on consoles? Do all those consoles have libraries and tools (profilers, debuggers, etc) that support Rust?
      - stu2b50 6y ago
        Yep, like in C++ it's trivially easy to use the platforms C apis. And indeed the debugger does work on all platform.

porknubbins 6y ago

Its interesting to me that in between the irreducible complexities of hardware/ x86 ops and real world domains C++ has emerged as an middle level of complexity in this stack. You can explore C++ features and syntax for years and there are entire podcasts and conferences that mostly just talk about language features and never run out of things to say. I wonder if some programmers are attracted to this complexity either for the challenge or because they enjoy exploring abstract human made systems.

mlang23 6y ago

It is not only legacy reasons why people are "stuck" with C++. In embedded and real-time applications, using a high level (GC'ed) language like Haskell is totally out of the question. D and Rust might be feasable, but typically lack the FFI you need for integration. I mention this because I recently wrote a DSP program for a (eurorack) synthesizer module, and C++ was pretty much the only sensible option. And I actually used variant in that codebase, even sending a (trivially copyable) variant over a RT queue to separate RT thread from UI. And std::visit was pretty useful in that context. I dont think it makes sense to rant against particular language/library features. Almost all of them are there fore a reason. It might just be that you dont see the reason right now. The design space for code is huge.

socialdemocrat 6y ago
You are specifically describing being stuck with C++ for legacy reasons despite trying to disprove it. You say you cannot use D and Rust because of the FFI needed for integration. How is that not a legacy issue? You got existing C++ code you need to integrate with. How is that not a legacy issue? What I am talking about is that if you don't have to use a C++ library to solve your task, there is simply no sane reason to pick C++.
- mlang23 6y ago
  From such a futuristic point of view, I guess you are right. However, it will likely take a few decades until your wish is granted and everything has been rewritten language X. Calling all interfaces your OS gives you legacy is pretty far stretched man :-)

rualca 6y ago

> The average programmer simply cannot deal effectively with this modern C++. It is too complex. I interpret this assertion with a high dose of incredulity and skepticism. You're specifically referring to a single class that's a part of C++'s standard library. C++'s standard library is extremely spartan when compared with other programming languages, such as Java. It's unbelievable that C++'s inclusion of stuff such as std::visit in its standard library renders it "too complex" when the extend and arcane nature of other standard libraries are incomparably higher. Hell, some toolkits and frameworks are incomparably far more complex and we don't see them accused of being unusable.

socialdemocrat 6y ago
I am talking about the total cognitive load of modern C++. Not one specific class. I highly doubt people express in public that a particular library is too complex. They simply choose not to use it. I remember some Boost Graph library once. What a a mess. I never expressed publicly that I couldn't figure out how do use it. Nobody does that, because nobody wants to appear stupid. Instead I just wrote a graph library in C++ from scratch myself. Discovered that was faster than figuring out the template insanity in that Graph library. I have worked on usability for a number of years and done usability testing on people. And rarely if ever do anyone ever blame the system. They blame themselves. Or they shut up because they don't want to appear stupid. That is why when you do usability testing you have to sit an observe people. You cannot rely on questionnaires because people seldom admit the system was complex. Actually observing a variety of people try to program modern C++, would likely have been a rather sad experience.

dkersten 6y ago

When I use C++ (for personal projects), it tends to be because of the libraries I want to use (eg EnTT[1] or Immer[2], both of which use templates so can't be easily used from other languages). Eventually something like Rust or D may have equivalents to all the libraries I want and I could use those for such projects instead, but for now, if I want to use those things, I need to use C++. You may also want to look at this talk: "What C++ got Right" [3], where the guy shows some nice things that C++ does that other languages don't. The other languages versions of the code he shows does tend to be simpler and nicer, but the C++ versions tend to give you more control. Some people value that control (rightly or wrongly) and other languages that don't provide it will never feel right to them. I do personally quite like Rust and I'm eagerly watching Zig and some of the other new contenders, so I'm all for moving to something more pleasant than C++, but modern C++ gives just enough new niceness that I don't feel pushed to jump ship until the alternatives check more boxes. [1] https://github.com/skypjack/entt https://github.com/skypjack/entt [2] https://github.com/arximboldi/immer https://github.com/arximboldi/immer [3] https://www.youtube.com/watch?v=bMSrNBcir4Y&t=1757s https://www.youtube.com/watch?v=bMSrNBcir4Y&t=1757s

suby 6y ago
I'm not replying to detract from your point, because I agree with you whole heartedly that competing ecosystems are not mature enough to dethrown C++ if you're someone who is pragmatic and wants to get things done. C++ has an enormous number of high quality libraries with often no equivalents in competing languages. There are some compelling ECS frameworks emerging in Rust if anyone is interested, though. Legion -- https://github.com/amethyst/legion https://github.com/amethyst/legion Hecs -- https://github.com/Ralith/hecs https://github.com/Ralith/hecs Shipyard -- https://github.com/leudz/shipyard https://github.com/leudz/shipyard Specs -- https://github.com/amethyst/specs https://github.com/amethyst/specs Bevy -- https://github.com/bevyengine/bevy https://github.com/bevyengine/bevy -- not strictly comparable as it's an entire game engine, but it's built around an (imo) more ergonomic fork of hecs. Some benchmarks -- https://github.com/rust-gamedev/ecs_bench_suite https://github.com/rust-gamedev/ecs_bench_suite
- dkersten 6y ago

FpUser 6y ago

I consider myself good architect but I am miles away from being deeply familiar with all of the sourcery of its metaprogramming facilities. I have real things to do and prefer to invest most of my mental efforts to more practical and productive things. I however do use C++ to write servers and if I do not try to play language guru in my code modern C++ along with the STL feels incredibly easy to use.

jasode 6y ago

>I think much of modern C++ should be rejected [...] then fricken switch language! There are countless better alternatives today: Rust, Swift, D, Haskell etc. The reality is that many projects are enabled more by existing libraries & tools rather than blank slate clean language syntax. Some example domains of libraries & tools where C++ is the 1st-class client instead of Rust/Swift/D/Haskell: + deep learning: NVIDIA CUDA api is C++ + HPC High Perfomance Computing: Intel MKL math library is C++ + physics engine for video games: Unreal game engine is C++ + latest cpu chip : ARM Allinea dev tools for the new ARM/Neoverse chips (e.g. latest AWS Graviton2 servers) is C++ + Qt GUI is C++ Because of the extensive C++ ecosystem, you get a counter-intuitive situation where programming the latest cutting-edge apps requires a 35-year-old language from 1985 instead of the newer Rust language from 2012. I predict this delta of tools+libraries between C++ and Rust/Swift will continue to exist for 10+ years. Recommending/lecturing people to use Rust/Swift/D overlooks the reasons that many programmers use C++. It's not a random choice. E.g., a realistic starting point for a project might be: "What's a good game engine... oh, it's Unreal, and that's C++." -- instead of -- "Rust has clean syntax of ownership and borrow with "&" ampersand symbol instead of ugly warts of unique_ptr<T> and std::move() in C++ so I'll code a game in Rust." Sometimes, we look at the ecosystem first, and then work backwards from that to make programming choices. It's when you have the luxury of a greenfield project that doesn't need legacy dependencies that choosing alternative cleaner syntax of Rust/Swift is possible. Amazon AWS and MS Azure are examples of doing new bare-metal projects with Rust instead of C++.

DerDangDerDang 6y ago
All true. Ironically the main thing keeping C++ relevant is the lack of a standard cross platform ABI. The moment interop with the C++ ecosystem becomes easier, the newer languages look so much more attractive.
- spaetzleesser 6y ago
  Very true. It also makes working with C++ harder. It’s so easy to use different libraries with C#, Java or Python vs the struggle it is to integrate a C++ library.
- 6y ago