С чего начинать вкатываться в котлин для андррйд, имея бэкграунд

веб разраба?

на котлине?

С документации 👍

Вы таки удивитесь, но бэкенд на котлине это очень симпатичное дело.

Не удивится :) Это был простой уточняющий вопрос.

нет, я таки не удивлюсь, а только порадуюсь) Я просто уточнял

бэкграунд же значит опыт, не? или причем тут бэкенд? сори не нашел там бекэнд

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

компиляторы на котлине тоже неплохо смотрятся

Возможно) но на проде такие компиляторы появятся после того как native полетит. А пока kotlin (в комбинации с spring) идеален в основном для бэкенда.

я если что про компиляторы ЯП

Я тоже про них. Но как-то не задумывался о таком применении. Привык, что компиляторы обычно на с(с++) пишут. Уже есть какие-то результаты?

ну, компилятор котлина на котлине)

А если так, то есть шансы на что-то вроде Go? Ну то есть компиляция котлина в нативный код?

Доброе утро.

ну, котлин нейтив

По котлин нейтив я несколько роликов посмотрел, сам попробовал и ничего не взлетело. На Go все элементарно получилось. Хотя как язык Go весьма корявый. Отсюда и мечты, про котлин с его синтаксическими сверхспособностями, и реальным нативом.

ну, нужно разбираться, почему не взлетело. Тут и в остальных чатах точно есть люди, которые помогут разобраться, что не так. Не стесняйтесь!

Фиг знает) Я по работе senior jvm developer, котлин давно как родной. Но натив у меня так и не запустился. В Go только из любопытства заглянул, а там вообще все из коробки. Сразу работает.

ну, нейтив бете (или альфе). Но следует задать вопрос просто, что не заработало

Общее ощущение, что котлин натив это пока зависшая бета. Чисто поиграться, если повезет)

да вроде нет, я думаю, у @noraltavir есть опыт

Жаль, что пока бета. Оч хочется иметь что-то высокопроизводительное, и при этом комфортное. Наверное, было бы лучше, если бы котлин-натив умел меньше, но умел бы это хорошо и сразу. Тогда общественность бы осознала, что дело серьезное намечается, подтянулась с идеями и помощью. Жаль будет, если котлин-натив так и зависнет в стадии эксперимента.

не зависнет (он активно развивается), но в чем ваша проблема с жвм сейчас?

С jvm у меня никогда проблем не было) Для jvm котлин это язык мечта. Вроде скоро 10 лет как на нем пишу, а эффект "вау" до сих пор не проходит. Респект создателям еще раз.

ну, я про то, что жвм вполне высокопроизводительная, она делает весьма и весьма много оптимизаций (слава Богам JIT), а не следует байткоду

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

ну, зато оптимизации JIT позволяют выполнять больше, чем AOT

а так еще есть inline classes, и будут value classes

Value classes это круто, хотя мне пока под них много use case не попадалось. Не было возможности плотно с ними поработать. Больше жду сontext receivers. Кажется, что это game changer в архитектуре.

это да, они есть, но в бете пока что. Вэлью классес - для высоконагруженных штук или где вычислений много. Например, движок графический или тд

Уже проверили и заметный выигрыш получили? Можно узнать плюс-минус примерную оценку? Вдруг уже пора на value classes активно переходить.

ну, они в процессе разработки (мною), перейти на них пока не получится, они еще не доделаны, но выигрыш есть, особенно на андроиде.

Значит, пора уже задумываться над переходом. Сенкс за информацию.

ну, было бы куда и была бы дата выхода превью (у вас), можно было бы задумываться, а пока рано

В таких вопросах никто быстрых решений не принимает, торопиться некуда. Просто надо понять, как их в рабочий процесс вписать. Просто потому, что все равно придется это делать.

А, это правда. Можно почитать KEEP: https://github.com/Kotlin/KEEP/blob/master/notes/value-classes.md

ну то есть если у вас у классов важна айдентити или много полей, то особого смысла нет в фиче для вас

А чиво зачеркнул в итоге? Таки плохо?)

нет, просто это я о своем, о компиляторном

"Много полей" тут неважно. Value classes это своего рода дополнительное "ребро жесткости" в системе в целом. Появляется возможность контролировать бизнес-сущности компилятором. Что очень немало. Условно говоря, раньше компилятору было все равно, если я в поле "имя" впишу фамилию, потому что и то и другое String. Теперь ситуация меняется.

