Мы узнали у экспертов по современным языкам программирования, что будет с их любимыми языками в 2023 году. Удалось собрать интересные инсайды и прогнозы про Python, Go, Haskell, Rust, Java, Swift, Kotlin и веб-разработку. Заодно обсудили, как программистам подготовиться к этим изменениям.
Никита — тoп-67 по коммитам в CPython, топ-6 по коммитам в mypy и typeshed. Лично участвует в процессе разработки Python 3.12. GitHub Никиты
В следующем году в ноябре выйдет новая версия Python 3.12, а до этого будут релизы нескольких альфа-версий, бета-версий и релиз-кандидатов. Альфа-версии уже доступны.
На новые версии Python сейчас переходят достаточно быстро, потому что в них минимальное количество ломающих изменений, а улучшений много. Нет смысла сидеть на старой версии, за исключением некоторых нюансов тулинга. Но если вы активный пользователь статических анализаторов, то они подтягиваются приблизительно спустя год после релиза синтаксических и семантических обновлений. Соответственно, сразу тащить новую версию Python в продакшен можно, если это простой сервис. Если вы делаете что-то сложное, энтерпрайзное, то ждать придется минимум год от релиза.
Проблема Python в том, что никто от него ничего не ждет — в этом языке уже все есть. Некоторые ждут какие-то фичи, но часто сами не понимают, зачем. Например, в Python 3.12, скорее всего, будет полноценный релиз субинтерпретаторов. Но люди пока не знают, что с ними делать, потому что это новая концепция. В других языках программирования я аналогов не помню. Понимания, как это использовать, и переезда на существующий тулинг люди будут ждать еще долго.
Планируется, что в 2023 году выйдет новый PEP 649, который будет по-другому работать с аннотациями. То есть from __future__ import annotations, скорее всего, будет убран как не очень хорошее решение. Вместо этого будут аннотации на дескрипторах.
Обязательно будут улучшать адаптивный интерпретатор. Некоторые называют его JIT, но это не совсем он, потому что работает на уровне кодов операций и не уходит глубже. Он просто уточняет одни и те же коды операций в некоторых случаях. Пример: при вызове функции по умолчанию существует код операции CALL, который может различными способами вызывать разные функции, например для вызова isintance есть CALL_NO_KW_ISINSTANCE. Если вы постоянно вызываете одну и ту же функцию и отрабатываете один и тот же код операции, то в какой-то момент будете использовать этот более конкретный операционный код. Это позволит сэкономить время на операциях с помощью вызова более специализированного кода. Ждут ли этого люди? Наверное, нет, поэтому никто этого не заметит.
Я очень жду удаления старых модулей. Мы удалили модули distutils, я лично удалил asynchat и asyncore, которые ненавидел всей душой. Будет удалена еще парочка модулей, про которые совсем никто не знает.
Будет изменен API importlib библиотеки, многое будет переработано, включая работу импортов. Очень много разных внутренних API-макросов уже переделали на inline-функции, это позволило упростить много кода. Теперь очередь за новыми компиляторами, которые их достойно оптимизируют и существенно ускорят процессы.
Стоит упомянуть инициативу faster-cpython. Это инициатива, которая занимается увеличением скорости работы Python в разных областях.
Этот релиз не будет настолько же кардинальным как 3.11. Наверняка добавят какие-то новые фичи, оптимизации и багфиксы. В результате 3.12 станет стабильным релизом, в котором подготовятся к большому количеству удалений в версии 3.13.
Все по-прежнему будут говорить, что нужны какие-то микрофреймворки, но использовать будут Django, потому что это самый популярный и применимый фреймворк. В остальных не хватает примерно всего.
В Django будут продолжать пихать разные асинхронные фичи, что там совершенно не нужно, зато людям нравится. О, асинхронная функция, она работает медленнее, и непонятнее, чем синхронная; давайте будем ее использовать.
Fast API окончательно загнется — это сейчас самый модный фреймворк, но у него не получилось создать сообщество контрибьютеров. Приходят миллионы людей и говорят: «У меня не работает», — а никто это не правит. Фреймворк в таком виде — это классная поделка, в которой можно запустить hello world и еще несколько приложений, но никто не возьмет это в серьезный продакшен.
Формируется понимание, что такое C API и C ABI, и как разным библиотекам их использовать. Речь о NumPy и подобных штуках. Уже есть много всего, но существует проблема, что какая-то часть C API или C ABI сломалась. Люди использовали то, что существовало годами, но не было задокументировано. Когда коду больше 25 лет, его использовали, а потом выяснилось, что никто не планировал, что это будут именно так. Поэтому сейчас идет стандартизация процесса, чтобы упростить жизнь тем, кто пишет свои C Extension. Для этого привлекаются люди из разных систем, которые занимаются большими данными и библиотеками для работы с ними, разными системными пакетами.
Основное направление развития Python сейчас — сохранять стабильность, увеличивать скорость работы и избавляться от легаси. Его очень много, ведь языку больше 30 лет.
Эмиль в Twitter
Знаковым событием для Go в 2022 году было добавление параметризованных типов. Так разработчики языка попытались удовлетворить давно уже ставшую мемом потребность сообщества в дженериках. Однако с момента выхода версии языка 1.18 прошло более восьми месяцев, а повсеместного использования дженериков в библиотеках и пользовательском коде так и нет. Причина — невозможность использовать параметризованные типы в функциях с ресивером, то есть в методах структур. Такое решение не сильно устроило сообщество языка и сейчас активно обсуждается поддержка обобщенного программирования методами. Эта фича — наиболее ожидаемая в 2023 году.
Создатели языка, однако, не говорят о планах добавить эту фичу, потому что ее реализация технически довольно сложна и может привести к значительному росту либо времени компиляции, либо времени исполнения. В комментариях к релизу 1.18 написали, что дальнейшая работа над дженериками будет вестись в последующих версиях.
Из наиболее интересных планов на релиз Go 1.20 можно отметить планы на поддержку profile guided optimization. Речь про возможности компилятора, который может оптимизировать наиболее нагруженные участки кода с помощью профиля, собранного с уже работающей в проде системы. Другое важное изменение — улучшение утилиты, которая используется для анализа покрытия кода тестами. С этим улучшением появится возможность видеть покрытие кода в модулях, отличных от модуля, в котором находится тест.
Все эти нововведения позволят пользователям эффективнее использовать Go в продакшен-системах и увеличат его надежность, ведь основная ниша для языка — написание надежных и быстрых сетевых сервисов. Не стоит ожидать, что в предстоящем году что-то кардинально изменится. Ежедневно в языке появляются новые библиотеки и фреймворки, которые, например, позволяют добавлять GUI, писать игры и даже мобильные приложения. Однако вряд ли Go внезапно превратится в лучший язык для настольных приложений или пошатнет C++ в сфере разработки игр.
Резюмируя вышесказанное: у Go есть своя ниша (например, на этом языке написан Kubernetes), поэтому популярность языка продолжит расти. Этому способствует как непрерывное улучшение языка и его экосистемы, так и его простота. В 2023 году стоит ждать планомерного роста количества проектов на Go и количества вакансий на нем.
Twitter: @anioutkajarkova
Осенью вышла бета-версия Kotlin Multiplatform с новой моделью памяти. Это означает, как и написано на сайте разработчиков Kotlin — JetBrains, что эта технология уже полностью готова к продакшену, и до выхода финальной версии осталось совсем недолго. А еще — что исчезнут почти все проблемы разработчиков с Kotlin Native при реализации решений на iOS. Все сложные воркэраунды по работе с памятью, решения проблем с многопоточностью в iOS, которым были посвящены доклады последних лет, уже не актуальны. Сейчас все реализуется само собой, из коробки.
В качестве тренда стоит упомянуть Compose. Еще в прошлом году на всех мероприятиях, посвященных Kotlin и Kotlin Multiplatform, команду JetBrains доставали вопросами, когда же появится Compose под iOS. Особенно, когда прошлой осенью появился Jetpack Compose под Android в стабильной версии, после чего начался новый виток развития этой технологии.
Тогда в компании JB отнекивались, что Compose под iOS не входит в их планы. Они сообщали, что планируют сосредоточиться на других технологиях. Однако наблюдательные энтузиасты заметили, что Compose под iOS уже есть в исходниках. А такие контрибьютеры в технологию KMM, как российская компания IceRock, его уже даже попробовали. Один из главных контрибьютеров в Kotlin Multiplatform — Touchlab, которые создают довольно много вспомогательных решений, тех же воркэраундов, уже не просто опробовали Compose под iOS, но и показали примерное приложение на droidcon London 2022. Докладчик и эксперт Алексей Гладков публиковал у себя в Telegram-канале скриншот, на котором видно, под какие таргеты будет идти Compose.
Так что вполне возможно, что мы хотя бы в альфа-версии сможем попробовать мультиплатформенный Compose не только для десктопа, но и для Kotlin Multiplatform. Может появиться возможность привязываться с минимальными различиями в реализации к таргетам, как это сейчас сделали в IceRock и Touchlab.
В целом это довольно интересное решение, но возникает много вопросов, насколько оно будет конкурентоспособным по сравнению с тем же SwiftUI. Хотя, учитывая некоторые серьезные сложности в реализации, те же проблемы с навигацией под SwiftUI, это вполне резонный вопрос: сможет ли Compose для iOS потеснить SwiftUI при реализации UI в мультиплатформенной разработке, и станет ли этот вариант удобнее.
Все мы ждем финализации Kotlin Multiplatform и улучшения работы с garbage-коллекторами. Уже сейчас исправлено большинство проблем с памятью и ее очисткой в разных потоках. Важным показателем интересности Kotlin Multiplatform является то, что Google представили портированные под нее версии своих библиотек Jetpack. Это доказывает, что на данную технологию идет большая ставка, и что она будет перспективна в дальнейшем.
Резюмируем, что мы ждем в рамках развития KMM: Compose для iOS и конкурентоспособность с SwiftUI, доработки и улучшения работы с Kotlin под разные платформы.
Twitter: @noraltavir
Из того, что ждут и что вполне может появиться, но никаких гарантий нет:
Также совершенно нельзя исключать появление Compose Multiplatform на IoS стараниями комьюнити. Это сделает Kotlin полным конкурентом Dart/Flutter.
В целом у Kotlin сейчас фаза планомерного роста и накопления библиотек. По сути там все уже есть, люди допиливают фичи и шлифуют. Быстро развиваются Compose Desktop и Compose Multiplatform.
Читайте также: 50 лучших фильмов и сериалов о технологиях
Twitter: @gaxeliy.
Мои ожидания распределены по нескольким направлениям:
Компилятор станет умнее. Правильная программа будет реже им браковаться, из сообщения об ошибке будет чаще понятно, в чем именно дело. Скорее всего, будет применяться больше клевых оптимизаций.
Возможности языка прокачаются. Я очень жду, когда константные дженерики научатся работать с алгебраическими типами данных. Появится возможность использовать дженерики в более сложных контекстах. Улучшится поддержка асинхронности всюду (типа асинхронных трейтов). Еще очень жду генераторов.
Экосистема. Я рассчитываю на улучшенные возможности использовать Rust на мобильных операционных системах. Сейчас уже можно делать бинарники, которые работают под Android и iOS, но статус библиотек для создания интерфейса мобильных приложений оставляет желать лучшего.
Жду нативной работы с DOM в WASM в Yew и других фронтенд-фреймворках. Эх, заживем!
Twitter: @int_index
Ждем новый релиз компилятора — GHC 9.6. Это будет первый релиз, где сообщениям об ошибках назначаются уникальные коды, по которым их можно искать. Эти коды планируется собрать в единую базу данных, там будет подробно описано, где и при каких обстоятельствах эти ошибки возникают.
Второе интересное изменение — это поддержка delimited continuations (GHC Proposal #313). На их основе можно делать более производительные библиотеки для управления эффектами. Также в новой версии компилятора реализовано расширение TypeData (GHC Proposal #106) и улучшены OverloadedLabels (GHC Proposal #170).
Наблюдается видимый прогресс по добавлению поддержки для запуска Haskell прямо в браузере — через компиляцию в WebAssembly и JavaScript. Вообще, такая возможность была уже давно благодаря ghcjs, но это был отдельный проект. Теперь это будет интегрировано в сам GHC и более активно улучшаться.
Читайте также: Haskell — язык, позволяющий глубже понять программирование. Как он устроен и почему его выбирают разработчики?
Касательно направления развития, продолжаем добавлять зависимые типы в язык. Это направление развития было утверждено с принятием GHC Proposal #378 "Design for Dependent Types". Но реализовываться оно будет, естественно, по частям. Работы там — непаханое поле, что-то будет реализовано в следующем году. Я сам активно занимаюсь добавлением новых механизмов явного и неявного ввода типовых переменных (см. также GHC Proposal #281, GHC Proposal #425).
Автор Telegram-канала mefody.dev, в Twitter — @dark_mefody
Год назад я бы мало мог что сказать: веб развивался медленно, новые возможности появлялись редко, до вечнозеленых браузеров доезжали неспешно. Сейчас же — как будто кто-то открыл кофейню с эспрессо прямо посреди W3C.
Я с большим интересом наблюдаю за проектом Interop, в рамках которого самые популярные браузеры делают так, чтобы спецификации в них работали одинаково и хорошо. 2021-2022 годы показали, что это очень успешная инициатива. Посмотрим, какие цели выберут на 2023 год. Посмотреть предложения можно здесь.
В CSS в 2023 году, скорее всего, будет доработка и дотаскивание до браузеров спецификаций Container Queries, CSS Layouts, CSS Nesting. Чего-то революционного не жду, потому что эти спецификации сами по себе очень сильно меняют привычные нам подходы к разработке, и в них еще много чего нужно доделать. Этим браузеры, скорее всего, и будут заниматься. Интересно, что Safari, как бы на него ни ругались, в этом соревновании лидирует по тестам веб-платформы.
Верстальщикам все чаще будут приходить запросы на верстку для складываемых устройств. Если сейчас мы вынуждены поддерживать бровки и монобровки от устройств Apple, то Microsoft целится в складываемые устройства, а там тоже есть своя специфика верстки.
В EcmaScript вряд ли произойдет что-то неординарное. У TC39, который принимает новые спецификации, все расписано на годы вперед. Жду Temporal, который однозначно изменит наши подходы к работе со временем и таймзонами. Но у него уже сейчас есть полифил, который можно брать и подключать.
Кажется, внезапно нас может удивить HTML и JS для новых DOM-элементов или хорошо забытых старых. Есть такая инициатива Open UI, внутри которой прорабатываются элементы на странице. У них уже есть довольно интересное решение, как стилизовать
Про фреймворки сложно что-то сказать. Чаще всего они появляются внезапно, наводят шуму, а потом комьюнити разбирается, действительно ли этот фреймворк хорош. С интересом наблюдаю за релизами Next.js, в которых есть поддержка серверных компонентов из React 18. Это то, что, наверное, ускорит большое число сайтов и не меньше сломает, потому что многие разработчики просто включат свежее решение в проде, не сильно замеряя эффект. Но подход интересный и правильный, с учетом тренда на производительность.
В Twitter — @neesoglasnaja. Спикер и организатор митапов по фронтенду MinskCSS и MinskJS и конференции FrontendConf. Амбассадор Women Techmakers.
Веб движется к нативности. В мобильных и десктопных браузерах появляются функции, которые раньше были только в нативных приложениях. Современные браузеры не только активно внедряют новые спецификации HTML, CSS и JavaScript, но и расширяют возможности своей платформы.
Из интересного — недавно узнала, что есть черновик спецификаций, чтобы делать нейронную сеть в браузере, и делать это без использования сторонних библиотек. Да, нейронки на JavaScript можно писать давно, используя, например,
TensorFlow.js. А вот иметь встроенное в браузер API, которое будет решать похожие задачи — это что-то совершенно новое и крутое. С точки зрения безопасности это хорошо: не нужно загружать данные на сервер, есть возможность работать локально в браузере, ведь пользователи не отправляют по сети свои данные. Интересная инициатива, но не знаю, насколько она реально применима на многих проектах.
В Chrome есть API, уже сейчас работающее на Android, с помощью которого вы можете дать доступ к своим контактам. Буквально поделиться данными со своего телефона, которые раньше были только для мобильных приложений.
Или посмотрим на возможность распознавания QR-кодов, используя камеру в браузере. Я помню время, когда на моем телефоне нужно было отдельно устанавливать специальное приложение, чтобы у него появилась такая функция. А в 2022 году можно встраивать такое распознавание прямо в веб-приложения для курьеров и мерчендайзеров, интернет-магазины с доставкой и выдачей товаров, потому что браузер уже умеет это делать.
Есть и обратная сторона у развития этого направления. Большинство таких API поднимают вопрос о безопасности и предоставлении доступа к данным пользователя. Безопасность в вебе была и остается важной темой. Никто не будет внедрять спецификацию, которая облегчит злоумышленникам работу. Также в какой-то мере рост количества внедренных API сдерживается вендорами, имеющими магазины нативных приложений. Им не выгодно, что их приложения можно заменить на страничку в Интернете, которая открывается в любом браузере.
Что ждет веб как платформу в 2023 году? Веб продолжит расти и расширяться, будут предлагаться и внедряться новые спецификации и браузерные API. Возможно, в будущем мы навсегда откажемся от мобильных приложений и все будем делать через браузер. Хотя пока об этом говорить рано.
В Twitter — @gskobelevff. Организовал книжный клуб для бэкенд-разработчиков { между скобок }.
В 2023 году в Java мы ждем релиз новой lts-версии. Предыдущая 17-я версия релизилась в прошлом году. А так как Oracle перешли на полугодичный релизный цикл, то следующей 21-й будет lts-версия. Какие фичи в ней будут, — большой секрет. Мы можем это предположить на основании того, что имеем в текущей версии, и как это продолжает развиваться.
В Java 17 появилась такая крутая фича, как record. Теперь не нужно писать большие классы с конструктором, геттером и сеттером — все уже реализовано с помощью конструкции record. Это невероятно удобно, и, как мы видим по 19-й версии Java, record перетекают в Instanceof, pattern matching. Я думаю, это будет что-то связанное с укреплением и улучшением record.
Еще одна крутая фича, которая появилась в Java 17, закрепилась и, скорее всего, получит какие-то интересные обновления, — например, текст-блоки. Раньше надо было писать большие текстовые конструкции в Java с помощью конкатенации строк, но теперь это ушло в прошлое. Теперь можно, просто использовать три открывающих и закрывающих кавычки, а внутри них писать прикольный большой текст-блок. На самом деле эта фича есть в большинстве языков программирования, она позволяет добавлять внутрь аргументы. Мне кажется, это будет невероятно круто.
В Java 17 активно развивается ещё одна фича — это switch. Непосредственно switch expression, и pattern matching с ним. Switch case существовал с самого начала существования языка, это было невероятно неудобно, но он круто преобразился в Java 17. Видно, что разработчики поняли, что нужно идти в сторону развития и упрощения конструкций, которые часто используют. Они получат улучшения: в pattern matching добавят рекорды, думаю, что в switch expression тоже.
Говоря про Java, нужно упомянуть Spring — фреймворк, без которого мы не можем сейчас представить свою работу. Произошло ключевое событие — недавно зарелизилась третья версия Spring и, скорее всего, следующий год будет посвящен обкатке и модификации.
Читайте также: Гриша Скобелев: Как книжный клуб для разработчиков помог мне справляться со злостью и стал приносить пользу людям
Что будет меняться? Во-первых, они сделали большой упор на Spring Native. Это возможность делать ahead of time компиляцию наших приложений. Вечный спор, какая компиляция лучше и быстрее, какие приложения быстрее: те, которые работают just in time или ahead of time. И Spring Native собирается выйти на поле ahead of time. Будет очень интересно.
Также обещали добавить spring modules, это очень важная фича. Все хотят потрогать ее руками, потому что пока не совсем понятно, как она будет работать. Модули появились в Java 9, но ей никто не пользуется, потому что это не имеет практического смысла. Контрибьютеры собираются переизобрести эту идею и сделать так, чтобы все начали использовать модули для проектов, чтобы улучшать их последующую модификацию и заменять одни модули на другие.
Хочется сказать и про сторонние проекты. Например, один из горячо ожидаемых всеми — это Project Loom, виртуальные треды. Обещают, что он зарелизится 2023 году. Многие сейчас перешли с Java на Kotlin из-за корутин, которые называли киллер-фичей. Ребята из Java сделали выводы: постарались взять все самое лучшее из Kotlin корутин и Go корутин и сделать из этого Project Loom с виртуальными тредами.
Следующий год обещает быть жарким. Выйдет Project Loom, лтс-ная версия Java 21, и мы увидим, насколько популярен новый релиз Spring.
Начну со SwiftUI: этой осенью они наконец зарелизили нативную навигацию, которая всегда была проблемной и с этим ничего не делали долгие годы. На WWDC22 продемонстрировали решение, которое стало доступным из коробки с выходом версии iOS 16. И откровенно говоря, во многом базируется на том, что предлагали энтузиасты от разработки.
На тему как можно побороть проблемы с нативной навигацией в SwiftUI, было много докладов и статей последние несколько лет. Разработчики технологии Apple сделали прототипы для WWDC19, но как будто по каким-то причинам не продумали, как это развивать: то ли кто-то из команды ушел, то ли не знают как переделать. Так и приходилось разработчикам-пользователям SwiftUI выкручиваться с помощью собственных workaround. А в этом году разработчики Apple представили свое нативное решение на базе workaround, но снова с недоделками. То, что по идее должны были сделать по умолчанию и под капотом, сделали конфигурируемым в формате конструктора из отдельных кубиков, которые можно сложить так, как нужно.
И по-прежнему, чтобы эта конструкция работала хорошо, нужны собственные наработки. Так что пока это довольно сырое решение. Хотя оно помогает ощутимо упростить проблемы, которые были — ту же утечку памяти или возврат на несколько уровней назад, Теперь же ждем доработанную версию.
В самом языке Swift мы ожидаем улучшения работы с functional builders и DSL, а еще возможности для работы с различными дженериками, ассоциированными типами (работают как дженерики, но для протоколов), что в итоге позволит оптимизировать код и SwiftUI.
Также планируется улучшение работы компиляторов в плане работы памяти. Ходят слухи, что будут дорабатывать SwiftPackage Manager, собственный менеджер по распространению зависимостей от Apple.
Разработчики языка сейчас идут по пути оптимизации и улучшению перформанса уже существующих технологий. Например, планируются улучшения и твики работы с памятью, направленные на устранение утечек, доработки и новые возможности как использовать Weak Self.
Новое есть и в работе с регулярными выражениями. На прошлом WWDC была представлена структурированная многопоточность async/await, в этом году продолжили развивать данную технологию, помимо различных примеров использования представили distibuted actors (WWDC). Так что я ожидаю дальнейших доработок async/await и акторов. И, возможно, на базе тех же самых акторов и памяти могут быть доработки, связанные с сетевым взаимодействием, сетевыми библиотеками, которые можно будет использовать в дальнейшей работе.
Так же я надеюсь, что разработчики улучшат работу с памятью в async/await. Может быть, добавят дополнительные типы задач, функционал и упростят реализацию. Тем более в этой версии они ориентируются на корутины, а корутины тоже сейчас развиваются.
Все эти новшества направлены на оптимизацию кода, чтобы он становился элегантнее и красивее. Все эти фичи (те же дженерики), упрощают решение задач в общем виде, реализацию алгоритмов в коде, который потом легче расширять и поддерживать. Это позволяет строить связи между объектами и компонентами по-новому и упрощать построение архитектуры компонентов. Если говорить про перформанс памяти, устранение утечек, ускорение компиляции и выполнения задач, то это всегда в плюс. Доработки в стиле DSL функциональных билдеров — то, что улучшит возможности реализации SwiftUI компонентов и позволит реализовывать интересные решения.
Также полезно: Язык программирования Go почему все его любят и что на нем можно писать
Нативная разработка остается в тренде, а крутые фича типа async/await увеличивают ее популярность и привлекательность. Но несмотря на то, что большинство продолжит делать свои продакшн проект на классическом стеке, DSL декларативные фреймворки вырываются впереди. Это будет до тех пор пока Compose для Android и SwiftUI для iOS не станут настолько удобными в работе, чтобы их можно было применять на сложных проектах. Тем не менее многие продолжают вкатываться в эту технологию и рассматривают ее внедрение для своих проектов, по крайней мере точечно.
Compose для Android — это то, во что нужно вкладываться. iOS-разработчикам желательно затронуть SwiftUI и посмотреть на новые технологии. Кстати, ходят слухи про Compose для iOS. Тем, кто хочет прокачаться в нативном стэке, обязательно нужно обратить внимания на новинки iOS SDK, чтобы не терять компетенций Например, имеет смысл перейти в проектах на тот же async/await как более эффективное и удобное решение работы с многопоточностью
Судя по тому, какие технологии Apple демонстрировали на WWDC, у них идет большая ставка на различные встроенные решения по машинному обучению, работе с графикой, анимацией, звуком и камерой. Также они выпускают новые гайды и документацию по работе со своими библиотеками. Не всегда эти рецепты полезны и содержательны. Например, в видео туториале по работе с навигацией просто рассказали, какие панельки для чего, как называть кнопки и т.п. Но в целом, это показывает, что они сейчас нацелены на переработку и оптимизацию своей документации. Вот мой доклад об этом.
У таких гайдов и видеообзоров WWDC следующий посыл: мы уже все сделали, вы просто не поняли нашу идею, делайте так, как сказали мы. А насколько это удобно — другой вопрос. Для них проще объяснить, что люди не поняли их замысел, и не важно, что этот замысел не применим к продакшену.
2023 год обещает быть интересным для сферы разработки. Больше всего изменений ждет языки Python, Go и Java. При этом разработчики языков продолжат курс на стабильность и борьбу с легаси. У Haskell и Rust выйдут новые релизы компиляторов, а разработчики на Kotlin с нетерпением ждут релиза Compose под iOS.