6 ms·

For those in the ecosystem these days - is there a compelling reason to choose Java over Kotlin? I am under the impression that Kotlin is a better Java without

For those in the ecosystem these days - is there a compelling reason to choose Java over Kotlin? I am under the impression that Kotlin is a better Java without any sacrifices. Is this true?

crickey 3y ago
I mean what are your goals, its never as clear cut as X is objectively better in all use cases over Y
mardifoufs 3y ago
At this point I think the more relevant question is: is there any point to using kotlin if you are not doing android dev?
- afavour 3y ago
  Personally I find it more enjoyable to code in than Java. There’s also maybe an argument to be made around Kotlin Native, KotlinJS too.
  - robertlagrant 3y ago
    Also Kotlin Multiplatform.
  - kaba0 3y ago
    GraalVM, TeaVM, Google’s Closure compiler. Java is an insanely big language, so if a tiny language has something, you can bet Java also has it in a much more ready form.
- xwowsersx 3y ago
  Sure, assuming you are happy with most of the language constructs and it feels ergonomic to you, Kotlin can make sense for backend/APIs, while still having access to all the Java libs/packages. I'm starting several new largeish projects now and have decided on using Kotlin.
- mdaniel 3y ago
  Having `@Nullable`/`@Nonnull` (or its dumb `Optional<T>` friend) is nothing compared to NPE being a compilation failure Also, all hail `val`; `final var` is objectively worse
  - iraqmtpizza 3y ago
    var is write-only and won't catch type errors
    - mdaniel 3y ago
      Sorry, I don't understand your concern. My observation is that having a variable declaration that is single-assigment in Java requires the "final" keyword, which in the most charitable case is "final var" where the caller and/or the IDE know the type (e.g. "final var foo = new ArrayList<Bar>()") and in the degenerate case is "final ApplicationEvent<Map<String, List<String>>> thing = doSomething()" In Kotlin one can get finality via the much nicer "val" keyword, and seems to be idiomatically the default, versus Java's mutable-by-default stance Saying either language "won't catch type errors" is not something I can agree with
      - iraqmtpizza 3y ago
        Normally, declaring a variable offers type safety. var matches anything and thus it's never a compile-time error. If someone accidentally changes the return type of getAddresses from Map to List, there is no compile-time error. There is nothing to check the return type against except Object in this case because Tuple.of takes Objects. final var addressMap = getAddresses(); final Tuple args = Tuple.of("a", 200L, x); So you may as well inline the method call and give up on any type checking. Another example: final long limit = getLimit(); for (var i = 0; i < limit; i++) {} The wrapping behavior is determined by whether there is an L (or lowercase, l) after the 0. If limit happens to be greater than Integer.MAX_VALUE, that L is the difference between an infinite loop and a well-behaved routine. Some junior programmer could easily remove the L accidentally. And you wouldn't run into the bug until limit gets big enough. Which could happen at runtime in production. All because you wanted to save one character by using var instead of long. This is just what I could think of off the top of my head. I'm sure there are other examples. You are absolutely giving up some compile-time sanity checks with var. If it's just some throwaway script, then fine. But if so why use Java in the first place?
- cutler 3y ago
  Spring Boot has full Kotlin support.
