4 ms·

The future is very certain. Mainline Java has been cherry picking the best features from these languages after there's sufficient traction and the issues have a

The future is very certain. Mainline Java has been cherry picking the best features from these languages after there's sufficient traction and the issues have already surfaced. Since the tooling has to support both Java and some other contender, Java always gets first-class support. Using any of the alternative JVM languages (except maybe Clojure) gives you better syntax, somewhat better abstractions for a few years, and worse tooling. And syntax is overrated. Java might be verbose, but it's well-understood, and it's not actually what slows development.

voidfunc 3y ago
This. I love the Kotlin language but Java had just caught up and the things that made Kotlin super exciting several years ago are less exciting now as Java advanced. Also I looked back at Kotlin recently and things have gotten way more complex than I remember around 1.0. 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.
- MrBuddyCasino 3y ago
  The one major thing Kotlin still has going for it is null safety, and IMO it eclipses every other „nice“ feature. But Java will get this too, and then I‘m not sure I can justify using it. Oh and I wish Java would support „it“ in lambdas, very useful.
  - cryptos 3y ago
    Java will not have the same level of null safety as Kotlin. Instead Types can be explicitly marked as "not null", so the default is still that every reference type can be null.
    - MrBuddyCasino 3y ago
      Yes unfortunately, but I mostly miss null safety in domain classes, not in the stdlib. It remains to be seen if this is "good enough" or not.
  - brabel 3y ago
    Will Java have null-safety?? Can you link to that, I haven't heard anything at all about this.
    - MrBuddyCasino 3y ago
      See "Use of null-restricted types" which is part of Project Valhalla[0], the proposed syntax is the opposite of Kotlin, where everything is non-null by default but can be made nullable by adding a "?", eg "val s: String? = null". The Java version instead looks like this, where you add an exclamation mark to mark it as non-nullable: class Cursor { private Point! position; } [0] https://bugs.openjdk.org/browse/JDK-8251554 https://bugs.openjdk.org/browse/JDK-8251554
      - brabel 3y ago
        Ok, but notice that's not about making Java null-safe in any sense. It's about making "value types" (which will be introduced by Project Valhalla) possibly non-null, mostly for optimization purposes (though it should also benefit programmers reason about value types if they can't be null). 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). [1] https://openjdk.org/jeps/8316779 https://openjdk.org/jeps/8316779
        MrBuddyCasino 3y ago
        I actually missed that it was restricted to value classes, thanks for the correction, this is unfortunate. To be fair null-checking (or just documenting null-safety) the data classes is the main use case, as other cases of nullability (class collaborators, eg a repository injected into a service) are usually a bug and quickly fixed. 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).
pharmakom 3y ago
Syntax may be overrated but expressiveness is not.
pkphilip 3y ago
Yep, all true. 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.
- ShadowBanThis01 3y ago
  Not to mention that Node isn't a language, and Deno is cleaner.
  - pkphilip 3y ago
    I was referring to Java as a platform rather than just as a language. .NET isn't a language either
    - ShadowBanThis01 3y ago
      Indeed, but I only wanted to include so much pedantry!
- DeathArrow 3y ago
  >.NET is a serious contender though. It the other way around. Java has barely caught up with C#. C# team is typically introducing more features, faster.
  - royjacobs 3y ago
    I'm not sure language design should be a race to see who can add the most features, though. I prefer Java's more thoughtful approach to introducing new features.
    - keithnz 3y ago
      in what way do you think it's more thoughtful than C#?
hitekker 3y ago
> Java might be verbose, but it's well-understood, and it's not actually what slows development. 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.
- deleted 3y ago
  [deleted]
- throwaway13623 3y ago
  I think you may have a point. At mature companies, they have largely solved the product market fit and uses a stable stack that just works. I have worked worked for such companies, and developers jumped at the chance to use the latest (untested) technologies for greenfield projects if they had the chance. 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.
esafak 3y ago
Kotlin has great tooling, and Java library compatibility, so why wouldn't you use it? When you work in Kotlin, you give the masses of Java programmers the ability to contribute and a licence to check their EnterpriseGradeFizzBuzzSolutionStrategyFactory mentality at the door. Do Java projects in industry even use the new stuff? Also, you can use virtual threads with coroutines.
- happymellon 3y ago
  I'm allowed to use Streams but var isn't because it makes GitHub PRs difficult to parse. We got to upgrade from Java 8 to Java 17 in 2023.
  - throwaway13623 3y ago
    I've worked in "enterprise" and have a different experience. The enterprise projects that I was working on switched to Java 8 in 2015. There were some legacy services that remained on 5 or 6 for a while, but they were mostly in "maintenance" mode and nobody wanted to spend time on them. 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.
gleenn 3y ago
Clojure is such a joy to use. I get the maturity of the Java ecosystem and the immutability, functional style, and concision of a lisp. If performance really matters, and Clojure does perform well, you can always dive into stuff with all the Java tooling and interop is extremely easy. I really wish more people picked it up.
- cryptos 3y ago
  I feel no desire to use dynamic typing again, as nice as Clojure might otherwise be. While Kotlin is not strictly immutable, it is much better in this regard than Java. Collections are immutable by default in Kotlin (or more precisely you get an immutable view defined by the respective interface) and that is quite useful in practice.
