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

когда я подступаюсь к коду :))))))))

I. Быстрая Java

Производительность в Java -- она не в каком-то конкрентном месте, это часть
культуры (анти-)качества Java. На Java можно (и нужно) писать быстрый и
качественный код, но часто не получается. Дело не в каких-то компонентах,
вроде бенчмарки говорят "у нас всё (почти) быстро", но тут потеряли немного
на неэффективном расположении данных в памяти, тут для простоты библиотеку
набросили, и так далее.

Вот, пример культуры: http://blog.mikemccandless.com/2011/03/lucenes-fuzzyquery-is-100-times-faster.html
Непонятно, как это работает, но мы переписали с Питона -- и вуаяля, прирост в
100 раз.

И наблюдается постепенная деградация, когда код скатыается в категорию "полный
энтерпрайз". И вот уже запуск тестового сервера требует 32Гб памяти, а то и
полный кубернетис. Сил не хватает, и в бой идут все. Десятки команд, полный
скрам и скрам скрамов, и все пишут, пишут код. Который, прямо скажем, не блещет
гениальностью. И таким образом, замыкает цикл Java.

Когда-то было не так. Был C, C++ и совсем ассемблер. И через отрицание C++
появилась Java. Язык выского уровня. Забыты все те устремления к идеальному
и выразительному, осталась только самая суть, объекты и их взаимоотношения.
И постепенно даже производительность подросла. И бенчмарки показывают, что
всё хорошо, быстро. Даже иногда быстрее, чем C++.

Но были те, кто говорили, что тормозит. В микро-, может, и нормально, но
макро- -- тормозит. И предлагали эксперимент, "а давайте перепишем на C++, и
сравним". И все смеялись над ними, дурачками, потому что ну нельзя же
действительно всерьёз обсуждать переписывание на C++, это в 21-то веке!

II. ...или всё-таки можно?

А почему всё-таки нельзя? Было время, когда на C++ было очень опасно
программировать. То ногу себе отстрелишь, то диск отформатируешь. Инструменты
никакущие, и все не очень совместимые. Нельзя большое приложение писать!

Потом вдруг оказалось, что можно-то и поменьше кусочки делать, и
производительность стала более конкретно в деньгах выражаться. И самое главное,
стали появляться языки, на которых и писать комфортно и проклятия Java нет.
И вот пошёл новый виток, отрицание отрицания. Частичный возврат к более
приземлённым языкам, например, Go. Или вот, например, Rust. С одной стороны --
вроде бы системный язык, всё такое низкоуровневое. Но если немного абстрагироваться
от особенностей синтаксиса и посмотреть на предлагаемые возможности, то открывается
интересная картина. Язык по выразительным возможностям очень даже ничего.
Единство противоположностей. С одной стороны, можно орудовать весьма абстрактными
понятиями (не Haskell, конечно, но всё равно), а с другой -- всегда под рукой
тяжёлая дубина попроще. Можно указателями вдарить, SIMD, макросами, или даже
просто условной компиляцией. Заимствования и подсчёт ссылок -- это, конечно,
не сборка мусора, но очень часто эргономика терпимая (меня уверяют, что даже
на C++ стало гораздо лучше жить, но я им не очень доверяю).

При этом, можно, например, что-нибудь такое навертеть: http://www.vldb.org/pvldb/vol10/p1118-li.pdf
Это, конечно, странно, сначала сделать ужасный формат, а потом его героически
парсить, но правила пишем не мы.

III. Производительность или переход количества в качество

Почему же нужна производительность, если всё упирается в базу или сеть?
Конечно, дешевле же просто докупить железа для сервисов, они же у нас масштабируются?
Железо не обходится бесплатно, тут заплатили, тут команду нарастили поддерживать,
тут вероятность отказа выросла. И опять наблюдается переход количества в качество,
там, где можно было обойтись чем-нибудь попроще, работают кластеры, огромные
команды.

А если наоборот? Там, где была bulk обработка вдруг оказывается целесообразной
реалтайм обработка, там где нужен был кластер, можно обойтись одним узлом.
Я знаю компании, которых разорили счета с AWS. Можно невооруженным взглядом
наблюдать проблемы производительности, например, на мобильных устройствах.
Какой-то жалкий Apple Music тормозит так, как будто он биткойны майнит.

(это вместо того, чтобы The Lucifer Effect почитать на поезде, хорошая, кстати, книжка)

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

Так я ж про то.и написал!

Это культура. Отказ от Java -- это не отказ от Java программистов, это отказ от культуры.

При этом можно даже от Java не отказываться :))

ну вот я например всегда старался писать оптимаильно и при этом всю карьеры писал на Java, поэтому мне странно ассоциировать это с культурой JAva. Вот enterprise - это да

не попадаю по кнопкам ((

Есть ещё более практические соображение, что один язык везде -- это или JavaScript или не-Java.

Прям плач по тем временам, когда хуй стоял, и волосы были. Существует подозрение, что кластер нужен не потому, что джава разучила всех писать код, а нагрузки подросли, потому что software eating the world и вот это всё.

JavaScript я в принципе не готов принимать, поэтому, например, Rust 🙂

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

Это в целом верно, не только про программирование

Насчёт нагрузок -- и да, и нет. Но всерьёз я не готов эту тему обсуждать. Опять же пример с JSON парсером.

Ещё был интересный момент, какой-то компонент для kubernetes-а, написанный на Java, запускается на ноду, а не на под (как хотелось бы авторам -- если я правильно помню), потому что кушает много (т.е по современным меркам-то -- копейки, но суммарно выливается). Другой пример количество-качество.

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

И мой пасквиль не был направлен в прошлое, наоборот. Именно сейчас, когда бигдата пришла в каждый дом, появились более удобные инструменты и процессы, аргумент "делать быстро -- дорого" становится менее актуален.