К сожалению, вы невнимательно читаете. Речь идет не об уменьшении времени компиляции на 94%, аоб увеличении производительности (скорости) компилятора на 94%.
Таким образом:
Раньше я мог выполнять работу X за время Y - начальная производительность.
Теперь я могу выполнять работу X за время Y / 2 - конечная производительность.
Итого: конечная производительность в 2 раза больше начальной.
Выгода здесь понятно в рефакторинге. И два бонуса. Основной - это масштабирование на несколько целевых архитектур. Я думаю, ради этого всё затевалось. Второй - ускорение компиляции - это бонусом.
Языку уже 13 лет, цели изменились, много нового добавилось.
Из-за появления новых целевых архитектур замедлялась разработка фичей языка. Поэтому JB в последних релизах и в том числе в 2.0 не выпускают ничего нового. Но в будущем новый компилятор открывает дорогу.
Я бы не сказал что была основная цель, а что-то далось бонусом. Тк ускорение фронтенда и масштабирование на разные архитектуры происходит в разных частях компилятора. Поэтому логично предположить что работа над этими улучшениями была разделена.
Ничего особенного с точки зрения компиляторов. Одна из возможных архитектур в развитии.
Чем плоха классическая архитектура, если она решает нужные задачи и уже опробована в действии много раз. Kotlin не экспериментальный язык, чтобы испытывать что-то особенное в компиляторе)
Из альтернатив, тоже довольно стандартных, является построение по синтаксису отдельного семантического дерева. Здесь есть свои преимущества и недостатки, но их никто толком не анализировал.
Тк компилятор переписывался то я думаю что в JB анализировали разные подходы.
Наличие нескольких структур данных в предыдущей версии компилятора ухудшала JIT-оптимизацию и кеширование процессора. Видится, что в варианте с наличием нескольких деревьев может быть аналогичная проблема.
Но, конечно, интересно, какие альтернативы JB рассматривали. Я эту информацию в открытых источниках не нашел.
Про сахарные преобразования в статье сказано скупо, что этот этап есть. А это самое интернюесное, потому что именно здесь могут быть конфликты - некоторые сахарные преобразования можно выполнять только до других, а иные рекурсивно зависят от других, и нет регулярной литературы, описывающей решения. Наконец, понятно, что в сахарных преобразованиях участвует семантика, но проблема в том, что семантика может быть на момент сахарных преобразований еще не до конца выведена.
Так это часть алгоритма компилятора. Благо компилятор открытый. Статья и так получилась нагруженной и не было задачи разобрать все нюансы работы компилятора.
94% это ускорение по чистому билду. Помимо этого в статье с замерами есть и другие сценарии.
Замеры проведены на реальных развивающихся опенсорсных проектах: Anki-Android, Exposed. Понятно, что эти проекты не эталонные, и будет интересно увидеть цифры от крупных компаний в будущем.
ViewModel может использоваться не только для пережития ЖЦ вьюхи как в андроиде, но и как архитектурная сущность. Мы используем ViewModel в KMP-части, они шарятся между ios и android. Поэтому с этим проблем нет.
Все-таки не нужно смешивать KMP и Compose multiplatform. KMP не нацелен на реализацию кроссплатформенного UI.
А различия верстки на мобильном устройстве и десктопе придется учитывать при использовании любой технологии. Но это не значит что нельзя создать адаптивную верстку и переиспользовать UI-элементы.
Из платформ поддерживаются Windows, MacOS, Linux. В Compose Multiplatftorm для отрисовки используется Skia. В качестве skia backend могут быть использованы OpenGL/Vulkan/Metal/DirectX
Пожалуйста, перечитайте статью, C# не удовлетворяет ни 1 из приведенных сценариев.
Swift используется при реализации нативного UI ios-платформы. Не вижу с этим никаких проблем. Вся кроссплатформенная часть пишется на Kotlin. В том числе внутри кроссплатформенной части можно обращаться к нативным функциям платформы на Kotlin.
Что flutter, что kmp в stable. Ни для кого не секрет что flutter в стейбле дольше. Тут не нужно проводить сравнение. Не очень понял что значит писать с 0 или брать готовое решение.
Про ui отвечал в комментариях выше
KMP поддерживает ios / android / desktop / web. Будем честны, немобильные платформы редко берутся в расчет при выборе этих технологий. Desktop нераспространен, в web много своих нюансов.
В статье не приводится аргумент про "сложность" Dart. Ответил выше
Сравнение .NET MAUI и KMP некорректно в данном плане - Kotlin нативный язык для Android. И при разработке сложных мобильных приложений разработчику все равно нужно будет знать нативную платформу.
Откуда взята информация, что KMP - устаревшее решение? Было бы хорошо, если бы вы пояснили свою мысль
В статье не упоминается KMP как "замена" Flutter. И KMP таким действительно не является. Он не целится в переиспользование UI (хотя compose multiplatform и позволяет это делать) в этом и заключается одно из преимуществ - шарьте только то что нужно вам. Почему вы считаете это костылем?
Использовать compose multiplatform не будет возможным без KMP.
Выучить новый язык не составит сложностей разработчику с опытом, да это и не утверждается в статье. Но очевидно, что распространение Kotlin выше чем у Dart. Dart используется в основном на флаттере и больше нигде. В веб разработке с него ушли, например Wrike.
В любом форке в долгосрочной перспективе будет проблема что ваши изменения не будут совместимы с новой версией библиотеки, поэтому одной кнопкой тут не обойдешься.
Спасибо за решение!
На конфе показывали сценарии:
patreon: выжимка важной информации из непрочитанных сообщений в чате
grammarly: умные подсказки по улучшению написанного текста
В статье говорится об ускорении компилятора на 94%, а не уменьшении времени компиляции на 94%. См объяснение выше.
К сожалению, вы невнимательно читаете. Речь идет не об уменьшении времени компиляции на 94%, а об увеличении производительности (скорости) компилятора на 94%.
Таким образом:
Раньше я мог выполнять работу X за время Y - начальная производительность.
Теперь я могу выполнять работу X за время Y / 2 - конечная производительность.
Итого: конечная производительность в 2 раза больше начальной.
Языку уже 13 лет, цели изменились, много нового добавилось.
Из-за появления новых целевых архитектур замедлялась разработка фичей языка. Поэтому JB в последних релизах и в том числе в 2.0 не выпускают ничего нового. Но в будущем новый компилятор открывает дорогу.
Я бы не сказал что была основная цель, а что-то далось бонусом. Тк ускорение фронтенда и масштабирование на разные архитектуры происходит в разных частях компилятора. Поэтому логично предположить что работа над этими улучшениями была разделена.
Чем плоха классическая архитектура, если она решает нужные задачи и уже опробована в действии много раз. Kotlin не экспериментальный язык, чтобы испытывать что-то особенное в компиляторе)
Тк компилятор переписывался то я думаю что в JB анализировали разные подходы.
Наличие нескольких структур данных в предыдущей версии компилятора ухудшала JIT-оптимизацию и кеширование процессора. Видится, что в варианте с наличием нескольких деревьев может быть аналогичная проблема.
Но, конечно, интересно, какие альтернативы JB рассматривали. Я эту информацию в открытых источниках не нашел.
Так это часть алгоритма компилятора. Благо компилятор открытый. Статья и так получилась нагруженной и не было задачи разобрать все нюансы работы компилятора.
94% это ускорение по чистому билду. Помимо этого в статье с замерами есть и другие сценарии.
Замеры проведены на реальных развивающихся опенсорсных проектах: Anki-Android, Exposed. Понятно, что эти проекты не эталонные, и будет интересно увидеть цифры от крупных компаний в будущем.
Вы неправильно трактуете это число. Как трактовать эти числа можете почитать в статье.
Также в этой статье привожу пример на официальные замеры JB. Там явно видно числа: 94% это не в 16 раз ускорение, у чуть меньше чем в 2.
Вакансии постят, видимо, живут
Вчера JB провели вебинар и ответили на этот вопрос. Не планируют в ближайшее время, сейчас фокус на другом
ViewModel может использоваться не только для пережития ЖЦ вьюхи как в андроиде, но и как архитектурная сущность. Мы используем ViewModel в KMP-части, они шарятся между ios и android. Поэтому с этим проблем нет.
По этому поводу уже заведено несколько issue 1, 2
Все-таки не нужно смешивать KMP и Compose multiplatform. KMP не нацелен на реализацию кроссплатформенного UI.
А различия верстки на мобильном устройстве и десктопе придется учитывать при использовании любой технологии. Но это не значит что нельзя создать адаптивную верстку и переиспользовать UI-элементы.
Из платформ поддерживаются Windows, MacOS, Linux. В Compose Multiplatftorm для отрисовки используется Skia. В качестве skia backend могут быть использованы OpenGL/Vulkan/Metal/DirectX
как уже подсвечивал в статье, знание 2 языков не является обязательным требованием
с использованием Compose multiplatform количество Swift-кода уменьшается
ну и для написания платформенно-специфичного кода во flutter swift тоже нужен.
Пожалуйста, перечитайте статью, C# не удовлетворяет ни 1 из приведенных сценариев.
Swift используется при реализации нативного UI ios-платформы. Не вижу с этим никаких проблем. Вся кроссплатформенная часть пишется на Kotlin. В том числе внутри кроссплатформенной части можно обращаться к нативным функциям платформы на Kotlin.
Что flutter, что kmp в stable. Ни для кого не секрет что flutter в стейбле дольше. Тут не нужно проводить сравнение. Не очень понял что значит писать с 0 или брать готовое решение.
Про ui отвечал в комментариях выше
KMP поддерживает ios / android / desktop / web. Будем честны, немобильные платформы редко берутся в расчет при выборе этих технологий. Desktop нераспространен, в web много своих нюансов.
В статье не приводится аргумент про "сложность" Dart. Ответил выше
Сравнение .NET MAUI и KMP некорректно в данном плане - Kotlin нативный язык для Android. И при разработке сложных мобильных приложений разработчику все равно нужно будет знать нативную платформу.
наверное поэтому можно с завидной регулярностью встретить статьи про то как с камерой работать во flutter и какие там нюнасы ))
и посмотрим на платформы Compose Multiplatform )
а если серьезно то вряд ли в ближайшем будущем что-либо пошатает позиции текущих веб фреймворков
Откуда взята информация, что KMP - устаревшее решение? Было бы хорошо, если бы вы пояснили свою мысль
В статье не упоминается KMP как "замена" Flutter. И KMP таким действительно не является. Он не целится в переиспользование UI (хотя compose multiplatform и позволяет это делать) в этом и заключается одно из преимуществ - шарьте только то что нужно вам. Почему вы считаете это костылем?
Использовать compose multiplatform не будет возможным без KMP.
Выучить новый язык не составит сложностей разработчику с опытом, да это и не утверждается в статье. Но очевидно, что распространение Kotlin выше чем у Dart. Dart используется в основном на флаттере и больше нигде. В веб разработке с него ушли, например Wrike.
В любом форке в долгосрочной перспективе будет проблема что ваши изменения не будут совместимы с новой версией библиотеки, поэтому одной кнопкой тут не обойдешься.