Как это reflection ничего не стоит при исполнении? А как же SecurityManager? Каждый вызов метода или обращение к полю идёт через него. И если выключить рефлексию на уровне JVM, то он будет выбрасывать исключение. Всё это требует ресурсов.
Не холливара ради, просто мнение - в современном ландшафте с контейнеризацией ИМХО JVM выглядит лишним звеном. Кажется, что прямая упаковка в контейнер какого-нибудь собранного под Linux гошного сервиса выглядит более оптимальной по ресурсам и принципу работы. Ну и может быть еще когда-нибудь допилят WASM edge-servers. Пока все они что я видел чистый proof of concept и не вывозят ни по какому параметру.
WASM же никто не будет руками писать... так какая разница с чего будем компилить? Если прям совсем не кошерно в Java AOT - есть реализации, где можно .class байткод в WASM компилить, со Scala и Kotlin можно сразу. А JVM в контейнерах такой же лишниий, как Node.js или любой vm рантайм, если контейнеров по несколько десятков штук на условном хосте.
@@qandak Соглашусь, рантайм в контейнере тоже костыль. Гошечка - для попсы и раст для любителей - и то и другое нормально пишется и собирается в бинарник, который в скратч и кладем. Все! И да, WASM руками конечно не будут писать. И не особо важно из чего он будет компилится. Тут скорее удобно, что у нас по сути есть рантайм для него в составе самого сервера. Хотя, по чесноку это примерно как NJS для nginx - на этом можно написать логику, но зачем? ИМХО, может я его не так понимаю, легко заблудится в маркетинговой мишуре.
Привет! Часто среди коллег слышу похожее мнение. Короткий ответ - JIT компилятор. Чуть более развернуто - умные дядьки, которые в индустрии очень давно, убеждены, что будущее за интерпретируемыми языками. Именно из-за того, что агрессивные оптимизации их рантаймов + анализ реального исполнения кода будут давать преимущество в перфомансе над компилируемыми в машинный код языками.
@@alexeialexei7910 Привет! Ну, возможно, однако в компилируемых так же есть сходные инструменты. Например PGO в гошечке. Да и микросервисный подход скорее всего будет давать практически сразу оптимальный код, а общая тенденция все же идти в эту сторону, насколько я понимаю. Но в целом интересно, я думал что в основном просто по привычке идут в этом стеке, типа "Уже столько всего написано, что глупо менять", что тоже валидный аргумент, в общем-то.
Плохо вяжется утверждение о том, что динамические языки принципиально медленные, с тем, что динамические среды исполнения могут спекулировать и выносить предположения за пределы горячего кода - казалось бы, можно перед горячим циклом убедиться, что на вход переданы, как и обычно в этот метод, числа, после чего дробить их с той же эффективностью, что и в любом другом языке, чем тот же V8 довольно успешно и занимается
Не понимаю в чем проблема с этим утверждением. Динамическим языкам надо выводить типы в рантайме, чтобы все быстро работало. Но есть особенность, что многие пишут мегаморфный код - тут уже ни один JIT не сможет вывести типа
@@valerysmirnov9535 ну какой-то оверхед, конечно, есть, но в контексте кода, которому действительно критична производительность, его вклад минимален на практике (кто-то же пишет зачем-то на JS микросервисы, работающие под заметной нагрузкой - и вполне себе сносный получают перформанс). А так можно, конечно, долго говорить о том, как круто писать шаблонный код на C++, у компилятора будет информация про весь поток исполнения, никаких виртуальных функций, оптимизация полиморфного кода под каждый контекст отдельно с большим временным бюджетом на компиляцию - куда уж там джаве с её вездесущими ссылками, виртуальными функциями и проверками на null. На практике же, хотя такой взгляд не то чтобы оторван от реальности, оказывается, что усилиями разработчиков рантаймов удаётся в значительной степени побороться со всем: короткоживущие объекты скаляризуются, методы девиртуализируются, проверки на null (если не стреляют) вообще в обработчик SIGSEGV вынесены - и производительность вполне сопоставимая
@valerysmirnov9535 ну какой-то оверхед, конечно, есть, но в контексте кода, которому действительно критична производительность, его вклад минимален на практике (кто-то же пишет зачем-то на JS микросервисы, работающие под заметной нагрузкой - и вполне себе сносный получают перформанс). А так можно, конечно, долго говорить о том, как круто писать шаблонный код на C++, у компилятора будет информация про весь поток исполнения, никаких виртуальных функций, оптимизация полиморфного кода под каждый контекст отдельно с большим временным бюджетом на компиляцию - куда уж там джаве с её вездесущими ссылками, виртуальными функциями и проверками на null. На практике же, хотя такой взгляд не то чтобы оторван от реальности, оказывается, что усилиями разработчиков рантаймов удаётся в значительной степени побороться со всем: короткоживущие объекты скаляризуются, методы девиртуализируются, проверки на null (если не стреляют) вообще в обработчик SIGSEGV вынесены - и производительность вполне сопоставимая
@@АдамСмит-ы7р мы дошли до того уровня развития процессоров, что в айтишке стало мейнстримом делать вещи самым неэффективным образом Если я могу сделать нормально - сделают нормально Кроме C и плюсов есть куча компилируемых языков с большим количеством статических гарантий
![HIWWHEE | OHM [Official MV]](http://i.ytimg.com/vi/OJJLtTLqLag/mqdefault.jpg)
Прекрасное интервью!
Пожалуйста, пригласите на следующие подкасты Евгения Борисова или Павла Финкельштейна
Вооо, неужели интересный выпуск! Гораздо лучше, чем очередная охуительная история про переезд в очередную страну.
лампово. Гость позитивный👍
Супер интересно, спасибо ❤❤❤
Тяжело было за раз осилить из-за длины. Но за несколько заходов осилил - было интересно.
История с переходом из Оберона на Джаву у меня была та же, только лет на 10 позже.
А теперь посмотрите тесты java и JavaScript на bun и удивитесь "медленности" жса. Современные движки жс создают точно такой же байт код.
Как это reflection ничего не стоит при исполнении? А как же SecurityManager? Каждый вызов метода или обращение к полю идёт через него. И если выключить рефлексию на уровне JVM, то он будет выбрасывать исключение. Всё это требует ресурсов.
Наконец-то!
Не холливара ради, просто мнение - в современном ландшафте с контейнеризацией ИМХО JVM выглядит лишним звеном. Кажется, что прямая упаковка в контейнер какого-нибудь собранного под Linux гошного сервиса выглядит более оптимальной по ресурсам и принципу работы. Ну и может быть еще когда-нибудь допилят WASM edge-servers. Пока все они что я видел чистый proof of concept и не вывозят ни по какому параметру.
WASM же никто не будет руками писать... так какая разница с чего будем компилить? Если прям совсем не кошерно в Java AOT - есть реализации, где можно .class байткод в WASM компилить, со Scala и Kotlin можно сразу.
А JVM в контейнерах такой же лишниий, как Node.js или любой vm рантайм, если контейнеров по несколько десятков штук на условном хосте.
@@qandak Соглашусь, рантайм в контейнере тоже костыль. Гошечка - для попсы и раст для любителей - и то и другое нормально пишется и собирается в бинарник, который в скратч и кладем. Все!
И да, WASM руками конечно не будут писать. И не особо важно из чего он будет компилится. Тут скорее удобно, что у нас по сути есть рантайм для него в составе самого сервера. Хотя, по чесноку это примерно как NJS для nginx - на этом можно написать логику, но зачем? ИМХО, может я его не так понимаю, легко заблудится в маркетинговой мишуре.
Привет! Часто среди коллег слышу похожее мнение.
Короткий ответ - JIT компилятор. Чуть более развернуто - умные дядьки, которые в индустрии очень давно, убеждены, что будущее за интерпретируемыми языками. Именно из-за того, что агрессивные оптимизации их рантаймов + анализ реального исполнения кода будут давать преимущество в перфомансе над компилируемыми в машинный код языками.
@@alexeialexei7910 Привет! Ну, возможно, однако в компилируемых так же есть сходные инструменты. Например PGO в гошечке. Да и микросервисный подход скорее всего будет давать практически сразу оптимальный код, а общая тенденция все же идти в эту сторону, насколько я понимаю. Но в целом интересно, я думал что в основном просто по привычке идут в этом стеке, типа "Уже столько всего написано, что глупо менять", что тоже валидный аргумент, в общем-то.
Плохо вяжется утверждение о том, что динамические языки принципиально медленные, с тем, что динамические среды исполнения могут спекулировать и выносить предположения за пределы горячего кода - казалось бы, можно перед горячим циклом убедиться, что на вход переданы, как и обычно в этот метод, числа, после чего дробить их с той же эффективностью, что и в любом другом языке, чем тот же V8 довольно успешно и занимается
Не понимаю в чем проблема с этим утверждением. Динамическим языкам надо выводить типы в рантайме, чтобы все быстро работало. Но есть особенность, что многие пишут мегаморфный код - тут уже ни один JIT не сможет вывести типа
@@valerysmirnov9535 ну какой-то оверхед, конечно, есть, но в контексте кода, которому действительно критична производительность, его вклад минимален на практике (кто-то же пишет зачем-то на JS микросервисы, работающие под заметной нагрузкой - и вполне себе сносный получают перформанс).
А так можно, конечно, долго говорить о том, как круто писать шаблонный код на C++, у компилятора будет информация про весь поток исполнения, никаких виртуальных функций, оптимизация полиморфного кода под каждый контекст отдельно с большим временным бюджетом на компиляцию - куда уж там джаве с её вездесущими ссылками, виртуальными функциями и проверками на null. На практике же, хотя такой взгляд не то чтобы оторван от реальности, оказывается, что усилиями разработчиков рантаймов удаётся в значительной степени побороться со всем: короткоживущие объекты скаляризуются, методы девиртуализируются, проверки на null (если не стреляют) вообще в обработчик SIGSEGV вынесены - и производительность вполне сопоставимая
Приходи на собес и доказывай чо хошь. ))))
@valerysmirnov9535 ну какой-то оверхед, конечно, есть, но в контексте кода, которому действительно критична производительность, его вклад минимален на практике (кто-то же пишет зачем-то на JS микросервисы, работающие под заметной нагрузкой - и вполне себе сносный получают перформанс).
А так можно, конечно, долго говорить о том, как круто писать шаблонный код на C++, у компилятора будет информация про весь поток исполнения, никаких виртуальных функций, оптимизация полиморфного кода под каждый контекст отдельно с большим временным бюджетом на компиляцию - куда уж там джаве с её вездесущими ссылками, виртуальными функциями и проверками на null. На практике же, хотя такой взгляд не то чтобы оторван от реальности, оказывается, что усилиями разработчиков рантаймов удаётся в значительной степени побороться со всем: короткоживущие объекты скаляризуются, методы девиртуализируются, проверки на null (если не стреляют) вообще в обработчик SIGSEGV вынесены - и производительность вполне сопоставимая
@@АдамСмит-ы7р мы дошли до того уровня развития процессоров, что в айтишке стало мейнстримом делать вещи самым неэффективным образом
Если я могу сделать нормально - сделают нормально
Кроме C и плюсов есть куча компилируемых языков с большим количеством статических гарантий
Никак не разберусь, почему через сутки работы спарк-приложение в yarn падает с java heap space. И честно говоря, мне уже хочется знать о jvm ничего.
Оказалось, всё дело в том, что кто-то добавил sys.addShutdownHook из-за чего объекты не собирались GC
мужик как будто на тех.собесе сидит
Как можно уйти из Huawei в JetBrains, что за бред.
Вы пробовали работать в китайской компании и культуре? Я вот от коллег наслышан, что это очень специфический опыт.
@@alexmatveev7246 И пробовал, и наслышан - всё ок. В то же время в нынешней JetBrains атмосфера абсолютно больная.
Надоело быть лидом 50 китайев и захотелось на пенсию в микро-команды из 3-4 синьёрс-онли и лидс-онли?
Из Huawei [Novosibirsk, Russia] в JetBrains [Limassol (Lemesos), Cyprus], если говорить точнее. То есть из Russia в Cyprus.
@@mrkandreev продолжайте искать корреляции.