Their point about using .NET were not really valid since one of the big and best reason to use Java is that you already have a Java codebase, but things like value types and generics without type erasure aren't solved in Kotlin, so Kotlin isn't really a good answer to his not really valid point.

> things like value types and generics without type erasure aren't solved in Kotlin

Perhaps not solved, but at least partially addressed with value classes[1] and reified type parameters[2].

[1] https://kotlinlang.org/docs/inline-classes.html

[2] https://kotlinlang.org/docs/inline-functions.html#reified-ty...

> take advantage of the jvm

In what way? It's slower and has less features than the .NET runtime.

> "no real reason" is a stupid take. I could list multiple, but a big one is that there are hundred java developers for each dotnet developer in my city. The java env is well tested and well understood, if anything one should argue why not use it instead of a hip and trendy alternative.

So, your only credible excuse for using java is inertia from boomers and middle managers refusing to adapt from the standard of the early and mid 2000s?

> So, your only credible excuse for using java is inertia from boomers and middle managers refusing to adapt from the standard of the early and mid 2000s?

If you come in and freely migrate all of the Java codebases to .NET while maintaining code quality and functionalities, I'm sure many people would let you do it. If you don't understand why people stick to one language, that means that you've never worked on a big codebase, or completly ignore the business side of the developer job. In both cases, that's a lack of wisdom on your part.

I guess you missed the 'new development' part of my original comment? Obviously it would be nonsensical to port a large extant codebase to a new language and tech stack if it's just being maintained.