Dev48
ЯЗЫК
  • О нас
  • Услуги
  • Индустрии
  • Технологии
  • Статьи
  • Контакты
Забронировать звонок
    Главная/Статьи/Rezultaty oprosa oglaske otladchikah rust za 2026 god
Dev48

© 2026 · All rights reserved.

Результаты опроса огласке отладчиках Rust за 2026 год

Источник: Rust

Результаты опроса огласке отладчиках Rust за 2026 год

Источник: Rust

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

27 сентября 2026 г.•Обновлено: 27 сентября 2026 г.

Одной из главных проблем, о которых разработчики Rust сообщают в наших ежегодных опросах, является неудовлетворительный опыт отладки. Поэтому еще в феврале мы провели наш первый опрос по отладке в Rust в надежде выяснить, как разработчики Rust используют отладчики и с какими проблемами они при этом сталкиваются. Мы получили более 2 300 ответов и хотели бы поблагодарить всех, кто уделил время участию в опросе!

В этом отчете мы рассмотрим некоторые результаты опроса. Если хотите, вы также можете ознакомиться с полными результатами опроса.

Если вы хотите сразу перейти к какому-то конкретному разделу, воспользуйтесь этим оглавлением:

  • Кто использует отладчики?
  • Как используются отладчики?
  • Сложности
  • Визуализаторы отладчика
  • Заключение

Кто использует отладчики?

Первый шаг к пониманию результатов опроса — разобраться, кто именно в нем участвовал. Мы попросили респондентов оценить свой уровень владения Rust: от «Никогда не использовал» до «Продвинутый». Более 80% охарактеризовали себя как «Продвинутый» или «Средний», разделившись примерно поровну между этими двумя категориями:

Мы также спросили респондентов, используют ли они или использовали ли когда-либо отладчики в Rust. Более 46% ответили, что используют в настоящее время, а остальные ответы разделились между «использовали в прошлом» и «никогда не использовали». Это означает, что более половины респондентов в настоящее время не используют отладчик для Rust!

Если классифицировать ответы по уровню квалификации, то окажется, что примерно половина «новичков» никогда не пользовалась отладчиками в Rust! С другой стороны, почти половина «продвинутых пользователей» в настоящее время действительно использует отладчики в Rust:

У тех респондентов, которые указали, что ранее использовали Rust, но больше не делают этого, мы спросили, стали ли проблемы с поддержкой отладки причиной отказа. Почти для 3% ответом было «да», а еще 24% назвали проблемы с отладкой частично ответственными за это (хотя стоит учитывать небольшое количество ответов: большинство респондентов были активными пользователями Rust):

Как используются отладчики?

Понимание того, какие отладчики используют разработчики и каким образом, — еще одна важная часть осмысления стоящих перед ними проблем. С этой целью мы спросили респондентов, как именно они отлаживают свои программы. Неудивительно, что большинство разработчиков используют отладку с помощью вывода печатью (print) и макрос dbg!. Исключая их, использование lldb внутри IDE было самым популярным выбором, за которым следовал gdb в командной строке:

Мы можем получить более детальную разбивку этих результатов, если учтем операционную систему, в которой респонденты используют тот или иной подход к отладке. Мы рассматриваем это с двух разных точек зрения. Первая точка зрения: «На какой операционной системе X какой процент респондентов использует отладчик Y?». Отладка с помощью вывода и макрос dbg! снова неизменно занимают первые два места, но если заглянуть дальше, становится интереснее. В Linux использование gdb в командной строке оказалось самым популярным выбором с небольшим отрывом, опередив lldb в IDE всего на 0.4%. В Windows, Windows Subsystem for Linux (WSL) и macOS лидером с отрывом как минимум в 6% стал lldb в IDE, что делает его очень популярным выбором в целом. В Windows тремя наименее популярными вариантами стали отладчики командной строки (gdb CLI, lldb CLI и BugStalker), а как в Windows, так и в macOS третьим по популярности ответом был «Я не знаю». Те, кто отлаживал на неперечисленных операционных системах (Другое), чаще всего использовали какой-то специальный встроенный отладчик или gdb:

