3 ms·

> I’ve seen this sentiment a lot and I don’t understand it. I just don't think any feature of the language of Kotlin is that much better than Java's implementa

by vips7L 3y ago

> I’ve seen this sentiment a lot and I don’t understand it. I just don't think any feature of the language of Kotlin is that much better than Java's implementation. I'm also a big supporter of brevity != clarity when it comes to code. What language feature in Kotlin do you think is that much better?

Alupis 3y ago
I was you not that long ago. I've had the same conversation with a lot of other Java developers too - they/we always say the same things. It's weird being on the other side of the fence now - hearing the same things I used to say. Kotlin was a gateway drug out of not just Java, but OO/Solid and into FP for me (FP being another thing I used to not "get"). The beauty of Kotlin is you don't have to ever write FP code if you don't want to - but you will want to before too long. I would recommend trying it out for yourself. It's Spring integration is amazing, and you'll have a great time. Write even a little Kotlin and you'll have an "ah ha!" moment and everything will forever be different. It's one of those things where you need to experience it for yourself before you actually understand how great it is. There is no argument you will hear that will convince you, sadly. I was the same once...
- deleted 3y ago
  [deleted]
- bcrosby95 3y ago
  To me Kotlin is different enough to be annoying to learn, but not different enough to matter that I use it over Java. So it just kinda feels like a waste of time.
