то есть, если у нас, например, раньше было по одному инстансу на все части приложения (бек, база и тд), а потом этого перестало хватать, у нас случился хайлоад. Потом мы сделали систему распределенной, и она стала справляться с нагрузкой. Ноды больше не ложатся, базы не ложатся, аптайм всей системы 100%. Это значит, у нас больше не хайлоад?

У фшарпа неудобно трехсторонние дифы смотреть из-за идентации

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

Есть вещи, которые надо делать всегда. Там, не писать совсем говна на рефлексии, не закладываться на то, что у тебя один инстанс аппы будет

Потому что проще сделать приличными кучу совсем мелких сервисов, чем один монолит. В нормальное проектирование монолитов мало кто умеет

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

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

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

Ну амазон тоже просто сайтик!!1

С идеей, что хайлоад измеряется не цифрами, а симптомами я согласен

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

с 4к и прочим не хочу брать просто потому что у меня на всех дистрибутивах вечно жопа подгорает с масштабированием

Трогал один раз говнокод индусов на J#

Сделаем там type erasure, а потом придумаем смишные расширения, чтобы с ним бороться.

Самое смешное в type erasure то, что его в упор не считают проблемой

А чем jvm не устраивает?

По-настоящему смешно было, когда скалисты не смогли портироваться на CLR из-за того, что у нас нету type erasure :)

Почему я обязан заранее знать, сколько моей программе нужно памяти?

Щас нужно один гиг, а завтра десять.

Почему я обязан заранее знать, сколько моей программе нужно памяти?

Блин, я думал только я это не понимаю

Блин, я думал только я это не понимаю

Сразу видно, что ты не ява-разработчик!

Не, ну для сервера иногда мы можем узнать верхнюю границу доступных ресурсов, или сколько мы «в среднем» готовы выделить.

А я ява-разработчик, но всё равно не понимаю :)

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

Сразу видно, что ты не ява-разработчик!

И переписать все GC, чтобы они учитывали этот параметр (мухаха)

Да, возможно, у них аллокации более быстрые, или GC шустный, я не замерял. Но жрёт памяти оно как не в себя, а тюнинг этого всего через -Xmx не радует глаз вообще.

Вот кстати да. А теперь усложним задачу, на одной ноде намеренно запускается два разных распределенных процесса чтобы эти процессы могли коллокейтится на этой и других нодах и делать РПЦ без нетворка. Вопрос - как этими ебаными параметрами управлять памятью???

Вот кстати да. А теперь усложним задачу, на одной ноде намеренно запускается два разных распределенных процесса чтобы эти процессы могли коллокейтится на этой и других нодах и делать РПЦ без нетворка. Вопрос - как этими ебаными параметрами управлять памятью???

То есть надо сказать что допустим этому процессу 50гб, и этому 50гб. А есть моменты когда один жрет, второй не жрет

И чо тогда, насильно его кормить?

Короче, жвм разочаровывает

Ты испорчен CLR, в которой всё просто берёт и работает.

Ну как-то жава разработчики более нетерпимы к другим платформам

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

Я Java-разработчик, и вполне терпим :3

Ну там оптимизаций вагон, которые нам не нужны так как есть стак, валуе типы и генерики

Не, их вагон оптимизаций бы и нам тоже пригодился, на самом деле.

Вот где куча снобизма, это у скалистов

Если твое решение не включает в себя пару алгебр - это априори плохое решение.

Ещё пару дуплоидов

Пара дуплоидов образует дуплодок