Другой ракурс, с которого мы можем посмотреть на эти ответы: «Для пользователей отладчика X какой процент респондентов использует его в операционной системе Y?». Для большинства отладчиков Linux составляет наибольшую долю использования — от примерно 45% до примерно 77%, за ним следуют Windows, а затем macOS. Самыми заметными исключениями являются WinDbg и отладчик Visual Studio, которые в основном используются на Windows, а также lldb, который на macOS используется чаще, чем на Windows — как в IDE, так и в командной строке:

6 респондентам, использующим WinDbg в Linux: желаем удачи!

Что касается того, как люди фактически используют выбранный ими отладчик, совокупные результаты не слишком удивительны. Примерно 87% пользователей используют отладчики для пошагового выполнения программ строка за строкой, и чуть более половины пользователей используют отладчики для получения трассировок стека (stack traces) зависших или аварийно завершившихся процессов. Только четверть респондентов используют отладчик для отладки асинхронного кода. Отчасти это может быть связано с тем, что процесс отладки асинхронного кода в Rust неуклюж и неполен, а может быть, пользователи просто пишут не так много асинхронного кода:

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

Последнее представление о том, как «растовцы» (Rustaceans) используют отладчики, касается того, отлаживают ли они программы, в которых Rust сочетается с другими языками программирования. Для 44% респондентов ответом было «да», и это довольно высокий показатель!

Что касается того, что это за языки, то здесь доминирует C с результатом чуть более 70%, за ним следует C++ с примерно 43% и Python с примерно 20%:

Сложности

Вместо того чтобы сразу переходить к вопросу «с какими проблемами вы сталкиваетесь при использовании отладчиков?» или чему-то подобному, мы сначала спросили респондентов, почему они вообще решают не использовать отладчики, когда они это делают, включая причины, которые не обязательно являются «проблемами с отладчиками».

Наиболее часто упоминаемой причиной стало то, что для решения проблем проще или быстрее использовать логи или отладку выводами, о чем сообщили чуть более 81% респондентов. Отчасти это можно объяснить открытыми ответами, в которых содержались жалобы на то, что отладчики слишком сложно настраивать и/или использовать (особенно в Windows, при работе с WebAssembly или в контексте встраиваемых систем), а также мнение о том, что мелкие и/или простые проблемы на самом деле просто не нуждаются в отладчике. Это заставляет задуматься о том, можно ли сделать пользовательский опыт достаточно удобным, чтобы свергнуть отладку выводами, но перебить столь интуитивный подход, судя по всему, сложно. Далее следуют примерно 37% респондентов, которые пишут код, который «Просто Работает» (Just Works). Вполне справедливо. После этого около 26% респондентов указали, что решили не использовать отладчики в ситуациях, когда языковые функции, с которыми они работали, имели слабую поддержку. Это чуть больше, чем проблемы с типами стандартной библиотеки (около 22%), что, в свою очередь, чуть больше, чем проблемы с типами внешних библиотек (около 20%):

Поскольку предполагалось, что пошаговое выполнение кода станет одним из самых распространенных вариантов использования отладчиков, мы напрямую спросили респондентов, сталкивались ли они с какими-либо проблемами при этом. Чуть более 51% респондентов ответили утвердительно! У тех, кто сообщил о проблемах с пошаговым выполнением кода, мы поинтересовались, в каких именно случаях они возникали. Асинхронный код оказался наиболее частым случаем, о котором сообщили чуть более 28% респондентов, за ним следует код с использованием макросов — около 23%. Наименее распространенным случаем был код с указателями на функции, о котором сообщили почти 6%:

Мы также напрямую спрашивали респондентов, с какими типами из стандартной библиотеки было сложно работать (если таковые были). Это был вопрос в свободной форме, и, судя по ответам, особенно частые жалобы касались перечислений и коллекций, в частности std::collections::HashMap и std::vec::Vec. Это также заметно на облаке тегов в полном отчете.

Мы попросили респондентов указать, с какими трудностями они сталкивались при использовании отладчиков в Rust (если таковые были). Чуть более 74% отметили плохой вывод значений в качестве самой распространенной проблемы с большим отрывом, за ней следует невозможность вывести переменные — чуть более 55%:

