Hacker News Reader

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.

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.

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.

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.

> 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.

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.

Yeah, 'ironically' because although your points are quite correct, so are Gibbon1's.

'paradoxically' would have been a better word choice on my part

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.

Why not F#? :)

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)

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#?

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.

(Small periodicity note here: Rust 1.0 was in 2015, not 2012. This makes your point even stronger, imho)

How about Nim, which transpiles to C++ and therefore has first-class support for C++ interop?

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?

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”?

> 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.

Umm you don't need to maintain two languages. And who cares about a language being “standard”?

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++

When it's the language you're using, it's a first-party dependency.

The official tutorial and manual is great and comprehensive. There are many kind people with more experience on the Nim forum.

You won't need to debug C++, just like you don't need to debug JavaScript if you transpile to it from, say, CoffeeScript or Dart.

If someone replaces complex and difficult code using a good, lean and fast library it would be an improvement.

And yet you could argue that it's "adding further layer / critical third-party dependence" and so on.

> 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.

originally CUDA is C. C++ came later.