5 ms·

Java 8 is fine and the argument to replace it with kotlin has to be very compelling. Kotlin was designed to replace Java 1.6 and that's about all it's good for

Java 8 is fine and the argument to replace it with kotlin has to be very compelling. Kotlin was designed to replace Java 1.6 and that's about all it's good for.

cies 4y ago
> Kotlin was designed to replace Java 1.6 and that's about all it's good for. Not sure what K was designed for. But we use it to fix J's billion dollar "implicit nulls" mistake, and terse syntax (making it useful for templating: Kotlinx.html), and pass-as-value method references. We love it's hang towards immutability. K is not Haskell, but it sure feels a lot safer that J (where a lot of strings were used to refer to methods, and strings+Groovy was used to do templates). Bottom line: I'm too old --and life's too short-- for NPEs.
- flatiron 4y ago
  Have your tried static analysis? When I used Java most (if not all) of our NPE problems were pointed out by sonar qube
  - ris58h 4y ago
    What if I don't want to put @Nullable/@NotNull all over the code?
    - seer-zig 4y ago
      Can't you setup your project to be `@NotNull` by default, and explicitly mark @Nullable fields? Those should be more rare anyway.
  - cies 4y ago
    Yes. But coupled with our Groovy templates (that we're now moving to Kotlinx.html) it did not really help much. This is not Java's problem per se (though one could argue that J's verbose syntax prohibits it for in-code HTML templating)
  - hn_throwaway_99 4y ago
    Ugh, to hear what hackarounds folks have to deal with in the Java ecosystem is kind of frightening. I moved from Java to Node (then Typescript) about 8 years ago. Moving to a language that doesn't allow implicit nulls makes a world of difference, importantly, at "programmer" time, not just build time. That is, when programming in VSCode, I immediately get feedback if I attempt to use a nullable variable in an unsafe manner. That has huge productivity benefits compared to if I only got that feedback after my build ran. Similarly, simple things like safe optional chaining (i.e. foo?.bar?.baz) makes code so much faster and easier to write, and AFAIK this hasn't been added to Java yet (correct me if I'm wrong).

Java 8 is fine and the argument to replace it with kotlin has to be very compelling. Kotlin was designed to replace Java 1.6 and that's about all it's good for.

cies 4y ago

> Kotlin was designed to replace Java 1.6 and that's about all it's good for. Not sure what K was designed for. But we use it to fix J's billion dollar "implicit nulls" mistake, and terse syntax (making it useful for templating: Kotlinx.html), and pass-as-value method references. We love it's hang towards immutability. K is not Haskell, but it sure feels a lot safer that J (where a lot of strings were used to refer to methods, and strings+Groovy was used to do templates). Bottom line: I'm too old --and life's too short-- for NPEs.

flatiron 4y ago
Have your tried static analysis? When I used Java most (if not all) of our NPE problems were pointed out by sonar qube
- ris58h 4y ago
  What if I don't want to put @Nullable/@NotNull all over the code?
  - seer-zig 4y ago
    Can't you setup your project to be `@NotNull` by default, and explicitly mark @Nullable fields? Those should be more rare anyway.
- cies 4y ago
  Yes. But coupled with our Groovy templates (that we're now moving to Kotlinx.html) it did not really help much. This is not Java's problem per se (though one could argue that J's verbose syntax prohibits it for in-code HTML templating)
- hn_throwaway_99 4y ago
  Ugh, to hear what hackarounds folks have to deal with in the Java ecosystem is kind of frightening. I moved from Java to Node (then Typescript) about 8 years ago. Moving to a language that doesn't allow implicit nulls makes a world of difference, importantly, at "programmer" time, not just build time. That is, when programming in VSCode, I immediately get feedback if I attempt to use a nullable variable in an unsafe manner. That has huge productivity benefits compared to if I only got that feedback after my build ran. Similarly, simple things like safe optional chaining (i.e. foo?.bar?.baz) makes code so much faster and easier to write, and AFAIK this hasn't been added to Java yet (correct me if I'm wrong).