а, ну если у вас одно поле, то уже как пару лет (если не больше) есть inline classes — вэлью классы с одним полем

А чего он "лишнего" сейчас умеет?)

Не знаю) У меня оно так и не завелось. Не то, чтобы очень уж много времени потратил, но точно больше, чем надо для prod ready продукта.

Да, их и использовали. В некоторых местах очень неплохо получилось. Но не везде. Уже не помню, какие сложности возникли (видимо специфичные для того проекта), но более широко внедрять не стали. Решили подождать до value classes.

Тут согласен. Просто вроде я не припомню там фичей, которые прям не нужны. Ну по крайней мере из того, что много времени занимало. Могу разве что понять, если вам интероп с обж-с неинтересен, но тут ничего не поделать, основной фокус сейчас на мобилках :)

А в чем проблемы, а то может я как и не решу проблему вашу, а вы будете ожидать решения.

Не, у нас интерес попроще был: микросервисы. Чтоб были еще шустрее и еще меньше ресурсов требовали. То, что Go умеет.

а в чем проблема размер хипа уменьшить

Ток фокуса на крутом перфе у К/Н особо не было. Сейчас дела, конечно, намнооооого лучше, чем было в ранний период, но всё равно.

+

ну то есть они есть, но пока вторичны

Ничего конкретного не скажу, потому что с того проекта давно ушел и не знаю, какие там надобности. Но помню, что мутабельности там точно не требовалось.

эх, жаль

Если вы решите задачу для unmutable value classes, то для многих случаев будет достаточно.

это да, у остальных есть identity

Такие слова только девопсы знают) Что-то такое делали наверное.

Вы оскорбляете программистов, говоря, что про кучу знают только девопсы.

У нас библиотеки.

Да блин! (Простите) Кто вам сказал, что нативное значит производительное?

Какой? Вы мерили?

люди верят, что вот они то лучше будут управлять памятью и оптимизировать, чем какие-то инженеры из Оракла😅

Не портьте малину) В кои-то веки появились люди, на которых можно скинуть всякую скуку.

Виртуальная машина в любом случае какие-то ресурсы съедает. Я лично не мерил, но видел измерения тех, кто занимается graalVM.

Вот почему-то я всегда слышу именно этот ответ "я не мерил, но где-то видел". Да, JVM отъест у вас дополнительные 30-50 Мб памяти и около секунды на время разогрева на старте. При этом в пиковой производительности почти гарантированно будет лучше и в поддержке существенно дешевле. Я не говорю, что надо ее использовать всегда и везде, но стремиться к нативным приложениям где-то кроме консольных утилит - это странная позиция.

А зачем тогда существует проект graalVM? Если бы потери ресурсов на виртуальной машине были настолько малы, то в данном проекте не было бы смысла.

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

это поэтому UI на Android 2048 всё ещё будет лагать по сравнению с айфонами?)

Вы мерили? Я не спец по мобильной разработке, но чего-то у меня есть подозрение, что это из тех же мифов. На современном андроиде UI будет лагать только если какой-то андроид-вайтишник вычисления на UI треде запускает.

А где он лагает?)

Вы прямо разрушитель шаблонов) Я строго за, потому что по основной специальности работаю только с jvm. Было бы здорово, если бы вы собрали ваши измерения в одну статью. Согласитесь, что это была бы реклама не столько jvm, сколько котлину. Потому что в чем точно проигрывают высокопроизводительные(?) ЯП, так это в эргономике и читабельности. Если окажется, что их выигрыш в производительности в каких-то случаях не так уж велик, то у котлина будет дополнительная аудитория.

Таких сравнений за время существования jvm провели уже тыщщи. Доклады делали на всех конференциях и прочее - куда ещё то?

Нет такой вещи, как высокопроизводительные ЯП. Это я вам как человек, занимающийся вычислениями, говорю. Есть сильно оптимизированные библиотеки. Измерения вы можете посмотреть в документации самого GraalVM. И измерения будут очень сильно зависеть от того, что вы меряете. Какую задачу.

Те измерения, что мне попадались, говорили только о том, что виртуальная машина даром не обходится. Отсюда и шаблон.

в смысле мерял, возьмите две свежих модели, поводите пальцем. Не знаю, какую они там магию делают, но андроид всегда ощущается, как каличный суррогат. Столько лет спустя уже неприлично списывать на слабое железо или плохой код, фундаментальные ограничения кажутся ближе к правде и имхо это натив vs виртуалка.