Визуализаторы для отладчиков

Мы попросили респондентов указать, являются ли они авторами библиотек, и если да, то знают ли они об атрибуте debugger_visualizer и используют ли его. Почти 62% респондентов указали, что они являются авторами библиотек, которые не знают об этом атрибуте:

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

Для тех из вас, кто читал этот раздел и задавался вопросом, что такое атрибут debugger_visualizer, вы можете прочитать о нем в The Rust Reference: Debugger Attributes. Краткое объяснение заключается в том, что атрибут debugger_visualizer может применяться к модулям или корню крейта для внедрения файлов в отладочную информацию, которые улучшают отображение значений в определенных отладчиках. В настоящее время поддерживаются два типа файлов: файлы Natvis, используемые отладчиками Microsoft, такими как WinDbg, и «красивые выводчики» (pretty printers) для GDB, которые представляют собой структурированные скрипты на Python, используемые GDB.

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

Заглядывая в будущее, результаты опроса показали, что есть несколько заметных способов существенно улучшить отладку в Rust, таких как:

  • Исправление способа представления перечислений в отладчиках, чтобы они показывали актуальные варианты
  • Исправление способа представления коллекций (таких как HashMap) в отладчиках, чтобы они показывали свое содержимое, а не детали реализации
  • Исправление способа представления типов строк (таких как String и CString) в отладчиках, чтобы они отображались как текст, а не как детали реализации
  • Улучшение отладки асинхронного кода, особенно в части трассировки стека
  • Улучшение пошагового выполнения определенных конечных автоматов (таких как итераторы и Futures)
  • Предоставление документации по базовой настройке и использованию некоторых распространенных отладчиков

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

Одним из заметных способов улучшения работы с отладчиком в настоящее время является проходящий в рамках Google Summer of Code проект, улучшающий тестирование отладочной информации и скриптов визуализаторов, что упрощает поддержку и улучшение наших собственных скриптов визуализаторов и общую совместимость с ними без незаметных поломок или регрессий.

Еще раз хотим поблагодарить всех, кто уделил время участию в опросе!

← Все статьи

Ещё в разделе «Разработка ПО»

Все →
Обзор Sennheiser Momentum 5: великолепный звук, невероятное время автономной работы и минимум компромиссовПресса
Momentum

Обзор Sennheiser Momentum 5: великолепный звук, невероятное время автономной работы и минимум компромиссов

Boeing сообщает о программном сбое в 737 Max, затрагивающем некоторые функции автоматического захода на посадкуПресса
Boeing

Boeing сообщает о программном сбое в 737 Max, затрагивающем некоторые функции автоматического захода на посадку

Apple обязали выплатить 5,7 млрд долларов по иску о нарушении патентных прав на тактильные технологии в iPhone и Apple Watch
Пресса
Apple

Apple обязали выплатить 5,7 млрд долларов по иску о нарушении патентных прав на тактильные технологии в iPhone и Apple Watch

Компании выбирают САПР от PTC для разработки и проектирования продуктов
PTC

Компании выбирают САПР от PTC для разработки и проектирования продуктов

Clas Ohlson выбирает PTC FlexPLM для поддержки своей стратегии роста
PTC

Clas Ohlson выбирает PTC FlexPLM для поддержки своей стратегии роста

Canon ITS и PTC Japan запускают «Smart PLM Support Service» для поддержки трансформации рабочих процессов в сфере производства
PTC

Canon ITS и PTC Japan запускают «Smart PLM Support Service» для поддержки трансформации рабочих процессов в сфере производства

Ещё от Rust

Представление штатного сопровождающего: Скотт Шефер для команды Cargo
Rust

Представление штатного сопровождающего: Скотт Шефер для команды Cargo

GitHub Actions раскрывают секреты при кэшировании вывода Miri
Rust

GitHub Actions раскрывают секреты при кэшировании вывода Miri

Be alert: targeted attacks on prominent Rustaceans
Rust

Be alert: targeted attacks on prominent Rustaceans

Анонс Rust 1.98.1
Rust

Анонс Rust 1.98.1