Программирование *

AsmX G3 v30.0.0-rev1.0 — крупное архитектурное обновление, которое делает ассемблер не «инструментом 90-х», а полноценным современным языком системного программирования. Главные изменения: пакетная сборка --multiboot с Supervisor, атомарная очистка --multiclean, поддержка изменяемых данных (.data), новые ISA-инструкции (включая inc/dec и movsxd) и выразительный синтаксис функций с экспериментальной поддержкой возвращаемых типов.

Одной командой теперь можно собрать загрузчик, ядро, модуль ядра и динамическую библиотеку — и Supervisor гарантирует консистентность и изолированность ошибок в подзадачах. Для разработчиков это означает: CI в 3–5 строк вместо громоздких Makefile, меньше рутины и полная управляемость сборки.

Языковые улучшения (честные строки, @syscall, @fn share, @fn static, полноценная .data) переводят AsmX G3 в категорию «язык для реальных проектов»: библиотеки .so, production-модули .ko и микро-ОС — всё это теперь удобно писать, собирать и отлаживать на чистом ассемблере.

Если вы работаете с ядром, драйверами или пишете рантаймы, v30 — релиз, который стоит испытать прямо сейчас: меньше хака, больше гарантий, полный контроль над железом — и при этом современный синтаксис.

На сегодняшний день трансформеры правят балом хайпа в мире машинного обучения, особенно после появления ChatGPT и ему подобных языковых моделей. Это стало возможным благодаря лежащему в основе их архитектуры механизму внимания (attention), однако он же и является слабым местом с точки зрения производительности и потребления памяти. Хотя в связи с этим и была разработана изящная концепция Flash Attention (Tri Dao), её существующие реализации имеют ряд ограничений.

Поэтому представляю вашему вниманию первую и единственную open-source реализацию Flash Attention 2 на Triton с поддержкой Linux и Windows, Turing-Blackwell архитектур (теперь можно работать в Google Colab и Kaggle), гомо и гетерогенных кластеров, опциональным детерминизмом, а также возможностью ручной кастомизации ядер (kernels) для более гибкой настройки под каждую GPU архитектуру отдельно. Более подробно о том как это устроено и не только — далее в статье.

Привет, Хабр!

Многим кажется, что await работает только с Task и ValueTask, но на самом деле язык позволяет сделать любой объект ожидаемым — нужно лишь реализовать определённый паттерн.

Итак, зачем нужен свой await? Бывают случаи, когда вам хочется написать асинхронный метод, но результат приходит не из готового Task или таймера. Например, ждёте какое-то событие, изменение файла, считывание из сокета, или просто хотите встроить задержку без запуска Task. Когда вы пишете await expr, компилятор в глубине понимает так: берётся результат expr.GetAwaiter(), затем вызывается awaiter.IsCompleted. Если false, он подписывается на awaiter.OnCompleted, когда завершится, и потом берёт awaiter.GetResult().

Команда AI for Devs подготовила перевод резонансного расследования о том, как "приватные" VPN-расширения на самом деле зарабатывают на ваших ИИ-переписках. 8 миллионов пользователей, Featured-бейджи от Google и Microsoft, полный доступ к ChatGPT, Claude и Gemini — и всё это утекает дата-брокерам. История о том, почему обещания безопасности в браузере стоит читать особенно внимательно.

В 2013-м я получил свою первую вакансию джуна. Требования: PHP, MySQL, jQuery. Всё. Я открыл tutorial, за выходные накодил todo-лист, через месяц уже чинил баги в проде.

Вчера смотрел вакансию для джуна. Требования занимали два экрана. Node.js ИЛИ Python ИЛИ Go. React ИЛИ Vue ИЛИ Angular. PostgreSQL + Redis + MongoDB. Docker обязательно. Kubernetes — плюсом. GraphQL знание приветствуется. Плюс микросервисы, CI/CD, облака...

Я посчитал: чтобы формально соответствовать этой вакансии, нужно изучить минимум 15 технологий. На поверхностное изучение каждой — месяц. Итого больше года непрерывной учёбы. Для позиции джуна.

А что сейчас?

Сейчас — это Node.js, Deno, Bun для JavaScript-бэкенда. Go, Rust, Elixir для хайлоад. Python с FastAPI, Django, Flask. Kotlin, Java, Scala для enterprise. Плюс Ruby, PHP (еще жив), C#/.NET... И это только языки и рантаймы. А еще базы: PostgreSQL, MySQL, MongoDB, Redis, Cassandra, ElasticSearch. Очереди: RabbitMQ, Kafka, NATS. Контейнеризация: Docker, Kubernetes, Helm. CI/CD: GitLab, Jenkins, GitHub Actions, CircleCI. Облака: AWS, GCP, Azure.

