Как это reflection ничего не стоит при исполнении? А как же SecurityManager? Каждый вызов метода или обращение к полю идёт через него. И если выключить рефлексию на уровне JVM, то он будет выбрасывать исключение. Всё это требует ресурсов.
Плохо вяжется утверждение о том, что динамические языки принципиально медленные, с тем, что динамические среды исполнения могут спекулировать и выносить предположения за пределы горячего кода - казалось бы, можно перед горячим циклом убедиться, что на вход переданы, как и обычно в этот метод, числа, после чего дробить их с той же эффективностью, что и в любом другом языке, чем тот же V8 довольно успешно и занимается
Не понимаю в чем проблема с этим утверждением. Динамическим языкам надо выводить типы в рантайме, чтобы все быстро работало. Но есть особенность, что многие пишут мегаморфный код - тут уже ни один JIT не сможет вывести типа
@@valerysmirnov9535 ну какой-то оверхед, конечно, есть, но в контексте кода, которому действительно критична производительность, его вклад минимален на практике (кто-то же пишет зачем-то на JS микросервисы, работающие под заметной нагрузкой - и вполне себе сносный получают перформанс). А так можно, конечно, долго говорить о том, как круто писать шаблонный код на C++, у компилятора будет информация про весь поток исполнения, никаких виртуальных функций, оптимизация полиморфного кода под каждый контекст отдельно с большим временным бюджетом на компиляцию - куда уж там джаве с её вездесущими ссылками, виртуальными функциями и проверками на null. На практике же, хотя такой взгляд не то чтобы оторван от реальности, оказывается, что усилиями разработчиков рантаймов удаётся в значительной степени побороться со всем: короткоживущие объекты скаляризуются, методы девиртуализируются, проверки на null (если не стреляют) вообще в обработчик SIGSEGV вынесены - и производительность вполне сопоставимая
@valerysmirnov9535 ну какой-то оверхед, конечно, есть, но в контексте кода, которому действительно критична производительность, его вклад минимален на практике (кто-то же пишет зачем-то на JS микросервисы, работающие под заметной нагрузкой - и вполне себе сносный получают перформанс). А так можно, конечно, долго говорить о том, как круто писать шаблонный код на C++, у компилятора будет информация про весь поток исполнения, никаких виртуальных функций, оптимизация полиморфного кода под каждый контекст отдельно с большим временным бюджетом на компиляцию - куда уж там джаве с её вездесущими ссылками, виртуальными функциями и проверками на null. На практике же, хотя такой взгляд не то чтобы оторван от реальности, оказывается, что усилиями разработчиков рантаймов удаётся в значительной степени побороться со всем: короткоживущие объекты скаляризуются, методы девиртуализируются, проверки на null (если не стреляют) вообще в обработчик SIGSEGV вынесены - и производительность вполне сопоставимая
@@АдамСмит-ы7р мы дошли до того уровня развития процессоров, что в айтишке стало мейнстримом делать вещи самым неэффективным образом Если я могу сделать нормально - сделают нормально Кроме C и плюсов есть куча компилируемых языков с большим количеством статических гарантий
Не холливара ради, просто мнение - в современном ландшафте с контейнеризацией ИМХО JVM выглядит лишним звеном. Кажется, что прямая упаковка в контейнер какого-нибудь собранного под Linux гошного сервиса выглядит более оптимальной по ресурсам и принципу работы. Ну и может быть еще когда-нибудь допилят WASM edge-servers. Пока все они что я видел чистый proof of concept и не вывозят ни по какому параметру.
WASM же никто не будет руками писать... так какая разница с чего будем компилить? Если прям совсем не кошерно в Java AOT - есть реализации, где можно .class байткод в WASM компилить, со Scala и Kotlin можно сразу. А JVM в контейнерах такой же лишниий, как Node.js или любой vm рантайм, если контейнеров по несколько десятков штук на условном хосте.
@@qandak Соглашусь, рантайм в контейнере тоже костыль. Гошечка - для попсы и раст для любителей - и то и другое нормально пишется и собирается в бинарник, который в скратч и кладем. Все! И да, WASM руками конечно не будут писать. И не особо важно из чего он будет компилится. Тут скорее удобно, что у нас по сути есть рантайм для него в составе самого сервера. Хотя, по чесноку это примерно как NJS для nginx - на этом можно написать логику, но зачем? ИМХО, может я его не так понимаю, легко заблудится в маркетинговой мишуре.
Привет! Часто среди коллег слышу похожее мнение. Короткий ответ - JIT компилятор. Чуть более развернуто - умные дядьки, которые в индустрии очень давно, убеждены, что будущее за интерпретируемыми языками. Именно из-за того, что агрессивные оптимизации их рантаймов + анализ реального исполнения кода будут давать преимущество в перфомансе над компилируемыми в машинный код языками.
