C/C++ facts we learned before going ahead with CLion
blog.jetbrains.com
blog.jetbrains.com
How does that work?
You get a constantly up to date compiler (because of the system package management) and you don't need a MS license for your buildbot. It's a win win.
Another thing to note is the sources of information used for these statistics, including their own user surveys. These aren't necessarily accurate for the industry as a whole, but rather represent a particular sample, which happens to include their own existing users, people on Reddit, people sharing code on GitHub, etc.
Also the embedded SW development market is really big, and C/C++ is still dominant there. E.g. in automotive nearly all ECUs are pure C, using compilers that fall in the "others" category of this survey.
But I guess the issue could be the used sources here. E.g. embedded is in large parts a closed ecosystem with less visibility on the internet sites about programming (which are often very web-focused).
Another surprising number was that Windows users use GCC almost as often as Visual Studio. GCC on Windows is kind of a PITA, and the VS toolchain is really pretty good. Maybe people go with GCC because they need proper C99/C11 support.
I'm looking forward to digging into this further; it's a really useful and interesting dataset!
I think the usefulness is limited by the fact that they haven't explained how they gathered this data. At first glance, the data looks to have some specific quirks (44% Linux users, overwhelmingly in the Finance industry) – you'd have to wonder it that's due to how the survey was conducted.
The webpage is clearly about C/C++ ... that's the title of page ... in other words... "C Language" and "C++ Language".
Both languages were included in their surveys and market research.
Saying "C/C++" is like saying "ML/Haskell".
In embedded firmware development, for example, one often simply can't afford the RAM it would take to run a malloc/free heap, and may have hard realtime constraints that would preclude the use of dynamic memory management even if more RAM were available. It may still be worth using C++ for such systems even if you're writing functions-and-pointers style code like you would in C, because namespaces and class/struct encapsulation are useful tools on their own.
https://lwn.net/Articles/542457/
You cannot easily do that with a multi-million SLOC ML project.
That is bad, and is ripe to create a lot of errors.
C programmer who tries to write C code in C++ has the worst problem ever, IMO: he doesn't know that he's wrong. Everything compiles, everything works, and he goes home happy after a productive day of laying mines for future maintainers.
In fact, you could almost say it's a relief, largely because it tends to be impossible to write any overly-clever template-inspired madness that will be hard to understand and drag down compile times for a small benefit.
Additionally, when it comes time to optimize code (assuming this block is worth optimizing, and already is using the optimal algorithm), the C code tends to be closer to what you want to optimize than the C++ code. With the C++ code, you typically have to spend more time removing abstractions before you can start actually tuning it.
That said, while bad code in either is bad (obviously), someone could probably make the argument that bad C++ code is easier to fix than bad C code. I might be able to be convinced of this.
And sure, there are a few bits of C which aren't valid C++, but most of those are either edge cases or trivial to convert.