smallerfish 3y ago
I still prefer Kotlin, though the gap is closing. Null checking, extension functions, type inference, and various other features are really nice. I'm not sure what's on the Kotlin roadmap / whether JetBrains see value in making major improvements to the language.
exabrial 3y ago
Better is subjective. Java is a great language, has a mature and stable codebase, it runs at near-Cpp speed, has built-in SNMP-like monitoring, and the developers are super careful about not breaking backwards compatibility. That's all about there is to say about it. Kotlin is also a good language for many of the same reasons, mainly because it is run on the JVM. One really isn't better, they're just different. Use the tool you know how to use, and master it. The only category I would say is objectively "better" is Java (and other JVM languages like Kotlin) has the best IDEs out of _any_ language. There is nothing on-par for Python, Ruby, C/Cpp, etc as far as autocompletion, type inference, automated refactoring, partial recompiles, hot code swapping, unit test integration, Tomcat or server integration, code formatting, etc. Java is great because of it's IDEs. If we were writing Java in notepad.exe it'd be a pretty clunky experience, but nobody serious does that.
- randoglando 3y ago
  > The only category I would say is objectively "better" is Java has the best IDEs out of _any_ language. Kotlin was made by the people behind IntelliJ. I'm not sure I understand your point.
  - exabrial 3y ago
    sorry, I should have included Kotlin in that part of my comment. IntelliJ Kotlin is quite incredible. Every time I've needed to use it, my expectations have been met. Makes switching to vscode feeling going from an framing nailer to beating in rusty iron nails with a rock.
    - iraqmtpizza 3y ago
      extension functions can be scattered across any number of files and the import statements do not tell you where they are declared. kotlin was specifically designed to drive sales of IntelliJ
  - wiseowise 3y ago
    And it’s slow as molasses without feature parity. One feature that comes to mind is rearrange methods. I haven’t used Java in years so someone who actually uses both can find more cases where Kotlin support is worse than Java’s.
fiddlerwoaroof 3y ago
I've always viewed this the opposite way: Kotlin isn't better enough to prefer it to recent Java versions.
- randoglando 3y ago
  Kotlin is less verbose, has better null safety and mutability is clearer.
  - fiddlerwoaroof 3y ago
    I’ve never found that the differences of Kotlin matter enough to be worth it.
  - vips7L 3y ago
    Those just are not enough for many of us to warrant the switch. Mutability is fine if you’re not going over thread boundaries, many of us don’t struggle with null, and brevity does not always equal clarity.
    - The_Colonel 3y ago
      > Those just are not enough for many of us to warrant the switch. I understand that, but for starting new projects the equation can be different. > many of us don’t struggle with null Sorry, but I don't believe there's anybody like that. I guess many people accepted/internalized the struggle.
      - ivan_gammel 3y ago
        Null safety at application level is just a good architecture, test coverage and regular code reviews. It is not an internalized struggle of any sort. Last time I saw uncaught NPE in server logs was a long time ago: why would it necessarily be more frequent than some data validation error?
        The_Colonel 3y ago
DarkNova6 3y ago
Which platform? For Android? Kotlin all the way. Servers? Java is much closer to the JVM and Kotlin is an abstraction over it which honestly does not provide much extra compared to Java 21. Kotlin has several design decisions which are neater 80% of time, but Java is the better general purpose language for those 20%. OC, much is a matter of taste. And in Kotlin will find yourself in awkward positions where you have to use Java Collections and you lose all the advantages of Kotlin (HashMaps not having non-nullable values is one of them).
- adra 3y ago
  All kotlin collection types are essentially Java ones (at least for a JVM target), the difference is that the IDE and compiler are smart about its type inference system so that it can tell when a variable use is nullable or not. Java has come a long way in recent years and it's far better than it was in the past. Kotlin stands on the great baseline of features that Java has established and there are certainly many advantages to (mostly ergonomics), to using Kotlin over Java at least for the time being.
