Питання не в тому хто кращій, а хто гірший. Питання в тому, хто готовий до віртуальних потоків. Якщо фрейморк ховає конфігурацію тредпулів від розробника, то воно одразу йде на смітник, бо неможливо уявити ситуацію в котрій перевага у ReST-запитах буде надана платформеним потокам.

От вам і питання: хто із цих фремфорків надає змогу користуватися віртуальними потоками через налаштування фабрики потоків, або вміє користуватися батьківським потоком через наслідування (підказка: майже ніхто окрім JDK HTTP).

Я перепрошую, ви просто накидуєте на вєнтілятор? Ви взагалі Java знаєте?

В общем, пул потоков управляется со стороны рантайма Go, а не вручную, что более логичный подход. Как и управление памяти через GC, а не вручную через вызовы malloc/free. То есть джава-девелоперы до этого ещё просто не дошли.

ВСЕ що ви написали теж робить середовище виконання. Після таких тез від вас я просто не впевнений, що із вам реально є сенс дискутувати.

Ещё второй важный аспект в релизе средств параллельного программирования — это обмен данными между виртуальными потоками. Понятно конечно, что везде есть мьютексы и атомарные операции для синхронизации. Но вот в реализации коротин обычно есть какой-ниубудь yield(a, b, c) для передачи данных из коротины в управляющий поток, и resume(d, e, f) для возобновления коротины. Естественно это работает с доступом к контексту управления. А в реализации горотин на Go обмен происходит через каналы. Если нет ни того, ни другого способа, то это недоделанная версия виртуальных потоков.

Я був впевнений, що ви розумієтеся на тому, що пишете про Java. Відповім коротко: все є, окрім знання Java у вас. Дуже сумно.

що саме ви цим прикладом хотіли показати? що маючи флот (fleet) ОС потоків ви можете контролювати кількість задач на один поток? чи ви хотіли сказати, що таким чином можете вичерпати GOMAXPROC, і змусити рантайм створювати нові ОС потоки?

В свою ж чергу я писав про те, що в Java ви можете створювати пули ОС тредів незалежно від рантайму, а із впровадженням віртуальних потоків зʼявилася можливість ще й вказувати фабрику потоків. В Golang ви не можете створювати системні потоки напряму, тобто ваш код буде виконуватися однаково навіть якщо в вас там математика чи мульти-блокуючі I/O. В Java в вас є вибір що й як робити, в golang — нема, є лише ось такі способи «pinning» горутин до ОС потоків.

Ви розумієте так як вам зручно і читаєте із тією інтонацією якою вам звично. По-перше, в Golang нема жодного іншого стеку для concurrent програмування, окрім випадків, коли вам дуже треба pthread_create, а бо пули з C++ Boost ASIO.

Може давайте ви ще накинете Python-у, чого ж це в них со-програми зʼявилися лише декілька років тому? Хочете поговорити про Golang? Давайте, горутіни зʼявилися майже одразу, але їх відладка в продакшені все ще продовжується, вже як 10й рік. Так що не порівнюйте час, розмір екосистеми та готовність комʼюніті до іновацій. Це Java, тут є все ще ті, хто сидить на JDK 8, а зараз актуальна JDK 21.

Я, як людина дотична до розробки та тестування нових проектів в Java/JDK, можу сказати, що пройде ще не один рік, а віртуальні потоки не будуть впроваджені в більшості фреймворків екосистеми (Spring, Netty, Apache Common). Тому 5 років розробки і 2 роки тестування це ніщо у порівнянні із якістю функціоналу та нових пропускних потужностей на які спроможна Java.

Як з язика зняли. 100% надані тести просто не мають жодного сенсу. Ба більше того, інструменти для тестування взагалі взяті зі стелі. Нащо брати jmeter, коли є JFR (+ JMC) і JMH.

Щоб якісно тестувати віртуальні потоки в вас повинні бути відповідні задачі для цього. А в цьому тесті/контексті просто нема, на жаль.

це так не працює, не можна вирішувати все однією технологією, бо це те й саме як закручувати шестигранник викруткою phillips. Наведу простий приклад який показував на конфі по Golang колись: візьміть C++ CV, в вас є вибір, або ви берете Python, бо вже знаєте як написать OpenCV hello-world (або классифікатор Хаара), або візьмете GoCV. Результат один і той же — задача виконана, але диявол в деталях і кошторисі на виконання та підтримку. Ви 100% знайдете більше відповідей на StackOverflow по OpenCV на Python, але ви також заплатите за повільний інтерпретатор або, як із GoCV, заплатите часом на вивчення API та відладкою.

Golang не панацея. Треба вирішувати проблему найбільш підходящими інструментами, особливо в serverless.

Не платити за них. 20мс на одному запиті, але коли питання доходить до сотні мільнів запитів щомісячно, то які аргументи будуть проти економії коштів ентерпрайзу?

для світу серверного JS Bun нічого не дав (поки що), а от в світі serverless, де саме холодний старт це критично, Bun дуже добре підходить як заміна node.js

Тому, якщо ви використовуєте серверлесс на JS, то Bun це для вас.

Типова реакція: «навіщо spring і сюди тягнути?!». Вона вірна загалом, окрім декількох аспектів: — оригінальна кодова база (була) є написана на Spring (Spring Cloud). Із серверлесс досі найбільшою проблемою є деплоймент-пакет — частіше за все це якийсь вироджений архів або контейнер із купою обмежень. І в таких випадках чим менший розмір на диску, там краще. Саме тут спрінг просто програє так швидко, що навіть maven архетип не встигає встановитися =)

