Рекомендации ВК очень редко попадают в мои интересы, а умная лента мало того что убила охваты в пабликах (что привело к массовым миграциям на ТГ), так ещё и мешает мне видеть полную картину, помещая в какой-то информационный пузырь.
Помню в Python по такой причине приходилось выключать GC и использовать только ref counter. По-сути получали странную версию Rust (это было до 2015 года релиза раста).
Интересный опыт :]
Я как фанат Rust на самом деле поддерживаю в вашем случае переход именно на Zig. Во многом пожалуй в как раз контексте поддержке кода (за что вас тут в комментариях пытаются критиковать). Тут я поддержу выбор Zig:
1) В эпоху LLM поддерживать код на Rust всё еще сложно, потому что нужно хорошо владеть приемами "борьбы с лайфтаймами" и в них придется погрузиться, чтобы хоть что-то поменять в проекте, когда это понадобится. То есть взять не раст-инженера и "побыстрому" посадить его на проект не получится.
А вот Zig в этом плане простой как веник. За пару дней можно выучить весь синтаксис языка, а дальше ну это по сути Си, только не Си. Я 100% уверен, что с минимальной помощью LLM на проект можно нанять PHPшера Perl-иста, и он разберется.
Огромное спасибо за ваш взвешенный комментарий! Приятно встретить человека, который понимает суть инженерных компромиссов. Вы правы в каждом пункте:
Ваша мысль про LLM и Rust — бьёт в точку, хотя изначально не планировал на этом акцентироваться. Zig действительно даёт:
✓ Предсказуемую кривую обучения
✓ Прозрачную интеграцию с C
✓ Минимальный cognitive overhead для новых разработчиков
P.S. Ваш комментарий — редкий пример того, как должно выглядеть профессиональное обсуждение технологий. Без холиваров, с пониманием реальных инженерных задач. Но вы рискуете быть заминусованым за непопулярное мнение :)
P.P.S. И да — вы точно описали мой опыт: имея базовые навыки в C, в Zig разобрался за пару часов. Первые шаги с Rust заняли недели. Но Rust я тоже люблю
OCVPN — это серверная часть VPN, она раздаёт доступ для аккаунтов. В штатном ocvpn есть такая функция: при подключении показать сообщение (появится в всплывающем окне) — это называется баннер. Штатная версия позволяет задать 1 статичный баннер через файл конфигурации сервера, ocserv.conf — этого не достаточно.
В данном проекте баннеры используются как способ доставки важной информации к пользователю: срок окончания подписки, какие-то сведения, etc.
Спасибо за интерес к деталям нашего выбора! Позвольте пояснить мой подход более развернуто:
1. О выборе языков в принципе
В профессиональной разработке существует 4 основных пути выбора языка: ✓ Личные предпочтения технического руководства ✓ Корпоративные стандарты и комплаенс ✓ Популярные заблуждения ("все пишут на X") ✓ Осознанный выбор под конкретные требования
Я выбрал последний путь.
2. О распределении языков в нашем проекте
Zig: для низкоуровневой части (модификация C-программы)
Идеальная совместимость с C ABI
Контроль памяти без сложностей Rust
Минимальные накладные расходы
Go: для вспомогательных сервисов
Удобен для concurrent-задач
GC не критичен для логирования
Быстрая разработка
PHP: основной бэкенд
Только немного подрпавил, так как удовлетворяет требованиям
3. О философии выбора
Я принципиально не утверждаю, что: ✓ PHP/Python "хуже" ✓ Zig/Rust "лучше"
Каждый язык имеет свою нишу:
Когда нужен контроль памяти — берем Zig/Rust
Когда важна скорость разработки — Go/Python
Когда работает legacy — не ломаем без нужды
Каждый случай выбора языка под проект заслуживает отдельного анализа. В моём сценарии: ✓ Модификация C-кода → Zig ✓ Высокоуровневые сервисы → Go ✓ Основной бэкенд → PHP
почему раньше был отдельный процесс на каждое vpn-соединение, а теперь один процесс для всех?
Вероятно моя формулировка в статье создала неверное понимание происходящего. Давайте разберём архитектурные изменения подробней.
1. Как было раньше:
На каждое подключение создавался отдельный процесс PHP
В каждом процессе загружалась вся кодовая база скриптов
Плюс работал основной процесс ocserv-worker → Двойная нагрузка на систему
2. Как сейчас:
Вся бизнес-логика встроена непосредственно в процедуру авторизации
Никаких дополнительных процессов не создаётся
Модифицированный ocserv-worker обрабатывает всё сам
P.S. Если бы я разрабатывал систему с нуля сегодня — возможно, выбрал бы другие инструменты. Но профессиональный подход — это работать с текущими реалиями, а не гнаться за мейнстримом
Спасибо за первый по-настоящему конструктивный вопрос! Действительно, и Zig, и Rust могут ломать обратную совместимость, но в нашем случае выбор Zig был обусловлен несколькими ключевыми факторами:
Частота изменений vs критичность
Да, Zig ещё молод и действительно меняется чаще Rust
Но: наши изменения в бизнес-логике происходят раз в 5-10 лет
Обновление Zig-части (если потребуется) займёт ~1 день работы
Сложность миграции
В Rust breaking changes часто затрагивают систему владения
В Zig изменения обычно касаются:
API компилятора (не нашего кода)
Второстепенных фич (async/await и т.п.)
Конкретный наш случай
Мы зафиксировали версию Zig (0.14)
Код максимально простой (нет сложных абстракций)
Даже если ABI Zig сломается — пересборка займёт минуты
Практический компромисс
Rust даёт больше гарантий, но:
Требует больше времени на разработку
Сложнее интегрируется с нашим legacy C-кодом
Zig выбрали как "золотую середину" между:
Контролем памяти (как в Rust)
Простотой C
P.S. Для высоконагруженных новых проектов я бы склонился к Rust. Но для нашей задачи (минимальная модификация стабильного C-кода) Zig оказался идеальным инструментом — даже с учётом его молодости.
"Если вы придёте ко мне с сжатыми кулаками, я могу вам гарантировать, что мои кулаки сожмутся ещё крепче. Но если вы придёте ко мне и скажете: "Давайте обсудим наши разногласия", — мы обнаружим, что расстояние между нами не так велико."
— Дейл Карнеги
Как заметил Дейл Карнеги: "Когда в дискуссию входят со сжатыми кулаками, трудно ожидать рукопожатия".
Мы могли бы продуктивно обсудить:
Реальные технические компромиссы между Zig и другими языками
Конкретные метрики поддержки кода
Экономику разработки
Но когда диалог начинается с диагнозов "это писал джун" и предположений о некомпетентности бизнеса, или предложения переписать всё на Java — увы, это сразу задаёт неконструктивный тон.
Не могу понять я пишу настолько хорошо или настолько плохо.Как вы относситесь к нейронкам? Чтобы я понимал, меня сейчас оскорбили или похвалили.
что ещё печальнее
Самое прекрасное - это ваша уверенность, что понимаете чужой мыслительный процесс, на основании пары комментариев.
в любом случае странная реакция - нарекать тех, кто что-то вам возразил, гуру и экспертами
А возражать ради возражения это не странно в наше время, совершенно с вами согласен. Или предлагать всё переписать на Java, там где JVM не было и в помине.
О, наконец-то конкретные вопросы! Давайте разберём ваш новый шедевр экономического анализа:
как быстро ваша компания сможет найти программиста
Последняя правка бизнес-логики заняла 1 час рабочего времени (включая тесты). Выбор языка - это выбор между "сделать быстро" и "сделать и потом месяц фиксить".
Сколько будет стоить этот программист?
Ваша ошибка фундаментальна — вы считаете только зарплату, забывая про:
Стоимость простоя ("наши" серверы не падают)
Потерю клиентов (они больше не уходят)
Экономию на инфраструктуре (в 5 раз больше клиентов на 1 сервере)
P.S. «Дорогой» Zig-разработчик окупится за 2 месяца — за счёт снижения затрат на поддержку.
Может вам и кажется, что у вас Toyota, вот только запчасти к вашему авто будет найти несколько проблематичнее. Поиск запчастей - тоже проблема бизнеса.
Ваша аналогия разваливается при первом же взгляде:
Наш код не требует постоянных «запчастей» (работает годами)
«Ремонт» происходит в предсказуемое время (а не в 3 часа ночи)
«Механиков» мы готовим сами (внутренние знания > рыночная конъюнктура)
И вопрос на засыпку
Когда вы в последний раз видели enterprise-решение, где: ✓ Нет техдолга ✓ Ночные дежурства не нужны ✓ Клиенты не жалуются
P.P.S. Если для вас «идеальный проект» — это когда можно быстро нанять 100 «механиков» для вечного ремонта «Жигулей»... Может, проблема не в нашем выборе, а в ваших стандартах?
P.P.P.S. Кстати, о «запчастях» — сколько ваш бизнес тратит в год на «ремонт» вашего legacy-кода? Или это «не считается»?
Вы серьёзно приводите issues на GitHub как аргумент?
Тогда давайте посмотрим баги в Node.js (их в 10 раз больше)
Или в Spring Framework (там просто эпидемия)
Или, о ужас, в JVM (целые кладбища memory leak'ов)
то остановились на Rust. Да медленнее не разработка, чем на Zig, но зато за три года в продакшне ни одного краша и общий показатель фичи/баги по компании самый низкий
Поздравляю с удачным выбором! Только:
Мы модифицируем C-программу, а не пишем с нуля
Нам нужна была совместимость с существующим кодом
И, простите, но "три года без крашей" — это скорее заслуга инженеров, а не языка
то остановились на Rust
Самое смешное, что вы:
Хвалите Rust (молодой язык с малым пулом разработчиков)
Критикуете Zig (молодой язык с малым пулом разработчиков)
И при этом забываете, что ваш "идеальный" выбор — это ровно та же "проблема", за которую вы меня критикуете
Когда-нибудь и вы поймёте, что: ✓ Нет "серебряной пули" ✓ Выбор языка зависит от задачи ✓ А главный показатель — работающее решение, а не ваши личные предпочтения
P.S. Ваш Rust-сервис не крашится? Прекрасно! А теперь попробуйте найти 10 разработчиков, которые его поддержат быстрее, чем за месяц. Или это другое?
P.P.S. Кстати, раз уж заговорили про GitHub issues — может, поделитесь статистикой по вашему "идеальному" Rust-сервису? Или там "баги не считаются"?"
О, внезапно проснулся профессор логики! Давайте разберём ваш удивительный вклад в дискуссию:
strawman argument
Забавно слышать это от человека, который:
Сам придумал тезис про «недоказанность связи»
Не заметил, что: ✓ Bun.sh/TigerBeetle уже доказали жизнеспособность Zig ✓ Наш проект РАБОТАЕТ и приносит прибыль ✓ Клиенты перестали уходить Но да, конечно — это мы «не доказали тезис».
указание участнику дискуссии на то, что приведенный им довод не относится к теме дискуссии
Ваш ответ: «Это не аргумент, потому что я так сказал»
P.S. Если для вас «логическая чистота» дискуссии важнее её содержания — может, вам действительно стоит писать учебники по риторике? А мы пока продолжим делать работающие системы. Как-то так.
P.P.S. На всякий случай напомню очевидное (но, видимо, не для всех): Zig был выбран не потому что "модно", а потому что он:
Идеально подходит для модификации C-программ (наш случай)
Даёт контроль над памятью без головной боли (в отличие от ручного malloc/free)
Предоставляет современные фичи (компилятор, тестирование, кросс-платформенность)
Но да, конечно — я должен был: ✓ Остаться на PHP (где даже type safety — это фантастика) ✓ Или переписать всё на Java (где GC — это русская рулетка) ✓ Или нанять "любого из 90k C-разработчиков" (которые, как показывает практика, чаще пишут segfault'ы, чем работающий код)
Кажется, я сделал правильный выбор — даже если он не вписывается в вашу картину мира.
По стране найдётся может человек 500, которые смогут это поддержать (или хотя бы понять код за день-другой).
Ваш аргумент:
«Мало специалистов → бизнес в опасности»
Реальность:
"Наш" бизнес уже просек разницу между:
«100 PHP-джунов, которые не могут починить утечку памяти»
«1 Zig-разработчик, который разбираются в системе»
Итог: клиенты перестали уходить, серверы не горят — странно, да?
Попробуйте предложить бизнесу (например, такси в Воронеже) купить несколько Lamborghini
Ваша аналогия настолько далека от реальности, что это уже поэзия:
Мы не покупали «гиперкар» — мы выбросили «Запорожец», который:
Глох на каждом светофоре (segfaults)
Требовал ремонта каждую неделю (memory leaks)
Разваливался на ходу (race conditions)
Теперь у нас нормальный автомобиль (не Lambo, а просто исправная Toyota)
А бизнес точно в курсе
Вы всерьёз считаете, что:
Клиенты перестали уходить → бизнес не заметил?
Серверы перестали падать → бизнес «не в курсе»?
Экономия на поддержке → бухгалтерия проигнорировала?
P.S. Если для вас «успешное решение» — это только то, где «500+ айтишников в каждом городе», тогда да — наш подход вам непонятен. Но, кажется, Stripe, Cloudflare и Uber как-то живут с этим. Может, и нам повезёт?
P.P.S. Кстати, если уж так переживаете за воронежское такси — может, сначала поинтересуетесь, сколько они тратят на ремонт своих Lada в год? А то ведь «официальный сервис есть» — но почему-то клиенты предпочитают Uber...
P.P.P.S. Самое забавное, что вы с таким умным видом рассуждаете о проекте, сути которого:
Даже не поняли (модифицированный ocserv — это не "вундервафля", а отлаженное enterprise-решение)
Не знаете критериев (стабильность > "много программистов")
Не видели в работе (годы работы без правок — это не баг, это фича)
Видимо, в вашей картине мира: ✓ Всё ПО должно постоянно ломаться, чтобы "специалисты" были нужны ✓ Отлаженные системы — это миф ✓ А главный KPI — количество резюме на HH, а не работающие решения
Но не переживайте — когда-нибудь и вы столкнётесь с проектами, где "просто работает" — это норма, а не фантастика. Возрастное. 😉
Рекомендации ВК очень редко попадают в мои интересы, а умная лента мало того что убила охваты в пабликах (что привело к массовым миграциям на ТГ), так ещё и мешает мне видеть полную картину, помещая в какой-то информационный пузырь.
Именно поэтому "чел" оставил бэкенд на "пхп".
Интересный опыт :]
Огромное спасибо за ваш взвешенный комментарий! Приятно встретить человека, который понимает суть инженерных компромиссов. Вы правы в каждом пункте:
Ваша мысль про LLM и Rust — бьёт в точку, хотя изначально не планировал на этом акцентироваться. Zig действительно даёт:
✓ Предсказуемую кривую обучения
✓ Прозрачную интеграцию с C
✓ Минимальный cognitive overhead для новых разработчиков
P.S. Ваш комментарий — редкий пример того, как должно выглядеть профессиональное обсуждение технологий. Без холиваров, с пониманием реальных инженерных задач. Но вы рискуете быть заминусованым за непопулярное мнение :)
P.P.S. И да — вы точно описали мой опыт: имея базовые навыки в C, в Zig разобрался за пару часов. Первые шаги с Rust заняли недели. Но Rust я тоже люблю
В каком-то смысле
:-D
OCVPN — это серверная часть VPN, она раздаёт доступ для аккаунтов. В штатном ocvpn есть такая функция: при подключении показать сообщение (появится в всплывающем окне) — это называется баннер. Штатная версия позволяет задать 1 статичный баннер через файл конфигурации сервера, ocserv.conf — этого не достаточно.
В данном проекте баннеры используются как способ доставки важной информации к пользователю: срок окончания подписки, какие-то сведения, etc.
Как мудро заметил один философ:"Когда дискуссия переходит на личности — это высшая форма технической аргументации".
Спасибо за ваш опыт и конструктивные замечания! Полностью согласен с вашими опасениями насчёт стабильности - это действительно важный аспект.
Но в этом проекте логика, которая вынесена на Zig, не будет меняться ближайшие 5-10 лет, за это время и rust успеет сломать совместимость.
И настолько конструктивное, что в качестве аргументов пошли минусы в карму (не от меня) :)
Вы совершенно правы — рассуждать о чужом бизнесе, не зная деталей, действительно несерьёзно.
А что если наши 100 пользователей — это:
VPN-инфраструктура для банковских отделений
Где каждый сеанс обрабатывает финансовые транзакции
С требованиями SLA 99.99%
Уже не так однозначно, верно?
Спасибо за интерес к деталям нашего выбора! Позвольте пояснить мой подход более развернуто:
1. О выборе языков в принципе
В профессиональной разработке существует 4 основных пути выбора языка:
✓ Личные предпочтения технического руководства
✓ Корпоративные стандарты и комплаенс
✓ Популярные заблуждения ("все пишут на X")
✓ Осознанный выбор под конкретные требования
Я выбрал последний путь.
2. О распределении языков в нашем проекте
Zig: для низкоуровневой части (модификация C-программы)
Идеальная совместимость с C ABI
Контроль памяти без сложностей Rust
Минимальные накладные расходы
Go: для вспомогательных сервисов
Удобен для concurrent-задач
GC не критичен для логирования
Быстрая разработка
PHP: основной бэкенд
Только немного подрпавил, так как удовлетворяет требованиям
3. О философии выбора
Я принципиально не утверждаю, что:
✓ PHP/Python "хуже"
✓ Zig/Rust "лучше"
Каждый язык имеет свою нишу:
Когда нужен контроль памяти — берем Zig/Rust
Когда важна скорость разработки — Go/Python
Когда работает legacy — не ломаем без нужды
Каждый случай выбора языка под проект заслуживает отдельного анализа. В моём сценарии:
✓ Модификация C-кода → Zig
✓ Высокоуровневые сервисы → Go
✓ Основной бэкенд → PHP
Вероятно моя формулировка в статье создала неверное понимание происходящего. Давайте разберём архитектурные изменения подробней.
1. Как было раньше:
На каждое подключение создавался отдельный процесс PHP
В каждом процессе загружалась вся кодовая база скриптов
Плюс работал основной процесс ocserv-worker
→ Двойная нагрузка на систему
2. Как сейчас:
Вся бизнес-логика встроена непосредственно в процедуру авторизации
Никаких дополнительных процессов не создаётся
Модифицированный ocserv-worker обрабатывает всё сам
P.S. Если бы я разрабатывал систему с нуля сегодня — возможно, выбрал бы другие инструменты. Но профессиональный подход — это работать с текущими реалиями, а не гнаться за мейнстримом
Спасибо за первый по-настоящему конструктивный вопрос! Действительно, и Zig, и Rust могут ломать обратную совместимость, но в нашем случае выбор Zig был обусловлен несколькими ключевыми факторами:
Частота изменений vs критичность
Да, Zig ещё молод и действительно меняется чаще Rust
Но: наши изменения в бизнес-логике происходят раз в 5-10 лет
Обновление Zig-части (если потребуется) займёт ~1 день работы
Сложность миграции
В Rust breaking changes часто затрагивают систему владения
В Zig изменения обычно касаются:
API компилятора (не нашего кода)
Второстепенных фич (async/await и т.п.)
Конкретный наш случай
Мы зафиксировали версию Zig (0.14)
Код максимально простой (нет сложных абстракций)
Даже если ABI Zig сломается — пересборка займёт минуты
Практический компромисс
Rust даёт больше гарантий, но:
Требует больше времени на разработку
Сложнее интегрируется с нашим legacy C-кодом
Zig выбрали как "золотую середину" между:
Контролем памяти (как в Rust)
Простотой C
P.S. Для высоконагруженных новых проектов я бы склонился к Rust. Но для нашей задачи (минимальная модификация стабильного C-кода) Zig оказался идеальным инструментом — даже с учётом его молодости.
P.P.S. Плюсую в карму за вопрос по делу :)
Как заметил Дейл Карнеги: "Когда в дискуссию входят со сжатыми кулаками, трудно ожидать рукопожатия".
Мы могли бы продуктивно обсудить:
Реальные технические компромиссы между Zig и другими языками
Конкретные метрики поддержки кода
Экономику разработки
Но когда диалог начинается с диагнозов "это писал джун" и предположений о некомпетентности бизнеса, или предложения переписать всё на Java — увы, это сразу задаёт неконструктивный тон.
А может меня вообще нету? Есть только AI-агент, почему нет. Пол хабра сейчас заваленно вайб-кодингом и тем как сделать своего агента.
Не могу понять я пишу настолько хорошо или настолько плохо.Как вы относситесь к нейронкам? Чтобы я понимал, меня сейчас оскорбили или похвалили.
Самое прекрасное - это ваша уверенность, что понимаете чужой мыслительный процесс, на основании пары комментариев.
А возражать ради возражения это не странно в наше время, совершенно с вами согласен. Или предлагать всё переписать на Java, там где JVM не было и в помине.
Напомню, что оригинальный комментарий:
С ходу поставил диагноз квалификации разработчика
Проигнорировал технические аргументы
Свёл обсуждение к субъективным впечатлениям
Но да, конечно — это я «остро реагирую», а не кто-то пришёл ляпнуть глупость и обижается на ответ.
О, наконец-то конкретные вопросы! Давайте разберём ваш новый шедевр экономического анализа:
Последняя правка бизнес-логики заняла 1 час рабочего времени (включая тесты). Выбор языка - это выбор между "сделать быстро" и "сделать и потом месяц фиксить".
Ваша ошибка фундаментальна — вы считаете только зарплату, забывая про:
Стоимость простоя ("наши" серверы не падают)
Потерю клиентов (они больше не уходят)
Экономию на инфраструктуре (в 5 раз больше клиентов на 1 сервере)
P.S. «Дорогой» Zig-разработчик окупится за 2 месяца — за счёт снижения затрат на поддержку.
Ваша аналогия разваливается при первом же взгляде:
Наш код не требует постоянных «запчастей» (работает годами)
«Ремонт» происходит в предсказуемое время (а не в 3 часа ночи)
«Механиков» мы готовим сами (внутренние знания > рыночная конъюнктура)
И вопрос на засыпку
Когда вы в последний раз видели enterprise-решение, где:
✓ Нет техдолга
✓ Ночные дежурства не нужны
✓ Клиенты не жалуются
P.P.S. Если для вас «идеальный проект» — это когда можно быстро нанять 100 «механиков» для вечного ремонта «Жигулей»... Может, проблема не в нашем выборе, а в ваших стандартах?
P.P.P.S. Кстати, о «запчастях» — сколько ваш бизнес тратит в год на «ремонт» вашего legacy-кода? Или это «не считается»?
Вы серьёзно приводите issues на GitHub как аргумент?
Тогда давайте посмотрим баги в Node.js (их в 10 раз больше)
Или в Spring Framework (там просто эпидемия)
Или, о ужас, в JVM (целые кладбища memory leak'ов)
Поздравляю с удачным выбором! Только:
Мы модифицируем C-программу, а не пишем с нуля
Нам нужна была совместимость с существующим кодом
И, простите, но "три года без крашей" — это скорее заслуга инженеров, а не языка
Самое смешное, что вы:
Хвалите Rust (молодой язык с малым пулом разработчиков)
Критикуете Zig (молодой язык с малым пулом разработчиков)
И при этом забываете, что ваш "идеальный" выбор — это ровно та же "проблема", за которую вы меня критикуете
Когда-нибудь и вы поймёте, что:
✓ Нет "серебряной пули"
✓ Выбор языка зависит от задачи
✓ А главный показатель — работающее решение, а не ваши личные предпочтения
P.S. Ваш Rust-сервис не крашится? Прекрасно! А теперь попробуйте найти 10 разработчиков, которые его поддержат быстрее, чем за месяц. Или это другое?
P.P.S. Кстати, раз уж заговорили про GitHub issues — может, поделитесь статистикой по вашему "идеальному" Rust-сервису? Или там "баги не считаются"?"
О, внезапно проснулся профессор логики! Давайте разберём ваш удивительный вклад в дискуссию:
Забавно слышать это от человека, который:
Сам придумал тезис про «недоказанность связи»
Не заметил, что:
✓ Bun.sh/TigerBeetle уже доказали жизнеспособность Zig
✓ Наш проект РАБОТАЕТ и приносит прибыль
✓ Клиенты перестали уходить
Но да, конечно — это мы «не доказали тезис».
Тема: «Выбор языка для стабильного решения»
Ваш вклад: «Вы неправильно используете логические конструкции»
Видимо, вы:
✓ Путаете Хабра с факультетом философии
✓ Считаете, что список fallacies важнее работающего кода
Мы уже привели:
Конкретные примеры (Bun.sh, Uber)
Технические аргументы (память, производительность)
Бизнес-метрики (клиенты, серверы)
Ваш ответ: «Это не аргумент, потому что я так сказал»
P.S. Если для вас «логическая чистота» дискуссии важнее её содержания — может, вам действительно стоит писать учебники по риторике? А мы пока продолжим делать работающие системы. Как-то так.
P.P.S. На всякий случай напомню очевидное (но, видимо, не для всех):
Zig был выбран не потому что "модно", а потому что он:
Идеально подходит для модификации C-программ (наш случай)
Даёт контроль над памятью без головной боли (в отличие от ручного malloc/free)
Предоставляет современные фичи (компилятор, тестирование, кросс-платформенность)
Но да, конечно — я должен был:
✓ Остаться на PHP (где даже type safety — это фантастика)
✓ Или переписать всё на Java (где GC — это русская рулетка)
✓ Или нанять "любого из 90k C-разработчиков" (которые, как показывает практика, чаще пишут segfault'ы, чем работающий код)
Кажется, я сделал правильный выбор — даже если он не вписывается в вашу картину мира.
Ваш аргумент:
«Мало специалистов → бизнес в опасности»
Реальность:
"Наш" бизнес уже просек разницу между:
«100 PHP-джунов, которые не могут починить утечку памяти»
«1 Zig-разработчик, который разбираются в системе»
Итог: клиенты перестали уходить, серверы не горят — странно, да?
Ваша аналогия настолько далека от реальности, что это уже поэзия:
Мы не покупали «гиперкар» — мы выбросили «Запорожец», который:
Глох на каждом светофоре (segfaults)
Требовал ремонта каждую неделю (memory leaks)
Разваливался на ходу (race conditions)
Теперь у нас нормальный автомобиль (не Lambo, а просто исправная Toyota)
Вы всерьёз считаете, что:
Клиенты перестали уходить → бизнес не заметил?
Серверы перестали падать → бизнес «не в курсе»?
Экономия на поддержке → бухгалтерия проигнорировала?
P.S. Если для вас «успешное решение» — это только то, где «500+ айтишников в каждом городе», тогда да — наш подход вам непонятен. Но, кажется, Stripe, Cloudflare и Uber как-то живут с этим. Может, и нам повезёт?
P.P.S. Кстати, если уж так переживаете за воронежское такси — может, сначала поинтересуетесь, сколько они тратят на ремонт своих Lada в год? А то ведь «официальный сервис есть» — но почему-то клиенты предпочитают Uber...
P.P.P.S. Самое забавное, что вы с таким умным видом рассуждаете о проекте, сути которого:
Даже не поняли (модифицированный ocserv — это не "вундервафля", а отлаженное enterprise-решение)
Не знаете критериев (стабильность > "много программистов")
Не видели в работе (годы работы без правок — это не баг, это фича)
Видимо, в вашей картине мира:
✓ Всё ПО должно постоянно ломаться, чтобы "специалисты" были нужны
✓ Отлаженные системы — это миф
✓ А главный KPI — количество резюме на HH, а не работающие решения
Но не переживайте — когда-нибудь и вы столкнётесь с проектами, где "просто работает" — это норма, а не фантастика. Возрастное. 😉