- dullcrisp 3y ago
  > HashMaps not having non-nullable values Not sure about that example since it’s easy to do class MapWithDefault<K, V>( private val map: Map<K, V>, private val defaultValue: V ) { fun get(k: K) = map.get(k) ?: defaultValue // … } Edit: or I’m sure there’s something that does this already.
  - DarkNova6 3y ago
    Still, this is not a first-class citizen in the Kotlin space, even-though you would assume it to be the case. Introducing such custom classes is always a little icky when working in a team.
  - jayd16 3y ago
    It's probably about having to box value types.
- eweise 3y ago
cempaka 3y ago
Java's structured concurrency approach to async code eventually may result in much simpler libraries compared to Kotlin's approach, which introduces function coloring with the "suspend" modifier.
- wiseowise 3y ago
  https://elizarov.medium.com/how-do-you-color-your-functions-a6bb423d936d https://elizarov.medium.com/how-do-you-color-your-functions-... That’s a feature, not a bug. > We could eliminate suspend modifiers from pure-Kotlin code, but should we? I’m inclining to answer no. Having to mark asynchronous functions with suspend modifier is a small price to pay, but in return you get better insight into your code. You immediately see which functions are allowed to perform potentially long communications and which are supposed to complete quickly.
smokel 3y ago
One of the most interesting things with respect to the future of Kotlin is its mission to be a multi-platform language. When WebAssembly/gc becomes generally available, it will be exciting to see which languages will successfully target it. Kotlin has quite good chances of succeeding as a full-stack language, because of its growing ecosystem of multi-platform libraries that work in the JVM, in a browser, and on a native system. Note that the Java standard library is great, but it does not interoperate well with the JavaScript ecosystem. The same goes for C# and Rust. As a personal pet project, and to check if the multi-platform concept actually works, I have written an emulator for an old computer in Kotlin. Initial development was done in the JVM, because I was familiar with JavaFX and sound output in Java. I then later compiled it to JavaScript, which was trivial and required no code changes, except for an implementation of canvas and audio rendering. A serious problem is the IDE experience though. Interactive web development in VSCode with TypeScript is a breeze, with a subsecond edit-compile-run cycle. Kotlin compilation is still clunky, and fixing a typo requires at least 10 seconds of my patience, even on a decent workstation. Work is underway to improve this, but only time will tell if things succeed.
- cutler 3y ago
  10 seconds to fix a typo? Install the IDEAVim plugin then it's simply :<line number> , w w w ..., cw. Or there's /<search term>, n n n ..., cw.
  - smokel 3y ago
    I meant fixing a typo in the source code for a user interface application, and then seeing the end result on screen. Or perhaps I'm missing some sarcasm here :)
- kaba0 3y ago
  Java is a much bigger language, if feasible it will have much better support for wasm/native/etc. frankly, I don’t see a point of this aspect of kotlin.
geodel 3y ago
Its better without sacrifices similar ways as : 1) Cloud is better than data centers without sacrifices 2) Meal kits are better than grocery shopping without sacrifices 3) Online shopping is better than going to store without sacrifices 4) SAAS is better than locally installable software without sacrifices
derriz 3y ago
Some reasons that spring to mind: - Compile speed - Kotlin is still painfully slow - about 4-5 times slower than equivalent Java functionality (rough estimate) - Kotlin is completely proprietary, no community or openness, no alternative to Jetbrain's IDE - Kotlin (for me) has passed from being a simpler/more terse/attractive version of Java into being a complex language with lots of strange corner cases. Particularly largish Kotlin code-bases can be hell to read as Kotlin supports and encourages a DSL like approach.
- wcerfgba 3y ago
  Isn't Kotlin licensed as Apache 2?
  - kernal 3y ago
    Indeed. It's hard to take someone seriously when they call a language proprietary when it's been open source since inception and then claim it's 4 - 5 times slower in compilation speed and then provide no metrics to back up their point.
    - vips7L 3y ago
      Fwiw the compiler is definitely slower. It’s a big selling point of Kotlin 2.0 because they rewrote the compiler to be faster.
- cutler 3y ago
  4-5 times slower? That estimate is indeed rough. For some workloads Kotlin's function inlining creates more efficient bytecode than Java.
  - dikei 3y ago
    He's talking about compilation speed, not execution speed.
    - cutler 3y ago