Ничего даром не обходится, но больше всего производительность страдает от криворукости программиста и только уже в каких-то очень специальных случаях vm начинает влиять и большинство этих мест уже покрыты интринсиками и прочими оптимизациями так что заметить и замерить разницу это надо очень постараться

Вы мощность ядра смотрели? Какие модели-то сравниваете? У меня на самсунге ничего не лагает. Но да, цена повыше.

Нормальний тф возьмите а не кал за 200$

Самсунг какой-нибудь последний на квалкоме выдаёт честные 120 фпс и все. Дальше идёт чисто субъективная тема связанная со скоростью анимаций отзвычивостью тачскрина и тд

да, вот статья как раз про это: https://medium.com/@altavir/about-good-programmers-good-programs-and-performance-2d7b79a2ab08

И это говорит фанат эппл ))

Это да)) Хороший бизнес-аналитик может построить такую оптимальную доменную модель, что выигрыш ресурсов по системе в целом будет исчисляться часами и гигабайтами. Никакие нативные ЯП с их "+10%" не догонят.

"у меня на самсунге ничего не лагает". Потому что вы держите в руках самсунг. Я тоже своим OnePlus доволен и айфона никогда не имел. Но я ж не слепой, покривлю душой, если не признаю, что любой айфон в магазине плавнее самсунга с соседней стойки. Свайпаешь, как наркоман просто потому что приятно свайпать, как-будто даже экрана не касаешься.

Ну новые GC для jvm уже пишутся на джава, компиляторы тоже на ней, грааль вроде

Да, весь JIT там на Java и сейчас делают C1 тоже на Java (Espresso).

Боксинг убрали 🌚 ? Шарить такие классы через структуры данных с дженериками так себе - получаем примитивы 2.0

Ага, убрал на жвм

😁😆🙃

Я не шучу!

Вне андроида кстати почти нет. Современные JVM очень хорошо скаляризуют. Хотя, разумеется, в корнер кейсах можно получить хороший прирост.

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

Вот это интересно очень будет посмотреть. Не хочешь на митапчике выступить? Или все пока секретно?

Насчёт секретности - к Ильмиру. Но я могу Вам ПЗ к ВКР скиеуть, там бенчмарки есть

*из Sun 🌚

Судя по эмодзи, из Moon

Ну я именно про выступление. А то у нас немного KUG завял (по моей вине, разумеется)

Там уже до фига людей поработало из других мест тоже

Отбирает, и кратковременный запуск будет с оверхедом, можно с2 отключить для таких сценариев. Но в долгосрочной перспективе мы получаем буст

Напыщенное Эго
Вижу бенчмарки, где у Java потребление памяти в ра...

CLBG - это лажа. Рассказать вам историю, почему regex-redux там на всех языках, кроме Java имеет одно и то же время выполнения?

Напыщенное Эго
Вижу бенчмарки, где у Java потребление памяти в ра...

нет

Интересно, расскажи

Расскажите, конечно. Но я не вижу что там одно время выполнения в regex-redux

Там под низом у всех одна и та же сишная библиотека, которая просто вызывается из оберточного кода. А в Java/Kotlin используется совбственный парсер с совсем другим набором фич. Это к вопросу о "скорости языка"

плюс минус одно.

ну под языком подразумевается связка язык-платформа. И если эта связка дает удобный и дешевый интероп - это хорошо. И в ваших словах так же чувствует обида, на дешевый нативный интероп)

а как тогда тест binary-trees по памяти объяснить?

Напыщенное Эго
Вижу бенчмарки, где у Java потребление памяти в ра...

Эти бенчи полная параша, а авторы - упоротые кретины. Извините. Поясняю. У них сорцы в архиве. Но это бы ладно Когда хочешь им внести исправления в бенч - типа, а вот тут можно так и будет быстрее, они говорят - ТАК ПИСАТЬ НА ЯЗЫКЕ ХХХ НЕЛЬЗЯ - но ведь можно, смотрите - ЭТО НЕ КАНОНИЧНО Поэтому регэкспы те же в C# могут почему-то PInvoke (нативный вызов из дотнетного рантайма) в сишную либу использовать А F# (такой же дотнет язык, который точно так же может делать PInvoke) не может. Потому что авторы ебанутые наглухо