Не існує мов «ізначально рассчітаних» на serverless. Нагадаю, AWS Lambda це оркестратор firecracker над гіпервізором. Тобто лямбда — віртуальна машина. У всіх інших серверлесс — це контейнери (cgroup). Отже, є рантайми більш схильні до швидкого старту (компільовані) і швидкого прогріву, а є інтерпретатори (Python, node). Останні — найгірші для серверлесс, бо при малих ресурсах запуск самого інтерпретатора — дуже дороге задоволення. У той же час є Java, із нею ситуація зовсім інша — можна скомпілювати код в native image, а можна використовувати AppCDS і кеш з класами, що зробить запуск швидким, а прогрів JVM ще ближчим у часі. Е ще ініціатива CRaC або point-restore-in-time, це коли можна створити JVM, прогрітим зробити снепшот і перенести у якості рантайму у контейнері, приклад. Я вже не кажу, про збірку через jlink кастомногш рантайму без зайвих компонентів. І вже при цьому всьому Java легко може конкурувати по швидкості запуску із Golang та C++ в серверлесс.

Якщо дуже треба Spring, то в них є Spring Functions. Там є все необхідне для AWS. Але я все ще вважаю це заскладним і не маю кращої ідеї, ніж користуватися нативними бібліотеками для написання Serverless Функцій, бо в десятки разів менше залежностей у вашому застосунку.

Фактично ні, бо виконуються обчислення фактору паралелізму для обох типів потоків на старті. JVM порахує скільки треба створити платформених потоків (ForkJoinPool), та окремо порахує скільки треба потоків-носіїв для віртуальних потоків, які будуть створюватися через новий ExecutorService. В будь-якому випадку просадки не буде видно, бо в обох випадках пули потоків вже існують.

Але, в теорії, треба уникати таких ситуацій. Так каже «command responsibility segregation concept», типу довгі та важки запити повінню оброблятися окремим компонентом.

можна посилання на це і на опитування

Це опитування проводилося в США так званим college board серед майже усіх великих ВИШів із IT спеціальностями. Я трохи дотичний до цього, як буде саме що пошерити — напишу.

Kubernetes, Docker, Terraform будуть реалізовані на Go.

Вірно, а до цього був OpenStack і Python, був Chef та Puppet з Ruby, але чомусь я не бачу засилля цих інструментів у сьогоденній розробці. Щодо Kubernetes, Istio і майже усього CNFC, то це й не дивно, бо всі розуміють хто просуває ініціативи. Із Terraform ситуація трохи складна, тому і виникли ініціативи типу Pulumi, тому що golang для багатьох ця мова є лише проблемою. А от для OpenSource я сам обирав Golang не один раз, буду відвертим (бо багато працюю із Serverless).

Тобто ви зараз зрівняли специфічний білд Java

Ви трохи не зрозуміли MicroProfile, це надпотужна ініціатива в спільноті мета якої створити уніфікований набір інструментів, плагінів, інджекшенів для створення cloud-native мікросервісів без привʼязки до транспортного протоколу.

container image з single Go binary

це якщо ви hello-world пишите, в продакшені ж ситуація зовсім інша: golang плагіни, native бібліотеки. Єдиний плюс Golang в данному випадку, так це уніфіковані інтерфейси HttpRequest, HttpResponse. А MicroProfile це про час і кошти на розробку, бо з коробки є майже все що треба для інтеграції у кубери чи то хмари (oracle cloud, aws, gcp). Ну а про компіляцію в native image я вже не кажу, бо є такі проекти як GraalVM з Java SE які створять вам native image з Java коду.

Ваша думка може не збігатися із цим висловлюванням, але опитування показують, що ситуація саме така. І ось декілька фактів:
* студенти все більше схиляються до вибору Java при карʼєрному орієнтуванні.
* у той час як писати hello world простіше на Python, але банківську систему буде реалізовано на Java.
* наявність таких ініціатив як MicroProfile є дуже великою перевагою в порівнянні із іншими технологіями типу node.js, python, golang

я б ще міг запропонувати аргументів, але й цього буде вдосталь.

Саме так. Дякую, що випередили мене.

Формально так, за допомогою фабрики Thread.ofPlatform().factory() або Thread.ofVirtual().factory() можна створити блок Structured Concurrency під певний вид тредів. Але в документації до віртуальних тредів сказано, що вони ефективні лише в I/O задачах бо там є висока частота перемикань контекстів (очікування I/O івентів). В найгіршому випадку, CPU-задача запущена на віртуальному потоці призведе до блокування потоку-носія (carrier thread, аналогічно до концепту в Golang) що виконує віртуальний поток. Тому треба бути уважним який потом за замовчуванням створюється в Structured Concurrency.

Дякую що запитали, я не дуже спеціаліст в .NET, нажаль.

Structured Concurrency являє собою сегмент коду який по суті своїй є синхронним блоком виконання, але всередині цього блоку можна запускати асинхронні блоки, які можна легко профілювати навідміну від асинхронного коду з конкретною точкою входу, я наприклад в Python 3.

Ось тут я розписував що воно таке dou.ua/forums/topic/39928

Фотографія, якщо дуже серйозно підійти. Скажемо, пейзажна. Там можна просто тижнями ловити правильне світло і композицію. Можна почати фігачіть FPV дрони. Це дуже популярна тема і як раз розминка для мізків.

а давайте поміркуємо що саме таке Вроцлав? Окрім Олімпія Порт там нема реально якісних районів, а враховуючи те, що туди продовжують тулитися білоруси та нащі, то місто просто перенавантажене айтівцями, що відповідно впливає на ціни аренди. Наприклад, не комора в 60-70 квм буде вартувати майже 2 тисячі євро на місяць. Це великі ціни, за них можна дуже якісно жити в Іспанії та Італії.

По моїх спостереженнях окрім Олімпія Порт у Вроцлаві нема якісних районів для сімʼї. Інша справа Краков чи Познань, хоча ціни ті ж сами.