switch007 3y ago
Will they cherry pick Kotlin’s null safety…?
- cryptos 3y ago
  No, they will allow to mark types as explicitly not null (the other way around). The default in Java will still be that everything can be null.
sho 3y ago
> syntax is overrated 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..

voidfunc 3y ago

This. I love the Kotlin language but Java had just caught up and the things that made Kotlin super exciting several years ago are less exciting now as Java advanced. Also I looked back at Kotlin recently and things have gotten way more complex than I remember around 1.0. 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.

MrBuddyCasino 3y ago
The one major thing Kotlin still has going for it is null safety, and IMO it eclipses every other „nice“ feature. But Java will get this too, and then I‘m not sure I can justify using it. Oh and I wish Java would support „it“ in lambdas, very useful.
- cryptos 3y ago
  Java will not have the same level of null safety as Kotlin. Instead Types can be explicitly marked as "not null", so the default is still that every reference type can be null.
  - MrBuddyCasino 3y ago
    Yes unfortunately, but I mostly miss null safety in domain classes, not in the stdlib. It remains to be seen if this is "good enough" or not.
- brabel 3y ago
  Will Java have null-safety?? Can you link to that, I haven't heard anything at all about this.
  - MrBuddyCasino 3y ago
    See "Use of null-restricted types" which is part of Project Valhalla[0], the proposed syntax is the opposite of Kotlin, where everything is non-null by default but can be made nullable by adding a "?", eg "val s: String? = null". The Java version instead looks like this, where you add an exclamation mark to mark it as non-nullable: class Cursor { private Point! position; } [0] https://bugs.openjdk.org/browse/JDK-8251554 https://bugs.openjdk.org/browse/JDK-8251554
    - brabel 3y ago
      Ok, but notice that's not about making Java null-safe in any sense. It's about making "value types" (which will be introduced by Project Valhalla) possibly non-null, mostly for optimization purposes (though it should also benefit programmers reason about value types if they can't be null). 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). [1] https://openjdk.org/jeps/8316779 https://openjdk.org/jeps/8316779
      - MrBuddyCasino 3y ago
        I actually missed that it was restricted to value classes, thanks for the correction, this is unfortunate. To be fair null-checking (or just documenting null-safety) the data classes is the main use case, as other cases of nullability (class collaborators, eg a repository injected into a service) are usually a bug and quickly fixed. 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).

pharmakom 3y ago

Syntax may be overrated but expressiveness is not.

pkphilip 3y ago

Yep, all true. 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.

ShadowBanThis01 3y ago
Not to mention that Node isn't a language, and Deno is cleaner.
- pkphilip 3y ago
  I was referring to Java as a platform rather than just as a language. .NET isn't a language either
  - ShadowBanThis01 3y ago
    Indeed, but I only wanted to include so much pedantry!
DeathArrow 3y ago
>.NET is a serious contender though. It the other way around. Java has barely caught up with C#. C# team is typically introducing more features, faster.
- royjacobs 3y ago
  I'm not sure language design should be a race to see who can add the most features, though. I prefer Java's more thoughtful approach to introducing new features.
  - keithnz 3y ago
    in what way do you think it's more thoughtful than C#?

hitekker 3y ago

> Java might be verbose, but it's well-understood, and it's not actually what slows development. 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.

deleted 3y ago
[deleted]
throwaway13623 3y ago
I think you may have a point. At mature companies, they have largely solved the product market fit and uses a stable stack that just works. I have worked worked for such companies, and developers jumped at the chance to use the latest (untested) technologies for greenfield projects if they had the chance. 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.

esafak 3y ago

Kotlin has great tooling, and Java library compatibility, so why wouldn't you use it? When you work in Kotlin, you give the masses of Java programmers the ability to contribute and a licence to check their EnterpriseGradeFizzBuzzSolutionStrategyFactory mentality at the door. Do Java projects in industry even use the new stuff? Also, you can use virtual threads with coroutines.

happymellon 3y ago
I'm allowed to use Streams but var isn't because it makes GitHub PRs difficult to parse. We got to upgrade from Java 8 to Java 17 in 2023.
- throwaway13623 3y ago
  I've worked in "enterprise" and have a different experience. The enterprise projects that I was working on switched to Java 8 in 2015. There were some legacy services that remained on 5 or 6 for a while, but they were mostly in "maintenance" mode and nobody wanted to spend time on them. 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.

gleenn 3y ago

Clojure is such a joy to use. I get the maturity of the Java ecosystem and the immutability, functional style, and concision of a lisp. If performance really matters, and Clojure does perform well, you can always dive into stuff with all the Java tooling and interop is extremely easy. I really wish more people picked it up.

cryptos 3y ago
I feel no desire to use dynamic typing again, as nice as Clojure might otherwise be. While Kotlin is not strictly immutable, it is much better in this regard than Java. Collections are immutable by default in Kotlin (or more precisely you get an immutable view defined by the respective interface) and that is quite useful in practice.

switch007 3y ago

Will they cherry pick Kotlin’s null safety…?

cryptos 3y ago
No, they will allow to mark types as explicitly not null (the other way around). The default in Java will still be that everything can be null.

sho 3y ago

> syntax is overrated 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..