Все проблемы типо это забота компилятора, на уровне вызвала - метод на значении можно вызвать тогда и только тогда, когда в типе этот метод есть. Для всех остальных ситуаций есть ClassCastException, ClassDefNotFound и еще парочка. Так что хостящийся язык может делать практически все, что хочет.

Ну просто JVM это и не машинный код. По логике в ФП нахер не нужны все эти классы, методы, например. Весь декларативный функциональный код можно скомпилить в одну большую императивную портянку применив по максимуму оптимизаций (ну разве что в местах стыка библиотек оставить АПИ какой нить). И чем оно тогда будет в JVM? Одним большим классом с кучей статических методов? Не, так то я не против конечно. Но зачем?...

потому JVM на данный момент один из лучших вариантов для хостящихся языков

поддерживается много железа, может адресовать достаточно памяти, есть бесплатные варианты, простой байткод, много пользователей, хорошая спека

Ну ок, разве что поэтому

если бы были альтернативы лучше - использовали бы другие) некоторые и свои пишут, лол

Ну по поводу семантики я б поспорил... Я могу два года слоняться по сибирским лесам, собирая грибы, а потом вернуться и  глядя в java код понять что, к чему. А глядя в fun method(): Object? придется поднапрячься, что там с областью видимости этой функций, зачем ? торчит и т.п. Может поэтому Java до сих пор и живёт в энтерпрайзе что даже самый древний код до сих пор нормально читается?

Или ты просто не привык читать новый код

Тот факт, что fun method(): Object? == @Nullable public final Object method() описывается в самом начале доки по Котлину :)

Вопрос не в том, что привык/не привык. А в том, что в Java человеческими словами все написано. А во многих языках есть некие договоренности про которые надо помнить. И если приходится часто переключаться, то путаешься уже - где чего тот же знак вопроса после типа данных может обозначать.

Опять же, написано человеческими словами только потому, что выработалась привычка понимать этот язык за время работы с ним.

То же как и учить другой разговорный язык, только намного проще

В том то и дело, что тут не разговорный язык, а символьные обозначения и сокращения, которые были приняты сообществом этого языка. А ещё в разных языках одни и те же символы имеют разное значение. @Nullable, например, по любому будет понятнее, не зависимо от глубины знания языка. Мне довелось когда-то поработать, что в разных проектах свой DSL использовался во всяких разных стилях. Такая мука была потом спустя полгода-год к своему же коду возвращаться, чтоб какой-то баг поправить. На SpEL кто-то сейчас сможет код с лёгкостью прочесть, например?

По поводу nullable - ИМО, слава Богу не использующийся костыль в рамках Java (не считая всяких ORM). Здесь Котлин выглядит страннее Джавы (? и ! торчат тут и там), но зато активно форсят обрабатывать возможное отсутствие значения.

По поводу обозначений - дело, опять же, привычки. Пока свой пет проджект не напишешь - так и будет отсутствие понимания синтаксиса на почве отсутствия практики.

Смотря какие грибы 😏

Нуллабл шмуллабл. Имхо самое лучшее средство против нуля - просто забыть о нуле. Никогда не писать null, никогда не проверять на нул, никогда не предполагать что calling side передаст нуль в метод, или что метод вернёт нуль, и писать код так, как будто нуля не существует. Мне помогает. Исключения - вызовы на 3rd party коде. Обычно этого хватает.

Ну правда это работает только в паре с мантрой "в топку DTO" и консервативным использованием мутабельности в классах, справедливости ради.

Как раз обозначения - не фига не дело привычки. Это очень важно. Мы код пишем не для себя и не для компа, мы код пишем, чтоб его потом кто-то читал. В идеале иметь такой код, который даже аналитики и бизнес читать мог. Поэтому в плане семантики мне Java больше нравится, чем Kotlin, например, если это помогает даже не специалисту его читать.
Вот если юристы в какой-то конторе, например, решат, что русский не слишком удобен для оформления юридических документов и введут свои сокращения. Вместо "каждый сотрудник получает зарплату 10 го числа месяца" станут использовать "ev. :) get $ #10.MM". Со временем все привыкнут и даже будут рады, что теперь любой юридический документ на одном листочке помещается и вполне читаем. Но для нового человека будет сложнее  вникать, т.к. помимо сути документа надо будет его ещё расшифровывать сначала. А ещё со временем может появиться какая-то новая более "лучшая" система и все перейдут на нее, и будут долго материться, когда придется старые документы поднимать и просматривать.

Зависит от того какой код пишешь на Java. Прочитай и пойми код, например, обвязок клиентов Kafka над их легаси Scala кодом, или код под какой-то Apache Spark. «Открой для себя мир дженериков огромной вложенности», который «легко читается даже не специалистом»

Оборачивай такой код в общие библиотеки и фреймворки, а бизнес код оставляй читаемым