JavaScript Still Tops Python and Java in RedMonk's Latest Rankings, While Go and TypeScript Rise (redmonk.com) 54
RedMonk has released its latest quarterly rankings of popular programming languages, arguing that "The idea is not to offer a statistically valid representation of current usage, but rather to correlate language discussion and usage in an effort to extract insights into potential future adoption trends."
Their methodology? "We extract language rankings from GitHub and Stack Overflow, and combine them for a ranking that attempts to reflect both code (GitHub) and discussion (Stack Overflow) traction." Below are this quarter's results:
1. JavaScript
2. Python
3. Java
4. PHP
5. C#
6. CSS
7. C++
7. TypeScript
9. Ruby
10. C
11. Swift
12. R
12. Objective-C
14. Shell
15. Scala
15. Go
17. PowerShell
17. Kotlin
19. Rust
19. Dart
Their analysis of the latest rankings note "movement is increasingly rare.... the top 20 has been stable for multiple runs. As has been speculated about in this space previously, it seems increasingly clear that the hypothesis of a temporary equilibrium of programming language usage is supported by the evidence.... [W]e may have hit a point of relative — if temporary — contentment with the wide variety of languages available for developers' usage."
And yet this quarter TypeScript has risen from #8 to #7, now tied with C++, benefiting from attributes like its interoperability with an existing popular language with an increased availability of security-related features. "There is little suggestion at present that the language is headed anywhere but up. The only real question is on what timeframe." Unlike TypeScript, Go's trajectory has been anything but clear. While it grew steadily and reasonably swiftly as languages go, it has appeared to be stalled, never placing higher than 14th and having dropped into 16 for the last three runs. This quarter, however, Go rose one spot in the rankings back up to 15. In and of itself, this is a move of limited significance, as the further one goes down the rankings the less significant the differences between them are, ranking-wise. But it has been over a year since we've seen movement from Go, which raises the question of whether there is any room for further upward ascent or whether it will remain hovering in the slot one would expect from a technically well regarded but not particularly versatile (from a use case standpoint) language.
Like Go, Kotlin had spent the last three runs in the same position. It and Rust had been moving in lockstep in recent quarters, but while Rust enters its fourth consecutive run in 19th place, Kotlin managed to achieve some separation this quarter jumping one spot up from 18 to 17.
Their methodology? "We extract language rankings from GitHub and Stack Overflow, and combine them for a ranking that attempts to reflect both code (GitHub) and discussion (Stack Overflow) traction." Below are this quarter's results:
1. JavaScript
2. Python
3. Java
4. PHP
5. C#
6. CSS
7. C++
7. TypeScript
9. Ruby
10. C
11. Swift
12. R
12. Objective-C
14. Shell
15. Scala
15. Go
17. PowerShell
17. Kotlin
19. Rust
19. Dart
Their analysis of the latest rankings note "movement is increasingly rare.... the top 20 has been stable for multiple runs. As has been speculated about in this space previously, it seems increasingly clear that the hypothesis of a temporary equilibrium of programming language usage is supported by the evidence.... [W]e may have hit a point of relative — if temporary — contentment with the wide variety of languages available for developers' usage."
And yet this quarter TypeScript has risen from #8 to #7, now tied with C++, benefiting from attributes like its interoperability with an existing popular language with an increased availability of security-related features. "There is little suggestion at present that the language is headed anywhere but up. The only real question is on what timeframe." Unlike TypeScript, Go's trajectory has been anything but clear. While it grew steadily and reasonably swiftly as languages go, it has appeared to be stalled, never placing higher than 14th and having dropped into 16 for the last three runs. This quarter, however, Go rose one spot in the rankings back up to 15. In and of itself, this is a move of limited significance, as the further one goes down the rankings the less significant the differences between them are, ranking-wise. But it has been over a year since we've seen movement from Go, which raises the question of whether there is any room for further upward ascent or whether it will remain hovering in the slot one would expect from a technically well regarded but not particularly versatile (from a use case standpoint) language.
Like Go, Kotlin had spent the last three runs in the same position. It and Rust had been moving in lockstep in recent quarters, but while Rust enters its fourth consecutive run in 19th place, Kotlin managed to achieve some separation this quarter jumping one spot up from 18 to 17.
finally (Score:1)
Finally an actual ranking and not a wishful thinking [tiobe.com] one.
It's honestly boring to read news every other day that C is still the undisputed king of programming languages, and JS is ranked low, and .NET even lower. I've been in the "industry" long enough to know that this is simply not true.
JS, Python, Java, .NET... all much more "popular" (big quotes there) than C in business software nowadays, and that's where the bulk of software dev is.
Re: finally (Score:3)
Re: (Score:1)
You were converting data in Python and managed to write a smaller version in C?
Was this all character arithmetic and mutable strings or something?
Re: finally (Score:1)
Re: (Score:1, Flamebait)
JS, Python, Java, .NET... all much more "popular" (big quotes there) than C in business software nowadays, and that's where the bulk of software dev is.
Hey look, we found an engineer who works in all industries and knows what all businesses use because they only use XYZ. amazin
Re: (Score:3)
Finally an actual ranking and not a wishful thinking
this isn't different to any other "popularity" measure but congratulations if the "results" please you particularly. they're still irrelevant :-)
varies widely (Score:2)
It varies widely by industry and company. At my company my entire team is using Go for everything. There are about 3000 devs using C or C++ as their primary language in their products. Most teams here have Python as a secondary language, rarely as a primary one. Nobody is using .NET. Some of the release infrastructure and IT teams are still writing tools in Java, but we anticipate they will move to Python or Rust soon.
These surveys are always funny to me because neither this one or tiobe have line up with m
Re: (Score:2)
A fortune 500 company with an incompetent IT department? I don't think this is unusual. IT is viewed as an expense and not a revenue generating business unit, most companies don't put a lot of effort into hiring the best and brightest. Sometimes we accidentally get it right, but I assure you we never planned for our IT department to exceed expectations, only to meet them.
Why would you go from a fairly performant JIT compiled language to an incredibly slow interpreted language,
DevOps is taking over the world for better or worse (mostly worse). Having JVMs to deploy is more work than having bare containers with a
Re: (Score:2)
For science and engineering I see more places using Python now. Mostly because the speed of the language is pretty much irrelevant since almost 100% of the time is spent in high performance libraries. One of the programs I have worked on recently spends 99.9% of the time in just a few libraries written in c and the program has thousands of lines of python code. So, while we could rewrite the whole program in something faster, we could gain no performance at all and the code would be harder to write, test, a
Two Lists (Score:4, Interesting)
I'd like to see these broken out into compiled and interpreted languages as well.
Same thing for lists of comparative language speed. For instance, it's kind of absurd to compare Python to c when it comes to speed and executable byte load.
They're pretty different from each other in many cases.
Re: (Score:2)
These distinctions have become less clear over time, and more difficult to assess.
Many languages these days are hybrids, compiled "just in time". While this technique does not result in execution as fast as pure compiled code, it's faster than pure interpreted code. Also, some languages are purely interpreted, while others are "compiled" to bytecode, a compromise between interpreted and compiled architectures.
Speed too is difficult to gauge, because speed has a lot to do with the amount of effort put into o
No Commercial Languages or Tools (Score:2)
This list is a compilation of OSS and free languages. Even the data collection method bares this out. Still, it shows where developers like to spend their time and, um, money (they donâ(TM)t).
Oddly, Shell is a language? Damn.
And, the communityâ(TM)s darling, Rust sits near the bottom?
Same with Go and Kotlin.
And, mobile development tools sit in the lower half of the list as well.
Re: No Commercial Languages or Tools (Score:2)
Re: (Score:2)
That is what the shebang (#!) is for.
Your interactive shell has no impact on the executable script.
I'm sure some of the commands you regularly use are bourne shell, perl or python scripts and you aren't aware of it because they are properly shebanged.
Re: No Commercial Languages or Tools (Score:2)
for i in $(ls
Re: No Commercial Languages or Tools (Score:2)
Re: (Score:2)
This ranking (and other rankings) has no meaning in "the real world (tm)".
COBOL is not listed anywhere probably because no one uses github for that language in commercial environments. From what I hear, large banks and insurance companies are desperate for COBOL people. Never mind other proprietary languages that are used in large companies.
Re: (Score:2)
Based on the methodology, it makes sense that these languages don't appear. These banks and other large companies need to move on, if they want to move forward.
Re: (Score:2)
They don't want to move forward.
They want to keep their business running with absolutely minimal issues. When you handle millions of transactions every day, you can't handle the typical error rate of startup company code. And if you have life insurance contracts to manage where the typical time you need your data to be perfectly consistent is something like 60 years, you are not experimenting with a flavour of the month.
Re: (Score:2)
Your statement makes me think you've never actually looked at "ancient" legacy code. It's long and convoluted. Nobody remembers how it actually works, or what the business rules were that defined it's intended behavior. It does what it does because that's what it does, not because that's what it's supposed to do. In every situation I've seen (and I've seen quite a few), companies don't want to rewrite this legacy code not because it works, but because the revamp will be expensive, and they don't want to pay
Re: (Score:2)
I've worked for insurances and banks, and I still know COBOL (I hate it, though, so I sat out the Millenium Bug frenzy).
Of course revamping this ancient code is expensive. One of those costs is the time and money it'll take to weed out bugs in any new code - both of which were already paid for the old code. I think, at least from my experience, that you overestimate the cost of maintaining this old code. It is rarely touched anymore, so there are no new bugs introduced. Not many old bugs remain, after decad
Re: (Score:2)
You're right, as long as the old code doesn't need to change, you might be OK. But in healthcare and mortgage at least, both of which I've spent years writing code for, the rules and regulations change constantly. Medical coding goes from ICD9 to ICD10, mortgage regulators introduce TRID and URLA. Code that is used in the real world, has to be maintained and changed over time.
Re: (Score:2)
Yes, it's a matter of the field. In banks and insurances, things don't change so often (especially life insurance contracts). In some fields or sub-fields, things do change.
I have seen changes introduced with modern code (Java) on top of old COBOL code. Interesting approach. (basically, fudging the old data)
Re: (Score:2)
If somebody polled me on what I write most of these days, it's ksh (as dictated by the application, but they are replacing with Python). The syntax is awful, but it's capable of doing more than you should with it, at least compared to something like JCL. Like someone else said, it seems to be not really a popularity or "most loved" list, but an actual usage list.
Re: (Score:2)
Look at MATLAB for instance. It is expensive and in practice it is slower than Python and with less access to advanced libraries and encourages a coding style that makes it difficult to test and maintain long term. There is a reason that MATLAB has fallen out of favor. Sure, Python is slow as a language but most of the performance issues can be handled with high performance libraries and that is what people do.
I have also seen a push to get away from proprietary systems because the pain of lock-in is quite
So basically C/C++ and some apps written in those (Score:2, Troll)
So basically C/C++ and some apps written in those languages listed next to them.
Or apps written in a runtime, compiling to native code, that itself was written in C/C++.
Winner is clear.
Re:So basically C/C++ and some apps written in tho (Score:5, Interesting)
Yes, it is amusing when the Kool Kids promoting Language-of-the-week jump up and down proclaiming that C and/or C++ is dead when usually thats what their pet project is actually written in. There are a few exceptions such as Rust which is written in itself now, but most interpreters and VMs are ultimately written in C/C++.
Its a bit like someone who's built a tall tower saying he no longers needs the ground. So whats supporting his tower then?
Re: (Score:2)
> So whats supporting his tower then?
Turtles. It's turtles all the way down.
Re: (Score:2)
I'd add that the only reason to use C++ is if some library you need only provides a C++ interface - and possibly if you yourself are building such a library.
My point is that C++ is so poorly understood by so many programmers that use it for no better reason than "if it's ++, it has to be better". Anyway, for anything that's write once, use once, C++ just gets in the way - unless you just use it as C with a better (and maybe safer) set of standard libraries. And I'd argue that that "write once, use once" p
Re: So basically C/C++ and some apps written in th (Score:3)
Re: (Score:2)
I disagree.
C is just painful to work in. I don't want to have to worry about memory management and buffer overflows every time I manipulate a bloody string. Those better things in the C++ standard library compared to the C standard library are possible *because* of the extra language features C++ has.
Most of the newer languages that compile to native code have no shared library story to speak of, you are expected to build everything into your binaries statically and/or rebuild everything on a new compiler r
Re: (Score:2)
This is why I love working with Python. The cost of writing, testing, and maintaining the code is proportional to the number of lines. However, the performance is typically determined by only a small piece of the code. Python makes it easy to hand off the performance sensitive pieces to C/C++. Most of the time those high performance pieces already exist in standard libraries and when they don't it is pretty easy to write you own part in C and call that from Python.
My normal process is to first write in Pyth
purpose (Score:3)
Each one of those languages has its purpose. Javascript is on top because of the need to build dynamic powerful user interfaces. Of course people use js for server side, I consider that to be a perversion and I do not allow this in my company. We use mostly vanilla Java (and Spring for a single project), PostgreSQL and PostGIS. We have a project in PHP because of the availability of code for a specific task. We use Java for Android and Swift for iOS. We use some Perl for administration. Javascript (Angular 1 & 2 mostly) are used for the UI on the web portion of the system, our UI is very involved. Maps, editors, all sorts of forms and report generators, admin, accounting, customer support, data monitoring, various settings, gauges, etc. So by volume we probably have near one to one ratio between Java on the servers and Javascript code. My point is that In our case this has nothing to do with popularity but everything to do with the purpose. I mean we have C code because of the hardware development, not because it is popular but because that is what you do for firmware for certain processors. Faster to develop than in Assembly or straight machine code.
Re: (Score:2)
Each one of those languages has its purpose. Javascript is on top because of the need to build dynamic powerful user interfaces. Of course people use js for server side, I consider that to be a perversion
This, both of it. JS is popular because you need it to write web apps. If tomorrow all the browsers supported any other programming language natively, that language would instantly rise dramatically. If tomorrow, all the browsers stopped supporting JS, then JS would fall off that chart almost instantly. And the Internet would stop, but hey, collateral damage.
CSS (Score:2)
The best is last - No surprise (Score:2)
Re: (Score:3)
"Best" is subjective, and depends on the specific parameters being evaluated. If you want to write a GUI app, Rust isn't so great. And if you want to use Rust to build a web app, you have to rely on a third-party framework like Rocket. If you need a comprehensive language with full support for different programming paradigms, Rust isn't there yet.
Re: (Score:2)
Re: (Score:2)
I would argue that there is no such thing as "best" _generally_. Without identifying the target application type, it's impossible to evaluate what is "best."
It's like asking which tool in your garage is the "best" tool generally. Well, it all depends on what you need to do. You can have the best hammer in the world, but if you're trying to do plumbing work, you're not going to get far.
Whew! (Score:3)
They got that cutoff line in just the right place to knock Perl off the list. Embarrassment averted.
My take of the RedMonk graph is that the further along the horizontal axis (GitHub) a language is, the more projects are using it. The further up the vertical axis, the more programmers are posting questions on Stack Overflow (Someone please explain this shit!).
C++ popularity explained (Score:2)
Interviewer: Well, it's been a few years since you changed the world of software design, how does it feel, looking back?
Stroustrup: Actually, I was thinking about those days, just before you arrived. Do you remember? Everyone was writing 'C' and, the trouble was, they were pretty damn good at it. Universities got pretty good at teaching it, too. They were turning out competent - I stress the word 'competent' - graduates at a phenomenal rate. That's what caused the problem.
Interviewer: Problem?
Stroustrup: Ye
Reality Adjustment: Javascript Complete Language (Score:2)
css? (Score:2)
a list (Score:3)
They got their heads screwed on right and it's worth reading all the caveats preceeding the article, such as:
The idea is not to offer a statistically valid representation of current usage
Exactly. The list of why Github does not accurately represent the real world is probably longer than this top-20 list. Starting with all the code that isn't on Github at all and isn't as often asked on Stackoverflow about. Such as pretty much all the proprietary software in the world.
What I find much more interesting than the ranking is the relations between the two sources. Visual Basic and VBA seem to be either beginner languages or hard to understand at all (much higher ranked in questions than code), while Go, Rust and Typescript have more code than questions. Apparently good documentation is actually worth it.
Will never be accurate (Score:2)
When I look around from my desk, I can see dozens of non-computer devices that run software which likely was made with C (at least these days). I see the computer's CPU and thi
Programming (Score:1)