C++ was the fastest growing programming language in Sept according to TIOBE
techrepublic.com
techrepublic.com
But you're also right that some of the larger trends are suspect as well. The big dip in C and Java in 2016-2017 could just as easily be due (at least in part) to a change in Google's search algorithm. The index doesn't solely rely on Google, but it certainly makes up a large part of the index [1].
There's no perfect metric for any of this, but making announcements about 1-month changes to a noisy estimate is not particularly convincing.
[0] https://www.tiobe.com/tiobe-index/cplusplus/
[1] https://www.tiobe.com/tiobe-index/programming-languages-defi...
I would go even further and state that TIOBE is deprived of any meaningful value. It's basically a index that tracks web noise. I mean with TIOBE, C++'s ranking goes up if someone writes a blog post with a joke that goes "A C++ developer walks into a bar...".
I wouldn't be surprised if this post in HN is contributing to the bump.
TIOBE is what you get from garbage-in.
> I wouldn't put much stock in this and I like C++.
I would bet that C++20 led some bloggers to post random stuff with C++ in it.
But C++ usage really is growing faster than ever, judging by the number of C++ conferences that had been scheduled in 2020, and the monotonically increasing number of attendees at the far-flung, tri-ennial ISO C++ Standard conferences.
But TIOBE is not a reliable measure; when it's right, it is as accidental as the stopped clock that is right twice a day.
Some example domains of libraries & tools where C++ is the 1st class client instead of Rust:
+ 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 Neoverse chips (e.g. latest AWS Graviton2 servers) is C++
+ Qt GUI is C++
Because of the extensive C++ ecosystem, you get a non-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 will continue to exist for 10+ years.
One could try to write a bunch of Rust wrappers for all the above C++ SDKs but I'm not convinced that's a good use of development resources.
+ macOS, iOS and Android drivers are C++
+ UWP/WinUI is a mix of .NET and C++
+ console SDKs use C++
+ Metal shaders and HLSL are C++ dialects
+ Arduino is C++
+ ARM mbed is C++
But that's Python, where the language is slow enough that any marshaling costs can generally be dismissed as a rounding error. The practicalities may be different in a shop that is deciding between Rust and C++.
35 years of usage means it is a sound language. Nothing non-intuitive there.
- fully evented with arbitrary number of threads servicing event loops
- straightforward API with examples
- HTTP 1.1/2/3 out of the box
- terminates SSL/TLS out of the box
- extremely hardened
It’s not tiny and header only or anything trendy like that, but it’s fast as hell, easy to code to, builds with cmake easily, actively developed, and runs one of the biggest sites on the Web.
I have yet to find a major downside.
header-only slows compilation down just so you can avoid adding in a single line in your build chain of choice. It's just not a trade off worth making imo.
So to me, not being header only is a pro, not a con.
It's not that I'll outright refuse to use a header-only lib, only that I very very strongly prefer not using them.
Which is something not even Python accomplished in half that time.
Embark Studios in Stockholm did exactly that for their open source NVIDIA PhysX wrapper [1].
I can recommend Tomasz Stachowiak's talk about how it was done and how all the compiler-defined behavior was dealt with [2].
Modern C++ is actually quite different from the 35 year old version. For example, you basically do not need new and delete if you stick to the core guidelines. That's a paradigm shift.
Unless c++ makes some major changes I think Rust will gain steam in all the areas you mentioned.
The fact that Rust has zero-cost FFI and even inlining across LLVM languages allows you to take existing C/C++ project, and start writing new Rust code on top of it.
It's like a more performant version of what people do with Python. Nobody says "oh, I can't use Python, because my device drivers aren't written in Python".
Almost every feature of C++ is there to make writing powerful libraries possible. Many uses of such features become part of the library interface, because that enables zero-overhead libraries with semantics intricately integrated into the caller's usage.
Rust has a goal of zero-overhead code, but is not designed to minimize the overhead of library usage. That was a choice: it makes the language simpler and easier to learn, but that comes at a cost. You cannot write a Rust library to do what is routinely done in C++ libraries, and a Rust wrapper cannot expose those capabilities to Rust code.
All Tiobe (who make these ratings) say is: "Popular search engines such as Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube and Baidu are used to calculate the ratings."
What does this mean? What algorithm is used? If they expect these ratings to be taken seriously they should open source the methodology and data-sets and put their reasonings for why this data plus this algorithm gives a meaningful result.
If someone is telling me: "This index of 'top' programming languages is meaningful" I want to understand how said index is generated, because obviously there is a massive human element. You could make indexes like this which show Haskell is the top programming language if you used certain data points and similarly you could make Rust the top language if you used a different set of data points. It's totally open to authorial biases.
Does that imply that a major news event (such as, say, a new language version) could drive perceived "popularity" simply by people reading/writing articles to evaluate it?
As soon as a metric becomes a target...
It is an interesting metric, but I just can't bring myself to see it as the measure of popularity that it is presented as. The number of page hits for a language is a function of many things. Popularity is one. Others include age, complexity, and how confusing/difficult-to-learn the language or its libraries are. I'm guessing there's a marketability angle, too - for economic reasons, there may not be as many codepoints being poured onto languages whose users are less likely to purchase commercial tools or consulting services.
I can think of no better illustration of this than the 5th, 6th and 7th places in this month's rankings. Does anyone really believe that JavaScript is only the 7th most popular programming language these days? Does anyone really believe that both C# and Visual Basic are more popular than JavaScript? If you take the TIOBE score as just a measure of popularity, it would seem to suggest that .NET developers are collectively over 3 times as numerous as JavaScript developers.
Outside of the tech bubble it's believable that JavaScript isn't as popular.
I can only imagine there's a ton of massive ASP.NET MVC + a bit of jQuery internal apps still chugging along too
Javascript is useful for websites. And outside of the tech bubble, that's basically all it's good for.
Yes, you can use Javascript for non-website stuff. But nobody is doing that because there are many cheaper and more efficient languages out there for doing all that other stuff.
It has been gamed in the past. For example, http://delphi.org/2008/10/the-many-faces-of-delphi/ and http://delphi.org/2008/10/delphi-keeps-climbing/
There have been other blips in the past caused by documentation for a project getting moved to a different server and in doing so the SEO for the material (inadvertently) changed.
TIOBE measures the SEO for different programming languages, nothing more.
TIOBE only exists for the sake of tech illiterate managers who are trying to make tech decisions beyond their technical know-how. They decide their team will use X technology and justify it with a link to TIOBE. The people in this thread should know better than this.
Here are a few examples of it being wildly inaccurate.
* JavaScript is only the 7th most popular language. Not the most popular like it is on Github, Stackoverflow and developer surveys.
* VB ranks higher than a bunch of other widely used languages. How do we interpret this? There are more jobs for VB developers than jobs for Javascript or Swift or Go or Ruby? Or that there's more software developed in VB than these languages?
* C and Java are pretty stable but if you look at historical TIOBE data they experience wild swings in popularity. There's no way that between 2016 and 2018 C lost half it's popularity and then regained it in 2 years. No, C was stable throughout.
If you really want to know how many developers out there are using a certain language, read the results of a survey where they ask developers that question - https://insights.stackoverflow.com/survey/2020#technology-pr...
Of course for mission-critical applications C is still the standard for firmware in the industry, but for many startups providing novel uses of edge computing and the plethora of hobby projects C++ is a solid choice.
[1] https://www.ntu.edu.sg/home/eechenss/Papers/conf-2011-A%20CM...
>Also, the growth in C++ is probably in the new standards,
This, especially since growth here means growth in queries.
Agreed! There are some novel remarks on that in the link under "[1]" in my reply to the parent comment.
Or see the following digest if paywalled: https://community.arm.com/developer/research/b/articles/post...
I do maintain that CMOS on-chip motion is useful because adding a PIR sensor is prohibitive for some form factors and more importantly has a lower effective range. What I find even more interesting, from a power usage standpoint, is this recent research on Adaptive Video Subsampling for Energy-Efficient Object Detection[0]. This buys some space on the energy budget for running ML on the device. Although image sensor reading is energy intensive compared to read-write and processor ops by 3 orders of magnitude, as outlined in the second slide of [0] we can see that LTE comms are a further 3-5 orders of magnitude more expensive than image sensor reads. Topically, here is some research on real-time wake from ultra-low power sleep (~10nW) and lowered idle SRAM usage [1] as well as the proposal for no power IR sensing [2].
[0] https://www.tinyml.org/summit/posters/Jayasuriya,%20tinyML%2...
[1] https://ieeexplore.ieee.org/document/9063136
[2] https://eri-summit.darpa.mil/docs/ERIPoster_Applications_N-Z...
For those who don't know, there is a short video from fluentcpp: https://www.youtube.com/watch?v=v9eJE2m3CYk (and a transcript if you prefer: https://www.fluentcpp.com/2018/03/09/c-metaclasses-proposal-...).
And the proposal from Herb Sutter is here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p070...
That now we have an ISO C++17 compliant framework and are supposed to wait for ISO C++23 reflection until Visual C++ team bothers to provide the same level of UWP/XAML tooling that C++/CX enjoys since 2012.
Until then, C++/WinRT provides a revivalist experience for those that missed the opportunity to deal with bare bones IDL file editing alongside ATL.
You can bring your C++98 code and compile it with the latest compiler in C++20 mode and it should still work.
This allows you to upgrade (and learn) incrementally. You can slowly incorporate new features into an old code base.
https://static.googleusercontent.com/media/research.google.c...
I will give a nod to the other poster who pointed out automatic tools. They are often worth running on everything, but they only fix a fraction of the things that a sane developer with 20/20 hindsight starting over would do differently.
I'd say C++98 + C++17 is easier to deal with than C++98 + Rust.
Keep in mind that these are largely relatively useless or now replaced features so any incompatibilities should be both few and far between and relatively easy to fix.
My new job is to port a company forward to C++11, FML.
The claim at the top of the page is that "The ratings are based on the number of skilled engineers world-wide, courses and third party vendors." However, the details show that it really is just a single search term across a variety of search engines. Maybe they used to have an intern read the classifieds at the back of the Communications of the ACM or something.
All languages evolve & change, not just HMTL5/ES5. I worked at Apple when Swift was first rolled out & the language today is very different & unrecognizable to me from the one that exists today. The original code won't even compile today (not necessarily terrible if the automated conversion tools are 100% perfect).
Java is on a ~1yr cadence for the past 3 years (used to be 2 before that except for Java 7, 8 & 9 which had a longer lead time & likely not coincidentally is the time period that saw tremendous growth in C#) Swift is on a ~1 yr cadence with major language changes still happening. Upgrades are managed by automatic tooling. Will be interesting to see if Apple can sustain this long-term (every problem gets magnified a lot with time if you're growing). Rust is on a ~~1 yr cadence although they've come up with an interesting way to land major language changes & improvements into the language (release process rather & I can't recall if they use automated tooling).~~*
The problem of evolving languages isn't being ignored but it's a hard challenge. However, any language designer who ignores new up & coming concepts in language design is relegated to repeat the mistakes of C++ and Java which stagnated for long periods & let other languages capture large amounts of market share. Market share = how healthy the ecosystem for that language is & whether new projects get started in it. So if you just try to solve that problem first you'll end up never getting off the ground because you won't have an ecosystem around you to drive investment of time & money from users of that language.
I think you're just seeing the reorientation to a faster release cadence in the industry. Rather than waiting many years to deliver on larger features (Python3, Perl5), there's a more regular process to continuously ship smaller subsets of them in a usable form to get feedback, amortize the cost of adoption, & address any issues sooner. This also makes you more competitive in terms of users adopting your language for new projects. This obviously does have an externality cost as there can be less QA & bake time for code. Those can be mitigated with automation. Design defects can be addressed sooner & those are valuable because they're the pain-points for your user base.
I wish C++ actually delivered faster but given that there's 3 mainline compilers & a bunch of ancilliary ones, it's going to stagnate & die in favor of Swift or Rust which only have 1 shared reference compiler that everyone uses. It's also why projects like PyPy never grow beyond a small niche if you make that kind of choice. I'm on the side of Swift and Rust models - in C/C++ to support different platforms I need different compilers. This means in any non-trivial project I have to add different per-compiler workarounds to language interpretation or feature set (even clang's attempts to pretend to be GCC or MSVC don't work out well & you end up having to adjust your project to actually be aware of it).
* EDIT: Corrected below. Rust is on a 6-week cadence with a 3-year roll-up of the supporting material & an interesting way to support mixing and matching code from different versions.
Which cadence are you talking about? We have releases every six weeks, and editions roughly every three years, but not a yearly cadence that I can think of right now.
Languish is based on GitHub activity instead of online content and searches (which is what TIOBE does), I find it neat.
He also has a video from February of this year where he presents it in more details: https://www.youtube.com/watch?v=xu0jWgGoDjc.
Good books include Stroustrup, "The C++ Programming Language", Josuttis, "The C++ Standard Library".
That only means that you have to unlearn a lot of bad habits. For example malloc/free should not be used in c++ code unless you call into a c library that uses the counterpart. Even the c++ equivalent new/delete pairs should only be used if it cannot be avoided.
> and then get into C++ with its Turing complete templating language and such in order to be able to be competent enough to grok all kinds of code written in C++?
I am quite sure I used Java collections before I had a grasp on its generics. You don't have to be able to implement std::vector<int> to understand that it is a collection of int. You might have to be told to avoid std::vector<bool>, but that is more because it is an unholy design failure that should have gone the way of the trigraph a long time ago .
Ruby Dropped out of Top 10 a while ago. But even Perl is now ranking higher?
There is a ~2x perf improvement from moving to a non-gc, natively compiled language in most benchmarks - will companies 10 years from now reap a dividend from being on average 2x faster than their competitors?
I would argue that wherever performance really matters, that is, where it is measured and where the improvement is estimated to reduce cost or increase revenue to the point where the programming effort is justified, we're already near the optimum. I don't see many fields where this is the case today but won't be tomorrow.
In the past, software needed to be optimized just to run at all, but that constraint is gone forever. Consumers generally accept software that is kinda clunky and slower than it needs to be, peak performance rarely becomes the differentiator that it needs to be to justify optimization on modern hardware.
Language benchmarks only give you the theoretical lower bound of runtime, but software in practice is usually much slower than that, regardless of language. For instance, it's not unusual to see some C code with unfavorable complexity, just because someone didn't bother to bring in a data structure that would've been part of the standard library of a slower language.
The gap between python and java is a lot bigger than java and C though, and I wouldn't be surprised if the latter optimization doesn't become worth it for a while longer.
Mid-upper laptop, lower watt, from like 2018. Looks like 80% faster per core.
https://cpu.userbenchmark.com/Compare/Intel-Core2-Duo-E8400-...
Latest lower watt Ryzen is like 8x faster in multithreaded apps.
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Celeron+N4000...
So 11x less power, much cheaper.
Their marketplace is exploding and, anecdotally, there are lots of new adopters.
the borrow checker is cool but not always an easy person to work with
if cpp20 adds a working module system and gets the design right (unlike golang the first 5 times), half of rust's advantage evaporates
On the other hand D, Nim and Rust are cutting edge.
Googling finds me something called 'gcc' and 'clang'. Really weird and esoteric stuff, I must be a googling wizard.