О, наконец-то конкретные вопросы! Давайте разберём ваш новый шедевр экономического анализа:
как быстро ваша компания сможет найти программиста
Последняя правка бизнес-логики заняла 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, а не работающие решения
Но не переживайте — когда-нибудь и вы столкнётесь с проектами, где "просто работает" — это норма, а не фантастика. Возрастное. 😉
Программист пишет на том, на чем хочет, но в рамках того, что позволяет бизнес
Странно, в моей реальности хороший инженер:
Сначала изучает задачу
Потом выбирает инструмент под неё
И только потом пишет
Видимо, мы живём в разных вселенных. В вашей, похоже, код — это личное творческое самовыражение.
бизнес не хочет заморачиваться
А вот это уже ближе к истине! Только:
"Наш" бизнес «заморачивается» ровно настолько, чтобы клиенты не уходили
И странное совпадение — после перехода с PHP проблемы с уходящими клиентами исчезли
Может, это не бизнес «не заморачивается», а просто его критерии отличаются от ваших?
это проблемы бизнеса
Абсолютно верно! Поэтому:
Бизнес решил перестать краснеть перед клиентами
Бизнес выбрал стабильное решение
И, кажется, бизнес оказался прав — система теперь работает
P.S. Если в вашей картине мира нет места инженерам, которые «заморачиваются» за бизнес — это, конечно, печально. Но, возможно, вам просто не повезло с работодателями?
Да ещё автор упоминает про magic_quotes_gpc - это же жуткая древность и моветон.
Да, это была гипербола (спасибо, что заметили). Но если вас смущает только это — поздравляю: значит, остальные проблемы кода настолько очевидны, что даже спорить не о чем.
Скоере всего, это писал какой-то джун задёшево
А вот это уже интересно. Вы:
Не знаете контекста (кто, когда и зачем это писал)
Не видели весь код (только фрагменты)
Но уже уверенно ставите диагноз
Видимо, у вас есть дар — определять квалификацию разработчика по «беглому взгляду». Может, откроете курсы?
не могу ничего сказать про Zig
Это единственное разумное в вашем комментарии. И да — теперь у нас:
Нет магических преобразований типов
Нет неожиданных утечек памяти
И главное — нет «беглых взглядов» от посторонних экспертов
P.S. Если вам так интересно — могу прислать пару примеров «нехорошего» кода на PHP. Для ностальгии. Или для осознания прогресса.
P.P.S.Кстати, если уж говорить про «древность» — как думаете, через сколько лет ваш текущий стек тоже будут так же вспоминать? 😏
Видимо вы не вкурсе насчет разных GC в современной Java, прежде чем пересказывать историю из нулевых актуализовали бы собственные знания.
Вы правы - в Java теперь целых 5 видов GC! И какой же из них:
Гарантирует отсутствие stop-the-world? (никакой)
Избавляет от memory leaks? (смешно)
Работает также предсказуемо, как ручное управление? (вы шутите)
P.S. ZGC - это круто, но он всё равно не волшебник. И да, я тестировал.
Вы похоже просто не вкурсе Java-мира. Не то что бы знание java-мира обязательно, но рассуждать о том в чем не разбираетесь должно быть стыдно
Забавно слышать от человека, который:
Лезит в чужую ветку с советами о бизнесе, о котором ничего не знает
Считает, что DI в Spring сводится к «вынесу-ка я new»
Путает «магию» фреймворка с плохой документацией
А Zig нагрузочного тестирования не требует? Или вам кажется что в мире Java нет такого?
Ах да, конечно:
В Zig тесты показывают, где я накосячил
В Java тесты показывают, где JVM решила устроить фестиваль сборки мусора
И вопрос на засыпку
Когда вы в последний раз:
Объясняли клиенту, почему его запрос обрабатывался 5 секунд (потому что GC)
Дебажили OOM в продакшене из-за неочевидного retain в лямбде
Пересобирали весь кластер из-за security-дыры в Spring-зависимости?
P.S. Если для вас «не знать Spring» = «не разбираться в разработке» — поздравляю, вы идеальный кандидат на позицию «корпоратного программиста года». Только вот Uber почему-то таких не ищет... Странно, да?
О, внезапно появился эксперт по кадровому менеджменту! Давайте разберём ваши "аргументы"
Вы это сами придумали, PHP не единственный популярный язык
Вы правы - PHP не единственный популярный язык. Есть ещё COBOL! Там тоже много специалистов, и они точно не попадут под автобус - потому что уже на пенсии.
Вы это сами придумали, вам указали на то что в условиях выбора из большого числа кандидатов шанс найти подходящего укладывающегося в бюджет выше
Забавно, что вы считаете 90 тысяч резюме преимуществом. На практике это:
89 тысяч джунов, которые не знают, чем malloc отличается от calloc
999 мидлов, уверенных, что GC сделает всю работу за них
И если повезёт - 1 senior, который уже работает в FAANG
Вы это сами придумали, вам указали на то что в рамках малого числа кандидатов шанс того что вы останетесь с вундервафлей которую никто не может запустить после перезагрузки сервера выше
Если ваш код превращается в магический артефакт при смене разработчика - проблема не в языке, а в:
Процессах (о да, "у нас тут всё в голове у Васяна")
А если серьёзно: скомпилированный ocserv, с доработанной и отлаженной логикой, может работать годами и плевать ему на ребуты. Где спрашивается вундервафля?
В работоспособности Zig никто не сомневался, вы уверены что работаете в Uber или конторе сопоставимого размера? Возможности по найму специалистов сильно зависят от размера конторы.
Ах, ну да, конечно — 45 МБ в простое это же "мелочь"!
Давайте лучше посмотрим, что происходит при 1к+ клиентов:
PHP:
Каждый новый коннект — это новый процесс с копией всего на свете
1000 клиентов? 1000 копий тех же самых библиотек в памяти
А теперь добавьте сюда утечки из-за циклических ссылок и глобальных переменных
Итог: сервер начинает свопиться, клиенты отваливаются, админ бегает с перезагрузками
Zig:
Один процесс, контролируемые аллокации, общие ресурсы
Никаких неожиданных утечек — потому что память не "магическая", а явная
Итог: сервер улыбается и жуёт трафик, клиенты довольны
Так что "гирлянда" была именно на PHP — только это не новогоднее украшение, а лампочки серверного стойла, мигающие от перегрузки.
И главный вопрос
Когда вы в последний раз сами:
Объясняли клиенту, почему его данные потерялись из-за magic_quotes_gpc?
Дебажили race condition в PHP-сессиях?
Перезапускали продакшен в 3 ночи, потому что скрипт сжёг всю память?
P.S. 45 МБ - это просто приятный бонус. Настоящая экономия в том, что теперь мы не теряем клиентов и не тратим ночи на поддержку.
Если для вас "экономия памяти" — это смешно, значит, вы либо никогда не масштабировали PHP-сервисы, либо успешно перекладывали эту боль на админов. В любом случае — поздравляю с удачным избеганием реальных проблем.
P.P.S. А PHP-код я привёл в порядок, но только он остался исключительно там где ему место — рисует HTML.
Можем попробовать прикинуть сколько памяти можно купить всего за одну месячную зарплату rust/go/zig разработчика
Забавно, что вы считаете, будто проблема решается «покупкой памяти». Видимо, никогда не сталкивались с тем, как GC под нагрузкой превращается в русскую рулетку — когда приложение внезапно замирает на секунду, потому что JVM решила почистить бардак, который сама же и создала.
Но да, конечно — можно закидать железом любую архитектурную проблему. Только почему-то Stripe предпочёл потратить деньги не на сервера, а на переход с Java на Rust. Странные они, да?
Для меня DI это всего-навсего вынос оператора new из бизнес логики
Если для вас DI — это просто «вынести new», тогда Spring с его 15 слоями абстракции — это как стрелять из пушки по воробьям. В Zig зависимость инжектится ровно там, где нужна — без магии, без рефлексии, без тонны сгенерированного кода.
У вас точно high load?
У нас может и не было «хайлоада» в вашем понимании (миллионы RPS), зато есть:
предсказуемая работа без GC-лагов
код, который не разваливается от правки в соседнем модуле
P.S. Кстати, если уж говорить о деньгах — интересно, сколько стоит месяц простоя из-за того, что GC не справился с нагрузкой? Или час дебага «магического» поведения Spring-приложения? Но да, конечно, «память дешевле».
P.P.S. Кстати, если уж считать деньги — сколько вы тратите на поддержку всех этих Spring-зависимостей? Каждый security-апдейт ведь требует пересборки всего приложения. Или у вас production до сих пор на Java 8?
Надо писать на PHP — потому что «программистов много».
Надо нанимать первого попавшегося — потому что «дешевле».
Надо молиться, чтобы «автобус» не приехал — потому что иначе проект развалится.
Но почему-то Bun.sh, Uber и TigerBeetle как-то рискнули и выбрали Zig — и, кажется, у них всё работает. Видимо, они предпочитают искать тех, кто действительно разбирается, а не просто «кого-нибудь из 90 тысяч».
Споры ни к чему не приводят. Потому что если инженер способен поддерживать только то, что «легаси 100 лет в обед», а не то, что технически оправдано — это уже вопрос не к языку, а к квалификации.
P.S. Мистический автобус, конечно, аргумент весомый. Но если система держится на одном человеке — проблема явно не в языке, а в подходе к разработке. Или вы считаете, что 90 тысяч C-разработчиков гарантированно защитят от любых форс-мажоров?
P.P.S. Кстати, если уж бояться «автобусов», то PHP-разработчики, судя по статистике, в зоне повышенного риска — их слишком много, вероятность ДТП выше. Может, тогда вообще запретим программистам выходить из дома? 😈
В Java/Spring аллокаторы действительно спрятаны за сборщиком мусора и кучей абстракций — что отлично работает, пока вам не нужно понимать, куда девается память под нагрузкой. Stripe и Cloudflare как раз поэтому и переходят на Rust/Zig для критичных сервисов. Но если ваш критерий "странности" — отсутствие 10 слоёв DI, тогда да, мой код вам покажется подозрительным.
P.S. Кстати, в Java 21 уже добавили virtual threads — может, теперь наконец-то можно будет писать высоконагруженные сервисы без Spring Boot + 50 зависимостей? Шучу, конечно... Или нет?
Вы правы - это действительно смена одного типа сложностей на другие. Только раньше сложности были вроде 'почему empty("0") == true', а теперь - в необходимости явно описывать обработку ошибок. Как-то так получилось, что второй вариант приводит к стабильной работе системы... Странное совпадение, да? Хотя если для вас разница между хронической болезнью и здоровыми нагрузками действительно неочевидна - тогда да, просто "другая боль".
О, статистика — это святое! Давайте тогда вернёмся к истокам: изначально проект был на PHP, где разработчиков — как песчинок в Сахаре. И что? Он "еле работал", а поддержка напоминала игру в "исправь один баг — получи два новых". Но зато специалистов много, да? Может, проблема не в языке, а в том, что хороший код пишут не толпы, а те самые 134 человека, которые хотя бы понимают, что делают?
Ну а если серьёзно — Zig выбрал не я один. Bun.sh (который рвёт Node.js по производительности), Uber (да, тот самый) и TigerBeetle (который обгоняет InfluxDB) используют его там, где важны контроль над памятью и отсутствие неожиданностей. Но да, конечно, можно и дальше верить, что "много программистов = хорошо'". PHP-то уж точно всех спасёт!
Сведения об этой практике содержит постановление окружного судьи США Уильяма Олсапа, который указал, что компаниям в сфере ИИ не нужно получать разрешение владельцев авторских прав для обучения своих больших языковых моделей, если книги были приобретены законно.
Когда у тебя есть мешок денег и нужные связи, то предупреждение в духе "Любая часть этой книги не может быть распространенна в том или инном виде без письменого согласия редакции/автора", просто перестаёт работать и вполне себе законным путём.
Законность действий Anthropic обеспечена доктриной первой продажи. Эта юридическая концепция позволяет покупателю делать с приобретённым товаром всё, что он захочет.
Однако попробуйте без согласия с редакцией издать перевод, а точно, это другое.
Честно говоря, математика это не языка, а скорее "рафинированная физика".
Греческое слово maqanw переводится как изучаю или понимаю, maqhsiz — изучение или познание, а слово математика (maqhmatikh) раньше означало науку вообще и глубокое познание всякого предмета. Здесь также уместно напомнить, что греческое слово гипотеза (upoqesiz) первоначально означало кинематическую модель и геометрическую схему. В этом значении данным термином пользовался Птолемей. Схоласты, недолюбливавшие конструктивные методы античных математиков, сообщили слову гипотеза коннотацию сомнения и предположения, отсутствовавшие в первоначальном значении слова. Рядом с исходным словом гипотеза можно было поставить и боговдохновенное слово теория или близкое ему слово теорема; они образованы от греческого глагола qewrein — созерцать. Таким образом, три основных математических термина — гипотеза, теорема и теория — апеллируют, прежде всего, к воображению.
Напомню, что оригинальный комментарий:
С ходу поставил диагноз квалификации разработчика
Проигнорировал технические аргументы
Свёл обсуждение к субъективным впечатлениям
Но да, конечно — это я «остро реагирую», а не кто-то пришёл ляпнуть глупость и обижается на ответ.
О, наконец-то конкретные вопросы! Давайте разберём ваш новый шедевр экономического анализа:
Последняя правка бизнес-логики заняла 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, а не работающие решения
Но не переживайте — когда-нибудь и вы столкнётесь с проектами, где "просто работает" — это норма, а не фантастика. Возрастное. 😉
Странно, в моей реальности хороший инженер:
Сначала изучает задачу
Потом выбирает инструмент под неё
И только потом пишет
Видимо, мы живём в разных вселенных. В вашей, похоже, код — это личное творческое самовыражение.
А вот это уже ближе к истине! Только:
"Наш" бизнес «заморачивается» ровно настолько, чтобы клиенты не уходили
И странное совпадение — после перехода с PHP проблемы с уходящими клиентами исчезли
Может, это не бизнес «не заморачивается», а просто его критерии отличаются от ваших?
Абсолютно верно! Поэтому:
Бизнес решил перестать краснеть перед клиентами
Бизнес выбрал стабильное решение
И, кажется, бизнес оказался прав — система теперь работает
P.S. Если в вашей картине мира нет места инженерам, которые «заморачиваются» за бизнес — это, конечно, печально. Но, возможно, вам просто не повезло с работодателями?
Да, это была гипербола (спасибо, что заметили). Но если вас смущает только это — поздравляю: значит, остальные проблемы кода настолько очевидны, что даже спорить не о чем.
А вот это уже интересно. Вы:
Не знаете контекста (кто, когда и зачем это писал)
Не видели весь код (только фрагменты)
Но уже уверенно ставите диагноз
Видимо, у вас есть дар — определять квалификацию разработчика по «беглому взгляду». Может, откроете курсы?
Это единственное разумное в вашем комментарии. И да — теперь у нас:
Нет магических преобразований типов
Нет неожиданных утечек памяти
И главное — нет «беглых взглядов» от посторонних экспертов
P.S. Если вам так интересно — могу прислать пару примеров «нехорошего» кода на PHP. Для ностальгии. Или для осознания прогресса.
P.P.S. Кстати, если уж говорить про «древность» — как думаете, через сколько лет ваш текущий стек тоже будут так же вспоминать? 😏
О, внезапно проснулся гуру Java! Давайте разберём ваши жемчужины
Вы правы - в Java теперь целых 5 видов GC! И какой же из них:
Гарантирует отсутствие stop-the-world? (никакой)
Избавляет от memory leaks? (смешно)
Работает также предсказуемо, как ручное управление? (вы шутите)
P.S. ZGC - это круто, но он всё равно не волшебник. И да, я тестировал.
Забавно слышать от человека, который:
Лезит в чужую ветку с советами о бизнесе, о котором ничего не знает
Считает, что DI в Spring сводится к «вынесу-ка я new»
Путает «магию» фреймворка с плохой документацией
Ах да, конечно:
В Zig тесты показывают, где я накосячил
В Java тесты показывают, где JVM решила устроить фестиваль сборки мусора
И вопрос на засыпку
Когда вы в последний раз:
Объясняли клиенту, почему его запрос обрабатывался 5 секунд (потому что GC)
Дебажили OOM в продакшене из-за неочевидного retain в лямбде
Пересобирали весь кластер из-за security-дыры в Spring-зависимости?
P.S. Если для вас «не знать Spring» = «не разбираться в разработке» — поздравляю, вы идеальный кандидат на позицию «корпоратного программиста года». Только вот Uber почему-то таких не ищет... Странно, да?
О, внезапно появился эксперт по кадровому менеджменту! Давайте разберём ваши "аргументы"
Вы правы - PHP не единственный популярный язык. Есть ещё COBOL! Там тоже много специалистов, и они точно не попадут под автобус - потому что уже на пенсии.
Забавно, что вы считаете 90 тысяч резюме преимуществом. На практике это:
89 тысяч джунов, которые не знают, чем malloc отличается от calloc
999 мидлов, уверенных, что GC сделает всю работу за них
И если повезёт - 1 senior, который уже работает в FAANG
Если ваш код превращается в магический артефакт при смене разработчика - проблема не в языке, а в:
Архитектуре (точнее, её отсутствии)
Документации (которую вы, видимо, считаете буржуазным излишеством)
Процессах (о да, "у нас тут всё в голове у Васяна")
А если серьёзно: скомпилированный ocserv, с доработанной и отлаженной логикой, может работать годами и плевать ему на ребуты. Где спрашивается вундервафля?
Раз уж заговорили про размер компании:
Bun.sh создали 3 человека
TigerBeetle - и вовсе стартап. Но видимо, они просто не знали, что по вашей логике им "нельзя" использовать современные технологии
Ваш аргумент звучит как "нельзя использовать React, пока вы не стали Facebook"
По этой логике 99% стартапов должны писать на Visual Basic
P.S. Ваш подход прекрасно объясняет, почему 80% enterprise-кода - это поддерживаемый кошмар. Но продолжайте в том же духе - нам есть с чем сравнивать!
P.P.S. "Вы это сами придумали" — это не аргумент. Это отсутствие аргументов.
Ах, ну да, конечно — 45 МБ в простое это же "мелочь"!
Давайте лучше посмотрим, что происходит при 1к+ клиентов:
PHP:
Каждый новый коннект — это новый процесс с копией всего на свете
1000 клиентов? 1000 копий тех же самых библиотек в памяти
А теперь добавьте сюда утечки из-за циклических ссылок и глобальных переменных
Итог: сервер начинает свопиться, клиенты отваливаются, админ бегает с перезагрузками
Zig:
Один процесс, контролируемые аллокации, общие ресурсы
Никаких неожиданных утечек — потому что память не "магическая", а явная
Итог: сервер улыбается и жуёт трафик, клиенты довольны
Так что "гирлянда" была именно на PHP — только это не новогоднее украшение, а лампочки серверного стойла, мигающие от перегрузки.
И главный вопрос
Когда вы в последний раз сами:
Объясняли клиенту, почему его данные потерялись из-за magic_quotes_gpc?
Дебажили race condition в PHP-сессиях?
Перезапускали продакшен в 3 ночи, потому что скрипт сжёг всю память?
P.S. 45 МБ - это просто приятный бонус. Настоящая экономия в том, что теперь мы не теряем клиентов и не тратим ночи на поддержку.
Если для вас "экономия памяти" — это смешно, значит, вы либо никогда не масштабировали PHP-сервисы, либо успешно перекладывали эту боль на админов. В любом случае — поздравляю с удачным избеганием реальных проблем.
P.P.S. А PHP-код я привёл в порядок, но только он остался исключительно там где ему место — рисует HTML.
Забавно, что вы считаете, будто проблема решается «покупкой памяти». Видимо, никогда не сталкивались с тем, как GC под нагрузкой превращается в русскую рулетку — когда приложение внезапно замирает на секунду, потому что JVM решила почистить бардак, который сама же и создала.
Но да, конечно — можно закидать железом любую архитектурную проблему. Только почему-то Stripe предпочёл потратить деньги не на сервера, а на переход с Java на Rust. Странные они, да?
Если для вас DI — это просто «вынести new», тогда Spring с его 15 слоями абстракции — это как стрелять из пушки по воробьям. В Zig зависимость инжектится ровно там, где нужна — без магии, без рефлексии, без тонны сгенерированного кода.
У нас может и не было «хайлоада» в вашем понимании (миллионы RPS), зато есть:
предсказуемая работа без GC-лагов
код, который не разваливается от правки в соседнем модуле
P.S. Кстати, если уж говорить о деньгах — интересно, сколько стоит месяц простоя из-за того, что GC не справился с нагрузкой? Или час дебага «магического» поведения Spring-приложения? Но да, конечно, «память дешевле».
P.P.S. Кстати, если уж считать деньги — сколько вы тратите на поддержку всех этих Spring-зависимостей? Каждый security-апдейт ведь требует пересборки всего приложения. Или у вас production до сих пор на Java 8?
Если следовать этой логике, то:
Надо писать на PHP — потому что «программистов много».
Надо нанимать первого попавшегося — потому что «дешевле».
Надо молиться, чтобы «автобус» не приехал — потому что иначе проект развалится.
Но почему-то Bun.sh, Uber и TigerBeetle как-то рискнули и выбрали Zig — и, кажется, у них всё работает. Видимо, они предпочитают искать тех, кто действительно разбирается, а не просто «кого-нибудь из 90 тысяч».
Споры ни к чему не приводят. Потому что если инженер способен поддерживать только то, что «легаси 100 лет в обед», а не то, что технически оправдано — это уже вопрос не к языку, а к квалификации.
P.S. Мистический автобус, конечно, аргумент весомый. Но если система держится на одном человеке — проблема явно не в языке, а в подходе к разработке. Или вы считаете, что 90 тысяч C-разработчиков гарантированно защитят от любых форс-мажоров?
P.P.S. Кстати, если уж бояться «автобусов», то PHP-разработчики, судя по статистике, в зоне повышенного риска — их слишком много, вероятность ДТП выше. Может, тогда вообще запретим программистам выходить из дома? 😈
В Java/Spring аллокаторы действительно спрятаны за сборщиком мусора и кучей абстракций — что отлично работает, пока вам не нужно понимать, куда девается память под нагрузкой. Stripe и Cloudflare как раз поэтому и переходят на Rust/Zig для критичных сервисов. Но если ваш критерий "странности" — отсутствие 10 слоёв DI, тогда да, мой код вам покажется подозрительным.
P.S. Кстати, в Java 21 уже добавили virtual threads — может, теперь наконец-то можно будет писать высоконагруженные сервисы без Spring Boot + 50 зависимостей? Шучу, конечно... Или нет?
Вы правы - это действительно смена одного типа сложностей на другие. Только раньше сложности были вроде 'почему empty("0") == true', а теперь - в необходимости явно описывать обработку ошибок. Как-то так получилось, что второй вариант приводит к стабильной работе системы... Странное совпадение, да? Хотя если для вас разница между хронической болезнью и здоровыми нагрузками действительно неочевидна - тогда да, просто "другая боль".
Насчёт APL всё правильно нашли.
О, статистика — это святое! Давайте тогда вернёмся к истокам: изначально проект был на PHP, где разработчиков — как песчинок в Сахаре. И что? Он "еле работал", а поддержка напоминала игру в "исправь один баг — получи два новых". Но зато специалистов много, да? Может, проблема не в языке, а в том, что хороший код пишут не толпы, а те самые 134 человека, которые хотя бы понимают, что делают?
Ну а если серьёзно — Zig выбрал не я один. Bun.sh (который рвёт Node.js по производительности), Uber (да, тот самый) и TigerBeetle (который обгоняет InfluxDB) используют его там, где важны контроль над памятью и отсутствие неожиданностей. Но да, конечно, можно и дальше верить, что "много программистов = хорошо'". PHP-то уж точно всех спасёт!
Звучит как преступление против человечества и борьба с интеллектуальным наследием.
Когда у тебя есть мешок денег и нужные связи, то предупреждение в духе "Любая часть этой книги не может быть распространенна в том или инном виде без письменого согласия редакции/автора", просто перестаёт работать и вполне себе законным путём.
Однако попробуйте без согласия с редакцией издать перевод, а точно, это другое.
Честно говоря, математика это не языка, а скорее "рафинированная физика".
Греческое слово maqanw переводится как изучаю или понимаю, maqhsiz — изучение или познание, а слово математика (maqhmatikh) раньше означало науку вообще и глубокое познание всякого предмета. Здесь также уместно напомнить, что греческое слово гипотеза (upoqesiz) первоначально означало кинематическую модель и геометрическую схему. В этом значении данным термином пользовался Птолемей. Схоласты, недолюбливавшие конструктивные методы античных математиков, сообщили слову гипотеза коннотацию сомнения и предположения, отсутствовавшие в первоначальном значении слова. Рядом с исходным словом гипотеза можно было поставить и боговдохновенное слово теория или близкое ему слово теорема; они образованы от греческого глагола qewrein — созерцать. Таким образом, три основных математических термина — гипотеза, теорема и теория — апеллируют, прежде всего, к воображению.
Ну да ладно, сейчас это всё не модно.
А можно я буду пользоваться своим мозгом и решать задачи самостоятельно, не возражаете?
А если автор использовал кодогенерацию из LLM, то прав на код нету даже у него самого - как он сможет их передать кому-то