Котлин никогда не "выпиливал паттерн матчинг". Вообще, откуда это вдруг выдумалось - не понятно. Паттерн матчинг в Котлине был исключен из рассмотрения из соображений экономии в дизайне языка. Сейчас он очень неторопливо пытается появиться, ожидается где-нибудь в 2.х. Начиная с 1.0, который считается первым "производственным" релизом Котлина, Котлин жестко блюдёт обратную совместимость, как на уровне исходников, так и на уровне бинариев. В Котлине есть "экспериментальные фичи". Это примерно как инкубаторные фичи в JVM, только надо ещё и в исходниках через аннотации отдельно включить экспериментальную фичу. Нужно это ровно для того же: посмотреть, как пойдёт, собрать фидбек. Бывало такое, что эксперимантельные фичи радикально переделывались (например, корутины), но на то они и экспериментальные.
Спасибо, отличный подкаст. По поводу того, что Java (как язык) не чувствует конкурента в виде Котлина, сомневаюсь. Android, как уже сказали - это большая победа, и очень большой рынок. Другое дело, что Котлин завендорлочен JB.
Речь скорее про бэкенд. Хотя вы знаете, я не уверен, что если бы на Андроиде была современная Java, то Котлин бы так легко победил. Но теперь да - там полная победа Котлина, конечно (и хорошо!).
@@uglianskyберешь программиста средней руки, который пишет для бизнеса, в заказной разработке и т. д., просишь его недели две, месяц писать на kotlin после java. Потом возвращается обратно - наблюдаешь ломку.
1:21:48 про panama заметно непонимание для чего он нужен. про это пояснил архитектор java Brian Goetz - th-cam.com/video/8Kpc97okVd0/w-d-xo.htmlm57s - то есть чтобы проще создать подключения к популярным библиотекам как tensorflow, sqlite и тд которые не имеет смысла или ресурсов переписывать
все верно, не вижу противоречия с тем, что я сказал. Конечно интероп нужен именно для того, чтобы подключать библиотеки, написанные не на Java, вопрос какому проценту людей это реально нужно (сравните с потенциальным количеством пользователей виртуальных потоков из Loom).
количество людей абсолютно не критерий в данном вопросе вообще, важно можно ли создать продукт используя технологию. Например, camunda, kafka streams используют rocksdb через jni, да и вообще успешны благодаря тому что тот самый rocksdb предоставляет jni интерфейсы сам. Остальные разработчики библиотек не хотят возиться с jni потому что он ужасен. panama это для как раз больше для них, а не для кодеров на java.
@@kjk254 "можно ли создать продукт используя технологию", "проще создать подключения к популярным библиотекам как tensorflow" - все верно, это можно делать и сейчас, через JNI. Но Panama, конечно, сделает это проще, в этом мотивация, все так. Почему количество людей - это не критерий, простите, не понимаю. Возможно вы хотите сказать что-то в духе: "сейчас людей, которые мучаются с JNI мало, но вот будет Panama их сразу станет больше, поэтому количество пользователей сейчас - это не аргумент", но это же теоретизация. Наверное да, станет больше, насколько - непонятно. А с Loom-ом то все понятно было сразу, пользователи - вот они: любой, кто пишет высоконагруженный бэкенд.
1:06:00 Оберонщики часто жалуются, как у них украли все пи-коды, но им остаётся только мечтать о феодальной раздробленности NMI, JRI, RNI, Java/COM, JNI и JNA. У них даже и раздробленности такой не было. Я напрягаю память и не могу вспомнить, чтоб был какой-нибудь ONI, Oberon Native Interface, и чтоб была цепочка попыток и неудач, и было соревнование, так кто же прав, так как лучше сделать. Спрашивал оберонщиков, вот есть мир из Си, C++ и Java, и они друг к другу ходят, и друг друга усиливают, они едины. А есть, допустим, мир патриотов Паскаля, и у нас всё паскалевское, но кому-то нравятся управляемые языки с навязанной сборкой мусора, они бы писали на Обероне, а кому-то не нравятся, они бы писали на Аде, а как нам друг к другу ходить вызывать. Лучший ответ был: пишите всё на Обероне. Эм. Не удивительно, что патриоты Паскаля всасывают с таким подходом. 1:06:46 Да нет, там не просто ничего не работает. Там нарушения спецификации Java были по части допустимой эволюции Java-классов. То есть, поменяли Java-класс, и перестало работать даже на той же виртуальной машине, пока не перегенерить заголовки, не перекомпилировать нативный код. Ну, и сама спецификация не сразу потребовала обязательность допустимости эволюции. NMI ведь от Sun, это сами Sun наступили на горло своей песне, заменили NMI на JNI.
Спасибо за очередное прекрасное интервью. Мне нравится, что у вас интересные гости и вы умеете их раскрыть, сделать интервью интересным. Иван молодец!
Рады, что вам понравился выпуск! Мы действительно ищем гостей и темы, которые будут интересны нашим слушателям :)
Спасибо, было очень интересно) сам из Новосиба, не знал что у нас такое есть в НГУ)
Котлин никогда не "выпиливал паттерн матчинг". Вообще, откуда это вдруг выдумалось - не понятно. Паттерн матчинг в Котлине был исключен из рассмотрения из соображений экономии в дизайне языка. Сейчас он очень неторопливо пытается появиться, ожидается где-нибудь в 2.х.
Начиная с 1.0, который считается первым "производственным" релизом Котлина, Котлин жестко блюдёт обратную совместимость, как на уровне исходников, так и на уровне бинариев.
В Котлине есть "экспериментальные фичи". Это примерно как инкубаторные фичи в JVM, только надо ещё и в исходниках через аннотации отдельно включить экспериментальную фичу. Нужно это ровно для того же: посмотреть, как пойдёт, собрать фидбек. Бывало такое, что эксперимантельные фичи радикально переделывались (например, корутины), но на то они и экспериментальные.
понятно, прошу прощения, что неправильно сказал
Если бы там и вправду была обратная совместимость, но стандартная библиотека котлина была бы предоставлена в андроиде
Спасибо, отличный подкаст.
По поводу того, что Java (как язык) не чувствует конкурента в виде Котлина, сомневаюсь. Android, как уже сказали - это большая победа, и очень большой рынок. Другое дело, что Котлин завендорлочен JB.
Речь скорее про бэкенд. Хотя вы знаете, я не уверен, что если бы на Андроиде была современная Java, то Котлин бы так легко победил. Но теперь да - там полная победа Котлина, конечно (и хорошо!).
Что значит завендорлочен? Вроде бы это open source language под apache license.
@@uglianskyберешь программиста средней руки, который пишет для бизнеса, в заказной разработке и т. д., просишь его недели две, месяц писать на kotlin после java. Потом возвращается обратно - наблюдаешь ломку.
@@ugliansky А не лучше ли, чтобы победил Oxygene. Патриоты Паскаля, по идее, должны за Oxygene топить
@@uglianskyна момент подкаста в плане языковых фичей была джава 17, сейчас 21. Лаг есть, и не все API доступны, но всё же
1:21:48 про panama заметно непонимание для чего он нужен. про это пояснил архитектор java Brian Goetz - th-cam.com/video/8Kpc97okVd0/w-d-xo.htmlm57s - то есть чтобы проще создать подключения к популярным библиотекам как tensorflow, sqlite и тд которые не имеет смысла или ресурсов переписывать
все верно, не вижу противоречия с тем, что я сказал. Конечно интероп нужен именно для того, чтобы подключать библиотеки, написанные не на Java, вопрос какому проценту людей это реально нужно (сравните с потенциальным количеством пользователей виртуальных потоков из Loom).
количество людей абсолютно не критерий в данном вопросе вообще, важно можно ли создать продукт используя технологию. Например, camunda, kafka streams используют rocksdb через jni, да и вообще успешны благодаря тому что тот самый rocksdb предоставляет jni интерфейсы сам. Остальные разработчики библиотек не хотят возиться с jni потому что он ужасен. panama это для как раз больше для них, а не для кодеров на java.
@@kjk254 "можно ли создать продукт используя технологию", "проще создать подключения к популярным библиотекам как tensorflow" - все верно, это можно делать и сейчас, через JNI. Но Panama, конечно, сделает это проще, в этом мотивация, все так. Почему количество людей - это не критерий, простите, не понимаю. Возможно вы хотите сказать что-то в духе: "сейчас людей, которые мучаются с JNI мало, но вот будет Panama их сразу станет больше, поэтому количество пользователей сейчас - это не аргумент", но это же теоретизация. Наверное да, станет больше, насколько - непонятно. А с Loom-ом то все понятно было сразу, пользователи - вот они: любой, кто пишет высоконагруженный бэкенд.
1:06:00 Оберонщики часто жалуются, как у них украли все пи-коды, но им остаётся только мечтать о феодальной раздробленности NMI, JRI, RNI, Java/COM, JNI и JNA. У них даже и раздробленности такой не было. Я напрягаю память и не могу вспомнить, чтоб был какой-нибудь ONI, Oberon Native Interface, и чтоб была цепочка попыток и неудач, и было соревнование, так кто же прав, так как лучше сделать. Спрашивал оберонщиков, вот есть мир из Си, C++ и Java, и они друг к другу ходят, и друг друга усиливают, они едины. А есть, допустим, мир патриотов Паскаля, и у нас всё паскалевское, но кому-то нравятся управляемые языки с навязанной сборкой мусора, они бы писали на Обероне, а кому-то не нравятся, они бы писали на Аде, а как нам друг к другу ходить вызывать. Лучший ответ был: пишите всё на Обероне. Эм. Не удивительно, что патриоты Паскаля всасывают с таким подходом.
1:06:46 Да нет, там не просто ничего не работает. Там нарушения спецификации Java были по части допустимой эволюции Java-классов. То есть, поменяли Java-класс, и перестало работать даже на той же виртуальной машине, пока не перегенерить заголовки, не перекомпилировать нативный код. Ну, и сама спецификация не сразу потребовала обязательность допустимости эволюции. NMI ведь от Sun, это сами Sun наступили на горло своей песне, заменили NMI на JNI.
Зачем чел, который якобы шарит за JVM, вообще в разговоре упоминает Котлин (сахар для Джавы), а не гораздо более развитую Скалу
"звуки скалы джонсона"
Слабовато