These days Java isn't slow to develop on at all. There are plenty of very good frameworks where you can get going with developing a web app or rest service in next to no time with far better tooling support, sophistication etc.
.NET is a serious contender though.
Node isn't really on the same ballpark in terms of maturity.
It the other way around. Java has barely caught up with C#. C# team is typically introducing more features, faster.
I prefer Java's more thoughtful approach to introducing new features.
In addition, green threads approach is a strictly worse and a more limited solution that only solves thread blocking without unlocking the variety of terse concurrency patterns enabled by the way the tasks are handled in .NET. They also add significant overhead to interop with native code due to thread pinning/stack switching (also applies to Go).
Yes. Kotlin fans need to understand that Kotlin is not competing with the old Java ways and stop mentioning bloody enterprise as an argument against Java, because bloody enterprise is largely ignorant to Kotlin‘s cause. EnterpriseStrategyAdapter anti-pattern is not a language problem, it is a management problem. It won’t be solved neither by new features of Java nor by new features of Kotlin. The real competition is in the new code in startups and Java has one big advantage there: faster recruiting, more reliability in tooling, better quality of business code for the money. Kotlin is a good perk for developers in late stage startups, where the teams are big, delivery timelines more relaxed and you can afford fancy but less mature language or tool to consume resources instead of delivering more business value.
The proof being?
Also, it's hard to find Java programmers who haven't been tainted by that enterprise mentality, so in a way it makes hiring hard if you don't have the resources to filter the junk. When you see Clojure or Scala on a resume you know they're above that.
And when it comes to concurrency Rust is the worst language I've ever used by far. The type checker makes dealing with objects between threads extremely painful. With the JVM it's all just handed for you.
Rust is great when you want a tiny binary with minimal memory consumption.
Looking at TIOBE and PYPL, it comes that for backend Java and .NET are huge, followed by .Node.js, followed by Python and then PHP.
Remember that "Systems Programming", which is what Golang was designed for, isn't necessarily just Kernel and device drivers, but everything that isn't "Application Programming", and that includes the whole K8S networking and container stuff where it is very successful.
You're delusional if you really think any of this is true. There are, proportionally to "enterprise", extremely few startups using java. For good reasons.
As an average company what you want from a language is: your team already knows it or is fast to learn, it is arguably better in a measurable way (development is faster, codebase is easier to maintain), developers like it more, it has a large support and audience.
How many of these does Kotlin check?
We got to upgrade from Java 8 to Java 17 in 2023.
I have over two decades of experience and there has always been room for trying out the "new" technologies and keeping up with the latest best practices, even in enterprise. I know that not everyone has this experience, but there are actually a lot that happens outside slow big American legacy companies...
In my current startup we use the latest JVM and have a mix of Java and Kotlin. It works really well and we have never experienced any problems with development speed that was related to code or language syntax. JVM + Spring boot + Postgres may be the "boring" choice, but it has enabled us to focus on getting things done and focusing on the product. It didn't take long for juniors to be productive in our stack either. Spring itself looks a bit scary at first sight, but once you learned the basic philosophy you have less issues than a Node project in my experience.
I know that my experience may not match your experience, so I recognize that I can't make a generic statement. It's just a bit frustrating to see similar statements made by people with bad experiences.
- Not all Java development happens in enterprise. There is a thriving eco system of small to middle sized companies and startups using Java
- Not all enterprises are the same. I've actually noticed a shift to the other extreme, where enterprise uses the latest technologies to attract new employees. Nobody who has a choice wants to work with factory patterns on an old version of Java
- Old Java patterns like factories and extreme use of inheritance is out of fashion. There is of course a lag like in any trends, but remember that Java is so widely used so you will always find companies that are slow to adopt, or have legacy software that is in maintenance mode.
I have to keep alternating between startup and enterprise so that I can keep sane but also get pension contributions, so I do know there is a great world out there. Just not always great paid (am in UK).
Speak for yourself there good buddy. It's pretty important to me!
But I do agree with your broader point. From one perspective, Kotlin has been a great success if we define its mission as a test-bed and laboratory for improving Java proper. Unfortunately, while it has arguably succeeded in that mission, in doing so it might unavoidably fail in another mission, which is to thrive as an independent language.
I'd liken it to yarn and npm. Yarn was a huge success.. at forcing npm to massively improve and thus basically rendering itself irrelevant. A bittersweet success, but a success nonetheless..
I wonder if there's a term for this kind of self-sacrificial project which makes the world better for having existed but doesn't survive the process..
I think you're onto something. Maybe some Java-by-default workplaces lack technically interesting problems that engineers want to solve, so those engineers instead overfocus on the frictions of the parts they can control. Maybe those engineers desire expressiveness in their working programming language to compensate for the restrictions on the rest of their work.
Just a hunch though.
In my startup we also use a "boring" stack, but the problems we solve are innovative and motivation in itself. The developers work closely with customers and can see the impact that the product has. They are no longer working in a Jira-factory and while they are still interested in technology they also find motivation in the product itself.
Kotlin needed to succeed on the native front to live beyond Java. It didn't and that puts it in a perilous long-term spot.
Oh and I wish Java would support „it“ in lambdas, very useful.
The Java version instead looks like this, where you add an exclamation mark to mark it as non-nullable:
class Cursor {
private Point! position;
}
As mentioned in the relevant JEP[1]:
"A null-restricted type is a reference type expressed with the name of a value class followed by the ! symbol."
Goals: "Allow a value class to "opt in" to the automatic creation of an appropriate default value used to initialize fields and arrays that don't store null."
Non-goals: "It is not a goal to support null-restricted types for identity classes or classes that do not provide a default value."
So, I don't see how that's in any way going to threaten Kotlin's position as a null-safe language - Java will almost certainly always have "unsafe" `null`, removing it from Java seems simply impossible at this point (notice that Dart managed to do it, but it had a much, much smaller ecosystem than Java, and even then, it required multiple years of migration of every single Dart package in Pub - and the ones that were unmaintained were simply abandoned and no longer work with the latest versions of Dart which is fully null-safe).
The data that flows through the app at runtime is the big issue, and even just documenting null-safety at the API interfaces goes a long way in making refactorings safer and maintenance less of a pain. Those are usually records nowadays (DTOs, VOs, Entities).