3 вопроса: 1. Ну и что, много зарабатывает бот/код? 2. Если метод действительно рабочий и позволяет рубить бабло, зачем всем рассказывать? 3. Зачем забивать гитхаб сгенереным говнокодом?
Сегодня DeepSeek вполне сносно пишет на Rust и даже с какой-то попытки осиливает Zig. Я бы не сказал, что это плохой код, зачастую это код лучше чем напишет среднестатистический "кодер" с хабра.
Но это не имеет отношения к посылу статьи, который универсален к любой сфере: использовании ИИ вместо своего мозга ведёт к неизбежной атрофии последнего.
Рекомендации ВК очень редко попадают в мои интересы, а умная лента мало того что убила охваты в пабликах (что привело к массовым миграциям на ТГ), так ещё и мешает мне видеть полную картину, помещая в какой-то информационный пузырь.
Помню в 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 не было и в помине.
После слов:
> Десять лет в девопсе. Десять. И я гуглю
tar -xzf.Читать дальше не стал.
А ссылка на гитхаб будет?
3 вопроса:
1. Ну и что, много зарабатывает бот/код?
2. Если метод действительно рабочий и позволяет рубить бабло, зачем всем рассказывать?
3. Зачем забивать гитхаб сгенереным говнокодом?
Сегодня DeepSeek вполне сносно пишет на Rust и даже с какой-то попытки осиливает Zig. Я бы не сказал, что это плохой код, зачастую это код лучше чем напишет среднестатистический "кодер" с хабра.
Но это не имеет отношения к посылу статьи, который универсален к любой сфере: использовании ИИ вместо своего мозга ведёт к неизбежной атрофии последнего.
Рекомендации ВК очень редко попадают в мои интересы, а умная лента мало того что убила охваты в пабликах (что привело к массовым миграциям на ТГ), так ещё и мешает мне видеть полную картину, помещая в какой-то информационный пузырь.
Именно поэтому "чел" оставил бэкенд на "пхп".
Интересный опыт :]
Огромное спасибо за ваш взвешенный комментарий! Приятно встретить человека, который понимает суть инженерных компромиссов. Вы правы в каждом пункте:
Ваша мысль про 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 не было и в помине.
Напомню, что оригинальный комментарий:
С ходу поставил диагноз квалификации разработчика
Проигнорировал технические аргументы
Свёл обсуждение к субъективным впечатлениям
Но да, конечно — это я «остро реагирую», а не кто-то пришёл ляпнуть глупость и обижается на ответ.