Statistics
GitHub
GitHub - GitHut 2.0 — Pull Requests 2024
GitHut 2.0 is an attempt to continue the githut.info project. GitHub is the largest code host in the world, with 40 million users and more than 190 million repositories as of January 2020. By analyzing how languages are used in GitHub it’s possible to understand the popularity of programming languages among developers and to discover the unique characteristics of each language.
As for 2024 (no newer data available), “Pascal” (all Delphi projects are detected as “Pascal” by GitHub) is in last (50th) place with 0.026%.
StackOverflow
StackOverflow Developer Survey 2025 — Technology Section
Most popular technologies → Programming, scripting, and markup languages
Which programming, scripting, and markup languages have you done extensive development work in over the past year, and which do you want to work in over the next year?
In “All respondents” and “Professionals” categories, Delphi is 29th with 2.5% (compare: C# — 27.8%, Java — 29.4%), in the “Learning to code” category, Delphi is 38th with 1.7% (C# — 23.1%, Java — 40.8%).
Admired and Desired → Programming, scripting, and markup languages
Which programming, scripting, and markup languages have you done extensive development work in over the past year, and which do you want to work in over the next year?
Delphi is in 36th place, only 1.9% of developers marked it as “desired”
Opinions
Delphi, a once up-and-coming programming language, is often seen as “dying out”. A look at the developer community shows that the number of Delphi developers is declining compared to other languages, and most new developers are opting for languages such as Java, Python or C#.
This has led to a growing “skills gap” as fewer and fewer professionals with Delphi experience are available. A survey by Stackoverflow, one of the best-known question-and-answer websites for programmers and developers, shows that in 2025, only 1.8 % of developers worldwide (over 45.000 participants) will still use or be proficient in Delphi as a programming language. Even more alarming: of these, only just under 1% state that they are actively learning Delphi.
— “The Future of Delphi Programming: Be Careful” (Soxes AG)
COBOL is still updated — it’s even gained object-oriented extensions. PowerBuilder can now target .NET and the web. Of course, no one cares except those who maintain legacy COBOL or PowerBuilder software. No startup is going to even consider those languages. No one under 40 is even going to have ever heard of or seen a line of code in those languages. Pascal stopped being taught in most parts of the world around 2000 or a little earlier. That’s a whole generation now who have grown up without seeing a line of Pascal.
Delphi developers are in their 40s or 50s. Where is the next generation coming from? It’s not enterprise, either, so it’s not like new developers will be trained by large companies (or want to use a language without memory management, type inference, etc.). Simply put, when Delphi devs leave or retire, there’s no one to take their place. There is no next generation, and therefore while it may not be “dead”, it does have a terminal illness that no one seems to want to treat.
— John Shepherd (Quora)
There are legacy apps that were built in Delphi, so there is a small market out there for Delphi. Since those customers are willing to pay, that’s what keeping Delphi alive and Embarcadero has not pulled the plug, because it generates revenue.
But if ever those companies migrate their apps, Delphi is dead.
…
If you are a startup with a brilliant idea, would you like to invest in Delphi whose resource you would not find? Time is money, would you be willing to wait or train people to code in Delphi? Would people stay with your company? What will be the future of your idea then?
And if you are an established company, 99% of the time you would stick to what you have confidence in. You might allow some people in your company to try Dart, or Rust but would never allow stupid experimentation using something that has no future!
Some people would say Delphi is not dead. Very true, just like FORTRAN, Cobol, Ada or VB6, but:
- Would any company like to invest in building apps in Delphi?
- Would any student like to use it for his final year project?
- Would YOU use it for the next killer app?
NEVER! Except only the legacy app maintainers, some hobbyists but mostly nostalgic people.
— Sarfaz Ahmed (Quora)
I don’t think it is dead, but I have to admit that it is increasingly difficult to find Delphi jobs. Generally they are maintenance jobs, looking only for junior developers who probably have never written a single Delphi application from ground up.
— Shah Ping (Quora)
I worked with Delphi personally and professionally for many, many years. You were at the precipice of unemployment in the 2000s if you used it then. To do it now? You’re like a looney toons character suspended in mid-air. There’s Delphi work around, to be sure, but you’re competing against people with 30 years of commercial experience building — or rather just keeping them limping along — today, and they are as desperate as the Powerbuilder, Oracle Forms, FoxPro and Lotus Domino folk in scratching out an income in a stagnant pool.
Delphi died an ignominious death a long time ago, and it is truly sad. I miss it; frontend development today is a joke compared to what we could do with Delphi. But so what? It’s dead. And it’s not coming back.
— mickeyp (news.ycombinator.com)
A product can’t survive without:
- A work force
- A jobs market i.e. new Delphi jobs
- Up-to-date libraries
- Commercial trust in the future of the product and the above factors
- New projects coming onboard each year
I did not suggest legacy projects don’t exist, that they don’t work great or that their developers aren’t great — they do and they are.
But the sad reality is, these projects live only because of their developers who are ageing and their projects will die with them when they retire or sadly pass away. This cliff has now been reached. How many Delphi developers really plan to be still working in 5 years time in Australia?
No major new work has been started in Delphi, in the western world over the last 10 years at any commercial scale to support a work force, support the third party vendors or support the future of Delphi.
Feel free to document a major app or project that started out new in the last 10 years in the western world in Delphi and reached commercial success.
A product can’t be considered serious if it’s only being used for maintenance and hobbyist. This is the definition of dying.
Ian and his friends nailed the last nail in the coffin when they refused to release a yearly roadmap. They’ve also never shown any factual data to counteract all the factual evidence out there about Delphi’s commercial death. No subscriber numbers etc to prove we are wrong.
YouTube views of Delphi VS Microsoft releases, forum usage, professional group membership etc all provide a picture so clear you really have to be true to the faith to believe it’s not the case.
— hsvandrew (Adug.org.au)
Why should you not trust the TIOBE index
▾ Click to read more…
-
It measures “search noise,” not real-world usage. TIOBE is driven largely by counts of search-engine queries and mentions (e.g., “{language} programming”). That’s a proxy for interest, confusion, tutorial-seeking, SEO churn, or even controversy — not a proxy for “companies are hiring for this” or “this is a strong ecosystem to build on.”
-
It’s extremely vulnerable to SEO and wording artifacts.
- It ignores what you actually want: job market signal.
If you’re optimizing for career outcomes or starting a new project, you care about:
- Open roles in your geography/remote preference
- Seniority mix (entry-level vs mid/senior)
- Compensation bands
- Industry stability (regulated industries, enterprise, government)
- Transferability (ecosystem and adjacent stacks)
TIOBE doesn’t measure any of that directly. A language can be “popular” in searches and still have weak hiring demand, or be concentrated in niches that don’t match your goals.
- It collapses many different “markets” into one misleading number.
One index number tries to represent: embedded, mobile, web, enterprise, data, ML, games, scripting, academic, legacy maintenance, etc. That’s like using a single “vehicle popularity ranking” to choose between a forklift, a cargo bike, and a long-haul truck. When starting a project, the context dominates:
- Latency constraints
- Team experience
- Deployment targets
- Compliance/security
- Time-to-market vs performance
- Vendor ecosystem
TIOBE can’t encode those constraints.
-
It overweights legacy “gravity” and underweights developer reality. Legacy languages can generate large footprints of discussion (maintenance, tutorials, errors, migrations). That can keep them high in “interest” metrics, even if the best new project choice for most teams is elsewhere. For your career, that can bait you into learning something with a lot of existing code (and pain), without realizing the new build momentum and tooling is elsewhere.
- It doesn’t tell you the cost of success.
For new projects, what matters is:
- Library quality
- Observability tooling
- Build/test speed
- CI/CD support
- Debugging experience
- Hiring pipeline
- Operational reliability
- Cloud/service integrations
- Vendor lock-in vs. open-source compiler, libraries, and tooling
A language can rank well and still be expensive to build/operate with due to tooling gaps or talent scarcity.