Инлайновый -- в смысле опшнл-тип на уровне языка поверх всё тех же наллов в байткоде? А как будет работать тот же Optional<Optional<T>>?

А как он в rust работает?

В расте нет рантайма и рефлексии и чего там в типах написано, никого не волнует

отлично тогда, но в андроиде это будет ещё более нескоро, чем в нормальной джаве

Там Option — это enum (sealed class, если по-котлински), но компилятор знает, что указатели не-нуллабельны, поэтому sizeof(Option<&Whatever>) == sizeof(usize)

в f# кстати тоже, но опять таки null запрешены для ссылок

Вопрос не в перформансе, а в том что он идейно не нужен в данном случае

Да, в конфиге все ок: порт по умолчанию 8080,  если  PORT задан в окружении — перезаписывается. Что подтверждается тем, что когда я меняю PORT в окружении AWS Elastic Beanstalk на 5000, то оно перестает запускаться

так это рантайм, при чем тут яп ?

При том, что от практик программирования зависит производительность в рантайме.

ну я к тому что опшинал не нужен 😏

В Java точно сделают Option inline рано или поздно, но это ничего не меняет. Задача языков программирования — давать удобные средства решения частых проблем программистов. Задача «представить отсутствующее значение» встречается слишком часто чтобы писать для этого Option<T>, поэтому современные языки добавляют специальный синтаксис T? и удобные способы обработки отсутствующих значений.

А что если option<T> и T? это одно и тоже? Как например в swift. Одно другому не мешает ведь.

А почему бы и нет. Как оно именно там устроено внутри обычному разработчику вообще все-равно. Об это я тоже уже писал. https://link.medium.com/SIL0uDUfh6

Синтаксис на основании частоты - немного странная вещь.
1. Как периодически вспоминают в Твиттере, лаконичность safe call'ов приводит к его не самому адекватному использованию (все вызовы просто делаются nullable вместо того, чтобы раньше обработать null)
2. Листы по ощущениям встречаются не реже, однако условный ["1", "12", "35"]*.toInt() до Котлина не дошёл.

Но насколько хорошо в других языках справляется T? вместо Option<T> не могу оценить, помню его наличие в Цейлоне, но он немного мёртвый, да и там union type были.

Неплохо, но позволяет писать одни и те же фундаментальные вещи по-разному.
Да и нечасто это нужно, на самом деле.

Литералы листов, безусловно, в реальном коде встречаются реже, чем отсутствующие/опциональные значения. Но и они дойдут до Котлина раньше чем в Java появится T? в любом виде. Это уж точно.

Зачеееем? Литералы коллекций, тернарник и прочий дублирующий синтаксис, позволяющий делать то же самое на три символа короче — это же чистейший мусор.

а ошибки то какие?

Я так понимаю, вопрос был не в литералах был, а в том, чтобы через .*toInt() сократить запись .map { it.toInt() }

Якобы, map частая операция, и давайте сделаем сокращённый синтаксис как в Groovy

Но тут, по-моему, и вариант с map достаточно лаконичен, и хорошо то, что можно заменить его на mapNotNull. Т.е. текущий синтаксис норм