Java is in decline, and there's data to prove it
devm.io
devm.io
I was expecting some novel analysis of in depth data scraped from GitHub APIs, or the results of a qualitative survey of big Java shops, or … something?
Instead what we got was a reposting of a few surface level stats pulled from other blog posts which have tolled the death of Java (or C++ or whatever) ad nauseum.
It’s as if the author started with a narrative and went searching for the line plots to justify it.
To be clear I don’t doubt the growth of Java amongst new learners is slowing down. Partly perhaps due to an image problem relative to other new languages, but likely also due to having somewhat saturated its “total addressable market” and not repositioning itself in new “markets” in the way that, say python has done.
But it’s still a great language for many categories of problem (e.g. high throughput live service) and has rich ecosystem. Build what you like with whatever tool is good for the job. Stop using bad stats to motivate your recent learning choices and just go build stuff :-)
Each language shines for specific applications and the provided public data adds little value without clusterization per each application type.
Plus, GitHub is not representative of the real world. As an example, how much Cobol is versioned there compared to the number of LOC in production today?
Also, less new questions on SO may just be a symptom of a mature language instead of a decline.
This is an interesting topic that rarely gets addressed objectively.
But, yes, there are definitely limitations to GitHub and SO data. You'd probably have to do some primary survey research of the audience in question--e.g. large enterprises--to get better numbers for that audience. And, even then, my experience with trying to get some sort of handle on the amount of C code out there years ago was that few people really have a great grasp on lines of code (? an imperfect measure in its own right) of various languages in use in their organizations.
C# was a better language than Java for some years until Java caught up again.
You can always call something async synchronously (by waiting for finishing). Or something synchronous in an async way (by putting it onto another thread). But there is no way to completely remove this fact from the eyes of the programmer. async/await is one of the ways to make it easier to read or write.
Recent Java has just made threads cheap, so async concurrency is much simpler and more consistent with existing libraries and APIs.
Why make life more difficult when you can have code that reads linearly?
It’s not hugely helpful for a UI-bound application which occasionally needs to move some work into a background thread to cut down on UI jank.
Kotlin’s suspending function syntax effectively lets you know which operations are going to (potentially) take a while, so you can make sure the UI thread isn’t blocked, and also make sure you’re communicating to the user that something is happening.
I think that’s a very flawed assumption. Some IO operations are pretty fast, like reading a local filesystem, and can be done in the UI thread, while some heavy non-async functions are accidentally O(n^2), and freeze your IO thread.
And if you say that “of course you should know what you’re doing”, then I think that suspend syntax just adds extra complexity without much semantic benefit.
Probably you can think of a more complex example where it’s not that straightforward, please link code that you have in mind, we can see how with cheap threads it could be made better.
In order to replace Java and it's ecosystem one would need to offer MUCH MORE than just null safety...
But certainly if I were to add new features to an existing Java codebase I’d use Kotlin. The interop between the two is fantastic and for me the null safety alone makes it worthwhile.
When you're building software with a design lifespan of decades or more, this stability is advantagous. You don't want to have to go back and make big code changes (ie: pay increased maintanance costs) every few years because the libraries and frameworks you used are moving targets.
1) Not crashing-and-burning on simple "Hello World" level use-cases (e.g. working in a Python terminal, a 3-liner script, etc.)
2) Giving actual performance gains in typical cases
3) Allowing code to change in both directions, quickly and easily
4) Integrate well into other parts of the language (e.g. list comprehensions or iterators / generators in Python, or multiprocessing)
I also don't like the amount of verbosity added. I can describe a system which would do all-of-the-above, but I don't think I could have independently invented it. It's based on using JS and Python async / await for a while, and understanding where things were done wrong.
On a mile-high level, I'm also ultimately not sure this is the right model. We:
- Created cooperative multitasking (e.g. in Windows 3.1 and earlies)
- Found pre-emptive multitasking worked better, in part since people were bad at deciding when to release control
- Re-invented cooperative multitasking within apps with async / await
I think there is a more dynamic, higher-level programming model where I describe what needs to be done. Just-in-time profiling and optimization, decides what to do synchronously versus asynchronously versus in a new process versus e.g. on a GPU. An operation like:
[functional_function(x) for x in l]
I wouldn't be so sure if I was you. A lot of work is being put into JSpecify [1] lead by Google and with most major players in the Java ecosystem participating. If it is a success we might see it in the language one day and not just with annotations.
Java is dying in the sense that Beteigeuze is going supernova. Some day it will happen, but it may not be in my lifetime.
There were lots of Java is Dead on Desktop. ( And that is certainly true from a consumer standpoint ). But I dont remember a single Java or the JVM ecosystem is dead article.
Comparatively speaking, there are 10 times more Ruby is dead article....
C# is 2000. And Windows-only for a very long time.
…And an emphasis on long term stability. The ecosystem seems to understand this. If you’re building things that will last over a year, use Java.
Because of the time Java was released it’s still common to think this way. Not a slight on Java, there’s things we’ll believe in 2040 that 2023 people won’t quite feel the same way about.
Sure, the mentality you mention has always existed, regardless of language or environment. But I believe that by it's verbose, static nature, Java's maintainability is a great tool to fight against it.
The companies that don’t maintain end up replacing. And perhaps paying even more, when the big bang replacement project has troubles.
Plus 99% of the production code I ship is in Java.
At this point it's almost a meme to say that the hyped language of the moment is killing the established players based on normally weak and disputable claims. Anyone who has been around long enough heard this many, many times for all new language in the block. I have no idea if people will be starting new projects in 10 years with kotlin, but I'm sure the will with java.
The community activity can affect enterprise use as well. For smaller, new projects that do not depend on existing codebase, companies realize that they can build things using a different language which may bring in faster development speeds, active community support and other benefits. Also, if a smaller portion candidate pool knows Java or masters Java, it forces companies to rethink their direction. (At my company we have a lot of trouble hiring people who want to write new code using some legacy stack)
Anecdotally, I know as a matter of fact that companies are moving away from building UI in Java. (I know, this is not the best example.) There used to be a time where people create lots of apps using Java Swing and frameworks based on it. Not anymore -- companies are running away as fast as possible, because things break all the time and hardly anyone is maintaining anything. Guess what they choose instead? The web stack is a favorite.
The issues are elsewhere. For example distribution is/was harder than for a web app, though jlink and Conveyor [1] makes it much easier now than it used to be.
[1] https://hydraulic.software/ (disclaimer: my company/product)
Go has a solid stdlib. Go can cross-compile and provide single-binary distribution.
Go doesn't have and client-side JVM dependency nonsense. Literally just ship the compiled Go binary for your app, everything is "batteries included" for the user. Doesn't matter if you're writing a simple CLI tool or a server.
I even don't write shell scripts any more, I write in Go and ship the binaries. It's cleaner and more robust to code and it's easier to deploy because of zero dependencies.
I quite like it now in some ways, its packaging system allows for comparatively rapid development, you can find libraries for a lot of stuff, and it is quite an expressive language. In other ways it's in a sad state - the reflexive use by most projects of quite heavy frameworks that purport to do a lot of work for you and then fail at various edge cases while adding multiple layers of opaque magic and tons of transitive dependencies... it's less than brilliant. And startup times are an issue.
Go is nice too. It has some shortcomings in the breadth of its ecosystem, but I'm sure that will grow with time.
Yes, I agree.
But at the time, fighting with Tomcat stack traces was often still preferable to a number of other options at the time.
Its obviously been a while, but IIRC for web stuff if you were not a JAR shop, then you were (probably) using ColdFusion or PHP, because the Microsoft badge couldn't be trusted at the time to be put on the web. And back then PHP was v4/v5 where it deservedly gathered community hate unlike today's pretty decent v7/v8. ColdFusion was generally ok though, but I think its largely going the way of Java these days, overtaken by better tech.
> It's cleaner and more robust to code and it's easier to deploy because of zero dependencies.
If you want clean and simple then C# does all this and is clean and simpler.
I don't like using Windows or Visual Studio for development.
Edit: changed all to most as I still need windows for some c++ specific stuff at the moment.
What kind of stuff? I am going to invest heavily in learning C# and .NET in 2023. Anything that takes me out of Unix development and hosting would be a huge no for me. I get the impression you might be doing things at the edges that I might not ever encounter so you are not going to dissuade me, but I'm curious nonetheless.
I also dislike the way you have to manage a sln file— which doesn’t work as well as Go & other more recent languages with my preference for simple editors.
I also didn’t like the enterprisey culture that seemed to nearly always surround C# (this was maybe 10+ years ago, so this may have changed).
All that said, C# + Visual Studio was a remarkably productive combo.
I sometimes get the feeling I'm falling a little behind on the language features. Fortunately they aren't required, and the basics of C# (especially with Linq and generics) are so good that the newer features are benefits to discover as and when needed.
Definitely agree with the solution files. Core is a little better in that at least in the project files there's no longer the repo churn as individual source files don't need to be explicitly listed. I quite like Go's modules, and especially prefer how you can redirect a Go module reference to point directly to a local version when you're working on it, rather than adding a local publish folder as a Nuget source in C#. Little things that add up.
From the outside looking in - I don't know C# yet but I want to learn it in 2023, and I've been perusing docs and books - the language and ecosystem doesn't look much more complex than anything else I've worked with.
It seems to have many features, but that's precisely one of the things that I'm looking for, personally.
> All that said, C# + Visual Studio was a remarkably productive combo
Most C# and .NET devs repeat this (though VS is replaceable with Rider), and honestly I'm too tired to care about much else so that's what I find appealing about it. I just can't bear the decision fatigue of JS (or even Python) any longer.
You don't need Windows or Visual Studio (though Visual Studio [ie not VSCode] is actually pretty good with the native Mac edition).
I do a lot of C# (alongside mainly Go and Node) and the quality of the experience on a Mac is easily on a par, plus the language is much nicer in many areas than its peers (eg needing more than Go's maps and slices). It is Windows-first on the developer tooling, for historical reasons, but far from Windows-only these days.
For deployments you can build self-contained which includes the bits required to run.
So for example I’m building a little browser game in my spare time. It’s a web app and a service. So 2 components. They are deployed to (ubuntu server cos I’m waiting for Amazon linux 202# to release) which does not have the .NET runtime installed. It’s used the built in kestrel server to accept web requests. So no nginx or Apache or anything. Tho I would prob add nginx if the server was public facing but since everything goes via a load balancer I don’t bother.
Seems like your knowledge about Java is ~10 versions old.
So there is still a JVM dependency then, you're just hiding it.
How does that JVM bundling work out for bloat ? I'm guessing it increases the size of the package, and the JVM still has a tendency to eat RAM for breakfast like it always did ?
Does JVM still need "tuning" for production via obscure flags and XML file params ?
I don't really care about a few mb extra size of bundling. Maybe some use cases do. I haven't tweaked jvm params in years. For a dockerized cloud deploy it's fire and forget.
If we're talking about bloat, the current python app I'm working on needs ~20x as many nodes as a similar jvm project I worked on earlier..
As for package size, there are people who bundle a stripped down JVM with a single app, but I don’t think that’s a good use of time—I’d much rather declare a dependency on the complete OpenJDK, and rely on the system package manager to install exactly one copy of it for all apps to use.
Your other comments seem to fall into the mindset of those that think that being able to control or configure your environment is somehow bad because it requires you to know something about that environment.
I really hope you're trolling to come up with this kind of statement.
Java had a good run being one of the fastest rising languages in the late 90s, and it's still not ever yet - some of the biggest applications still use Java to this day. I have a feeling that Kotlin and GoLang are going to be some of the fastest growing languages of this decade, though.
It's my new year's resolution to learn Kotlin and GoLang, just incase they explode like Python has.
First of all, what do these various metrics account for? The article mostly states its about "popularity", without defining it. I suspect the definition vary with the source. And when it's a relative popularity, it should be dealt with care, since a lower rank may be just marginally significative if the competitors are at the same level.
Then, what do all those popularity trends in public websites show about the languages trends in companies? The article implicitly suppose they are the same, or at least are related, but that's far from obvious. For instance, a few years ago Python became the de facto language for teaching programmation in many countries, and I suppose that explains its boom in StackOverflow (4% to 16% in 8 years)... but was there the same boom in the professional world?
I also think the comparison to Kotlin is very shallow. It's not easy to compare trends between an old and widespread language and a much younger and rare language. In the same way the author claims that Kotlin is on its way to replace Java, I could claim that Python will get replaced by Nim. The data is there: Python's popularity is stagnating, while Nim's had a huge grow. But that would be absurd, since they are not in the same category.
Most of all, what does a decline mean? Since the introduction claimed there was a 70% increase in the number of developers over the last 3 years, the usage of Java could increase by 20% while its global share goes down. Would that count as a decline?
To put things in perspective that ranking still has Java at #3, one spot down from ten years ago (replaced by Python).
SlashData, another developer survey platform, published data in 2022 showing that there are now 5 million Kotlin developers worldwide, and that the number of Kotlin developers doubled in one year.
I agree doubling of developers overall doesn't make sense. I quick look suggests maybe up to about a 10% increase.
> In 2019, it was estimated that there were 18 million developers worldwide. That number is now estimated to be 31.1 million by SlashData.
OK, it's not exactly doubling, just 73% increase. Still 13 million developers summoned from the void in three years.
Looking back at the verbosity of the language and the horror of Enterprise Java frameworks, I would never go back to Java.
Everyone currently coding in Java should look into alternative JVM languages like Scala (or Kotlin, although it’s not as expressive).
Java may be in decline, but its scalability is still why it rules the enterprise roost.
Whether that is intrinsic to the language, or a reflection of engineering practices that surround Java is an interesting question.
Kotlin was not at all designed to replace java, anymore than typescript was designed to replace javascript
Starting from java 17, it's completely free.
https://www.java.com/en/download/manual.jsp
With the big warning that we should be aware this isn’t free to use with no strings attached, you need a subscription.
Again, I believe you when you say it has changed but historically using OpenJDK was the not supported option for a lot of products.
That’s just not the kind of software I’m looking for.
Given the clear pattern of Java decline and Kotlin growth combined with the near seamless interoperability between Java and Kotlin, I expect Kotlin will slowly but surely take over during the next 10 years.