если я правильно понимаю у нас есть язык баш, т.е набор команд, а есть оболочка, куда мы эти команды вводим
На этапе "мне важнее скорость, чем согласованность/целостность данных" почти наверняка особой разницы между нормально настроенным мускулем и нормально настроенным постгресом не будет.
Если те, кто разрабатывает приложение и обслуживает базу лучше знает эту софтину, чем постгрес.
Поэтому хочется иметь дублирующий механизм который просто по тайм-ауту будет выполнять проверки. (нет новостей 5 минут? Окей, проверим сами). Но он не запускается если оповещения приходят достаточно часто.
Ладно, называйте их все языками программирования. Но все эти сравнения абсолютно не уместны. Bash и прочие шеллы - это совсем иное, чем python и языки программирования, совсем разное назначение. Про "библиотеки" слышать забавно, сами же писали про высокие затраты на fork.
Другое дело никто не назовет это библиотеками, даже при микросервисной архитектуре, сервисы разносятся совсем не потому что ЯП не позволяет писать эти сервисы.
И вообще, говорить про то, что любая консольная команда становится "библиотекой" можно только, если вы не писали на bash ничего более-менее сложного. Если бы писали, то знали, что вывод многих команд очень слабо подходит для машинной обработки, и дело не в хитрых манипуляциях в sed, а в том что нельзя гарантировать, что в выводе что-то неожиданно не изменится. Любой разработчик, знает что такое API, и знает что выше описанный подход - хрень полная.
Не игнорируйте, расскажите, как вы будете складывать числа с плавающей точкой в этом универсальном ЯП. Не забудьте рассказать про затраты на fork. Ну и параллельно, расскажите что же там за типы integer и array при таких вычислениях. Я прекрасно понимаю, что это вызов внешних команд, но не я заявлял, что они библиотеки.
И это просто элементарные вычисления, мы даже близко не рассматривали математический аппарат настоящих ЯП, и тем более такого языка как python.
Примитивный - это не попытка обидеть вашу любимую игрушку, это констатация факта. Если в python вы положите команду в переменную, она не начнет выполнятся при выводе на экран. Чтобы добится такого же поведения в python, нужно взять динамический код, заменить переменные через тупо подстановку строк, а затем выполнить через внутреннюю команду исполнения кода. И, привет от инъекций кода. Кто писал внутренние языки прекрасно это знают, остальные знают по sql-инъекциям.
Т.е. дело не просто в экранировании, проблема глубже в отсутствии разделения данных и кода, для командного процессора - это нормально, для ЯП - это ад.
Это не проблема, мы сознательно жертвуем производительностью ради более удобной и легко контролируемой структуры. Либо не жертвуем в тех местах, где иные приоритеты (и вообще возьмем какой-нибудь Go или Си). Но писать про это предлагая взамен полное копирование всех страниц памяти интерпретатора (fork) даже при элементарных операциях - это показывать полное непонимание на чем можно экономить, а на чем нельзя.
Тоже самое про контейнеры, вы не понимаете, что каждый инструмент имеет область применимости. Никто не придет к вам домой инспектировать ваш комп на наличие вагранта. Но при разработке стек бывает достаточно большой, с сложными зависимостями, сторого определенными версиями продуктов, и чтобы развернуть это все с нуля потребуется не час и не два.
Ну не я же писал, что циклов и ветвлений достаточно, а структуризация ненужный "оверинженерниг".
Если вам в жизни удастся поуправлять самолетом, вы не станете пилотом. Работа с памятью один из важнейших моментов, даже на языках более высокоуровневых. Они вам дадут более безопасную работу с типами в отличии от Си, но не смогут за вас контролировать ее использование. А вы пишите, что вполне нормально копировать все страницы памяти, для простейших операций.
Но, работая с Си, вы должны были заметить отличия в разделении кода и данных, кастомных типах позволяющих создавать сложные типы данных и огромное кол-во функционала который позволяет назвать Си универсальным языком программироавния в отличии bash специализирующего на запуске команд.