Unless it's Android, if they can't access the latest features of Java they more than likely can't access the latest features of Kotlin either.

Why don't the nullability examples use Java's Optional?

This code:

  if (nullableVariable != null) {
      boolean success = nullableVariable.someMethodCall()
      if (success) {
          return success
      } else {
          return fallbackIfNullMethodCall()
      }
  } else {
      return fallbackIfNullMethodCall()
  }

Could also be written something like this:

  result = Optional.ofNullable(nullableVariable)
                   .map(NullableType::someMethodCall)
                   .orElse(fallbackIfNullMethodCall());

Sure, it's no Elvis operator, but it's a lot more readable than the "standard" if/else structure of traditional Java. If we're comparing Java and Kotlin, we should at least give Java a fair chance. I dislike the verbosity of the Optional wrapper, but it's a lot better than if/else checking.

How does the order of evaluation work in the second form there? Will fallbackIfNullMethodCall() be evaluated even if not returned?

  result = Optional.ofNullable(nullableVariable)
                   .map(NullableType::someMethodCall)
                   .orElseGet(() -> fallbackIfNullMethodCall());

Yeah this is nonsense and isn't an argument against the language. Embedded devs aren't allowed to use Rust, does that mean we shouldn't compare C++ 20 to Rust? Does that mean Rust is a bad language? If these said devs are limited to Java 6/7/8 does their company have the inertia to use a brand new programming language (Kotlin) that their devs don't know? Does this mean Kotlin is bad because they're not using it?

This is a bad argument.

Absolutely wild how people are all in favour of Either/Result, but still look down on checked exceptions.

OK, but where are the advantages? The page has just a different syntactic sugar resembling Pascal/Scala; sine JVM nihil Kotlin anyway. Sometimes Kotlin's "advantages" there have more boilerplate than Java...

Probably should do 13 since it's the current release.

Comparing to

>>> public static void main(final String[] args) { System.out.println("Hello world!") }

Is just a glamour shot. How many times does one actually have to type public static void main? Once per application, by definition.

The I/O example is moot since Java 11 where Java got https://docs.oracle.com/en/java/javase/13/docs/api/java.base..., so we can do `Files.readString(Paths.get(doc.txt))`.

Java 14 is getting an experimental preview of Records (https://openjdk.java.net/jeps/359) which takes care of much (but not all) of ceremony around "data classes".

And Java 13 got a preview of text blocks, https://openjdk.java.net/jeps/355.

Things are coming. That said, I hardly believe those minor syntax improvements are what is so "good" about Kotlin. It has some better defaults (non-null by default, final classes by default), and is a more modern language. Java will stay with us for many years to come, though.