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

мол там не хватает эвентлупа и асинхронности.

далее ворвался Антон Титов, и сказал что разговоры о плохих языках это особенность русских. В США эти вопросы редко поднимаются. Там просто берут задачу, бюджет, срок и говорят кто сделает?

И обычно в этой игре выигрывают сишарп, ява или пхп.

Это территория бизнес логики и эти языки там ок.

Вообще я не верю в лучшие языки или фреймворки. Верю в команды и крутых программистов, которые могут решать задачи.

раст, си++, голанг, это история про хайлоад, про рокет сайнс.

тема же началась про то что на тему хайлоада и так уже хватает разговоров. тема перегрета. и мне кажется там все понятно.

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

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

То, что вы называете "хайэкстенсибл", в моем мире обычно C++. Хотя иногда там появляются Java и Python.

А если нет большой нагрузки, то вообще пофиг на чем и как писать. Костылями можно закидать бизнес-логику любого уровня сложности :)

вероятно мы говорим одно слово, но вкладываем туда разные значения )

хайэкстенсибл - это расширяемость системы.

она противоположна скорости. и эффективности. она про антихрупкость.

мы не можем нагреть и охладить продукт одновременно. надо выбирать. вот хайлоад и хайэкстенсибл это такие же процессы.

расширяемые системы строяется на позднем связывании, событиях, доменах.

позволяют решать боль разработки в больших системах, когда идет переиспользование кода, исключение конфликтов между командами и взаимных блокировок.

эта тема которая сейчас болит в моей голове. и потому я копаю ее. ищу интересные примеры и практики именно в этой области

Мой опыт говорит о том, что расширяемость и скорость не противоположны.
Мало кто умеет умеет нормально проектировать это факт

ну в принципе идеи построения больших систем давно существуют и развиваются - message passing, компонентное программирование, erlang otp, микросервисы

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

И я так и не понял какую проблему вы пытаетесь решить

Видимо у нас разный опыт )

Я не видел систем в которых ростет функционал и скорость одновременно.

Чем больше функционал и сложность - тем ниже скорость.

Когда решаются задачи скорости, то в первую очередь уходят в микросервисы и упрощают систему. Чем меньше кода, тем легче получить скорость.

Тоже самое написано в книге Антихрупкость, автор Нассим Талеб.

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

Конечно это можно понять по разному. И даже в погоне за правильными словами наделать дичи )

ну мотивация описана в статье

и тогда это противоречие исчезает - внутри подсистема делается со строгой типизацией и высокой производительностью, а вот между системами гуляют сообщения и опционально - асинхронная связь или графы процессов

да это круто работает когда у тебя 1000 программистов. ты берешь, выделяешь какое то узкое горлышко в микросервис, садишь туда 10 прогеров и они начинают делать круто.

но это территория Амазона, Гугла, Яндекса.

есть обратная сторона этой медали. молодые программисты ходят но конференции, слушают все эти истории про то что микросервисы это очень круто.

берут и запиливают 15 микросервисов в команде на 10 программистов. а потом умирают )

и задача "мы добавили в API новый параметр и должны одномоментно переделать все подсистемы где он задействован" превращается в "мы добавили новый опциональный параметр и можем в любом порядке обновлять модули использующие и реализующие этот API"

я пришёл к этой проблеме в своём единоличном проекте, правда долгосрочном

доклад айспринга, говорит как раз об этом. о том что микросервисы это зло, если их применять вне соответствующего контекста. и предлагает альтернативный путь - получая преимущества монолита и микросервисов - 2 в 1.

мне кажется, это и есть компонентная архитектура, нет?

Мы в iFunny уже много лет практикуем DDD и чистую архитектуру, при этом мы highload - 2 миллиона DAU, 20k RPS в пике только в PHP-монолит, 500к строк кода, фейспалмим каждый раз, когда кто-то начинает рассказывать, как они пилят на миклоселвисы свой огромный монолит в 50к строк.

https://www.youtube.com/watch?v=9xoP9GCUoDU - вот наш доклад о том, как мы это сделали сами и рекомендуем всем желающим.

она самая

т.е. проблема отсутствия фундаментального образования, благо что software engineering даже в вузах мало кто учит