5 ms·

>I think much of modern C++ should be rejected [...] then fricken switch language! There are countless better alternatives today: Rust, Swift, D, Haskell etc.

• 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.
  • rualca 6y ago
    > Ironically the main thing keeping C++ relevant is the lack of a standard cross platform ABI. I find that statement very odd, because in my experience the bane of C++, and perhaps the primary reason to look for alternatives, is C++'s lack of a standard ABI. The lack of a stable ABI is C++'s main source of bit rot, and the main technical point that justifies migrating projects, even legacy ones, into other programming languages. If not for the ABI issue, most of the technical points used in favour of jumping away from C++ into some bandwagon of the moment would be moot.
    • Gibbon1 6y ago
      If C++ had a stable defined API then you could just import a C++ library blob into python, or rust, or whatever and it would just work. That you can't is what keeps people developing projects in C++ instead of more productive and sane languages.
    • DerDangDerDang 6y ago
      Yeah, 'ironically' because although your points are quite correct, so are Gibbon1's. 'paradoxically' would have been a better word choice on my part
• steveklabnik 6y ago
  (Small periodicity note here: Rust 1.0 was in 2015, not 2012. This makes your point even stronger, imho)
• xigoi 6y ago
  How about Nim, which transpiles to C++ and therefore has first-class support for C++ interop?
  • matkoniecz 6y ago
    So to solve overly large C++ complexity I will add further layer increasing complexity? And add critical third-party dependence? And learn one more programming language that is rarely used?
    • xigoi 6y ago
      We're talking about what language you can use instead of C++, without losing access to C++ libraries. Nim doesn't have the unnecessary complexity of C++, and being rarely used is not a problem. How does it add “third-party dependencies”?
      • rualca 6y ago
        > We're talking about what language you can use instead of C++, without losing access to C++ libraries. Congratulations, your suggestion requires you to maintain two entirely separate languages, one of which is not standard nor mature, not to mention maintaining interoperability bugs.
        • xigoi 6y ago
          Umm you don't need to maintain two languages. And who cares about a language being “standard”?
      • matkoniecz 6y ago
        In this case Nim is “third-party dependency”. "being rarely used is not a problem" it is a problem if I want to find docs, tutorials or people with more experience willing to help me "instead of C++" as soon as something breaks I will need to debug both Nim and C++
        • 6y ago
• guenthert 6y ago
  To add to that, not all software is written by those who identify chiefly as software-engineers. In, e.g. the embedded world, software is often written by those who are electrical engineers by profession, who use assembler, C, C++, FORTH or Python if they are lucky and rarely venture further. Consequently for some MCUs available tools are only for C/C++ (and of course assembler). Often those engineers are more concerned how much the MCU costs or how much power it dissipates, rather than how elegant the language is they are programmed in. It's a pity, but part of reality.
  • ryandrake 6y ago
    Yea, there is a lot of this in the embedded world. "Software" is just another line item on the BOM, like connectors and bolts. Source it as cheap as possible or find some junior EE in house who barely knows C to do it. That code is going to get written once and never read again.
• matkoniecz 6y ago
  Exactly - right now I write program in C#. Not because C# is cool or because I like its syntax but because it is what Unity supports. It could be C++, if I would go with Unreal Engine. I used Squirrel in past, solely because for some reason it was modding language of OpenTTD. I am not fan of any of them, I am not an expert in any of them. But it was more effective that writing from scratch 3D engine or AI backend to use something else.
  • sideeffffect 6y ago
    Why not F#? :)
    • v-yadli 6y ago
      I love to write F# (I built FVim), but there's still gap towards high performance game programming. In C# you get a lot of low-level unsafe constructs with zero allocation overhead that integrates very well with the external libraries. In F#, you either get a clumsy library special form (without proper syntax support), or the idea itself is considered "only for C# interop uses" and thus not prioritized. F# has been in this position: a smaller team that tries to align with C#, without a language implementation team backing them (unlike Roslyn-C#), yet constantly feeding innovations back into the dotnet ecosystem. You can see a lot of example where F# piloted the idea, and later C# adopted and extended it in its own way, and F# struggling to catch up in that OO-centric world (Disclaimer: MS employee, but not on the language teams)
    • matkoniecz 6y ago
      Why F#? I need a good reason to use one more programming language and one more dependency. Also, how many Unity examples and tutorials and knowledgeable people are using C# and how many F#?
