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

Источник: Rust

Результаты опроса об отладке в Rust за 2026 год

Источник: Rust

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

25 сентября 2026 г.

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

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

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

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

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

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

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

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

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

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

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

Мы можем получить более детальную разбивку этих результатов, если учтем операционную систему, в которой респонденты используют тот или иной подход к отладке. Мы рассмотрим это с двух разных точек зрения. Первая точка зрения: «В операционной системе X какой процент респондентов использует отладчик Y?». Отладка выводом на печать и макрос dbg! снова неизменно занимают первые два места, но если заглянуть дальше, становится интереснее. В Linux использование gdb в командной строке оказалось самым популярным выбором с небольшим отрывом, опередив lldb в IDE всего на 0,4%. В Windows, Windows Subsystem for Linux (WSL) и macOS lldb в IDE занял первое место как минимум с 6% отрыва, что делает его очень популярным выбором в целом. В 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% пользователей используют отладчики для построчного выполнения программ, и чуть более половины пользователей используют отладчики для получения трассировки стека из зависших или аварийно завершившихся процессов. Только четверть респондентов используют отладчик для отладки асинхронного кода. Отчасти это может быть связано с тем, что опыт отладки асинхронного кода в Rust неуклюжий и неполный, а может быть, пользователи просто пишут не так много асинхронного кода:

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

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

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

Сложности

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

Наиболее часто упоминаемой причиной было то, что проще или быстрее использовать логи или отладку печатью для решения проблем — об этом заявили чуть более 81% респондентов. Отчасти это можно объяснить ответами в свободной форме, в которых содержались жалобы на то, что отладчики слишком сложно настроить и/или использовать (особенно в Windows, при работе с Web Assembly или в контексте встраиваемых систем), а также мнение о том, что мелкие и/или простые проблемы на самом деле не требуют отладчика. Это заставляет задуматься, можно ли сделать пользовательский опыт достаточно удобным, чтобы свергнуть отладку печатью, но что-то столь интуитивное переплюнуть непросто. За этим следует примерно 37% респондентов, которые пишут код, который просто работает. Что ж, вполне справедливо. После этого около 26% респондентов указали, что решили не использовать отладчики в ситуациях, когда языковые фичи, с которыми они работали, имели плохую поддержку. Это чуть больше, чем проблемы с типами из стандартной библиотеки (около 22%), что, в свою очередь, чуть больше, чем проблемы с типами из внешних библиотек (около 20%):

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

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

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

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

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

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

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

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

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

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

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

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

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

← Все статьи
Dev48

© 2026 · All rights reserved.