Kotlin is the closest thing to a "better Java" that I've found. I've used it with Spring Boot and the interoperability with Java is fantastic. A Java dev would have no problem picking it up quickly (as opposed to Clojure and even Scala).
I say this as a Clojure fan, there are many instances where I'd probably choose Kotlin nowadays. You can also mix JVM languages within the same application; I've found it rather useful to sprinkle some Clojure into a Java/Spring application for certain tasks. Maven and Gradle both have tooling to handle it :)
Couldn't agree more! It's particularly disappointing when you need to work on an older java codebase after finishing a Kotlin project. You'll constantly miss features
Nullable types, module level functions, context receivers, nicer type signatures for functions, a better standard library (e.g map works directly on lists without the stream.map crap)
Personally, these features are not something I feel like I would constantly be missing. I don't constantly feel like I'm missing them after switching from JavaScript, at least for not having to call .stream(), context receivers (which Java provides with ScopedValue), or signatures for functions.
I'll give you nullable types, though I personally don't struggle with null at all.
C#'s problem is it's quickly becoming C++ in that it doesn't just have the kitchen sink, it has three kitchen sinks...
Unlike C++ though, one day the powers that be will just remove features as part of yet-another framework rewrite and you'll just have to deal with it.
The other issue is just how tightly coupled C# as a language is to the .NET framework/platform. Some of the things people like C# for are actually framework things and they don't realize it because that separation isn't as clear as with Java and say, JavaEE or Spring or $X.
If you talk to a C# developer - of course they're using .NET and of course they're using Entity Framework - to them, there's no other way. It's inconceivable that any other library or framework might do it better than Microsoft's official offering... and then you'll find the official offering to be lacking in fundamental ways.
Talk with a Java developer and you'll find there's a lot more diversity of frameworks and libraries being used - so there's a lot more differing opinions on priorities and a lot more good ideas being tried out or implemented everywhere. The communities are vastly different in that regard.
Collection literals are a pointless extension of the pattern matching syntax added to get around the fact that there is no way to name a generic type in C# without specifying its type arguments.
It's yet another double down on object initializers instead of writing constructors and factories, and unlike using a factory you have to fully express the result type of the collection instead of having it inferred (they are "target typed", another feature that probably should not have been added).
There is a pattern matching aspect but I think the energy behind it is largely motivated by a desire to clean up syntax when working with data structure based APIs and DSLs.
I've read the proposal, design meeting notes, and GH conversations. Not seeing a compelling counter argument here.
I say this as a Clojure fan, there are many instances where I'd probably choose Kotlin nowadays. You can also mix JVM languages within the same application; I've found it rather useful to sprinkle some Clojure into a Java/Spring application for certain tasks. Maven and Gradle both have tooling to handle it :)