The TIOBE index is widely regarded as mostly useless for the kind of thing people try to use it for. Their own description of the index shows the problem:
> Basically the calculation comes down to counting hits for the search query +"<language> programming"
That's it. The rest of the definition hinges on weighting the different search engines and deciding what counts as a programming language. So the index is actually just measuring a proxy (search hits) for the number of online pages that contain the words "$LANG programming" in them.
A number of problems become evident with that definition, but most important here is that common linguistic usage patterns in a community have an enormous impact in rating. "Swift programming" may get fewer hits, but "iOS development" is a synonymous search term these days that gets ignored by TIOBE. The same for "Rails" and "Ruby" and "Android" and "Kotlin".
TIOBE is fine as a tool if you understand its limitations, but articles like this rarely do.
Kind of. It doesn't measure search traffic, it measures search results. So I could see it doing that to the extent that fewer articles may be being written in certain communities than before.
Aside from my doubts about the way this is measured, is it even a good strategy to simply chase the currently "most popular" languages?
A few years ago I shared an office with three aged graybeards who sat in a corner and spent 3 half-days per week silently working on legacy COBOL systems. I thought they were something of a joke, and said so when a person with insight into their invoicing was present. They corrected my impression.
Aside from "the right tool for the right job" kind of conversation, there's one inherent aspect to chasing the most popular language (given that you find an actual ranking that's put up meaningfully, which I don't think the TIOBE index is): you may find more people able and willing to work with it, which can sometimes be a feature.
I've been in a company which had a major refactor need, and they took the opportunity to slowly convert their backend from PHP to Go* because they couldn't find any good PHP developer (let alone any willing to work in PHP). For the actual project, it kinda worked, but for the recruitment, it went from not having any applicants / very mediocre people, to having way more people applying, and a few competent ones in that pool.
* As to whether that was the right choice, that's a completely different topic...
Sort of. Chasing the latest everything is always a bad thing. Chasing ONE latest anything may be a good thing. Staying to far back can be a big negative - COBOL may pay the bills, but you will have a hard time hiring someone willing to work with it, and there are some things we have learned since COBOL that really are worth having.
You should always keep an eye out on what is happening elsewhere. Sometimes those things are enough better you should switch. Sometimes those things are better but you should just add them to what you have. If you write COBOL you should be writing the 2023 version today which has a lot of things not in the original 1959 version (what I don't know what since I don't write COBOL).
There is a cost to switching/rewriting everything. There is a cost to whatever downsides of your language/frameworks have. The other language/framework options also have their own downsides - often they are unknown. Most of the problems you are having are not caused by the language, rewriting to a better architecture in the current language would solve a lot of problems (I recommend you put the money for a big rewrite into a refactor in place effort, the costs long term is similar, but you are always shippable which means if budgets are a concern you can scale back and extend the schedule)
If the language is popular that is a big advantage. I can teach you whatever programming language you choose to use, but if the language you choose is popular you can hire "experts" while if the language is unique you will spend years training people before they are experts. This is a big advantage of something popular.
I agree this is not a good strategy, but I found it curious that Kotlin seems to have stalled and maybe is even declining. After all, it really seems what many developers would like Java to be. The article also mentions the existence of better alternatives in the form of some other languages' cross-platform frameworks, but doesn't make any concrete example. Anyone has ideas on which frameworks those could be?
Btw, Kotlin isn't platform-specific as they seems to say in the article, it's cross-platform as well.
> After all, it really seems what many developers would like Java to be.
As a backend Kotlin developer, I wonder if a lot of the advantages that Kotlin used to have over Java are rendered moot by new features in recent versions of Java.
It may not be that Kotlin is declining in general but rather mobile development using it (and Swift) is declining which is the dominant case. If we could see non-mobile Kotlin use that would be an interesting trend to see. I imagine some of the adoption and familiarity could carry over to backend uses.
The TIOBE index is based on search queries. I stopped relying on it years ago, and I imagine this will become less and less relevant over the coming years.
I agree. It would be useful to include additional metrics on things like new/active projects/number of commits/etc. that give a better idea/representation of how active a programming language is.
Search queries will only really reflect news around a language, such as an AI paper, Ladybird announcing it is adopting Swift, a language conference (like Google's I/O conferences referencing Kotlin), etc.
High or rising TIOBE ranking might as well be viewed as a warning sign, like “why are people struggling with this language so much?”
Especially with AI tools integrated into IDEs and able to usually get you over small hiccups with syntax or explaining a language concept interactively and with RAG on the language and framework docs, personally searching through the SEO slop is increasingly a waste of time.
I write Java for Android. But I'm more like jack of all trades, I'm not specializing on Android development. I know Kotlin, but it's too complex for my taste, so I'm avoiding it, Java works just fine.
Actually the same for iOS and Objective C. I learned Objective C like 15 years ago and it didn't change much since then. I also learned Swift the day it was released and I know nothing about modern Swift, it changes so fast. I don't really care. Objective C works just fine for me too.
I still write Android apps exclusively in Java, albeit it's Java 17. The most recent new app I started was in 2022.
I don't know Kotlin and don't want to know it. The one time I had to deal with an app with parts of it in Kotlin, doing anything in those parts felt like coding through molasses.
So, as someone who only knows the basics of the android ecosystem, are you able to compile down to lower target versions and still use the Java 17 niceties?
As I understand it, most people were using Kotlin because the alternative was java 8, and the syntactic sugar made it worth migrating.
Kotlin really got lucky with Google choosing it for Android dev. While Google is known for relegating some of its tech to the dust bin, Android is too big at the moment. Flutter + Dart was a little surprising though. If they hadn't chosen Kotlin, I couldn't have seen a real path forward for JetBrains. It was basically a much nicer Scala (and I'd argue, a really nice Java) But they keep it locked up with IntelliJ. This, by the way, is why none of us are writing SmallTalk these days. Having to purchase and use a particular IDE is not how we do software these days. (Feel free to tell me how AMAZING IntelliJ is... it's not my cup of tea)
I recently blogged about the developer experience with server-side Kotlin at https://glennengstrand.info/software/coding/csharp/kotlin so you should know that the IntelliJ folks offer a community edition of their IDE that works great with Kotlin. You don't even need the IntelliJ IDE at all. I was able to code up that Kotlin service using VS Code which was also a great experience. Nothing felt limited or dummied down at all.
The entire JVM ecosystem is built around "we all know you're using an IDE, right?" I among most folks who use Kotlin are aware of the Community Edition of IntelliJ. The price isn't the thing keeping me from using it. 1. an employer _should_ be covering that cost. 2. The tools is truly outstanding and well worth the 500 bucks (I'd argue it's not worth 500 bucks a year but...) With all of that said, I really don't enjoy the IDE experience. I do tend to write Kotlin + Quarkus in NeoVim... but the LSP is a volunteer effort. Meanwhile Rust and Go's LSPs are incredibly.
My biggest complaint against the JVM community will alwyas be, "don't expect that we can auto-import... document where methods/constant/imported vars come from".
Nice writeup, but it's kinda meaningless to consider import statements when comparing LOC as they're written for you in both C# and Kotlin. Also, just because the default code style doesn't like glob imports doesn't mean you have to roll with it - Kotlin isn't like Go where there's One True Style and everyone is expected to follow it. You can just turn on import globbing and optimization. That would presumably cause LOC to be much more similar.
Oh no doubt it's my favorite backend way to build an API. Just toss in SpringBoot or Quarkus and it's very nice. The only thing that bothers me is that it's a pain to use with NeoVim.
It always boggles my mind that python is so popular while being so unfriendly and hard to use. Terrible package management. Poor typing system. Useless stack traces. Unintuitive syntax (no ternary operator?!). And yet it has become the default language almost.
I guess the way forward now would be to "make python good". Thank goodness uv is trying.
I personally don't think this "use a dependency for every little thing" npm development style is good for software quality, performance, maintainability, etc. The complaints I see about Python in this regard seem to be coming from that mindset.
Using the included batteries, and just adding a small number of well vetted extras had worked great in my experience.
I like Python of short scripts. Anything over 100 lines and bash is painful. Python works great up to about 50,000 lines of code. Anything larger than that and I need a strongly typed language. A larger number of programs/services/scripts can be done in less than 50,000 lines of code and python is easier than getting those type details right, but as you get bigger than that the effort of getting type details correct becomes well worth it.
The lines of code numbers above are somewhat arbitrary and not a hard block. Instead their are a continuum, the more lines of code you have the harder code is to maintain. Languages offer various things that make it easier to maintain long programs, but they just help, 10k lines of python will always be easier than 10 million lines of Java.
But yeah I can't stop myself from eye-rolling when I'm using python (which honestly is very useful for a lot of data manip that is one-off for my job) and there's just tiny syntax differences for seemingly no reason, like not instead of !, X if Y else Z, len(x) instead of it being a member... it's all very fast to look up, but easy to miss when you're also working in C++ or Rust.
> Kotlin and Swift have declined in the ratings because they are both mainly used for a particular mobile platform, Kotlin for Android and Swift for iOS, Jansen said. There are other sufficiently good languages and frameworks to use for cross-platform development now,
Yeah that sounds about right, native work has been drying up quite a bit in the past couple of years and React Native is all everyone is after, it seems. YMMV
RN also has a very unfair advantage where you can use Codepush to OTA updates, bypassing Apple/Google's reviews (within its limits of course). It's against the TOS, but the store caretakers have no way (or don't want to) of policing apps that do that, so in the end if you do native only - you're playing with one hand behind your back.
And it's not only small devs that do that - all the major automotive manufacturers like BMW (Flutter), GM (React Native), etc do it.
I am curious how much of python’s rise is a result of the data/ai rise and people wanting to be a part of that. Is it being used to consistently build production applications? If the TIOBE is mostly lines of code, which it’s description seems to indicate, are their any other indexes that are something like “production lines of code”?
As a guy who started off as a PHP developer and graduated into a jack of all trades, with only so much time and different types of problems to solve, and before AI, the objective for me has been to economize my learning capacity and not double up on learning languages to solve the same domains of problems.
To that end, I’ve always seen Python and Ruby as similar except Python has all the data goodness and a slightly less popular web framework for which I could always fallback on PHP (Laravel) if I need a web framework that got it all.
Betting on Python a decade ago was a good use of my time.
How do you define "production application" though? Customer facing? Running 24/7 to keep systems alive?
Python is great for making scripts, e.g. to process logs or quickly analyse and plot data for example. I've seen so many of these Python scripts and internal apps that are critical to customer support and keeping other systems healthy. They might not be in the critical path but they help with and speed up work.
Readit News
> Basically the calculation comes down to counting hits for the search query +"<language> programming"
That's it. The rest of the definition hinges on weighting the different search engines and deciding what counts as a programming language. So the index is actually just measuring a proxy (search hits) for the number of online pages that contain the words "$LANG programming" in them.
A number of problems become evident with that definition, but most important here is that common linguistic usage patterns in a community have an enormous impact in rating. "Swift programming" may get fewer hits, but "iOS development" is a synonymous search term these days that gets ignored by TIOBE. The same for "Rails" and "Ruby" and "Android" and "Kotlin".
TIOBE is fine as a tool if you understand its limitations, but articles like this rarely do.
https://www.tiobe.com/tiobe-index/programminglanguages_defin...
A few years ago I shared an office with three aged graybeards who sat in a corner and spent 3 half-days per week silently working on legacy COBOL systems. I thought they were something of a joke, and said so when a person with insight into their invoicing was present. They corrected my impression.
I've been in a company which had a major refactor need, and they took the opportunity to slowly convert their backend from PHP to Go* because they couldn't find any good PHP developer (let alone any willing to work in PHP). For the actual project, it kinda worked, but for the recruitment, it went from not having any applicants / very mediocre people, to having way more people applying, and a few competent ones in that pool.
* As to whether that was the right choice, that's a completely different topic...
You should always keep an eye out on what is happening elsewhere. Sometimes those things are enough better you should switch. Sometimes those things are better but you should just add them to what you have. If you write COBOL you should be writing the 2023 version today which has a lot of things not in the original 1959 version (what I don't know what since I don't write COBOL).
There is a cost to switching/rewriting everything. There is a cost to whatever downsides of your language/frameworks have. The other language/framework options also have their own downsides - often they are unknown. Most of the problems you are having are not caused by the language, rewriting to a better architecture in the current language would solve a lot of problems (I recommend you put the money for a big rewrite into a refactor in place effort, the costs long term is similar, but you are always shippable which means if budgets are a concern you can scale back and extend the schedule)
If the language is popular that is a big advantage. I can teach you whatever programming language you choose to use, but if the language you choose is popular you can hire "experts" while if the language is unique you will spend years training people before they are experts. This is a big advantage of something popular.
As a backend Kotlin developer, I wonder if a lot of the advantages that Kotlin used to have over Java are rendered moot by new features in recent versions of Java.
I would imagine stuff like ReactNative for example, which lets you write JS for mobile apps in a platform-agnostic manner.
Deleted Comment
https://www.tiobe.com/tiobe-index/programminglanguages_defin...
Search queries will only really reflect news around a language, such as an AI paper, Ladybird announcing it is adopting Swift, a language conference (like Google's I/O conferences referencing Kotlin), etc.
Especially with AI tools integrated into IDEs and able to usually get you over small hiccups with syntax or explaining a language concept interactively and with RAG on the language and framework docs, personally searching through the SEO slop is increasingly a waste of time.
That is one way of looking at it - an alternative interpretation is that mobile development has hit a plateau.
I don't think someone starting an iOS or Android app today would pick Objective-C/Java, but maybe there are less mobile apps being made today?
To sum up what I am saying:
Anyone got good data on this?Actually the same for iOS and Objective C. I learned Objective C like 15 years ago and it didn't change much since then. I also learned Swift the day it was released and I know nothing about modern Swift, it changes so fast. I don't really care. Objective C works just fine for me too.
I don't know Kotlin and don't want to know it. The one time I had to deal with an app with parts of it in Kotlin, doing anything in those parts felt like coding through molasses.
As I understand it, most people were using Kotlin because the alternative was java 8, and the syntactic sugar made it worth migrating.
My biggest complaint against the JVM community will alwyas be, "don't expect that we can auto-import... document where methods/constant/imported vars come from".
I guess the way forward now would be to "make python good". Thank goodness uv is trying.
Using the included batteries, and just adding a small number of well vetted extras had worked great in my experience.
The lines of code numbers above are somewhat arbitrary and not a hard block. Instead their are a continuum, the more lines of code you have the harder code is to maintain. Languages offer various things that make it easier to maintain long programs, but they just help, 10k lines of python will always be easier than 10 million lines of Java.
But yeah I can't stop myself from eye-rolling when I'm using python (which honestly is very useful for a lot of data manip that is one-off for my job) and there's just tiny syntax differences for seemingly no reason, like not instead of !, X if Y else Z, len(x) instead of it being a member... it's all very fast to look up, but easy to miss when you're also working in C++ or Rust.
Yeah that sounds about right, native work has been drying up quite a bit in the past couple of years and React Native is all everyone is after, it seems. YMMV
RN also has a very unfair advantage where you can use Codepush to OTA updates, bypassing Apple/Google's reviews (within its limits of course). It's against the TOS, but the store caretakers have no way (or don't want to) of policing apps that do that, so in the end if you do native only - you're playing with one hand behind your back.
And it's not only small devs that do that - all the major automotive manufacturers like BMW (Flutter), GM (React Native), etc do it.
To that end, I’ve always seen Python and Ruby as similar except Python has all the data goodness and a slightly less popular web framework for which I could always fallback on PHP (Laravel) if I need a web framework that got it all.
Betting on Python a decade ago was a good use of my time.
Would you make the same bet today? Or if not, what other language/technology would you bet on?
Python is great for making scripts, e.g. to process logs or quickly analyse and plot data for example. I've seen so many of these Python scripts and internal apps that are critical to customer support and keeping other systems healthy. They might not be in the critical path but they help with and speed up work.