I am also wondering if Meta still uses PHP or Hack.
Meta’s WWW codebase is its oldest, and still written in Hacklang. Lots of internal tooling is also written in Hack.
I wouldn’t be surprised if there are more committed lines of Hacklang than any other language (although, a good chunk of that is codegen, vs other core languages where codegen is part of the build process).
Even otherwise, at the scale the company operates it's much better to run codegen once at commit time rather than recreate the entire codebase on every deploy (several times a day) which would take forever.
Kotlin provides a lot of 'clever' syntactic sugar and features that makes certain things that are quite verbose in Java, nice and compact in Kotlin. It also means that there are many way to achieve the same thing in Kotlin. Once you've learned everything it allows you to do things that would take a lot of Java in much fewer lines of code. But there is also just more 'stuff' to learn in the Kotlin language.
Java is a much simpler language than Kotlin with relatively few features, but this simplicity means you sometimes have to build quite verbose structures to achieve what you want.
So which is 'simpler' very much comes down to how you define 'simple'.
Kotlin's one big advantage is having avoided the "billion dollar mistake" of null pointers. Or at least, mitigated it. But in my opinion it's not sufficient to install a whole new language into your stack.
I believe I read on the mailing list it’s implemented here: https://github.com/openjdk/valhalla/tree/lw5
Kotlin is incredibly expressive and can get quite complicated. Java is a bit more brutally simple (and obviously more verbose).
As a C# dev primarily, I love Kotlin, and I've always hated Java despite it being the very first language I learned.
I wouldn't call Kotlin simple by any stretch of the imagination. It's just a very high-level language.
If Java ever ships Valhalla we might get null restricted types: https://openjdk.org/jeps/8316779
Additionally, the above-linked JEP only proposes to make a small subset of types potentially null-safe. The goal there is performance, not correctness.
> Enhance Java's reference types to let programmers express whether null references are expected as values of the type
That seems really very limiting and like it would make the feature not very useful in practice.
It will eventually be a goal. Java does things in steps. First will be introducing the syntax, then another JEP will take care of the standard library. Just like they introduced virtual threads and then introduced structured concurrency. Or like introducing records and then introducing pattern matching over records. Baby steps.