будет ли код на си работать быстрее - будет. Но сколько хороших разработчиков на рынке си и пыхе. Очевиднее на пыше больше.. Для бизнеса важнее что бы было больше разработчиков на рынке, чем скорость работы кода.

та это сорказм был, посыл то не в этом

"будет ли код на си работать быстрее - будет" - а время ответа сервера при этом будет таким же внезапно

ну вот Visa - вполне себе бизнес, у них ядро по слухам крутится на ibm менйнфреймах , а core язык - кобол .
Ну т.е. вот нет. Бизнес, бизнесу рознь

ну вот есть проект. Начало свое берет вроде с 2010 - 2011 года. Код написан крайне плохо. И так что приходится поддреживать этот легаси сейчас. Так как переписать его дороже чем сделать очередной костыль. Но из-за этого проект не может развиваться в стек технологиях. По стеку  часть осталось на уровне 2012 года, а другая часть на 2016 году. И этого его потолок.  И в чем же плохи крайности? А если бы сразу делали бы нормально, то он бы и дальше бы рос.

не ну если ты сайт-визитки и лендинги делаешь то да. А если что сложнее то скорость работы кода на сервере тоже важна.

Разница в скорости выполнения кода в обычной бэкенд-разработке (ну, API, например, и т.п.) практически ни на что не влияет. Большую часть времени занимают сетевые издержки и выполнение запросов в базе данных. Если речь о какой-нибудь тяжёлой обработке видео и картинок, допустим, то да, разница, конечно, будет ощутима.

Нормально: это всегда в ретроспективе. Т.е. глядя назад видится как было бы правильно. Потому что опыт уже есть.
А в момент принятия решения, никакого "нормально" нет.
По большому счету, что бы что то менять, нужно уметь быстро проверять, что твои изменения ничего не поломали.
Т.е. нужно авто тестов вагон .
Ну вот не сделали их вначале, что мешает их сейчас делать. ?
Подпереть инфраструктуру большим количеством автотестов , описать базовые процессы (если они не описаны).
Да и бить приложение на функциональные зоны и потихоньку рефакторить?

такой легаси не затронет только один из стеков, он полностью протух

и тот баланс, который там достигли также

"хочешь хорошо делай хорошо" и прочие мудрости из категории "Даша путешественница"

Меня задело утверждение про "очередь может потерять сообщение". Отсюда рассуждения о транспортах

Через 5 лет активно развивающийся продукт пару раз успеет сменить какие-то инфраструктурные вещи но как правило это не полный переезд и всеравно много чего придется менять (не дёшево)

Большинство столько не живут (шоб активно развиваться при этом).

т.е. ты при проектировании не учитываешь, то что у тебя один из узлов может умереть с потерей данных? Я согласен когда цена этому 0, но цена может быть и не 0. Все зависит от задачи. И я просто хотел пердупредить что никто не бэкапит очередь, а вот базы бэкапят. И проще хранить в базе и по крону слать сообщение тогда когда их надо обработать.

Один узел умер, остальные нет, репликация кворумы, подтверждение записи

Если у тебя нормального брокера нет то да лучше в базе, да даже если нормальный брокер есть кейс с отложенным выполнением это не зона ответственности брокера

всем привет, вопрос немного специфичный, ответа в интернете не нашел

запускаю symfony serve, почему у меня сайт доступен с http://127.0.0.1:34249 (рандомныый порт каждый перезапуск)
и с
http://127.0.0.1:8000/

но!, у 8000 есть такая бляшка, которая на картинке отображена

в чем вообще проблема?

phpstorm при подключении xdebug не узнает каждый раз при перезапуске symfony serve проект и создает новый server, и приходится маппинги вручную выставлять (ну точнее просто клонировать существующие и порт в них менять)

что терпимо (дел на 30 сек), но все же неудобно, может быть можно задать

[Web Server ] Dec 13 12:40:45 |INFO   | PHP    listening path="/usr/bin/php8.1" php="8.1.0" port=34249

на нужный именно мне порт?

Никогда не запускай таким образом в продакшене это дерьмо все не используется разворачивай либо в докере либо в Linux устанавливая все необходимые сервера...