coldtea 3y ago
Using Java means going with the less fuss default (instrastructure and support) wise. And the gap is closing in.
lmm 3y ago
Kotlin has a less good backward compatibility record and interacts awkwardly with newer JVM/standard library features - e.g. streams are cumbersome to work with because Kotlin has a different approach to absence/nullability. Async in particular is a place where Kotlin has gone through multiple incompatible rewrites and is doing something that's not necessarily going to align with the JVM way of doing things in the future (Project Loom - which I have my own doubts about, but if you believe in it then that's definitely a reason to use Java over Kotlin). (Plus if you're going to go to the trouble of using a non-Java language it would be a real waste to use Kotlin over Scala)
- ptx 3y ago
  > streams are cumbersome to work with because Kotlin has a different approach to absence/nullability I'm not sure that's a reason to pick Java over Kotlin though – streams are just generally cumbersome, even in Java, compared to Kotlin's sequences. By choosing Java you're getting more exposure to them whereas in Kotlin you can mostly avoid them in favor of sequences.
  - lmm 3y ago
    Streams are less cumbersome in Java because you can use optional everywhere and it's relatively idiomatic; the ecosystem (at least the modern parts of it) will support you in doing so. Whereas in Kotlin everything expects you to use their special nullables and so you have to constantly shift back and forth.
    - rhdunn 3y ago
      I've had the opposite experience. I've found using Optional/map everywhere harder to read than Kotlin nullable types. And I find Kotlin streams/streaming API easier to read and use/more intuitive than Java's equivalent.
seoulmetro 3y ago
Kotlin is the coffeescript of Java. Kotlin is actually not a great thing to write with or learn as Java has caught up. (this example speaks over javascript and coffeescript battle where coffee was eventually killed by native improvements). I would not start Kotlin or learn it unless you go back 5 or more years.
Tainnor 3y ago
IMHO, there are certain developers who've always liked Java exactly as it is. They view Kotlin as too hipster-y, sugary, complex and changing too fast. I think those people should just continue to use Java. Then there's other people like me who come from other ecosystems. I used to write Ruby and I just can't stand how verbose and convoluted Java can be. It makes reading code a real pain. But with Kotlin I found a language that struck a good balance between expressivity and compile-time safety. Maybe Kotlin should do more to convert people from other ecosystems rather than trying to cater to the kinds of people who were never offended by the dullness of writing Java.

For those in the ecosystem these days - is there a compelling reason to choose Java over Kotlin? I am under the impression that Kotlin is a better Java without any sacrifices. Is this true?

crickey 3y ago

I mean what are your goals, its never as clear cut as X is objectively better in all use cases over Y

mardifoufs 3y ago

At this point I think the more relevant question is: is there any point to using kotlin if you are not doing android dev?

afavour 3y ago
Personally I find it more enjoyable to code in than Java. There’s also maybe an argument to be made around Kotlin Native, KotlinJS too.
- robertlagrant 3y ago
  Also Kotlin Multiplatform.
- kaba0 3y ago
  GraalVM, TeaVM, Google’s Closure compiler. Java is an insanely big language, so if a tiny language has something, you can bet Java also has it in a much more ready form.
xwowsersx 3y ago
Sure, assuming you are happy with most of the language constructs and it feels ergonomic to you, Kotlin can make sense for backend/APIs, while still having access to all the Java libs/packages. I'm starting several new largeish projects now and have decided on using Kotlin.
mdaniel 3y ago
Having `@Nullable`/`@Nonnull` (or its dumb `Optional<T>` friend) is nothing compared to NPE being a compilation failure Also, all hail `val`; `final var` is objectively worse
- iraqmtpizza 3y ago
  var is write-only and won't catch type errors
  - mdaniel 3y ago
    Sorry, I don't understand your concern. My observation is that having a variable declaration that is single-assigment in Java requires the "final" keyword, which in the most charitable case is "final var" where the caller and/or the IDE know the type (e.g. "final var foo = new ArrayList<Bar>()") and in the degenerate case is "final ApplicationEvent<Map<String, List<String>>> thing = doSomething()" In Kotlin one can get finality via the much nicer "val" keyword, and seems to be idiomatically the default, versus Java's mutable-by-default stance Saying either language "won't catch type errors" is not something I can agree with
    - iraqmtpizza 3y ago
      Normally, declaring a variable offers type safety. var matches anything and thus it's never a compile-time error. If someone accidentally changes the return type of getAddresses from Map to List, there is no compile-time error. There is nothing to check the return type against except Object in this case because Tuple.of takes Objects. final var addressMap = getAddresses(); final Tuple args = Tuple.of("a", 200L, x); So you may as well inline the method call and give up on any type checking. Another example: final long limit = getLimit(); for (var i = 0; i < limit; i++) {} The wrapping behavior is determined by whether there is an L (or lowercase, l) after the 0. If limit happens to be greater than Integer.MAX_VALUE, that L is the difference between an infinite loop and a well-behaved routine. Some junior programmer could easily remove the L accidentally. And you wouldn't run into the bug until limit gets big enough. Which could happen at runtime in production. All because you wanted to save one character by using var instead of long. This is just what I could think of off the top of my head. I'm sure there are other examples. You are absolutely giving up some compile-time sanity checks with var. If it's just some throwaway script, then fine. But if so why use Java in the first place?
cutler 3y ago
Spring Boot has full Kotlin support.

smallerfish 3y ago

I still prefer Kotlin, though the gap is closing. Null checking, extension functions, type inference, and various other features are really nice. I'm not sure what's on the Kotlin roadmap / whether JetBrains see value in making major improvements to the language.

exabrial 3y ago

Better is subjective. Java is a great language, has a mature and stable codebase, it runs at near-Cpp speed, has built-in SNMP-like monitoring, and the developers are super careful about not breaking backwards compatibility. That's all about there is to say about it. Kotlin is also a good language for many of the same reasons, mainly because it is run on the JVM. One really isn't better, they're just different. Use the tool you know how to use, and master it. The only category I would say is objectively "better" is Java (and other JVM languages like Kotlin) has the best IDEs out of _any_ language. There is nothing on-par for Python, Ruby, C/Cpp, etc as far as autocompletion, type inference, automated refactoring, partial recompiles, hot code swapping, unit test integration, Tomcat or server integration, code formatting, etc. Java is great because of it's IDEs. If we were writing Java in notepad.exe it'd be a pretty clunky experience, but nobody serious does that.

randoglando 3y ago
> The only category I would say is objectively "better" is Java has the best IDEs out of _any_ language. Kotlin was made by the people behind IntelliJ. I'm not sure I understand your point.
- exabrial 3y ago
  sorry, I should have included Kotlin in that part of my comment. IntelliJ Kotlin is quite incredible. Every time I've needed to use it, my expectations have been met. Makes switching to vscode feeling going from an framing nailer to beating in rusty iron nails with a rock.
  - iraqmtpizza 3y ago
    extension functions can be scattered across any number of files and the import statements do not tell you where they are declared. kotlin was specifically designed to drive sales of IntelliJ
- wiseowise 3y ago
  And it’s slow as molasses without feature parity. One feature that comes to mind is rearrange methods. I haven’t used Java in years so someone who actually uses both can find more cases where Kotlin support is worse than Java’s.

fiddlerwoaroof 3y ago

I've always viewed this the opposite way: Kotlin isn't better enough to prefer it to recent Java versions.

randoglando 3y ago
Kotlin is less verbose, has better null safety and mutability is clearer.
- fiddlerwoaroof 3y ago
  I’ve never found that the differences of Kotlin matter enough to be worth it.
- vips7L 3y ago
  Those just are not enough for many of us to warrant the switch. Mutability is fine if you’re not going over thread boundaries, many of us don’t struggle with null, and brevity does not always equal clarity.
  - The_Colonel 3y ago
    > Those just are not enough for many of us to warrant the switch. I understand that, but for starting new projects the equation can be different. > many of us don’t struggle with null Sorry, but I don't believe there's anybody like that. I guess many people accepted/internalized the struggle.
    - ivan_gammel 3y ago
      Null safety at application level is just a good architecture, test coverage and regular code reviews. It is not an internalized struggle of any sort. Last time I saw uncaught NPE in server logs was a long time ago: why would it necessarily be more frequent than some data validation error?
      - The_Colonel 3y ago

DarkNova6 3y ago

Which platform? For Android? Kotlin all the way. Servers? Java is much closer to the JVM and Kotlin is an abstraction over it which honestly does not provide much extra compared to Java 21. Kotlin has several design decisions which are neater 80% of time, but Java is the better general purpose language for those 20%. OC, much is a matter of taste. And in Kotlin will find yourself in awkward positions where you have to use Java Collections and you lose all the advantages of Kotlin (HashMaps not having non-nullable values is one of them).

adra 3y ago
All kotlin collection types are essentially Java ones (at least for a JVM target), the difference is that the IDE and compiler are smart about its type inference system so that it can tell when a variable use is nullable or not. Java has come a long way in recent years and it's far better than it was in the past. Kotlin stands on the great baseline of features that Java has established and there are certainly many advantages to (mostly ergonomics), to using Kotlin over Java at least for the time being.
dullcrisp 3y ago
> HashMaps not having non-nullable values Not sure about that example since it’s easy to do class MapWithDefault<K, V>( private val map: Map<K, V>, private val defaultValue: V ) { fun get(k: K) = map.get(k) ?: defaultValue // … } Edit: or I’m sure there’s something that does this already.
- DarkNova6 3y ago
  Still, this is not a first-class citizen in the Kotlin space, even-though you would assume it to be the case. Introducing such custom classes is always a little icky when working in a team.
- jayd16 3y ago
  It's probably about having to box value types.
eweise 3y ago

cempaka 3y ago

Java's structured concurrency approach to async code eventually may result in much simpler libraries compared to Kotlin's approach, which introduces function coloring with the "suspend" modifier.

wiseowise 3y ago
https://elizarov.medium.com/how-do-you-color-your-functions-a6bb423d936d https://elizarov.medium.com/how-do-you-color-your-functions-... That’s a feature, not a bug. > We could eliminate suspend modifiers from pure-Kotlin code, but should we? I’m inclining to answer no. Having to mark asynchronous functions with suspend modifier is a small price to pay, but in return you get better insight into your code. You immediately see which functions are allowed to perform potentially long communications and which are supposed to complete quickly.

smokel 3y ago

One of the most interesting things with respect to the future of Kotlin is its mission to be a multi-platform language. When WebAssembly/gc becomes generally available, it will be exciting to see which languages will successfully target it. Kotlin has quite good chances of succeeding as a full-stack language, because of its growing ecosystem of multi-platform libraries that work in the JVM, in a browser, and on a native system. Note that the Java standard library is great, but it does not interoperate well with the JavaScript ecosystem. The same goes for C# and Rust. As a personal pet project, and to check if the multi-platform concept actually works, I have written an emulator for an old computer in Kotlin. Initial development was done in the JVM, because I was familiar with JavaFX and sound output in Java. I then later compiled it to JavaScript, which was trivial and required no code changes, except for an implementation of canvas and audio rendering. A serious problem is the IDE experience though. Interactive web development in VSCode with TypeScript is a breeze, with a subsecond edit-compile-run cycle. Kotlin compilation is still clunky, and fixing a typo requires at least 10 seconds of my patience, even on a decent workstation. Work is underway to improve this, but only time will tell if things succeed.

cutler 3y ago
10 seconds to fix a typo? Install the IDEAVim plugin then it's simply :<line number> , w w w ..., cw. Or there's /<search term>, n n n ..., cw.
- smokel 3y ago
  I meant fixing a typo in the source code for a user interface application, and then seeing the end result on screen. Or perhaps I'm missing some sarcasm here :)
kaba0 3y ago
Java is a much bigger language, if feasible it will have much better support for wasm/native/etc. frankly, I don’t see a point of this aspect of kotlin.

geodel 3y ago

Its better without sacrifices similar ways as : 1) Cloud is better than data centers without sacrifices 2) Meal kits are better than grocery shopping without sacrifices 3) Online shopping is better than going to store without sacrifices 4) SAAS is better than locally installable software without sacrifices

