неблокирующее IO API. И что мешает просто взять и его использовать?
Используйте. Вам никто не мешает.
Но неблокирующее какраз больше кода, об этом же и пишу вам. Сложнее ментальная модель, сложнее в дебаге.
С новыми тредами вам это не нужно будет во многих случаях. Тоесь вы просто можете забитъ на ассинхронне апи, БЕЗ особого усложнения понятия тред. Вы почему-то пытаетесь доказать что треды будут сложнее. На мой же взгляд разница помойму очень проста, еще один уровень абстракции как в Го с сохранением АПИ.
Может у вас свой специфический контектс и там все так как вы говорите — тогда это частный случай скорее.
ИМХО мне кажется это очень правильное направление и упросит в будушем многое. 16 ядрами сейчас никого не удивишь к примеру. С лекговесными треадами и простым блокирующим кодом их будет проще запользовать — это правильное направление ИМХО.
Смотрите если в tasks у вас обычные треды вы там с блокирующими операциями просядите. Это понятно?
С виртуальными тредами не просядите, потому что когда до операции ввода/вывода дойтете то виртуальный тред хоть и будет ждать, но реальный не будет простаивать.
Тем самым вы упрощаете код который у вас:
/* do something */
там вы можете в лоб теперь блокирующе читать файлы или сокет… 100 000 раз. и все это без колбэков в коде. У меня нет под рукой сейчас примера с колбэком и без. Влом выдумывать.
Если вы про VirtualThread то, как-бы очевидно же (покрайней мере мне) что блокирующий код легче читать/писать… не нужно лишних нагромождений а иммено это опять будет возможно не теряя все плюшек многопоточности.
Два уровня же. Виртуальные треды проецируются на процессорные. Вот с загруской процессорных какраз пока особо ничего не меняется, кроме того, что им потенциально будет больше поделать а не меньше.
Оффициальная дока на 80% для всех этих тулз. не промахнетесь…
Главное кусочками делайте и прикладную задачу решайте!
Я лично не люблю эту ерунду с изучением каких-то вещей "прозапас" — это просто для галочки/бумажки и не работает.
Прикольно я вообще социализировался в яве, последнее время скорее архитект, но этот стек полностью тоже мой ;) Так я и DevOps ещё ;)
Сарказм немного ибо DevOps это не об стеке технологий
Если вы здаете такой вопрос, видимо вы в начале контейнерновго пути, хотите попробовать. Я бы сказал тут однозначно Докер. Просто готовая и экосистема с кучей контейноров и ответов на все ваши вопросы.
я не топлю за УМЛ вовсе…
Мой взгляд зацепило: "вы там свою работу сделайте сначала".
Довелось недавно столкнутся с оутсорсом в Белорусии. Сам я на западе социализировался в ИТ.
Мне в 2019 году рассказвают, что для успешного проекта надо 10 ролей (аналитик, тестировщик, писарь и редактор стори, узкотехнологичный программер сеньер., мид, джун… ) и каждый говорит "вы там свою работу сделайте сначала"….
Я пришел когда они каждый в своем бранже застряли и деплоить не могли на продукцию уже несколько месяцев. Причем большинство по отдельности вполне толковые были и знают свое (узкое) дело.
я посмотрел и мне как-то пока не понравилось громоскостью и новыми конецепциями и обвязками, с непонятным бенефитом.
За вечер накатали на Spring Cloud Gateway более привычные пока. Гоням на этом пока…
Нужна простота и понятность на данный момент.
Звучит будто envoy можно настроить как (микро) api gateway в кубернетовском сценарии.
Може ту вас есть опыт или идеи?
JWT поддержка (поверка хотябы, но лучше и сценарий получение его из opaque token)
А то я начал вчера с Spring cloud и security библиотхеками это делать, не покидает желание сравнить с чем-то другим..
Используйте. Вам никто не мешает.
Но неблокирующее какраз больше кода, об этом же и пишу вам. Сложнее ментальная модель, сложнее в дебаге.
С новыми тредами вам это не нужно будет во многих случаях. Тоесь вы просто можете забитъ на ассинхронне апи, БЕЗ особого усложнения понятия тред. Вы почему-то пытаетесь доказать что треды будут сложнее. На мой же взгляд разница помойму очень проста, еще один уровень абстракции как в Го с сохранением АПИ.
Может у вас свой специфический контектс и там все так как вы говорите — тогда это частный случай скорее.
ИМХО мне кажется это очень правильное направление и упросит в будушем многое. 16 ядрами сейчас никого не удивишь к примеру. С лекговесными треадами и простым блокирующим кодом их будет проще запользовать — это правильное направление ИМХО.
Смотрите если в tasks у вас обычные треды вы там с блокирующими операциями просядите. Это понятно?
С виртуальными тредами не просядите, потому что когда до операции ввода/вывода дойтете то виртуальный тред хоть и будет ждать, но реальный не будет простаивать.
Тем самым вы упрощаете код который у вас:
там вы можете в лоб теперь блокирующе читать файлы или сокет… 100 000 раз. и все это без колбэков в коде. У меня нет под рукой сейчас примера с колбэком и без. Влом выдумывать.
а то что вы показали останется тем же.
Если вы про VirtualThread то, как-бы очевидно же (покрайней мере мне) что блокирующий код легче читать/писать… не нужно лишних нагромождений а иммено это опять будет возможно не теряя все плюшек многопоточности.
Ну они не могут просто так поменять конктракт. И правильно.
На самом деле очень элегантно врезали новую фичу на мой вкус. Вы и сами пишите:
только можно и не менять или если то достаточно мало и без риска
неа
Два уровня же. Виртуальные треды проецируются на процессорные. Вот с загруской процессорных какраз пока особо ничего не меняется, кроме того, что им потенциально будет больше поделать а не меньше.
Оффициальная дока на 80% для всех этих тулз. не промахнетесь…
Главное кусочками делайте и прикладную задачу решайте!
Я лично не люблю эту ерунду с изучением каких-то вещей "прозапас" — это просто для галочки/бумажки и не работает.
Прикольно я вообще социализировался в яве, последнее время скорее архитект, но этот стек полностью тоже мой ;) Так я и DevOps ещё ;)
Сарказм немного ибо DevOps это не об стеке технологий
Спасибо, какраз стоит задача миугрануть в свежий прометей мониторинг некого легаси...
Если вы здаете такой вопрос, видимо вы в начале контейнерновго пути, хотите попробовать. Я бы сказал тут однозначно Докер. Просто готовая и экосистема с кучей контейноров и ответов на все ваши вопросы.
Мне то это понятно ;)
Вообще там где нет коммандности, доверия и работы над общими целями. Там ни процессы ни УМЛ не помогут.
я не топлю за УМЛ вовсе…
Мой взгляд зацепило: "вы там свою работу сделайте сначала".
Довелось недавно столкнутся с оутсорсом в Белорусии. Сам я на западе социализировался в ИТ.
Мне в 2019 году рассказвают, что для успешного проекта надо 10 ролей (аналитик, тестировщик, писарь и редактор стори, узкотехнологичный программер сеньер., мид, джун… ) и каждый говорит "вы там свою работу сделайте сначала"….
Я пришел когда они каждый в своем бранже застряли и деплоить не могли на продукцию уже несколько месяцев. Причем большинство по отдельности вполне толковые были и знают свое (узкое) дело.
Ага, тоесть нужно ещё гениальную команду вокруг вас обслуживающие образы в вашей голове…
Вот именно ;)
и Анжела Меркелева...
Уверен они к подобному и идут.
Ну как вводная тема ок. Полез таки смотреть доки.
я посмотрел и мне как-то пока не понравилось громоскостью и новыми конецепциями и обвязками, с непонятным бенефитом.
За вечер накатали на Spring Cloud Gateway более привычные пока. Гоням на этом пока…
Нужна простота и понятность на данный момент.
Если можно пинганите нам тут, почитаем с удовольствием ;)
Звучит будто envoy можно настроить как (микро) api gateway в кубернетовском сценарии.
Може ту вас есть опыт или идеи?
JWT поддержка (поверка хотябы, но лучше и сценарий получение его из opaque token)
А то я начал вчера с Spring cloud и security библиотхеками это делать, не покидает желание сравнить с чем-то другим..