Бедные джуны. Хотя нет — бедные мы все. Даже опытные разрабы теряются в этом океане, когда делают шаг в сторону. Зоопарк технологий растёт экспоненциально. И вопрос "с чего начать?" и "куда двигаться?" превращается в настоящий паралич выбора.

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

Теперь давайте поговорим про оставшиеся этапы нового рабочего процесса.

Привет, Хабр! Меня зовут Дмитрий Бабаев, я руковожу R&D в GigaCode — это ИИ‑ассистент для разработчиков от Сбера. Сегодня расскажу про очередной этап развития наших кодовых моделей. Недавно мы выпустили новую версию inline‑модели автодополнения кода (code completion). Это первая в мире MoE‑модель, созданная специально для этой задачи, мы полностью разработали и обучили её с нуля.

Доброго времени суток, господа и дамы! Иногда у некоторых людей возникает желание заняться откровенным непотребством в программировании — то, что не несет практической пользы напрямую, но помогает развлечься. И я — не исключение. В этой статье я хочу рассказать вам о лайфхаках, трюках (магических и не очень), алгоритмах на языке C!

Идея написать эту статью зародилась из моего поста, после него я написал статью «Математика, биты, магия и немного ненормального программирования на C», «Фокусы, хаки, магия и прочее ненормальное программирование на C» и «Тёмная сторона Си: трюки, хаки, магия и алгоритмы», которые раскрывали много интересных моментов.

Увидев, что многим понравилась, я решил продолжить, чтобы узнать насколько глубоко кроличья нора!

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

Всех, кто заинтересовался — прошу под кат.

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

Данная статья - это очередной Хабрахак с подведением итогов и получением обратной связи об использовании ИИ-помощников при разработке программного обеспечения с примерами кода и итоговыми выводами о целесообразности использования ИИ в том или ином проекте.

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

В этом посте будут объяснены две стратегии оптимизации WebAssembly, которые не так давно были реализованы в движке V8 и вошли в версию браузера Google Chrome M137. Речь пойдёт о спекулятивном встраивании call_indirect inlining и о поддержке деоптимизации в WebAssembly. В сочетании два этих приёма помогают генерировать более качественный машинный код, так как основаны на допущениях, которые строятся, исходя из обратной связи, поступающей от среды исполнения. Благодаря этому, WebAssembly выполняется быстрее, особенно это касается программ WasmGC. Например, проверив эти приёмы на наборе микробенчмарков, написанных на Dart, видим, что комбинация двух оптимизаций даёт ускорение в среднем более чем на 50%. В более крупных и реалистичных приложениях и на тех бенчмарках, которые рассмотрены ниже, достигается ускорение между 1% и 8%. Деоптимизации — также очень важная составляющая для дальнейшей оптимизации в будущем.

Привет!

Разберём ReadyToRun (R2R) — технологию предкомпиляции в .NET. Многие включают её, надеясь на супер ускорение, а потом удивляются результатам. Посмотрим, как это работает на самом деле и где реально помогает.

ReadyToRun — это AOT-компиляция для .NET. Обычно приложение поставляется в IL-коде, который JIT превращает в машинный код во время выполнения. R2R компилирует код заранее при публикации проекта — в итоговых DLL лежит и IL, и готовые машинные инструкции. При запуске CLR просто берёт нативный код без пауз на компиляцию.

Всем привет! Меня зовут Щепетков Константин, я TechLead бэкенд разработки компании ZeBrains, работаю в роли TeamLead бэкенда на проекте мобильного приложения Бургер Кинг.

Почти год назад мы запустили полную переработку бэкенда: распиливаем монолит на множество сервисов, всё пишем с нуля. Работы много, сроки плотные — классика.

Чтобы ускорить разработку, решил в качестве эксперимента делегировать часть задач ИИ-инструментам. Негативных кейсов поначалу было много, но со временем качество результата заметно выросло.

В статье делюсь, как давать ИИ чёткие задачи, чтобы он писал рабочий код, соответствующий архитектуре, а не выдумки. Рассказываю про workflow, контекст, шаблоны и кодогенерацию — всё, что превращает ИИ из рискованной игрушки в полезный инструмент для бэкенда. В конце статьи будет ссылка на пример подобных практик.