Jvm регексп ничуть не хуже, у него просто другой набор фичей. Обертка для этой либы делается в одно касание, но она никому не нужна

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

Кто-нибудь лимит по памяти поставил? Или может zgc включил? Если вы не сказали jvm, что надо оптимизировать память, почему она должна это делать. Плюс надо смотреть реализацию. Она же тоже разная

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

а разве описанные действия в конечном счете не приведут просто к более частым сборкам мусора? (что в свою очередь и понизит перформанс)

Оу

Не обязательно. Там скоее всего загрузка памяти неравномерная. Плюс гц паузы дешевые

Почему в джаве это интероп не заюзали ?

JNI? Не пробовал, но говорят дорогой..

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

ну да) Один вызов на java и вся логика на плюсах) классная программа на Java))

ну если условную либу пишешь, то почему нет)

ну бенч так решать нельзя.. Это будет справделиво только если это действительно популярная либа, которая стала дефакто стандартом для решения такого рода задач на заданном языке

Techempower более показательный в этом смысле, там jvm это примерно 64% от С++ что хорошо, потому что 36% перфоманса за нормальный язык и защиту от проблем с памятью для большинства ок. Дальше можно конечно пофлеймить на тему “вот раст безопасный, собирает сразу и там только reference count есть как GС, все быстро короче” на что резонно можно ответить что “собирать мусор можно когда запрос завершился тем самым уменьшить latency общую, раст так не может”. (Techempower не отвечает как конкретный тест расходовал ресурсы и куда отдано предпочтение в throughput или latency. Поэтому самим нужно мерить, удачи с этим ) Но даже на Rust нету того DevX который есть на Kotlin/JVM сегодня. Поэтому дальше вопрос что вам важнее, задеплоить фичу вчера или сэъкономить 30% RAM/CPU (нужное подчеркнуть) ценой использования нативных библиотек, потому что Rust все еще не покрывает даже базовые интерграции. Потом кто-то вспомнит что есть же graal который в теории офигительный по памяти и если купить лицензию у оракла даже не сильно отстает от JIT. Но голый throughput все равно на JVM лучше. Но все это смешно если посмотреть сколько проектов живет на django/rails у которых 3% от С++, а тот же spring 17% Если у вас нету специфичной задачи быть самым быстрым, то можете использовать JVM, это оптимимум в DevX, производительности, безопасности. Если нужно быть самым быстрым и экономить каждый байт - то тут C/C++. Если хочется быть максимально быстрым и при этом важна безопасность (а где сегодня она не важна?) то Rust/Go А JVM есть куда расти, с новыми API для дерганья нативного кода и работы с памятью (JEP 424), поддеркжкой векторных операций (JEP 414), Loom и т.д вероятность что можно будет писать приложения которые примерно 90% от C++ возрастает

Jni и jna

Дешевле, чем питоновский

Можете посоветовать наиболее перспективный набор библиотек для котлина по компьютерному зрению? Хочется пару соответствующих проектов с питона на котлин перевести. При всем уважении к питону, скриптовые языки даже для средних проектов это тупик.

Я не спец по компьютерному зрению. Кое-какая дискуссия была в слаке. Что-то простенькое есть в Kotlin-DL, но в целом пока это java библиотеки и сейчас появляется много котлин оберток.

Пардон, конечно) Компьютерное зрение это совсем отдельная жизнь. На всякий случай спросил, вдруг на физтехе где-то рядом обсуждалось. А по математике (линейная алгебра, статистика, обработка сигналов) уже сформировался какой-то стандарт хотя бы на уровне jvm ?

Глава Kotlin for Data Роман Белов как раз эксперт по компьютерному зрению. Но я не знаю, какую часть они делают на котлин. У нас сейчас будет несколько проектов на object detection, которые будем пытаться делать на KotlinDL. Но это не совсем компьютерное зрение.

По математике стандартом в JVM является Commons Math. Она могуча по охвату и хороша по API, но слабовата по оптимизации. А так есть много вариантов. KMath пока сильно экспериментальная, но зато интегрирует много всякого разного

Наверняка для kotlin multiplatform должна быть какая-то математическая библиотека. Пусть с урезанным для начала функционалом. Просто в качестве стандарта, к которому сообщество привыкнет и который потом расширять можно. Уже есть кандидаты? Тот же kmath например.

Я не могу быть объективен - я основной разработчик KMath