Kotlin, Swift, and Ruby losing popularity
infoworld.com
infoworld.com
> 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.
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:
They won't disappear but they won't rise again.
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.
edit: records actually work now, with compileSdk set to 35
edit2: and sealed classes now work too. I tested both on a Samsung Galaxy S9 running Android 10, but the decompiled code looks very much Java 6 compatible so it should run on anything
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".
At the risk of mixing cause and effect, Kotlin is IDEA shaped.
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?
I have done enough web to know I'd bet on python over PHP, but only because I know there are several popular web frameworks in python to chose from.
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.
A high search rate doesn't necessarily mean high rate of real world usage. Correlating across multiple metrics would be a better way to measure popularity.
Although popularity itself may still be a weak signal depending on your purposes.
In Python it is simply possible to create large amounts of flaky software at a rapid pace. People don't care for quality, so the amount of Python software on GitHub and PyPI explodes.
Because everything is basically buggy, people have to search constantly for solutions, which helps this bogus index.
The amount of student questions and AI promotion blogs also helps.
Your core point is valid -- python is grossly overrepresented -- but you don't have to (weakly if not ignorantly) shit on Python to make the point. Loads of extremely important, excellent software is written with python. It's actually laughably easy to write performant, extremely robust, quality solutions with python.
But python is searched a lot because everyone is doing trial little AI things to not be left behind.
(Google also phases out Python for new software.)
Objective-C is a fantastic language. Apple is still writing tons of it. It's the C++ we should have ended up with. Protocol oriented programming is an absolute revelation if you've never been exposed to it before. And being a superset, the ability to seamlessly drop in and out of pure C within the same file is something no other language can do. It also happens to have the most highly cohesive, battle tested, well documented interface libraries in existence for native desktop apps with Cocoa/AppKit/CoreGraphics et.al.
One thing I've found recently is that Obj-C actually works extremely well with agentic coding tools too. Having header files is like a cheat code for them. You don't have to fill your context with implementation code; just the interfaces, and the agent can actually reason about an entire huge codebase.
C++ and Objective C++ can do it just as well.
D and Zig have good C ABI integration.
For Apple platforms I write almost entirely Swift these days but Obj-C really isn’t that bad. Every once in a while for uncomplicated personal projects I’ll use it for its simplicity and compile speed.
Kotlin has built-in multiplatform support though.
Things like ReactNative or <insert cross-platform app dev toolkit here> miss exactly the same point that CEOs firing engineers over LLMs or vibe coders do: the code was _never_ the problem. It's all the domain expertise that allowed you to produce said code.
Do you know how often I use an app that was clearly built for Android, but also happens to run on iOS? Most likely once, and then never again. Because all the conventions are wrong, and it requires more effort than what I'm willing to give it.
Granted, I haven't played around with Flutter so maybe I'm unaware of how good these cross-platform solutions have become, but still.
That being the case, the value prop of cross platform UI frameworks is a lot more shaky. Usually the UI isn’t the hard part, and most apps don’t have a ton of complex logic they need to share either (though there are ways to do this, if necessary). At that point why bother with the cross platform UI framework at all? Just skip the extra layer of bugs and write native.
Problems are subjective.
To the people who work on the app and actually use it as a part of their work or daily lives, you're exactly right.
To the CEO doing the firing, the problem is that he wants a bonus because the other guy who founded his startup around the same time is able to afford <insert ostentatious display of wealth here> and he cannot. And in that case, the engineers are the problem because they cost money. Worst case scenario, you fire the engineers, business goes down, and you have to exit for less money than you thought you would. Not like it matters; you were paying yourself insane amounts of money out of the seed money anyways so you have plenty of money to last until the next big idea that Marc Andreessen wants to flush money away on.
... as for the survival of Objective C, I'm willing to bet that there's an entire class of apps for iOS and iPadOS that most of us use every day but barely give any thought to; apps that are the COBOL banking backends of the mobile world. They've fulfilled a purpose at some business since 2012, they're mission-critical, and you gain zero value rewriting them in anything else, so Objective C keeps getting written to add things onto those apps as new features are needed.
Most people think Kotlin = Android, but it would be interesting to know the exact proportion of Android vs the rest of Kotlin developers. Even frameworks like Spring Boot officially support Kotlin, so I think there's a significant user base, maybe too silent.
So as long Android stays around, Kotlin will keep its relevancy.
Same with Swift and iDevices, especially since Metal was the only thing that Apple still bothered to implement in Objective-C first, with Swift bindings.
Now Ruby, well outside Rails I hardly see any demand for it on the circles I move on.
Except for Android, there are no JVM implementations that take Kotlin into consideration.
Java and Kotlin both compile down to .class Java bytecode.
To the JVM, there is no difference
How do you call Kotlin co-routines from Java code without wrapper types?
My main point was that you can use Java code as is without modifications from Kotlin, and that if you wanted you could have Java code in your project and it will work just fine. Of course if you wanna start calling co-routines from the Java part of your project to the Kotlin part, hey that's up to you.
The only place C++ has really first class treatment on Metal is a shading language.
Python, with a rating of 23.08%
C++, 10.33%
C, 9.94%
Java, 9.63%
C#, 4.39%
JavaScript, 3.71%
Go, 3.02%
Visual Basic, 2.94%
Delphi/Object Pascal, 2.53%
SQL, 2.19% ---
Delphi is the 9th most popular language according to this. More that swift kotlin typescript ruby zig
OCaml suffers greatly from a lack of unified practice. There's a YouTube playlist, a Udemy course... an Apress book and those two other ones with camels on the cover. That's about it for stock OCaml. If you want to learn Jane Street flavored OCaml, there's Real World OCaml.