Тут не будет инструкций к конкретным ИИ-иструментам, но при этом поделюсь практическим опытом применения ИИ. Статья будет полезна не только бэкенд‑разработчикам, но и всем, кто хочет использовать ИИ-инструменты осознанно.

Привет, я Павел Таланов из команды Yandex Infrastructure. Вместе с командой мы создаём SourceCraft — платформу для полного цикла разработки IT‑продуктов. Хочу рассказать о прикольной задаче на стыке бэкенда и IDE, которую мы решали, чтобы сделать ещё более удобную навигацию по коду в SourceCraft — когда индексация кода проходит с нужной скоростью, а подсказки и другие фичи навигации всегда готовы к открытию пул‑реквеста.

Расскажу про требования, которые мы выявили для поиска по коду, чуть‑чуть про предметную область, а также о том, какая архитектура индексации у нас в итоге получилась — и почему.

Большие языковые модели часто используют как один большой "мозг": написал промпт, нажал Enter - и сразу запускаешь сгенерированный код. Быстро, удобно и наполненно магией. Такой подход можно называть вайб-коддингом.

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

В этой статье я покажу, как относиться к LLM не как к "герою-одиночке", а как к команде ролей (аналитик, ресерчер, архитектор, разработчик, ревьюер, QA, техписатель, валидатор) и собрать полноценный AI-Driven Development (AIDD) процесс с понятными договорами и quality-гейтами на каждом шаге.

Это практический how-to: от минимальной версии до более строгого процесса с ролями, гейтами и интеграцией с CI. Все примеры - на базе Claude Code, но принципы подхода можно перенести и на другие инструменты (Cursor, Copilot, локальные агенты и т.п.).

Меня зовут Александр, я fullstack разработчик с 20+ годами опыта (php+js+golang и всякое по мелочи). Количество мифов и заблуждений о разработке через ИИ превысило, на мой взгляд, все разумные пределы.

Я хотел бы порассуждать о причинах таких заблуждений.

Типичные заблуждения не-разработчиков звучат так:

Стабильность E2E-тестов: как добиться 100% успешных прогонов ?

Практика, проверенная на реальном проекте.

Флаки-тесты убивают доверие к автоматизации. В этой статье — проверенные подходы, которые помогают превратить нестабильные E2E-прогоны в надёжный инструмент проверки продукта.

Есть у меня один знакомый. Преподаватель. Примерно, раз в месяц принимает экзамены у студентов, с курсов повышения квалификации. Студенты решают задания на компьютерах, а он ходит между ними, вопросы задает и двойки ставит.

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

И настолько эта возня с бумагой его достала, что знакомый решил:
"Хватит это терпеть! Говорят, в соседнем дворе бабушка сама написала себе "ЦИАН" (находясь под воздействием). А я что? Лысый что-ли?!
Вон, даже курсы по вайбкодингу продаются! Напишу сам себе электронную ведомость!
Ведь может же сейчас обычный человек написать любую программу. Ну не будут же врать в Интернете."

Я почти 20 лет пишу код на С++ за деньги, и почти все это время ощущаю неприязнь к инструменту, который позволяет мне безбедно жить. К тому же я занимаюсь системным программированием, а это налагает дополнительные требования к знанию языка.

Я долго не мог выразить вербально, что меня так отталкивает в C++. Однажды из любопытства меня заинтересовал Rust. Я влюбился в него не сразу, сделав не менее 3х подходов к снаряду изучению, пока наконец-то не нащупал интуитивное понимание. С этого момента Rust превратился для меня в эталон инструмента для системного программирования.

Supabase — это краеугольный камень многих low-code и no-code платформ (Lovable — хороший тому пример) и он получил широкое распространение с приходом эпохи vibe-coding. Не просто так - им (супер)легко пользоваться как AI-кодинг агентам, так и углеродным формам жизни.

В некотором смысле он убирает необходимость иметь отдельного девопс / админа / администратора БД. Для стартапа преимущества очевидны: свободного времени и рук почти никогда не бывает. И, если честно, кому вообще хочется этим заниматься? Гораздо приятнее потратить это время более продуктивно - например, на думскроллинг в Twitter.

Команда Python for Devs подготовила перевод статьи о двух новых Rust-базированных анализаторах типов для Python — pyrefly и ty. Оба пока в ранней альфе, но уже демонстрируют впечатляющую скорость, разные подходы к выводу типов и новые возможности.