A long-standing coding choice has seen an unexpected rise in popularity, according to one tracker of programming languages:
Software-testing firm Tiobe, which maintains a monthly tracker of the popularity of the vast array of programming languages available to software developers, has picked C++ as its programming language of 2022.
Despite it being placed third in Tiobe's January 2023 index, the popularity of C++ rose faster than all other languages last year, up by 4.26% compared with January 2022, the company said.
Runners-up this year were C, the second most popular language, which grew in popularity by 3.82%, and Python, the top language, which grew by 2.78%. Having fallen from third, Java is now in fourth place, growing 1.55%.
[...] [Tiobe CEO Paul] Jensen also notes that C++ rival Rust entered the top 20 again (being ranked at number 26 one year ago), but says that "this time it seems to be for real", suggesting it could now hold a stable position in the top 20.
Rust's profile shot up during the past year after it was officially adopted for the Linux kernel version 6.1, clearing its way for drivers to be written in Rust.
Previously:
Ironically: It's Time to Stop Using C and C++ for New Projects, Says Microsoft Azure CTO
Related Stories
News and Advice on the World's Latest Innovations:
The Rust in Linux debate is over. The implementation has begun. In an email conversation, Linux's creator Linus Torvalds, told me, "Unless something odd happens, it [Rust] will make it into 6.1."
The Rust programming language entering the Linux kernel has been coming for some time. At the 2020 Linux Plumbers Conference, developers started considering using the Rust language for new Linux inline code. Google, which supports Rust for developing Android -- itself a Linux distro -- began pushing for Rust in the Linux kernel in April 2021.
As Wedson Almeida Filho of Google's Android Team said at the time, "We feel that Rust is now ready to join C as a practical language for implementing the kernel. It can help us reduce the number of potential bugs and security vulnerabilities in privileged code while playing nicely with the core kernel and preserving its performance characteristics."
It took a while to convince the top Linux kernel developers of this. There were concerns about non-standard Rust extensions being needed to get it to work in Linux. For instance, with the new Rust Linux NVMe driver, over 70 extensions needed to be made to Rust to get it working. But, Torvalds had told me in an earlier interview, "We've been using exceptions to standard C for decades."
This was still an issue at the invitation-only Linux Kernel Maintainers Summit. But, in the end, it was decided that Rust is well enough supported in the Clang -- the C language family compiler front end -- to move forward. Besides, as Torvalds had said earlier, "Clang does work, so merging Rust would probably help and not hurt the kernel."
[...] Now, Torvalds warns in this first release, Rust will "just have the core infrastructure (i.e. no serious use case yet)." But, still, this is a major first step for Rust and Linux.
Arthur T Knackerbracket has processed the following story:
Mark Russinovich, the chief technology office (CTO) of Microsoft Azure, says developers should avoid using C or C++ programming languages in new projects and instead use Rust because of security and reliability concerns.
Rust, which hit version 1.0 in 2020 and was born at Mozilla, is now being used within the Android Open Source Project (AOSP), at Meta, at Amazon Web Services, at Microsoft for parts of Windows and Azure, in the Linux kernel, and in many other places.
Engineers value its "memory safety guarantees", which reduce the need to manually manage a program's memory and, in turn, cut the risk of memory-related security flaws burdening big projects written in "memory unsafe" C or C++, which includes Chrome, Android, the Linux kernel, and Windows.
Microsoft drove home this point in 2019 after revealing 70% of its patches in the past 12 years were fixes for memory safety bugs due largely to Windows being written mostly in C and C++. Google's Chrome team weighed in with its own findings in 2020, revealing that 70% of all serious security bugs in the Chrome codebase were memory management and safety bugs. It's written mostly in C++.
"Unless something odd happens, it [Rust] will make it into 6.1," wrote Torvalds, seemingly ending a long-running debate over Rust becoming a second language to C for the Linux kernel.
In some ways, C and C++ run the world. You'd never know it from all the hype about other programming languages, such as Python and Go, but the vast majority of high-performance mass-market desktop applications and operating systems are written in C++, and the vast majority of embedded applications are written in C. We're not talking about smartphone apps or web applications: these have special languages, such as Java and Kotlin for Android and Objective-C and Swift for iOS. They only use C/C++ for inner loops that have a crying need for speed, and for libraries shared across operating systems.
C and C++ have dominated systems programming for so long, it's difficult to imagine them being displaced. Yet many experts are saying it is time for them to go, and for programmers to embrace better alternatives. Microsoft Azure CTO Mark Russinovich recently made waves when he suggested that C and C++ developers should move to Rust instead. "The industry should declare those languages as deprecated," Russinovich tweeted.
Many developers are exploring Rust as a production-ready alternative to C/C++, and there are other options on the horizon. In this article, we'll consider the merits and readiness of the three most cited C/C++ language alternatives: Rust, Carbon, and cppfront. First, let's take a look back through the history and some of the pain points of C/C++.
(Score: 3, Interesting) by looorg on Monday January 09, @05:51AM (8 children)
Very short on the how and why. It's just numbers rising and falling for "reasons" barely known, understood or explained. One would thing c++ would be boomer-tech and then no longer in demand. But as long as Cobol (#31) keeps breathing there is hope for all. Every one appears to say don't use it, are they picking it to spite people or is it just so much better the all the new shiny things?
https://www.tiobe.com/tiobe-index/ [tiobe.com]
The list.
(Score: 1, Funny) by Anonymous Coward on Monday January 09, @07:54AM
From article:
Maybe they tweaked their algos etc for 2023, the rankings have changed and some bright spark decided it was a good excuse to try to remind the world that Tiobe still exists.
(Score: 3, Insightful) by canopic jug on Monday January 09, @08:53AM (1 child)
Very short on the how and why. It's just numbers rising and falling for "reasons" barely known, understood or explained.
Indeed. Following your link several steps out, it seems that TIOBE has some kind of search engine polling [tiobe.com] which then aggregates the found results:
Not only is the how and why missing from the article but the article does not even mention which code bases they are measuring or hinting at the methodology used. Then again, the article is from ZDNet and they do have an anti-FOSS agenda to push in general and an anti-GNU/Linux agenda more specifically. It's not quite the official mouthpiece of Redmond but not far off.
ZDNet was quite good twenty years ago, but then they had much more staff who were allowed to cover actually developments in computing. Now, there is barely even a skeleton crew and they have a very, very short leash in regards to what they can cover and what they can actually say about the little they are allowed to cover.
It's 2023, please stop wasting our time with ZDNet any more. thanks
Money is not free speech. Elections should not be auctions.
(Score: 0) by Anonymous Coward on Monday January 09, @07:57PM
Note that Scratch [wikipedia.org] comes in at spot 20 on that index. Something tells me that index should not be trusted too much...
(Score: 5, Insightful) by JoeMerchant on Monday January 09, @12:20PM (4 children)
My problem with the shiny new things isn't the core things themselves, they may be all they claim - on a whitepaper.
Once you've got this theoretically wonderful language on a whitepaper, you're gonna need a compiler - that works 100.00000% correctly, because nobody likes teasing out that one flaky compiler (or optimizer) error affecting your 10,000,000 LOC master-work of a project.
Got a good compiler, how about an IDE (that's better than Eclipse)?
Got a decent IDE? Now how about deep functionality in libraries with widely understood APIs? Support in all the major OSs on all kinds of hardware? Can you write and debug code on your desktop, then just re-compile it on embedded devices and have it work the same?
Our previous generation of product had a DSP in the system. Our new generation implements that DSP code in Linux on an Intel CPU - with no changes. While we were waiting for our custom motherboard to come from the manufacturer, the developers were working with the same DSP code base running on Raspberry Pis... Technically their code is C++, but it's really 95% C. The libraries they use are all available with the same API on that DSP, in Raspbian in the Pi, and Ubuntu - zero code changes, zero significant differences in how the code runs.
Rust may be running in the Linux kernel, but it's a long way from replacing C++ in all the niches of the world.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 3, Funny) by tangomargarine on Monday January 09, @06:48PM (3 children)
What's wrong with Eclipse?
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2, Funny) by Anonymous Coward on Monday January 09, @07:59PM (1 child)
You've not used it then, eh?
(Score: 2) by tangomargarine on Monday January 09, @09:17PM
I've been using it for years. Answer the question.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by JoeMerchant on Monday January 09, @09:30PM
As AC said:
Eclipse is a very (theoretically) adaptable IDE originally written for Java developers, I understand some Java developers like it quite a bit, for Java.
Because it's all open source lying there alluringly cooing: "Use me daddy, I'm flexible!" it tends to be the first choice of IDE for all manner of embedded devices, FPGA custom processors, etc. etc. and it seems that the systems so using Eclipse don't invest a lot of effort in smoothing off the rougher edges of their Eclipse IDE adaptation to their products. Crashing because you looked at it with the wrong tilt of your head is a common complaint. Things it's supposed to do according to the rev. 3.2.6 documentation, it just can't do in 3.2.7 and later. Other things it's supposed to do according to the rev 3.2.8 documentation, it just can't do in 3.2.6 and earlier. Version 3.2.7 won't install properly on your system. Why? You may ask, but being this super nichey IDE the number of people who have successfully installed 3.2.7 on a system _like yours_ is vanishingly small, particularly what with the lack of those features only found in 3.2.6 and prior and 3.2.8 and later. 3.2.8 and later won't install on your system at all, and there's clear explanations of why on the web because some stubborn soul spent weeks running it all down.
Worst of all: it usually _does_ work after a fashion, just well enough that you don't declare it impossible and refuse to keep fighting it, daily. Just remember: clean boot, open the files in the _exact same sequence that successfully compiled last time_, start the compilation and don't open any web browsers lest you tempt the fates of page fault vagaries... Once successfully built and burned into the hardware, you can breathe again. You can even try a debugging session. I'd generally make it 3 hours between crashes on average, unless I really needed something to work right then, of course the frequency goes up dramatically in proportion to the urgency of need.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 5, Funny) by Mojibake Tengu on Monday January 09, @11:54AM
Poor rust people suffer from *pointer anxiety personality disorder syndrome.
It stems and grows from their toxic relations with random access memory.
That syndrome cannot be cured, only treated.
The edge of 太玄 cannot be defined, for it is beyond every aspect of design
(Score: 3, Interesting) by shrewdsheep on Monday January 09, @02:43PM (1 child)
I have recently watched some talks from the cppcon 2022 and it looks like C++ makes further steps in becoming more efficient to write. However, it has become a complex beast by now. I am personally stuck on C++17 mostly and adapting to the new standards takes a non-trivial time investment.
(Score: 4, Interesting) by stormreaver on Monday January 09, @03:30PM
I hadn't written C++ for about ten years. When I came back to it, I started with C++17. I needed to write a multithreaded server, and I was pleasantly surprised to find out that thread support had made it into the standard. That was a huge boon for me, as I no longer had to worry about pthreads on Linux. That support was a VERY long time in coming, but it does indeed make C++ more pleasant to work with.
(Score: 3, Interesting) by RamiK on Monday January 09, @04:32PM (2 children)
The C/C++ Jul / Dec popularity spikes ( https://www.tiobe.com/tiobe-index/c/ [tiobe.com] and https://www.tiobe.com/tiobe-index/cplusplus/ [tiobe.com] ) track the June and November layoff spikes ( https://www.trueup.io/layoffs [trueup.io] ) and overall yearly trends to a T.
To compare and contrast, if you look at other languages in the list ( https://www.tiobe.com/tiobe-index/python/ [tiobe.com] and the rest over at https://www.tiobe.com/tiobe-index/ [tiobe.com] ), you'll see similar spikes though not as severe.
So, while we can't be sure why C/C++ is creating more quarries (Did more C/C++ devs get fired than other languages? Does C/C++ codebases require more googling for documentation?), we can say for certain that the spikes follow the layoffs and are especially "beneficial" to C/C++ for some reason.
compiling...
(Score: 3, Funny) by istartedi on Monday January 09, @10:11PM (1 child)
we can't be sure why C/C++ is creating more quarries
Yeah, whenever I go to a quarry I'm much more likely to see equipment with rust.
Sorry. I know it was typo/auto-correct nonsense but it was too good a setup.
Appended to the end of comments you post. Max: 120 chars.
(Score: 2) by RamiK on Tuesday January 10, @08:35PM
Real low-end C/C++ devs quarry their silicon directly from the source!
compiling...
(Score: 4, Interesting) by rpnx on Monday January 09, @11:30PM
As someone who used to be primarily a C++ developer before taking my current position, and who still turns first to C++ for personal projects, not Rust or Python, the answer is simple. C++ has issues, but the C++ standards committee has been hard at work fixing them. If you keep up with new versions of C++ like C++20 and upcoming C++23, it's very clear that the language is becoming better and better as time passes. Most of the old reasons commonly cited for not using C++ are evaporating as new versions of C++ fix issues with missing features. At this point I don't really see many reasons to use anything else. Also the improvements to CMake and how generally useful CMake is for developing application software have made C++ a more and more attractive target for cross platform development. Did I mention it also runs on GPUs now too? No need to use HLSL or GLSL, you can run C++ directly on your GPU with SYCL or clang's spirv target (minus most of the standard library admittedly).
There's lots of reasons to use C++ and I think it's improving faster than Python or other languages are, hence the renewed interest in it.