К чему готовиться разработчикам: как изменятся технологии и языки программирования в 2023 году
2026-02-26 19:54 Diff
https://ru.hexlet.io/blog/posts/k-chemu-gotovitsya-razrabotchikam

Мы узнали у экспертов по современным языкам программирования, что будет с их любимыми языками в 2023 году. Удалось собрать интересные инсайды и прогнозы про Python, Go, Haskell, Rust, Java, Swift, Kotlin и веб-разработку. Заодно обсудили, как программистам подготовиться к этим изменениям.

Содержание

Python: новая версия языка 3.12 и PEP 649

Никита — т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 лет.

Go: параметризованные типы и поддержка profile guided optimization

Эмиль в Twitter

Знаковым событием для Go в 2022 году было добавление параметризованных типов. Так разработчики языка попытались удовлетворить давно уже ставшую мемом потребность сообщества в дженериках. Однако с момента выхода версии языка 1.18 прошло более восьми месяцев, а повсеместного использования дженериков в библиотеках и пользовательском коде так и нет. Причина — невозможность использовать параметризованные типы в функциях с ресивером, то есть в методах структур. Такое решение не сильно устроило сообщество языка и сейчас активно обсуждается поддержка обобщенного программирования методами. Эта фича — наиболее ожидаемая в 2023 году.

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

Из наиболее интересных планов на релиз Go 1.20 можно отметить планы на поддержку profile guided optimization. Речь про возможности компилятора, который может оптимизировать наиболее нагруженные участки кода с помощью профиля, собранного с уже работающей в проде системы. Другое важное изменение — улучшение утилиты, которая используется для анализа покрытия кода тестами. С этим улучшением появится возможность видеть покрытие кода в модулях, отличных от модуля, в котором находится тест.

Все эти нововведения позволят пользователям эффективнее использовать Go в продакшен-системах и увеличат его надежность, ведь основная ниша для языка — написание надежных и быстрых сетевых сервисов. Не стоит ожидать, что в предстоящем году что-то кардинально изменится. Ежедневно в языке появляются новые библиотеки и фреймворки, которые, например, позволяют добавлять GUI, писать игры и даже мобильные приложения. Однако вряд ли Go внезапно превратится в лучший язык для настольных приложений или пошатнет C++ в сфере разработки игр.

Резюмируя вышесказанное: у Go есть своя ниша (например, на этом языке написан Kubernetes), поэтому популярность языка продолжит расти. Этому способствует как непрерывное улучшение языка и его экосистемы, так и его простота. В 2023 году стоит ждать планомерного роста количества проектов на Go и количества вакансий на нем.

Kotlin: Kotlin Multiplatform и Compose под iOS

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

Из того, что ждут и что вполне может появиться, но никаких гарантий нет:

  • Kotlin/Wasm — компилятор для Wasm и по сути веб-фронтенд без JS. Серьезный шаг, потому что это первый высокоуровневый mainstream-язык для Wasm, который будет работать с GC. Не говоря о том, что это система мультиплатформенных библиотек, которые уже существуют и могут быть там использованы.
  • Стабильное API компиляторных плагинов. Возможность радикально увеличить гибкость языка при помощи манипуляций с исходным кодом.
  • Стабилизация контекстных ресиверов и обобщение их на все платформы.
  • Юнион-типы.

Также совершенно нельзя исключать появление Compose Multiplatform на IoS стараниями комьюнити. Это сделает Kotlin полным конкурентом Dart/Flutter.

В целом у Kotlin сейчас фаза планомерного роста и накопления библиотек. По сути там все уже есть, люди допиливают фичи и шлифуют. Быстро развиваются Compose Desktop и Compose Multiplatform.

Читайте также:

50 лучших фильмов и сериалов о технологиях

Rust: новые возможности для дженериков, работа с мобильными ОС

Twitter: @gaxeliy.

Мои ожидания распределены по нескольким направлениям:

  1. Компилятор станет умнее. Правильная программа будет реже им браковаться, из сообщения об ошибке будет чаще понятно, в чем именно дело. Скорее всего, будет применяться больше клевых оптимизаций.

  2. Возможности языка прокачаются. Я очень жду, когда константные дженерики научатся работать с алгебраическими типами данных. Появится возможность использовать дженерики в более сложных контекстах. Улучшится поддержка асинхронности всюду (типа асинхронных трейтов). Еще очень жду генераторов.

  3. Экосистема. Я рассчитываю на улучшенные возможности использовать Rust на мобильных операционных системах. Сейчас уже можно делать бинарники, которые работают под Android и iOS, но статус библиотек для создания интерфейса мобильных приложений оставляет желать лучшего.

Жду нативной работы с DOM в WASM в Yew и других фронтенд-фреймворках. Эх, заживем!

Haskell: новый релиз компилятора GHC 9.6

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, внутри которой прорабатываются элементы на странице. У них уже есть довольно интересное решение, как стилизовать