Java is in decline, and there's data to prove it(devm.io)
devm.io
Java is in decline, and there's data to prove it
https://devm.io/java/java-decline-kotlin
148 comments
I agree 100%.
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.
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.
GitHub and SO may be relevant directionally for languages that have some material presence on those sites. It's not unreasonable to think there may be a decline though, for a language still at #3 or so, the headline somewhat oversells.
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.
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.
A better data source could be online job listings. With the correct considerations that data may give you some insight on tech trends.
Possibly. I'd have to study the data sources to have an opinion. I could definitely see it being a source for languages that you wouldn't necessarily expect your average Python or Javascript developer to know or casually pick up--and therefore would be certain to be explicitly called out in a job ad.
Kotlin may be growing on GitHub, BUT Java has the "late-mover advantage": it will incorporate all good ideas from Kotlin & others into the language and it will skip on all failed ideas (like async/await, etc.). So the Kotlin advantage is shrinking - just like it happened with Groovy and others. The Java ecosystem is huge - you have libraries for just anything. And it is similar to Raspberry Pi vs other competitors: RPI has ecosystem, others are much smaller.
Async/await with futures/tasks/promises is really useful. Having async build in a language simplifies code and reduces boilerplate. Of course it introduces function "colors" as some say, but that's a good tradeoff imo as it's easy to handle (much easier than not having async/awiat). Java ecosystem is quite behind and won't catch-up because the language itself has some pain points like type erasure, nullable references (even C# got rid of that), etc. and that won't change ever. The most popular libraries and frameworks are stuck in time. Languages are moving forward and developers follow that, Rust, TypeScript show the way.
> won't catch-up because the language itself has some pain points like type erasure, nullable references (even C# got rid of that), etc. and that won't change ever.
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.
[1] https://jspecify.dev/
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.
[1] https://jspecify.dev/
I like async/await, but I haven't seen any language do it well. Doing it well would involve:
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:
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]
> "The most popular libraries and frameworks are stuck in time."
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.
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.
Sometimes I wish I had more colors to put on functions to organize my program, storage, resources, etc.
I assume the parent is referring to Loom which makes synchronous threading as efficient for throughput as asynchronous. This has multiple advantages such as a simpler model, easier debugging, understandable stack traces, etc. This is better and simpler than async/await.
At some point Java will introduce value types, which are non-nullable.
I primarily write c# for a living. What's wrong with async await in kotlin? I'd struggle to live without it in c#.
Async/await is extra syntax and one more function color which you have to keep in mind, while being just a workaround for expensive threads.
Recent Java has just made threads cheap, so async concurrency is much simpler and more consistent with existing libraries and APIs.
Recent Java has just made threads cheap, so async concurrency is much simpler and more consistent with existing libraries and APIs.
Cheap threads are fine if you’re in a server environment, and you need to spin up a large number of short lived parallel jobs.
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.
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.
If I understand your point correctly, you say that suspend keyword gives you a hint for which functions are long running, so that you run them in a background thread.
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.
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.
Custom schedulers are coming later with Project Loom. Should be fairly easy to create something where particular threads could have a higher/lower priority.
Loom has zero impact on client, sure. But I disagree that async is better for client. It makes it much harder to debug and track issues.
Can you provide a good cheap thread example for Java vs async/await. What I find online is horrible compared to async/await but people keep talking about function colouring etc. I just cannot see what is the issue. Nor do people give better examples; I was watching some guy on YouTube who said async/await sucks and my idea is better, then spent 30 minutes explaining his idea vaguely. No implementation, no examples.
In the simplest case, you take an async function, remove `async` and `await` keywords, and as a result you get a normal function which you can call and get a result without awaiting, which has better and more predictable performance, and a straightforward stack trace (and a simpler language syntax and semantics). All upsides, no downsides.
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.
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.
An Async<T> is not a T whether you have the monadic sugar or not.
Why make life more difficult when you can have code that reads linearly?
Why make life more difficult when you can have code that reads linearly?
Function coloring
Async/await doesn’t change anything there. It just makes it easier to deal with.
With the new thread model in java (project Loom) you don't need function coloring
I don't know the details. But a synchronous function returns a value and an async function returns something promise-like (it completes at some point and returns a value or an error).
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.
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.
I believe there are no plans to port Kotlin’s null safety to Java, which is possibly the biggest advantage Kotlin has right now. Once you’ve tried it there is no way you would want to live without it.
If this is the "biggest advantage Kotlin has right now" then it doesn't have much added value... Would you rewrite existing code base with millions of lines of code just to get null safety? If THIS is the biggest advantage of Kotlin, then Kotlin is on the same path as Groovy was a decade ago...
In order to replace Java and it's ecosystem one would need to offer MUCH MORE than just null safety...
In order to replace Java and it's ecosystem one would need to offer MUCH MORE than just null safety...
It would depend on the state of that codebase, really. If it’s well tested and does its job well, I wouldn’t bother rewriting it at all.
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.
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.
Java has historically been good at catching up when competing languages outran it.
C# was a better language than Java for some years until Java caught up again.
C# was a better language than Java for some years until Java caught up again.
C# is still a better language than Java, despite the purported catching up.
Can Java steal top-level functions already?
Just use static methods for that. Disadvantage: you are forced to use package and class name spaces. Advantage: everything is inside some namespace.
Agreed. I also find static imports handy to simplify the code at the call site.
I started Java in 1999. And I have heard these type of stories ever since. If Java is dying, then it's a really long process of dying.
Java is dying in the sense that Beteigeuze is going supernova. Some day it will happen, but it may not be in my lifetime.
Java is dying in the sense that Beteigeuze is going supernova. Some day it will happen, but it may not be in my lifetime.
I dont remember a single a Java dying story. It was extremely hyped in the early 00s. There were lots of hate during the very late 00s and early 10s when Ruby on Rails is hyped. But I dont remember anyone saying Java or JVM is dying or dead.
Uff - there were many - and they are again starting to pop up...
A quick search on HN doesn't show much about Java is Dead. And the only Java is dead story I remember was some opinion pieces of how Oracle will make Java unusable. Which hasn't been the case at all. I count those as Oracle hate article rather than Java is dead.
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....
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....
There’s still places that use Lotus Notes. Lotus Notes definitely isn’t dead. It’s not quite as influential as it used to be though.
It's in relative decline i.e. it's growing but not as quickly as other languages. It would be surprising if this wasn't the case because you can't expect a 25-year old language with wide enterprise adoption to grow at the same rate as the newer cooler languages. The text of the article acknowledges this of course.
Python is older. The article is based on bad data. I'm seeing a lot of growth and rekindled interest in Java thanks to latest innovations such as Loom, GraalVM, Valhalla, etc.
C# grew and it's almost as old.
Java is 1995
C# is 2000. And Windows-only for a very long time.
C# is 2000. And Windows-only for a very long time.
And C# is growing…
due to Unity and gaming maybe?
And microservices. asp.net is quite good for it, it turns out. I now know of several companies developing their backend stuff in C#.
I've steered clear of c# my whole career but .net 7 is the bees knees. the minimal API makes it very easy to build endpoints without a bunch of ceremony code.
I really enjoy Java: static typing, near-cpp execution speed, and a very mature set of build tools.
…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.
…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.
Same feeling here.
But my professional life has made me switch between Java, TS and Python.
So in term of time spent, Java is now probably my number 3. But the one I definitely enjoy the most.
Plus 99% of the production code I ship is in Java.
Plus 99% of the production code I ship is in Java.
I think the mentality has changed. We know unmaintained systems fail, so updates are considered part of the cost. That old app that has a bunch of exploits and network stack bugs is probably going to be Java.
You can write unmaintained applications in any language or stack. An unmaintained system is not the language's fault, it's the maintainer's fault.
Sure it’s a culture thing, not a technical thing, but programming languages are technology with their own culture around them. Parent poster was advocating for ’write it and you’re done’ which was the nineties / early 2000s mentality.
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.
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.
I didn't understand the parent poster as advocating for "write it and you're done". To me "long term stability" and "things that will last over a year" simply mean it excels at creating maintainable software.
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.
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.
Interesting. I don’t see any additional value using Java over any other language for long term software that is actually maintained - supporting eg old versions of the compiler / runtime is an indication the parent is in the (still very common in some companies) ‘make it and it’s done’ approach. Oracle is appealing to the same companies that want to run Operating Systems till the end of life.
According to Oracle's roadmap, Java 8 is scheduled to get support from March 2014 to December 2030, and I can't think of other software that has ever had that long of a support lifecycle.
That's true when you have plenty engineering power at your disposal. Most companies can't afford to regularly replace their legacies. That's how they became legacies, after all.
Maintenance isn’t replacement. It’s maintenance.
The companies that don’t maintain end up replacing. And perhaps paying even more, when the big bang replacement project has troubles.
The companies that don’t maintain end up replacing. And perhaps paying even more, when the big bang replacement project has troubles.
And "the fastest growing Kotlin", which runs on the same JVM will solve all those "exploits and network stack bugs"?
Not at all. You have to be very careful about the tools you use and how to use them. Picking the latest thing because it has new tech is a bad idea, just like believing unmaintained software will keep working is a bad idea.
Java is not a perfect language, but for what it proposes to be, a statically typed object-oriented language for building complex systems, it gets 90% right. The platform and the frameworks available for the java ecosystem are unmatched, in my opinion java is a kind of benchmark for the other languages and platforms.
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.
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.
Data from _Github_ is making this argument? Java is surely embedded in the kinds of enterprises that would never share a line of code publicly. I can believe Java is "in decline" for new open source projects, but that's not the same thing as being "in decline" among working programmers.
Yes and no.
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 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 reasons for leaving Swing aren't things breaking all the time or being unmaintained. Swing is maintained by Oracle and JetBrains, for example it recently got a Metal backend. It's been continuously maintained for, what, 20 years now? Compared to the JavaScript framework world, Java UI toolkits are highly stable. Both Android and desktop Java have only had two UI toolkit transitions in their history (Views/Jetpack Compose, Swing/JavaFX respectively), with interop existing in both cases.
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)
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)
[deleted]
My view is that Java was a product of its time. Absolutely fabulous for the 90's and 00's, no question whatsoever about that. But today you would be nuts to use Java instead of Go (or Rust if you need the low-level).
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.
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.
>But today you would be nuts to use Java instead of Go (or Rust if you need the low-level).
I really hope you're trolling to come up with this kind of statement.
I really hope you're trolling to come up with this kind of statement.
It wasn't exactly fabulous back then - 'Enterprise' java was a quagmire of mediocrity in the 00s.
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.
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.
> 'Enterprise' java was a quagmire of mediocrity in the 00s.
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.
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.
There is no client side jvm dependency anymore. You bundle the jvm as part of your executable, using jlink to only include what's needed. It's invisible to a consumer that it's a java program. No need to install JRE.
Seems like your knowledge about Java is ~10 versions old.
Seems like your knowledge about Java is ~10 versions old.
> There is no client side jvm dependency anymore. You bundle the jvm as part of your executable
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 ?
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 ?
Your argument was that go was "batteries included for the user", and I pointed out that's now true for java as well. Now you're moving the goal post.
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..
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..
Go also embeds a copy of the runtime in the executable and has a reputation for big executable size.
I am not familiar with GO but it seems a fallacy to believe that any language not already integrated with the OS wouldn't have some dependency that has to be installed or included in the distrusted files for them to work.
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.
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.
Tuning the JVM is no fun, but tuning by repeatedly rewriting your own code is a lot more effort and risk.
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.
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.
> 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.
> 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.
> 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.
The biggest thing about C# (and it's .NET peers) that turns me off is the link to Windows and Microsoft.
I don't like using Windows or Visual Studio for development.
I don't like using Windows or Visual Studio for development.
> I don't like using Windows or Visual Studio for development
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.
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 me, it’s the language complexity. For 15 years, I was nearly exclusively a C# developer. Since I moved on, it seems it’s gotten quite a bit of syntactic complexity.
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 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.
> For me, it’s the language complexity. For 15 years, I was nearly exclusively a C# developer. Since I moved on, it seems it’s gotten quite a bit of syntactic complexity.
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.
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.
> For me, it’s the language complexity.
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.
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.
You can use Linux or Mac to develop C#/.NET apps with VSCode, JetBrains Rider, or even vim: https://github.com/OmniSharp/omnisharp-vim
I do most my .NET development on Linux… you don’t need windows or visual studio for like 6 years now.
Edit: changed all to most as I still need windows for some c++ specific stuff at the moment.
Edit: changed all to most as I still need windows for some c++ specific stuff at the moment.
> 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.
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.
Haven't found a way to build a C++ DLL on Linux that can be registered in Windows. So I keep my laptop dual boot to do Windows specific stuff. In terms of C# that's entirelly on Fedora right now.
Um last time I got interested in it you still needed mono for runtime the same way java needs a jvm. Is that not the case anymore ?
You don’t need mono anymore as .NET 5 onwards (.NET Core previously) is cross platform.
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.
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.
What about being cross platform? There is something to be said about having a bytecode that makes switching to a new architecture easier.
Java is a bit late to the party, but native binaries are possible for a few years now.
With Excelsior JET [1] you could do that since 2000. They closed the company when GraalVM/Native Image started coming out...
[1]: https://en.wikipedia.org/wiki/Excelsior_JET
[1]: https://en.wikipedia.org/wiki/Excelsior_JET
They were far ahead of the GraalVM - especially with the Swing based GUI applications. The license costed a fortune though...
As long as there are no cheap go programmers to find you will see java being very relevant.
I am not sure I believe it. Java is used by massive amounts of developers happily writing enterprise code and then not bothering with what we would consider the programming community. I would guess that upwards of 90% of all the IT outsourcing programmers are using Java and most of them are not taking online surveys.
After having worked in SMB's and large enterprise environments, this is accurate. There are many, many Java devs working in companies that don't bother with online communities. They took a Java course and occasionally buy books to update their knowledge. They're at peace with being cogs in the machine.
Programming languages will evolve and grow, it's destined to change. No language can stay on top forever.
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.
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.
You can know most of Golang by tomorrow because the language is tiny and doesn’t bring new concepts, except perhaps the channels but you thankfully don’t have to master them.
Meanwhile JavaScript ecosystem and IDE's became so complicated (Note.js & IDE installation & configuration) that I can say Java is easier in this regard...
Which IDE do you use? The Jetbrains family of products do pretty much everything I ask of them out of the box. Even outside of Webstorm (eg, PyCharm, IDEA) they're all JavaScript-ready because it's so common to develop full-stack. Their batteries-included nature is one of the reasons why I'm willing to pay a premium over VSCode.
Hm. Install VS Code. Install Node. You’re good to go. I personally found JS/TS much easier to ramp up than Java.
I don't care about Java, I don't care much about its decline, but I do care about a good analysis. Unfortunately, I thought this article was quite shallow, despite its claims it is backed by data.
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?
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?
I was more interested in the number of software engineers having almost doubled in three years. Did that really happen? Is there any explanation for that?
The hyperexplosive growth of all tech (startups AND enterprise) in the period might be the big explanation. As to what explained that, possibly the chief factor was low interest rates, with other factors being Covid-led digitalization, growin demand for some hot sectors like crypto, fintech, AI, etc.
Kotlin developers. From a fairly small base. RedMonk's programming language rankings have it at #17--just above Ruse and just behind Go.
To put things in perspective that ranking still has Java at #3, one spot down from ten years ago (replaced by Python).
To put things in perspective that ranking still has Java at #3, one spot down from ten years ago (replaced by Python).
No I mean the total number of developers. I know software is growing, but having doubled since 2019 (and it wasn't small in 2019 either) is beyond reasonable.
The doubling of developers quote from the article is specifically Kotlin, which it seems plausible with respect to--even if the overall quoted number seems like a lot. It would represent about 15% of developers worldwide.
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.
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.
I'm referring to the first sentence
> 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.
> 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.
Ah, I missed that. Yes, highly improbable. I wonder if the article is drawing from two different sources.
Measurement error.
Yeah, honestly I was thinking they took two different studies with two different calculation methods and put them alongside.
From afar, modern Java seems like a decent language, and the JVM is truly a marvel. I love the new green threads and native compilation. I just don’t love touching anything associated with litigation-happy Oracle, so I’ll probably continue to observe from afar.
May this data lagging ? Since Oracle has been throwing a lot of updates and willing to make the language a lot more ergonomic it will probably improve stats in the coming years.
Java may not be a fashionable language for new greenfield projects and hot startups now days, but a huge chunk of the world's existing infrastructure runs on it. All that software needs ongoing maintenance, extensions, improvements. So, as a career choice, Java is going to be safe for decades to come. Heck, it's 2023 and there's still plenty of lucrative jobs for COBOL developers. Java will still be a good skill to have in, say, 2050.
After a decade working with Java, I moved onto Scala and rekindled my love of coding.
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).
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).
[deleted]
I was just pulling down some .jar files to run some cloud services locally.
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.
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.
As an android dev i assure the data is real from 2019 most of Java Android app base has been shifted to kotlin because they have good Developer experience with low code more functionality comparing Java, only spring Dev's are now using Java
> In 2022, Kotlin (a language seemingly designed to replace Java)
Kotlin was not at all designed to replace java, anymore than typescript was designed to replace javascript
Kotlin was not at all designed to replace java, anymore than typescript was designed to replace javascript
Netcraft confirms it?
At my jobs we have millions of java LoC, none on github
Java still very much rules in enterprise software. At least in my country it’s easily the most employable language simply for that reason.
Well, probably it's true that java is in decline but i pretty sure it will take the COBOL path: it will take half a century!
[deleted]
Since Python fixed its v2/v3 issue, things seem to go well for it.
Do they count on private repositories? I don't care how many open source todo list projects. I care what languages companies use.
Java is the reason I dropped my CS major. Python brought me back to programming
Again?
I don’t know and don’t care enough to see if it is actually real but it appears as if there is a big licensing problem with Java that makes me not want to touch it with a ten feet pole.
As is typical for these threads on HN, people with the least knowledge and the wrong information are most inclined to comment.
Starting from java 17, it's completely free.
Starting from java 17, it's completely free.
OpenJDK is under GPL+CPE. OracleJDK had "big licensing problem". Almost all are using OpenJDK and moving in this direction.
I’m sure there’s free options, yet if I am a normal user and go to download the JRE, or “download Java”, this is the page I end up on:
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.
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.
That's Java 8. In that version there were big differences between OpenJDK and the Oracle distribution. Post 8 that's no longer true and normal users aren't meant to download a JRE anymore. You bundle the JVM with the app instead. More stuff got open sourced and OpenJDK based distributions are now what people use.
I’ve been working almost exclusively with JVM languages for 6 years but have probably written less than 1000 lines of Java in that time. Almost all my work has been in Kotlin and Scala.
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.
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.
The "added value of Kotlin" is too small to rewrite all those systems from Java to Kotlin. AND: When JVM will introduce new features like value/inlined types - which are not compatible with Kotlin design - there will be problems with Kotlin on JVM... One more reason to stay away from it...
Why would that be incompatible with Kotlin? There are a few ways I can see this working.
Kotlin's data classes can not be mapped to Java's inlined/value classes which will be identity-less. They will need to find workarounds. And the Java's inlined/value classes are not finalized yet so you don't know for sure what can be done until it is finished...
Kotlin has been adding functionality with no signs of stopping. Saying you won't use a language because there's additional functionality that hasn't been finalized isn't really an argument. I use Kotlin and Java but my goto is Kotlin. It's a pleasure to write in. I have complete faith in JetBrains.
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 :-)