В теории это возможно, но на практике - тот факт, что делать дебаггинг на дев машине и на продакшен машине ( через трейсинг - даже тулзу свою написал под влиянием redbug-а: https://github.com/liveforeverx/exrun ) и это абсолютно одни и те же тулзы и воркфлоу - т.е. плюс в том, что разницы нет. А на продакшене всё или один процесс остановить нельзя.

Да и необходимости видеть состояния всех тредов - может быть только в настолько ужасном коде, который видимо настолько плохо написан, что его невозможно понять просто при чтении кода. Т.е. Что-то больше, чем трейсинг и IO.inspect, типа pry мне пригождалось только работая с говноговно кодом. Собственно на том проекте и всплывали идеи неоднократно, что было бы круто как в C++ остановить всё и посмотреть состояние всего...

* никакой изкоробочной попытки внятно форматировать вывод,
* команды не имеют внятной семантики, ты каждый раз должен гуглить, чтобы вспомнить, что тебе нужно,
* вывести значение из списка? Привет *arr @ 2
* вызвать код? Привет`cout is not a part of std`
ну и т.п.

я правда не уверен, что ты про отладку крестов

но я всегда мочусь кровью после того, как попользовался iex/ipython и пытаюсь отлаживать что-то с gdb

Хах, крестов избегаю всеми силами :D

Ну это да, есть такое :D

Ну голанг отлаживать гдб ещё больнее

Приведи пример того, что удобно отлаживать гдб?

Ну кроме тех случаев, когда ничего, кроме гдб нет

Я не с++ отлаживал, наверно это ключевое тут :D Плюсы на уровне бинаря это конечно трэш и угар 😂

ну так а что ты отлаживал гдб?

Это был обычный C.

Там все просто и понятно, даже на уровне дизассемблер вывода.

я прям восхищаюсь тобой, что после ipdb/iex — говорить gdb круче

особенно я бы посмотрел, как ты к какому-нибудь запущенному сервису подключаешься и там трапами пытаешь куда-то попасть

Gdb останавливает beam целиком, это менее костыльно чем iex.pry

По сути это единственное чем стоит отлаживать эрланг

Все остальное время можно только трейсить

debugger

О, здорово, надо глянуть.

наконец-то ack