И надо не забывать, что в Java проверка на null с выкидыванием NPE так чудно заоптимизирована, что и не стоит по сути ничего. Если смотреть на сгенерированный машинный код из JIT то там этих проверок и нету вовсе. Всё срабатывает через Uncommon Trap и прерывание процессора.
Ну на некоторые конференции по кусочкам вытаскивают. Но да. С огромным дисклеймером, что вы смотрите в замочную скважину и никакие выводы делать нельзя.
Но, блин, ощущение нереальной фантастичности такое, что сложно просто взять и поверить. Хочется попробовать. Но ведь потом опять на работу, где этого всего нет и приходится выкручиваться. И получится как будто посмотрел очень хороший сон, и снова проснулся в серой реальности.
Иногда сложно браться за слишком хорошие вещи из боязни, что либо разочаруешься, либо расстанешься. Увы...
На поверку в дискуссионных зонах оказалось гораздо больше эксклюзива, чем в самих докладах. Вот только записывать там непонятно как, т.к. акустика далека от приемлемой. А любая попытка это улучшить технически сразу нарушит теплоту и ненавязчивость общения.
А ещё в IDEA есть специальный инструмент, показывающий во что на уровне байткода превращается код нп Kotlin. Чтобы не надо было гадать.
И да. Смотреть туда довольно полезно, если вы действительно заботитесь о производительности. Иногда довольно занятные перлы обнаруживаются. Которые, впрочем исправляются с минорными релизами, если об этом сообщать разработчикам.
Ну тут очень тонкий момент. И намой взгляд нужно смотреть в том ключе, а мешают ли те функции, которые на данный момент являются избыточными?
В случае с SVN/Git — у гита есть практически всё, что есть у SVN, но и много всего другого тоже. При этом наличие дополнительных возможносте практически никак не влияет, если его использовать как SVN. Как бы дико это не звучало. Но если понадобится, если команда дозреет, то можно просто начать использовать.
В случае с Gradle/Maven — все несколько сложнее. Да Gradle в целом функциональнее. Но это функциональность в ряде случаев может явно сыграть в минус и это ничем нельзя (пока) компенсировать.
К чему это я? А к тому, что я часто встречаю аналогичную аргументацию, мол сейчас не нужно, по этому будем использовать другое. А на практике оказывается, что когда дополнительная функциональность понадобилась — то уже поздно. Собственно, тот факт, что понадобились продвинутые функции уже и означает, что поздно. Нештатная ситуация — вот она, а средст для её разрешения нету.
Из личного опыта: у нас изначально использовался Mercurial. Хотя на первых этапах использование было в стиле SVN. Но когда понадобилось — никаких проблем.
При этом мы изначально взяли Maven. И до сих пор на нём. Но когда вылазят нестандартные ситуации, то начинается адъ и Израиль с Ant вставками. А иногда и до JavaScript вставок через Ant вставки дело доходит. Но и мигрировать на Gradle не можем т.к. энтерпрайз, много больших команд и нету полного доверия между разработчиками (привет вашему докладу с Барухом).
Так что не всё так однозначно и надо подходить к вопросу вдумчиво и осторожно.
Спасибо, но я уже успел его найти и изучить. Просто у меня минисервер на Intel Atom (x86). По этой причине приходится пересобирать образа под себя самостоятельно. Ну а уж коли пересобираю, то за одно вношу коррективы для облегчения себе жизни.
А что до вашего образа, то он довольно сильно расходится с моими представлениями о правильности и качестве. Уж извините…
И надо не забывать, что в Java проверка на null с выкидыванием NPE так чудно заоптимизирована, что и не стоит по сути ничего. Если смотреть на сгенерированный машинный код из JIT то там этих проверок и нету вовсе. Всё срабатывает через Uncommon Trap и прерывание процессора.
Огромное спасибо за комментарий. Надо будет распечатать и вложить прямо в книгу.
С flocker теперь непонятно что будет: https://techcrunch.com/2016/12/22/clusterhq-hits-the-deadpool/
Хотя надежды есть: https://twitter.com/thenewstack/status/812016009163001856
А тут доклад на эту тему: https://www.youtube.com/watch?v=hRepfVJZvhY
Про AOT, в смысле.
Ну на некоторые конференции по кусочкам вытаскивают. Но да. С огромным дисклеймером, что вы смотрите в замочную скважину и никакие выводы делать нельзя.
Но, блин, ощущение нереальной фантастичности такое, что сложно просто взять и поверить. Хочется попробовать. Но ведь потом опять на работу, где этого всего нет и приходится выкручиваться. И получится как будто посмотрел очень хороший сон, и снова проснулся в серой реальности.
Иногда сложно браться за слишком хорошие вещи из боязни, что либо разочаруешься, либо расстанешься. Увы...
Просто JVM дзен высших порядков какой-то. Огромное спасибо за статью.
А насколько это вот всё годится для продакшена? Или строго только для экспериментов?
Чего лично я не смог получить от swarm mode — поддержка сетевых плагинов. Так что ксли нужен кластерный дискавери, то ой...
Конено нет. Это просто данные на диске лежат.
А программа конференции известна? По ссылкам найти не смог.
Вот да. Люто плюсую.
На поверку в дискуссионных зонах оказалось гораздо больше эксклюзива, чем в самих докладах. Вот только записывать там непонятно как, т.к. акустика далека от приемлемой. А любая попытка это улучшить технически сразу нарушит теплоту и ненавязчивость общения.
Я на некоторые доклады даже не пошёл, чтобы в дискуссионных зонах поторчать.
Прикольная модель получилась.
У меня после каждого запуска оставалось по два джедая. В результате попробовал сразу только двух ставить — и они выживали без проблем.
Аутентичненько...
Что-то видео всё нет и нет… А можно какие нибудь прогнозы, когда выложите?
А ещё в IDEA есть специальный инструмент, показывающий во что на уровне байткода превращается код нп Kotlin. Чтобы не надо было гадать.
И да. Смотреть туда довольно полезно, если вы действительно заботитесь о производительности. Иногда довольно занятные перлы обнаруживаются. Которые, впрочем исправляются с минорными релизами, если об этом сообщать разработчикам.
Так в этом и вся суть. Таких разработчиков на всех не хватит точно.
Имею в виду, что адрес 0.0.0.0 по идее резолвиться не может. Или это кем-то обеспечивается?
А можете пояснить следующую команду?
Как она вообще может работать? Что я упускаю?
В случае с SVN/Git — у гита есть практически всё, что есть у SVN, но и много всего другого тоже. При этом наличие дополнительных возможносте практически никак не влияет, если его использовать как SVN. Как бы дико это не звучало. Но если понадобится, если команда дозреет, то можно просто начать использовать.
В случае с Gradle/Maven — все несколько сложнее. Да Gradle в целом функциональнее. Но это функциональность в ряде случаев может явно сыграть в минус и это ничем нельзя (пока) компенсировать.
К чему это я? А к тому, что я часто встречаю аналогичную аргументацию, мол сейчас не нужно, по этому будем использовать другое. А на практике оказывается, что когда дополнительная функциональность понадобилась — то уже поздно. Собственно, тот факт, что понадобились продвинутые функции уже и означает, что поздно. Нештатная ситуация — вот она, а средст для её разрешения нету.
Из личного опыта: у нас изначально использовался Mercurial. Хотя на первых этапах использование было в стиле SVN. Но когда понадобилось — никаких проблем.
При этом мы изначально взяли Maven. И до сих пор на нём. Но когда вылазят нестандартные ситуации, то начинается адъ и Израиль с Ant вставками. А иногда и до JavaScript вставок через Ant вставки дело доходит. Но и мигрировать на Gradle не можем т.к. энтерпрайз, много больших команд и нету полного доверия между разработчиками (привет вашему докладу с Барухом).
Так что не всё так однозначно и надо подходить к вопросу вдумчиво и осторожно.
А что до вашего образа, то он довольно сильно расходится с моими представлениями о правильности и качестве. Уж извините…