• nyanpasu64 6y ago
  I agree with most of your post, but I think MKL is Fortran and C/C++, and implements the BLAS API. I recall that BLAS has a Fortran interface and a CBLAS (C, not C++) interface, and I used the latter. And Rust can call out to C ABI code.
• socialdemocrat 6y ago
  > The reality is that many projects are enabled more by existing libraries & tools rather than blank slate clean language syntax. As I said, sometimes for legacy reasons you must use C++. My point is to use a sane subset of C++ an ignore the modern crap. You are only going to make life harder for co-workers, and future maintainers. If the modern C++ features themselves are what attracts you specifically to C++ rather than some library you need to use, then that is when I suggest switching language. > deep learning: NVIDIA CUDA api is C++ You can do deep learning much better in Julia. It is a nicer language, allow iterative development in a REPL and will typically give you higher performance as well. And who on earth does machine learning in C++? People typically use Python today. C++ is an implementation detail. A necessary evil for a slow language like Python. But given a choice people pick Python as their interface, not C++, because C++ is a horrible language to use, which you should only use when you absolutely have to. > HPC High Perfomance Computing: Intel MKL math library is C++ Again you could actually use Julia for that. Next generation climate models running on super computers is built in Julia, specifically because it is fast. A language with 1/10th the cognitive load of C++. > physics engine for video games: Unreal game engine is C++ Sure, as I said, sometimes you need to use C++ for legacy reasons. But who on earth writes the game logic in C++? Typically you use Lua, JavaScript, GDScript or something else because people don't use C++ when they can avoid it. Historically it has been hard to avoid C++ when creating a physics engine, because you need the kind of high level performance and memory control C++ gives. > Qt GUI is C++ Yes, which I have spent a lot of my career coding. And which cannot be compared to the insanity of modern C++. Qt tries to keep C++ somewhat sensible. I could add VTK. Old school C++, which is fairly readable, unlike modern C++. As I said if you have some deep geek desire for fancy language features, find another language. > Recommending/lecturing people to use Rust/Swift/D overlooks the reasons that many programmers use C++. It's not a random choice. Problem is that you missed my central point. I didn't say you could go out and replace C++ in every instance with any of these languages. I specifically made it clear that for legacy reasons that may not be possible. And yes that may include that the functionality you need only exists in C++. My point was to write your code in cold old C++, which most people can actually somewhat fathom. If you want to geek out, C++ is a terrible place to do it. > What's a good game engine... oh, it's Unreal, and that's C++. Yeah... so Unreal Script was made because C++ is such an amazing language? You know I use Godot Engine, mostly written in C++, but I don't have to relate to that fact. I just code in GDScript. Fortunately the makers of Godot was no so sadistic as to require their users to code in C++. > 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. I think you are kind of overselling the need for using C++. You fail to mention in any of your examples that C++ is very frequently wrapped and not the preferred interface. E.g. TensorFlow is written in C++, but who the hell interface with it from C++? No, people use Python as much as possible. Or how about Qt. The most popular way to create Qt GUI code today is through QML, not through their C++ APIs. You also failed to mention that in most game engines such as Unreal you can do almost your entire game in a script language. It is typically only the Engine designers who have to program in C++. You have to consider each case, but frequently wrapping C++ works just fine and may make you a lot more productive. VTK is written in C++ but it is also frequently if not mostly used through bindings to other languages. If you cannot wrap C++, then embedding a script language may work well. I have written simple game engines in C++ with Lua. I found myself pushing more and more functionality over to my Lua layer as I experienced how much productive language that was.