Я тоже согласен с @Plesserи тоже выберу при прочих равных человека с pet project'ами, горящими глазами и вот это вот всё. Но не согласен с тем, что сессия - это какой-то незначительный стресс. Для многих, в том числе для меня, любое "испытание", которое лишь косвенно связано с профессиональными навыками, такое как сессия, собеседование, публичное выступление и т.п. - это колоссальный стресс. Даже после десятков повторений процедур, даже если они сами по себе могут нравиться.
В современных чипах это ветвление занимает ноль тактов.
Ну я вполне втыкался в производительность branch-miss'ов, для этого есть даже хрестоматийный пример, который вы можете воспроизвести и у себя: наивное чтение var-int'ов с помощью цикла. В этом случае у предсказателя переходов слишком высокая доля ошибок. Тривиальное лечение - вручную развернуть цикл, чтобы у таблицы переходов были разные адреса, и тогда если у вас в горячем цикле var-int'ы примерно одного размера, то всё починится само. Если у вас совсем произвольные var-int'ы, тогда есть чуть более сложные техники.
Тем не менее, даже в случае, если у вас всё хорошо предсказывается, таблицы предсказания ветвлений в процессорах не бесконечные. Руками вы конечно вряд ли их забьёте, но если начнёте генерировать код с избыточным ветвлением, то статистика предсказаний вполне может начать вытесняться.
Мне это всегда казалось и продолжает казаться неплохим способом проверить замотивированность кандидата заниматься относительно длительной подготовкой к интервью. Примерно как диплом о ВО доказательство 4-6 лет "усидчивости". Поэтому с готовностью решаю алгоритмические секции, но со своей стороны при собеседованиях делаю скидку, что вообще говоря, человек не обязан знать трюк с prefix sum, будь он трижды тривиальным (когда его знаешь). Не обязан уметь вращать деревья в уме. Но если вдруг умеет и в структуры данных, и в методы работы с ними, то разговор точно пойдет и проще, и интереснее. По крайней мере, это точно интереснее, чем фреймворк А, который уже завтра будет заменён фреймворком Б.
Тяжело в значении трудоемкости, банально количественно.
Я может что-то не знаю, но обычно красить приходится долго, упорно и до конца (до места где уже покрашено). Иначе костыли вставляются прям совсем мощные, с блокировкой потока.
А проблема как раз в большой кодовой базе: становится безумно тяжело производить изменения. Если мы где-то захотели что-то сделать асинхронным (в большой существующей кодовой базе), нам нужно протаскивать руками всю асинхронность наверх, в каждой сигнатура каждого метода. Включая те, что вообще не причём.
А так, конечно типы - огромное добро, в этом полностью согласен.
Нет. На уровне кода. В любом месте можно задать контекст выполнения.
Можно-то можно, но если это происходит, то у вас уже давно всё не работает (или продолжит отлично работать). Идея что stackfull, что stackless корутин в том, что ОС-поток - это дорого. Поэтому если у вас библиотека раньше внутри создавала (зачем-то) ОС-потоки руками - она просто продолжит работать как раньше, а раз вам раньше было с ней ок, то и сейчас будет.
Всю 30 летнюю экосистему Java взяли и по быстрому переписали? Оптимистично.
За 30-летнюю историю экосистемы Java все более или менее распространённые библиотеки и фреймворки уже давно позволяют конфигурировать свои тред-пулы, иначе это уже неюзабельно на тех нагрузках, на которых имеет смысл говорить о виртуальных потоках. А конфигурация виртуальных потоках как раз происходит на стороне тред-пулов.
Есть разница между тем что автор библиотеки написал async но не реализовал, потому что он дурак и тем когда автор ничего не писал и не гарантировал.
Именно, если автор ничего не писал и не гарантировал, то у него не будет под капотом своих тредов. Иначе автор таки написал и нагарантировал. И, обычно, это будет можно конфигурировать из вне. И даже если вдруг нет, то то, что внутри библиотеки какой-то код по каким-то причинам занимает ОС-потоки не будет особо сказываться на остальном приложении (если их немного, а если много - то это уже неюзабельно, ещё до виртуальных потоков).
Что вы предлагаете, переделать им на виртуальные потоки все?
Я предлагаю понимать это на этапе выбора языка, напомню, это было сказано в разрезе выбора Java vs Kotlin сегодня.
я бы не стал это называть "зло во плоти" точно
Ну мы с вами выбираем разную терминологию. Вы бы не стали, а я бы стал. Не вижу в этом никакой проблемы. Впрочем, конечно же, соглашусь, что раньше это могло бы быть аргументом в пользу условного Kotlin vs Java в некоторых контекстах.
в Java смотря на код вообще невозможно сделать никаких предположений о том как он выполниться
Вы делаете эти предположения на уровне конфигурации.
Если Вы вызываете библиотеку внутри которой создаются платформенные потоки по старой доброй памяти
То у вас уже большие проблемы, и да, автоматически их виртуальные потоки не починят. К счастью, таких библиотек исчезающе мало. Почти всё, что вы можете встретить в продакшене, позволяет конфигурировать способ создания потоков.
Самое неприятное что проблемы могут быть даже не у самой библиотеки а у библиотек которых она использует
Верно, это действительно проблема. Такая же, как во всех языках, кроме, пожалуй, Go, и то я не на 100% уверен. То что у вас снаружи написано async не значит, что внутри нет большого синхронного куска, не позволяющего переключать контекст.
или путешествовать по кишкам библиотеки и всех ее зависимостей
Или проверить треды любым observability-tool в рантайме. В принципе можно даже перехватывать любое создание ОС-треда без большого труда. Конечно, было бы классно знать заранее, но тут вы правы, это невозможно, но и в других языках (возможно кроме Go) это будет больше эвристика, чем реальность.
Ну Вы написали что раскраска функций - зло во плоти, а я считаю что пилить фичу 11 лет
Я вообще не рассуждаю о том, что лучше - иметь очень так себе имплементацию сразу или пилить хорошую 11 лет. Я рассуждаю на состояние сегодня, что лучше - заставлять красить методы (и перекрашивать, что самое плохое) или иметь stackfull на стороне рантайма. И на мой вкус, раскраска проигрывает колоссальным образом.
У меня есть ощущение, что вы не до конца понимаете как работают виртуальные потоки в Java (могу конечно ошибаться).
Не важно что написано в документации библиотеки, виртуальные потоки (stackfull-корутины) работают прозрачно и для вас, и для библиотеки. В любом safe-point может произойти переключение виртуального потока, автор библиотеки (или вы) вообще ничего не должны для этого специально делать.
Да, разумеется, сделать поддержку stackfull корутин намного сложнее, чем stackless. Но мы же не о сложностях реализации? И не про 2012й год. Речь всё-таки про пользователя, и пользователя сегодня. Кстати говоря, первая реализация была сделана быстро (и дубово), и длительность внесения в язык связана во многом с тем (пусть и не только), чтобы избавить пользователя от оверхеда, насколько возможно в подавляющем большинстве сценариев.
На мой взгляд, раскраска функций (когда нужно явно размечать, поддерживает ли функция асинхронный работу) в котлине и шарпе - зло во плоти. Подход go/java в этом смысле куда более комфортный, особенно в большой кодовой базе.
Что вы имеете ввиду под "потребуют примитивов синхронизации"? Виртуальные треды с точки зрения пользователя работают прозрачным образом, т.е. "просто работают". Разумеется, если вы модифицируете разделяемые данные, вам всё ещё нужно следить за корректностью с точки зрения модели памяти, что будет верным для любого языка.
Действительно, это уровень начинающего, но это хороший уровень для начинающего, в наши-то дни.
Если можно непрошеных советов:
Забудьте про ИИ для написания кода на ближайшие лет 5. Да, это неплохая замена гуглу, но в остальном - это лучший способ сломать себе обучение. Да и при гуглении прорываться через кучу мусора помогает расширять и углублять кругозор.
Ищите возможность поработать с опытными инженерами. В одиночку обучение обязательно упрется в потолок, и похоже он достигнут.
Монга практически всегда и для чего угодно хуже чем постгря. Хотите (почему-то) неструктурированные данные? Храните их JSON'ами/строками/blob'ами к постгре. Но чаще всего оказывается, что просто не нужно такого хотеть)
Питон, безусловно, имеет свою нишу. Но с какими-то существенными нагрузками эта ниша не связана. Хорошая нагрузка начинается в районе 1-10к rps.
Highload - мутный термин, но если пытаться дать ему какое-то значение, то это про уровень нагрузки и/или объема данных, принципиально выходящий за возможности вертикального масштабирования.
Там было достаточно много причин, почему "никак". Али-Баба, идейные вдохновители, у себя в продакшене запустили очень много лет назад и в ус не дули. Но их подход добавлял оверхед для других сценариев. Всё это время шла работа над устранением краевых случаев, и уже несколько лет как всё готово к использованию с разными оговорками. Сейчас уже скорее без оговорок.
У меня сейчас четвертая ипотека, причем уже в другой стране. Снится мне всё ещё школа.
Я тоже согласен с @Plesserи тоже выберу при прочих равных человека с pet project'ами, горящими глазами и вот это вот всё. Но не согласен с тем, что сессия - это какой-то незначительный стресс. Для многих, в том числе для меня, любое "испытание", которое лишь косвенно связано с профессиональными навыками, такое как сессия, собеседование, публичное выступление и т.п. - это колоссальный стресс. Даже после десятков повторений процедур, даже если они сами по себе могут нравиться.
По тону высказывания, я так понял, речь про стоимость.
Я не понимаю, почему все в пример приводят Java. Пожалуйста, на Java тоже прекратите писать интерфейсы где не надо.
Ну я вполне втыкался в производительность branch-miss'ов, для этого есть даже хрестоматийный пример, который вы можете воспроизвести и у себя: наивное чтение var-int'ов с помощью цикла. В этом случае у предсказателя переходов слишком высокая доля ошибок. Тривиальное лечение - вручную развернуть цикл, чтобы у таблицы переходов были разные адреса, и тогда если у вас в горячем цикле var-int'ы примерно одного размера, то всё починится само. Если у вас совсем произвольные var-int'ы, тогда есть чуть более сложные техники.
Тем не менее, даже в случае, если у вас всё хорошо предсказывается, таблицы предсказания ветвлений в процессорах не бесконечные. Руками вы конечно вряд ли их забьёте, но если начнёте генерировать код с избыточным ветвлением, то статистика предсказаний вполне может начать вытесняться.
Мне это всегда казалось и продолжает казаться неплохим способом проверить замотивированность кандидата заниматься относительно длительной подготовкой к интервью. Примерно как диплом о ВО доказательство 4-6 лет "усидчивости". Поэтому с готовностью решаю алгоритмические секции, но со своей стороны при собеседованиях делаю скидку, что вообще говоря, человек не обязан знать трюк с prefix sum, будь он трижды тривиальным (когда его знаешь). Не обязан уметь вращать деревья в уме. Но если вдруг умеет и в структуры данных, и в методы работы с ними, то разговор точно пойдет и проще, и интереснее. По крайней мере, это точно интереснее, чем фреймворк А, который уже завтра будет заменён фреймворком Б.
Да, думаю мы скорее согласны.
Тяжело в значении трудоемкости, банально количественно.
Я может что-то не знаю, но обычно красить приходится долго, упорно и до конца (до места где уже покрашено). Иначе костыли вставляются прям совсем мощные, с блокировкой потока.
А проблема как раз в большой кодовой базе: становится безумно тяжело производить изменения. Если мы где-то захотели что-то сделать асинхронным (в большой существующей кодовой базе), нам нужно протаскивать руками всю асинхронность наверх, в каждой сигнатура каждого метода. Включая те, что вообще не причём.
А так, конечно типы - огромное добро, в этом полностью согласен.
Можно-то можно, но если это происходит, то у вас уже давно всё не работает (или продолжит отлично работать). Идея что stackfull, что stackless корутин в том, что ОС-поток - это дорого. Поэтому если у вас библиотека раньше внутри создавала (зачем-то) ОС-потоки руками - она просто продолжит работать как раньше, а раз вам раньше было с ней ок, то и сейчас будет.
За 30-летнюю историю экосистемы Java все более или менее распространённые библиотеки и фреймворки уже давно позволяют конфигурировать свои тред-пулы, иначе это уже неюзабельно на тех нагрузках, на которых имеет смысл говорить о виртуальных потоках. А конфигурация виртуальных потоках как раз происходит на стороне тред-пулов.
Именно, если автор ничего не писал и не гарантировал, то у него не будет под капотом своих тредов. Иначе автор таки написал и нагарантировал. И, обычно, это будет можно конфигурировать из вне. И даже если вдруг нет, то то, что внутри библиотеки какой-то код по каким-то причинам занимает ОС-потоки не будет особо сказываться на остальном приложении (если их немного, а если много - то это уже неюзабельно, ещё до виртуальных потоков).
Я предлагаю понимать это на этапе выбора языка, напомню, это было сказано в разрезе выбора Java vs Kotlin сегодня.
Ну мы с вами выбираем разную терминологию. Вы бы не стали, а я бы стал. Не вижу в этом никакой проблемы. Впрочем, конечно же, соглашусь, что раньше это могло бы быть аргументом в пользу условного Kotlin vs Java в некоторых контекстах.
Вы делаете эти предположения на уровне конфигурации.
То у вас уже большие проблемы, и да, автоматически их виртуальные потоки не починят. К счастью, таких библиотек исчезающе мало. Почти всё, что вы можете встретить в продакшене, позволяет конфигурировать способ создания потоков.
Верно, это действительно проблема. Такая же, как во всех языках, кроме, пожалуй, Go, и то я не на 100% уверен. То что у вас снаружи написано async не значит, что внутри нет большого синхронного куска, не позволяющего переключать контекст.
Или проверить треды любым observability-tool в рантайме. В принципе можно даже перехватывать любое создание ОС-треда без большого труда. Конечно, было бы классно знать заранее, но тут вы правы, это невозможно, но и в других языках (возможно кроме Go) это будет больше эвристика, чем реальность.
Я вообще не рассуждаю о том, что лучше - иметь очень так себе имплементацию сразу или пилить хорошую 11 лет. Я рассуждаю на состояние сегодня, что лучше - заставлять красить методы (и перекрашивать, что самое плохое) или иметь stackfull на стороне рантайма. И на мой вкус, раскраска проигрывает колоссальным образом.
У меня есть ощущение, что вы не до конца понимаете как работают виртуальные потоки в Java (могу конечно ошибаться).
Не важно что написано в документации библиотеки, виртуальные потоки (stackfull-корутины) работают прозрачно и для вас, и для библиотеки. В любом safe-point может произойти переключение виртуального потока, автор библиотеки (или вы) вообще ничего не должны для этого специально делать.
Да, разумеется, сделать поддержку stackfull корутин намного сложнее, чем stackless. Но мы же не о сложностях реализации? И не про 2012й год. Речь всё-таки про пользователя, и пользователя сегодня. Кстати говоря, первая реализация была сделана быстро (и дубово), и длительность внесения в язык связана во многом с тем (пусть и не только), чтобы избавить пользователя от оверхеда, насколько возможно в подавляющем большинстве сценариев.
На мой взгляд, раскраска функций (когда нужно явно размечать, поддерживает ли функция асинхронный работу) в котлине и шарпе - зло во плоти. Подход go/java в этом смысле куда более комфортный, особенно в большой кодовой базе.
Что вы имеете ввиду под "потребуют примитивов синхронизации"? Виртуальные треды с точки зрения пользователя работают прозрачным образом, т.е. "просто работают". Разумеется, если вы модифицируете разделяемые данные, вам всё ещё нужно следить за корректностью с точки зрения модели памяти, что будет верным для любого языка.
Ключевое слово "если", что на мой вкус, мягко говоря, не так.
Так в Паскале вполне себе есть указатели.
Круто, что сделаны выводы!
Действительно, это уровень начинающего, но это хороший уровень для начинающего, в наши-то дни.
Если можно непрошеных советов:
Забудьте про ИИ для написания кода на ближайшие лет 5. Да, это неплохая замена гуглу, но в остальном - это лучший способ сломать себе обучение. Да и при гуглении прорываться через кучу мусора помогает расширять и углублять кругозор.
Ищите возможность поработать с опытными инженерами. В одиночку обучение обязательно упрется в потолок, и похоже он достигнут.
Монга практически всегда и для чего угодно хуже чем постгря. Хотите (почему-то) неструктурированные данные? Храните их JSON'ами/строками/blob'ами к постгре. Но чаще всего оказывается, что просто не нужно такого хотеть)
Питон, безусловно, имеет свою нишу. Но с какими-то существенными нагрузками эта ниша не связана. Хорошая нагрузка начинается в районе 1-10к rps.
Highload - мутный термин, но если пытаться дать ему какое-то значение, то это про уровень нагрузки и/или объема данных, принципиально выходящий за возможности вертикального масштабирования.
Конечно может! У этого приема даже есть название: оксюморон.
Там было достаточно много причин, почему "никак". Али-Баба, идейные вдохновители, у себя в продакшене запустили очень много лет назад и в ус не дули. Но их подход добавлял оверхед для других сценариев. Всё это время шла работа над устранением краевых случаев, и уже несколько лет как всё готово к использованию с разными оговорками. Сейчас уже скорее без оговорок.
Нет, вопрос был не к вам)