- kaba0 3y ago
  You can do many FP things in Java as well, as it is a multi-paradigm language, hell, Kotlin is not even particularly functional-y.
  - Tainnor 3y ago
    I'll agree that Kotlin is not hardcore FP (although you can get there some of the way with Arrow etc.), but FP in Java is clunky. - Having to remember the difference between "Function", "Consumer", "Predicate" and "Supplier" is weird. In Kotlin (and basically every other typed FP language that I know), I just write the type signature the natural way. - Having to use streams in order to use map, etc., is noisy. Why weren't these APIs retrofitted to collections? - Checked exceptions are a pain with functional code, e.g. map. - Mutability is still the default behaviour of almost everything in Java, save records (and strings). etc.
    - sitta 3y ago
      > Having to use streams in order to use map, etc., is noisy. Why weren't these APIs retrofitted to collections? Sure, methods along the lines of the following could have been added: public <R> List<R> map(Function<? super E, ? extends R> mapper) { return stream().map(mapper).toList(); } Yes, having them would make Java less verbose in the case where you only want to do a single map, filter, whatever operation on a collection, but I'm personally glad that they weren't because they produce extremely inefficient behavior when chained. So, it would add a performance footgun to save ~18 characters.
    - vips7L 3y ago
      But are these things enough to warrant me a full switch of programming language and ecosystem? Not for me. - I don’t think this is really that big of a deal. - Using streams is actually preferred so you don’t cause a performance nightmare and kotlin you has to use asSequence anyway. - I thought checked error handling was all the rage nowadays? - Mutability is absolutely fine if you’re not going over a thread boundary.
      - Tainnor 3y ago
        In Kotlin, asSequence gives you lazy behaviour (i.e. chains of map, filter, etc. are merged the way it's automatically done in Haskell), but if you don't care about the performance penalty, you can just call map, filter etc. on eager collections too. I'm of the opinion that you shouldn't prematurely optimise, for small enough data, it often doesn't matter much. And checked exceptions are widely seen as an anti-feature - I don't think any other language has them, with the possible exception of Swift (see below), and for good reason. Other languages encode errors (more or less ergonomically) in the type system (e.g. Rust, Haskell, and to an extent it's what Kotlin advocates as well), and that has the advantage of playing well together with other language mechanisms - e.g. no extra allowances need to be made so that map works with them. But for the sake of the argument: Swift also has something similar to checked exceptions, but only in the sense that functions can either throw or not throw. However, Swift also at least has constructs like "rethrows", which lets you say that a function such as map should throw iff the higher order function it wraps throws. Java simply decided that it doesn't need to deal with this problem at all (for whatever reason - they simply could have added something like "rethrows") and now it's up to callers to deal with the incredible awkwardness that is using FP with Java library code that makes heavy use of checked exceptions.
haspok 3y ago
Null safety checks and if being an expression are major pain point resolvers that are still not available in Java (OK, maybe pattern matching helps the if-expression part, because pattern matching IS an expression in Java). Oh, and the legacy library APIs, which Kotlin elegantly wraps with FP-compatible classes. Instead of fiddling with streams (which also lack some basic operations, or have some not so nice API), you can just .map or .fold over your (read-only by default) collection. Not only less verbose, but also easier to use and understand. Having said this, these are fairly minor things, which may not warrant a switch to Kotlin, if you are otherwise happy with Java...

by vips7L 3y ago

Alupis 3y ago

I was you not that long ago. I've had the same conversation with a lot of other Java developers too - they/we always say the same things. It's weird being on the other side of the fence now - hearing the same things I used to say. Kotlin was a gateway drug out of not just Java, but OO/Solid and into FP for me (FP being another thing I used to not "get"). The beauty of Kotlin is you don't have to ever write FP code if you don't want to - but you will want to before too long. I would recommend trying it out for yourself. It's Spring integration is amazing, and you'll have a great time. Write even a little Kotlin and you'll have an "ah ha!" moment and everything will forever be different. It's one of those things where you need to experience it for yourself before you actually understand how great it is. There is no argument you will hear that will convince you, sadly. I was the same once...

deleted 3y ago
[deleted]
bcrosby95 3y ago
To me Kotlin is different enough to be annoying to learn, but not different enough to matter that I use it over Java. So it just kinda feels like a waste of time.
kaba0 3y ago
You can do many FP things in Java as well, as it is a multi-paradigm language, hell, Kotlin is not even particularly functional-y.
- Tainnor 3y ago
  I'll agree that Kotlin is not hardcore FP (although you can get there some of the way with Arrow etc.), but FP in Java is clunky. - Having to remember the difference between "Function", "Consumer", "Predicate" and "Supplier" is weird. In Kotlin (and basically every other typed FP language that I know), I just write the type signature the natural way. - Having to use streams in order to use map, etc., is noisy. Why weren't these APIs retrofitted to collections? - Checked exceptions are a pain with functional code, e.g. map. - Mutability is still the default behaviour of almost everything in Java, save records (and strings). etc.
  - sitta 3y ago
    > Having to use streams in order to use map, etc., is noisy. Why weren't these APIs retrofitted to collections? Sure, methods along the lines of the following could have been added: public <R> List<R> map(Function<? super E, ? extends R> mapper) { return stream().map(mapper).toList(); } Yes, having them would make Java less verbose in the case where you only want to do a single map, filter, whatever operation on a collection, but I'm personally glad that they weren't because they produce extremely inefficient behavior when chained. So, it would add a performance footgun to save ~18 characters.
  - vips7L 3y ago
    But are these things enough to warrant me a full switch of programming language and ecosystem? Not for me. - I don’t think this is really that big of a deal. - Using streams is actually preferred so you don’t cause a performance nightmare and kotlin you has to use asSequence anyway. - I thought checked error handling was all the rage nowadays? - Mutability is absolutely fine if you’re not going over a thread boundary.
    - Tainnor 3y ago
      In Kotlin, asSequence gives you lazy behaviour (i.e. chains of map, filter, etc. are merged the way it's automatically done in Haskell), but if you don't care about the performance penalty, you can just call map, filter etc. on eager collections too. I'm of the opinion that you shouldn't prematurely optimise, for small enough data, it often doesn't matter much. And checked exceptions are widely seen as an anti-feature - I don't think any other language has them, with the possible exception of Swift (see below), and for good reason. Other languages encode errors (more or less ergonomically) in the type system (e.g. Rust, Haskell, and to an extent it's what Kotlin advocates as well), and that has the advantage of playing well together with other language mechanisms - e.g. no extra allowances need to be made so that map works with them. But for the sake of the argument: Swift also has something similar to checked exceptions, but only in the sense that functions can either throw or not throw. However, Swift also at least has constructs like "rethrows", which lets you say that a function such as map should throw iff the higher order function it wraps throws. Java simply decided that it doesn't need to deal with this problem at all (for whatever reason - they simply could have added something like "rethrows") and now it's up to callers to deal with the incredible awkwardness that is using FP with Java library code that makes heavy use of checked exceptions.

haspok 3y ago

Null safety checks and if being an expression are major pain point resolvers that are still not available in Java (OK, maybe pattern matching helps the if-expression part, because pattern matching IS an expression in Java). Oh, and the legacy library APIs, which Kotlin elegantly wraps with FP-compatible classes. Instead of fiddling with streams (which also lack some basic operations, or have some not so nice API), you can just .map or .fold over your (read-only by default) collection. Not only less verbose, but also easier to use and understand. Having said this, these are fairly minor things, which may not warrant a switch to Kotlin, if you are otherwise happy with Java...