derriz 3y ago

Some reasons that spring to mind: - Compile speed - Kotlin is still painfully slow - about 4-5 times slower than equivalent Java functionality (rough estimate) - Kotlin is completely proprietary, no community or openness, no alternative to Jetbrain's IDE - Kotlin (for me) has passed from being a simpler/more terse/attractive version of Java into being a complex language with lots of strange corner cases. Particularly largish Kotlin code-bases can be hell to read as Kotlin supports and encourages a DSL like approach.

wcerfgba 3y ago
Isn't Kotlin licensed as Apache 2?
- kernal 3y ago
  Indeed. It's hard to take someone seriously when they call a language proprietary when it's been open source since inception and then claim it's 4 - 5 times slower in compilation speed and then provide no metrics to back up their point.
  - vips7L 3y ago
    Fwiw the compiler is definitely slower. It’s a big selling point of Kotlin 2.0 because they rewrote the compiler to be faster.
cutler 3y ago
4-5 times slower? That estimate is indeed rough. For some workloads Kotlin's function inlining creates more efficient bytecode than Java.
- dikei 3y ago
  He's talking about compilation speed, not execution speed.
  - cutler 3y ago

coldtea 3y ago

Using Java means going with the less fuss default (instrastructure and support) wise. And the gap is closing in.

