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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Yep. And there’ll be something made in Java 8 in 2030 that nobody has invested in since when it was written, and there’ll be a big budget risky rewrite.
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.
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.
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.
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.
> '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.
> 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.
> 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.
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.
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 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.
> 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.
> 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 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.
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.
> 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 ?
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..
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.
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.
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.
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....
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.
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.
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.
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.
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.
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.
Custom schedulers are coming later with Project Loom. Should be fairly easy to create something where particular threads could have a higher/lower priority.
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.
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.
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...
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.
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.
> "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.
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:
[functional_function(x) for x in l]
Ought to sit on CPU synchronously if l is small and f is fast, in their own process asynchronously if they are medium, and on a GPU if they are massive and slow.
> 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.
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.
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.
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...
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.
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.
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.
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.
Man I was frustrated by this article. Despite it being on a subject matter I normally ignore, it lured me in with the promise to “dig into data publicly in a way that (so far) I haven’t seen anyone else do”.
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.
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.
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.
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.
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.
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?
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
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.
148 comments
[ 2.7 ms ] story [ 207 ms ] threadJava 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.
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.
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.
[1]: https://en.wikipedia.org/wiki/Excelsior_JET
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 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....
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.
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:
Ought to sit on CPU synchronously if l is small and f is fast, in their own process asynchronously if they are medium, and on a GPU if they are massive and slow.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/
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 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)
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.
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.
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?