Автор статьи — разработчик из экосистемы Zig — жёстко критикует практику отключать ассерты в продакшне. В Zig ассерты основаны на unreachable — языковой фиче, которая помечает недостижимые пути кода. Компилятор использует unreachable для оптимизации: в ReleaseFast он может выкинуть целые ветки switch, если доказал, что они никогда не выполнятся. При этом std.debug.assert — обычная функция (не макрос, как в C/C++), её аргументы всегда вычисляются, даже если сам ассерт не проверяется. В ReleaseSafe и Debug срабатывание ассерта паникует и крашит программу; в ReleaseFast и ReleaseSmall — это «unchecked illegal behavior»: программа просто начинает вести себя непредсказуемо.
Автор выделяет три подхода к ассертам: (1) оставить как рантайм-проверки, (2) использовать для оптимизации, рискуя misbehavior, (3) полностью отключить. Третий вариант он называет «непоправимо плохим». Почему? Отключение ассертов означает, что ложное предположение останется незамеченным — программа продолжит работать, но с неверными данными. Это не менее опасно, чем undefined behavior: SQL-инъекции, например, не требуют UIB. Главная проблема — «газлайтинг»: вы пишете код, полагаясь на ассерт, который никогда не проверяется в проде. Он может быть ложным, но вы не узнаете, потому что ассерт отключён. Со временем поверх такого ассерта добавляют новые проверки, и код обрастает скрытыми ошибками, пока не возникает уязвимость. Исправить ассерты и держать их включёнными — единственный способ достичь корректности.
Примеры из практики: TigerBeetle (финансовая БД) всегда оставляет ассерты. Ghostty (терминал) поставляет ReleaseFast сборки, но все серьёзные CVE у них были без повреждения памяти — просто из-за нарушения логики. Zine (генератор сайтов) автор публикует в ReleaseFast, так как ему важна скорость. Awebo (альтернатива Discord) будет в ReleaseSafe, но критические зависимости (FFmpeg, SQLite) — в ReleaseFast, потому что там выигрыш в производительности перевешивает риски.
Вывод: отключать ассерты в проде глупо — вы не получаете ни безопасности рантайм-проверок, ни полной оптимизации, а только плодите скрытые баги. Лучше чинить сами ассерты, а не прятать голову в песок.