lmm 3y ago

Kotlin has a less good backward compatibility record and interacts awkwardly with newer JVM/standard library features - e.g. streams are cumbersome to work with because Kotlin has a different approach to absence/nullability. Async in particular is a place where Kotlin has gone through multiple incompatible rewrites and is doing something that's not necessarily going to align with the JVM way of doing things in the future (Project Loom - which I have my own doubts about, but if you believe in it then that's definitely a reason to use Java over Kotlin). (Plus if you're going to go to the trouble of using a non-Java language it would be a real waste to use Kotlin over Scala)

ptx 3y ago
> streams are cumbersome to work with because Kotlin has a different approach to absence/nullability I'm not sure that's a reason to pick Java over Kotlin though – streams are just generally cumbersome, even in Java, compared to Kotlin's sequences. By choosing Java you're getting more exposure to them whereas in Kotlin you can mostly avoid them in favor of sequences.
- lmm 3y ago
  Streams are less cumbersome in Java because you can use optional everywhere and it's relatively idiomatic; the ecosystem (at least the modern parts of it) will support you in doing so. Whereas in Kotlin everything expects you to use their special nullables and so you have to constantly shift back and forth.
  - rhdunn 3y ago
    I've had the opposite experience. I've found using Optional/map everywhere harder to read than Kotlin nullable types. And I find Kotlin streams/streaming API easier to read and use/more intuitive than Java's equivalent.

seoulmetro 3y ago

Kotlin is the coffeescript of Java. Kotlin is actually not a great thing to write with or learn as Java has caught up. (this example speaks over javascript and coffeescript battle where coffee was eventually killed by native improvements). I would not start Kotlin or learn it unless you go back 5 or more years.

Tainnor 3y ago

IMHO, there are certain developers who've always liked Java exactly as it is. They view Kotlin as too hipster-y, sugary, complex and changing too fast. I think those people should just continue to use Java. Then there's other people like me who come from other ecosystems. I used to write Ruby and I just can't stand how verbose and convoluted Java can be. It makes reading code a real pain. But with Kotlin I found a language that struck a good balance between expressivity and compile-time safety. Maybe Kotlin should do more to convert people from other ecosystems rather than trying to cater to the kinds of people who were never offended by the dullness of writing Java.