> Java has null in it, all object references can be null, and it’s too late for that to change. At Facebook I used Hack, which is a fork of PHP. They've spent

> Java has null in it, all object references can be null, and it’s too late for that to change. At Facebook I used Hack, which is a fork of PHP. They've spent a ton of time on the type system to the point where I'd argue it's very good. One of the best things is that nullability is built into the type system so for: vec<?string> $a; // alows nulls vec<string> $b; // does not allow nulls function foo(string $s) {... } you get: $a = $b; // this is OK $b = $a; // error $b = Vec\filter_nulls($a); // OK foo($a[1]); // OK foo($b[1]); // error if ($b[1] is nonnull) { func($b[1]); // in this block the type is 'string' so this is OK } func($b[1] as string); // OK but throws a runtime error if it's null I was surprised just how useful these seantics are and how many errors could be avoided this way in annotated code (there are an ever-dwindling number of corners of the FB code base that aren't property typed). Like Java, this operates on type erasure at runtime so there are limits to the protection. I hope other languages with less advanced type systems (and I include Java when I say that) adopt nullability as a first class type concept. There's a lot of talk here about dependency injection. This was a big innovation in Java 20+ years ago. For some reason no other language seems to collectively wring its hand about DI quite like Java does. Java does suffer from a lack of duck typing, hence all these typically one use interfaces get created. It also has other issues (eg you can't make your own class that'll be a snap--in string replacement). Guice I consider to be a form of torture. Maybe it's time Java decides to stop rigidly solving a prroblem no one else seems to have. Maybe that part of a cultural problem. As for the "enterprise" problem, is that specific to J2EE? Is that still a thing? Or is just the consequences of the patterns J2EE promoted that still propagate (eg rigid DI)? It's generally better to have some structure rather than none, even if it's a bad structure. Maybe I just don't travel in the circles where you see a lot of bad Java enterprise code? Java has warts but the runtime maturity in particular is still world-class. I wish Google had bought Sun back in the day (I bet Google does too given the costs and consequences of the lawsuits) but Java continues to plod along and get better without getting massively complicated (I'm looking at you C++) so it all seems mostly fine.