Здравствуйте, m2user, Вы писали:
M>У меня на работе например под AWS писали на .NET core, Python, даже что-то нативное собирали, M>но только не на Java, потому что во-первых никто её не знал, во-вторых частично портировался существующий код на C#.
Я именно об этом и говорю. На Core переходят не потому что круто, а потому что это самый простой способ перейти на линух для легаси и шарповодов. Она и появилась потому, что винда проиграла как серверная операционка.
Конечно я защищаю то, что знаю. А вот твоя ненависть к шарпу поражает. Видно ты каким то образом обжёгся.
То что файберы они же зеленые потоки где то выигрывают от п времени активации потоков и синхронизации, не делает их серебрянной пулей.
Пул нативных потоков в большинстве эффективней.
По сути при асинхронном программировании использование синхронизации сведено к минимуму. Или синхронизация на тех же TaskCompletionSource https://ru.wikipedia.org/wiki/Green_threads
На многоядерных процессорах родная реализация встроенных потоков (native threads) может автоматически назначать работу нескольким процессорам, в то время как реализация green threads обычно не может[1][2]. Green threads могут быть запущены гораздо быстрее на некоторых виртуальных машинах. Однако, на однопроцессорных компьютерах наиболее эффективная модель ещё не определена. Тесты на компьютерах под управлением (старого) Linux на ядре версии 2.2 показали[3]:
Green threads значительно превосходят встроенные потоки Linux-системы по времени активации потоков и синхронизации.
Встроенные потоки Linux имеют несколько более высокую производительность операций ввода-вывода и переключения контекста.
Когда green thread выполняет блокирующий системный вызов, блокируется не только этот поток, но и все потоки внутри процесса[4]. Чтобы избежать этой проблемы, green threads должны использовать асинхронные операции ввода-вывода, хотя данную сложность можно скрыть, порождая скрытые для пользователя потоки на каждую операцию ввода-вывода, которые объединяются с green thread.
Есть также механизмы, которые позволяют использовать собственные потоки и снизить накладные расходы на активацию и синхронизацию потоков:
Пулы потоков снижают затраты на порождение новых потоков за счет повторного использования ограниченного числа потоков[5].
Также, языки, исполняющиеся на виртуальных машинах, НО использующие native threads, могут использовать технику оптимизации — анализ побочных эффектов (Escape-анализ), чтобы избежать синхронизации блоков кода, когда это возможно[6].
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Еще раз каков смысл в виртуальных потоках, если нужна работа с TaskCompletionSource и CancellationToken.
Смысл в глобальной асинхронной монаде, а не в локальной. Из за этого код не нужно ручками в нее (монаду) погружать в отличие от async/await. Все остальное одинаково.
Частный механизм, как сигнализировать преждевременное завершение вычислений, совершенно не имеет к этому отношения и абсолютно вторичен.
S> Конечно я защищаю то, что знаю. А вот твоя ненависть к шарпу поражает. Видно ты каким то образом обжёгся.
Откуда ты берешь про мою ненависть к шарпу? Хороший язык, лучше Явы.
S> То что файберы они же зеленые потоки где то выигрывают от п времени активации потоков и синхронизации, не делает их серебрянной пулей. S>Пул нативных потоков в большинстве эффективней. S>...
Тебе читать нужно научиться.
S>> Еще раз каков смысл в виртуальных потоках, если нужна работа с TaskCompletionSource и CancellationToken. N>Смысл в глобальной асинхронной монаде, а не в локальной. Из за этого код не нужно ручками в нее (монаду) погружать в отличие от async/await. Все остальное одинаково. N>Частный механизм, как сигнализировать преждевременное завершение вычислений, совершенно не имеет к этому отношения и абсолютно вторичен.
Покажи работу с TaskCompletionSource и CancellationToken.
Для их использования не нужны виртуальные потоки.
Зачем если есть пул потоков? В этом вся разница. Во многих случаях не нужен await нужна задача.
Можно вызавть await для массива задач (WhenAll, WhenAny ), можно вызвать ContinueWith итд. То есть больше механизмов использования.
Пул потоков более эффективен!
Еще раз читаем
Green threads значительно превосходят встроенные потоки Linux-системы по времени активации потоков и синхронизации.
Встроенные потоки Linux имеют несколько более высокую производительность операций ввода-вывода и переключения контекста.
Когда green thread выполняет блокирующий системный вызов, блокируется не только этот поток, но и все потоки внутри процесса[4]. Чтобы избежать этой проблемы, green threads должны использовать асинхронные операции ввода-вывода, хотя данную сложность можно скрыть, порождая скрытые для пользователя потоки на каждую операцию ввода-вывода, которые объединяются с green thread.
Есть также механизмы, которые позволяют использовать собственные потоки и снизить накладные расходы на активацию и синхронизацию потоков:
[q]
Пулы потоков снижают затраты на порождение новых потоков за счет повторного использования ограниченного числа потоков[
Также, языки, исполняющиеся на виртуальных машинах, НО использующие native threads, могут использовать технику оптимизации — анализ побочных эффектов (Escape-анализ), чтобы избежать синхронизации блоков кода, когда это возможно[6].
S>> Конечно я защищаю то, что знаю. А вот твоя ненависть к шарпу поражает. Видно ты каким то образом обжёгся. N>Откуда ты берешь про мою ненависть к шарпу? Хороший язык, лучше Явы.
Беру свои слова обратно. S>> То что файберы они же зеленые потоки где то выигрывают от п времени активации потоков и синхронизации, не делает их серебрянной пулей. S>>Пул нативных потоков в большинстве эффективней. S>>... N> N>Тебе читать нужно научиться.
и солнце б утром не вставало, когда бы не было меня
Работаю в топ 2 банке РФ, ещё несколько лет назад .net почти не было совсем. Сейчас это самый активно набираемый стек по количеству нанимаемых людей. Позиция руководства простая — все работает в кубере, взаимодействует между собой по кафке/http, язык не имеет никакого значения, важно только одно — за какой рейт можно нанять с рынка людей за условную сумму < x, и компании которые зацикливаются на чем то одном тупо проигрывают в деньгах.
Про новые проекты бред — чисто по удобству написания кода с c# и рядом никто не стоит. Все говорят смотри Котлин — смотрел, там даже деревья выражений не подвезли до сих пор. Поэтому новые проекты для бизнеса активно стартуют на .net.
А уж что за наркоманы будут опердни писать на питоне и js я не знаю, одна поделка годится только для фронта, вторая для наколеночных решений размером не больше одной страницы кода
Здравствуйте, novitk, Вы писали:
S>>Виртуальные потоки отстой. Ибо сливают таскам с TaskCompletionSource и CancellationToken. А вот яве без async/await хреново. Ибо во всех языках, даже в JS он существует. S>>Даже Котлин и то некое подобие изобразил. Кстати в TS когда в JS не было async/await, там генерировали стейт машину на промисах в JS. S>>Виртуальные потоки это хорошо забытые файберы и OVERLAPPED https://learn.microsoft.com/ru-ru/windows/win32/fileio/synchronous-and-asynchronous-i-o. Ничего нового. N>Ты не в состоянии понять, что тебе пишут или специально блокируешь в целях евангелизма .NET? N>Stackfull > Stackless ТЧК N>Тут не о чем дебатировать и в MS это [url=https://twitter.com/davidfowl/status/1583326637219000321 N>]понимают[/url]
Я не против зеленых потоков. Возможно они лучше в каких то сценариях нативных потоках. Но они никак не являются заменой async/await которые используют пул потоков хоть нативных хоть зеленых. Единственно, что для долгих операций стоит использовать более легковесные потоки.
То есть нужно смотреть и замерять.
Но они ну никак не являются заменой ради не использования async/await
Про отстой я говорил как замена задач выполняемых в пуле потоков, на задачи основанных на зеленых потоков.
При использовании Task никто не использует Thread напрямую, но можно делать подсказки вроде TaskCreationOptions, ConfigureAwait, ContinueWith, RunSynchronously
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, microuser, Вы писали:
M>Работаю в топ 2 банке РФ, ещё несколько лет назад .net почти не было совсем.
Рад за топ 2 банк РФ, но будущее платформы определяется в других недружественных странах — стартапах, FAANG и т.д.
M>Сейчас это самый активно набираемый стек по количеству нанимаемых людей. Позиция руководства простая — все работает в кубере, взаимодействует между собой по кафке/http, язык не имеет никакого значения, важно только одно — за какой рейт можно нанять с рынка людей за условную сумму < x, и компании которые зацикливаются на чем то одном тупо проигрывают в деньгах.
.NET — приемлемый выбор, а вот зоопарк технологий из за того, что сегодня кто-то дешевле не есть умно.
M>А уж что за наркоманы будут опердни писать на питоне и js я не знаю, одна поделка годится только для фронта, вторая для наколеночных решений размером не больше одной страницы кода
vscode — одна страницу кода? Я в курсе, что он в основном на ts, но под js понимается платформа, а не язык.
M>А уж что за наркоманы будут опердни писать на питоне и js я не знаю, одна поделка годится только для фронта, вторая для наколеночных решений размером не больше одной страницы кода
вот этот челhttps://youtu.be/etKOc80-cw0
в одном из докладов говорил что в европе некоторые банки фулстэк на js
Здравствуйте, novitk, Вы писали:
N>Здравствуйте, microuser, Вы писали:
N>Рад за топ 2 банк РФ, но будущее платформы определяется в других недружественных странах — стартапах, FAANG и т.д.
А это вообще какие отношение к текущему разговору имеет, будущее любой платформы определяется там и что дальше? Чем джава в этом плане отличается?
N>.NET — приемлемый выбор, а вот зоопарк технологий из за того, что сегодня кто-то дешевле не есть умно.
Не есть умно — это складывать все яйца в одну корзину, завтра одна из технологий пойдет по пизде и весь твой не зоопарк вместе с ней
N>vscode — одна страницу кода? Я в курсе, что он в основном на ts, но под js понимается платформа, а не язык.
Причем здесь редактор кода когда речь про написание опердней?
Здравствуйте, novitk, Вы писали:
M>>А уж что за наркоманы будут опердни писать на питоне и js я не знаю, одна поделка годится только для фронта, вторая для наколеночных решений размером не больше одной страницы кода N>vscode — одна страницу кода? Я в курсе, что он в основном на ts, но под js понимается платформа, а не язык.
Блазор является js платформой? Да там для используется js, но платформа Webassembly
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, microuser, Вы писали:
M>А это вообще какие отношение к текущему разговору имеет, будущее любой платформы определяется там и что дальше? Чем джава в этом плане отличается?
Разговор идет о популярности будущих платформах. .NET не популярна where it matters.
N>>.NET — приемлемый выбор, а вот зоопарк технологий из за того, что сегодня кто-то дешевле не есть умно. M>Не есть умно — это складывать все яйца в одну корзину, завтра одна из технологий пойдет по пизде и весь твой не зоопарк вместе с ней
Никакого плохого завтра не будет ни с одной из обсуждаемых технологий, тем более если оно еще и ОSS.
N>>vscode — одна страницу кода? Я в курсе, что он в основном на ts, но под js понимается платформа, а не язык. M>Причем здесь редактор кода когда речь про написание опердней?
Опердни в топ2 банке РФ сложнее vscode?
Здравствуйте, microuser, Вы писали:
M>Это маргинальщина какая то
Хочешь ближе к "топ2 банку РФ", а не к ФААНГ?
Список языков/платформ на которых работают главные риск-системы в следующих банках(5000+ разработчиков в каждом):
GS: slang(проприетарный язык)/jvm
JPM: python
Morgan Stanley: scala/jvm
BaML: python
Здравствуйте, Serginio1, Вы писали:
S> Покажи работу с TaskCompletionSource и CancellationToken.
TaskCompletionSource? Судя по описанию назыывается вроде чуть менее чем везде Promise.
Как делать cancellation в языке с зелеными потоками? Например так.
S>Можно вызавть await для массива задач (WhenAll, WhenAny ), можно вызвать ContinueWith итд. То есть больше механизмов использования.
Ты разговариваешь с человеком, который знаком с первоисточником всей так возбуждающей тебя красоты, которую МS тащит в C# — монадами, хаскeлем, библиотеками эффектов, FRP и т.д.
Здравствуйте, Serginio1, Вы писали:
S> Блазор является js платформой? Да там для используется js, но платформа Webassembly
Нет конечно. Цель wasm собственно и было открыть browser для других языков. С ней кстати тоже все складывается не гладко.
Здравствуйте, novitk, Вы писали:
S>> Покажи работу с TaskCompletionSource и CancellationToken. N>TaskCompletionSource? Судя по описанию назыывается вроде чуть менее чем везде Promise. N>Как делать cancellation в языке с зелеными потоками? Например так.
Суть того, что задачи никак не связаны с асинхронные операции ввода-вывода. Порт завершения ввода / вывода (IOCP)
TaskCompletionSource это создание задачи и ручное получение результата через SetResult https://learn.microsoft.com/ru-ru/dotnet/api/system.threading.tasks.taskcompletionsource-1?view=net-7.0
Ты почитай ссылки, что я даю. Я трачу время и они полезны Использование асинхронного шаблона, основанного на задачах
S>>Можно вызавть await для массива задач (WhenAll, WhenAny ), можно вызвать ContinueWith итд. То есть больше механизмов использования. N>Ты разговариваешь с человеком, который знаком с первоисточником всей так возбуждающей тебя красоты, которую МS тащит в C# — монадами, хаскeлем, библиотеками эффектов, FRP и т.д.
Я изучал монады, хаскели и прочее. И то что сделано в F# и C# меня возбуждает больше.
Я просто указал на разницу между потоками (пусть и зелеными) и задачами на пулах потоков. Только при чем тут "монадами, хаскeлем, библиотеками эффектов, FRP и т.д."
Вообще в основе своей той же стейт машины стоит yield, то есть генерация класса с замыканием переменных для хранения состояния и изменение через MoveNext.
Оно прекрасно себя зарекомендовало в Linq и было перенесено на async/await
Кстати в свое время делали энумераторы делали на файберах, аналог зеленых потоков. Но MS предложили через yield и дало огромный толчок для использования функциональщины в C#
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, novitk, Вы писали:
S>> Блазор является js платформой? Да там для используется js, но платформа Webassembly N>Нет конечно. Цель wasm собственно и было открыть browser для других языков. С ней кстати тоже все складывается не гладко.
Это все понятно. Делают GC, доступ к DOM.
Но вот блазор работает как на сервере так и на клиенте. Кстати первый блазор в вэбасембли был моно который интерпретировал MSIL.
Сейчас они делают AOT. Но нужна сборка мусора и доступ к DOM.
Но преимущество это не только язык но и единая кодовая база как для сервера так и клиента. Можно писать единый код используя условную компиляцию.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, AntoxaM, Вы писали:
S> Аргументы против?
ну например, корутины продуманнее выглядят, выкинуты всякие бесполезные new и т.п.
Ну и вообще синтаксис продуманнее, можно всякие dsl типа compose или gradle делать.
S>>>Опять же Котлин это андроид в основном. AM>>нет, он вполне живёт и на сервере. S>Жить то он может где угодно. Только вот какова востребованность. S>https://survey.stackoverflow.co/2023/#most-popular-technologies-language-prof S>Котлин скоро Dart у будет уступать.
да, видимо за счёт флаттера дарт растёт S>>>Шарп это фигаро в том числе и Xamarin для мобилок. AM>>и сколько этим xamarin'ом пользуются? S>https://survey.stackoverflow.co/2023/#most-popular-technologies-misc-tech-prof S>В 2 раза меньше чем QT или Electron
и в 3и раза меньше того же флаттера. а если сравнить с предыдущими годами: то с 7.4% в 2018 упало в 2 раза. Похоже востребованность так себе.
S>>> А сколько продает? Большинство пользуется VS. AM>>которая без решарпера всегда так себе была. S> 2022 вполне себе и без решарпера хороша. С ИИ
надо будет глянуть как-нибудь
Здравствуйте, AntoxaM, Вы писали:
S>>Здравствуйте, AntoxaM, Вы писали:
S>> Аргументы против? AM>ну например, корутины продуманнее выглядят, выкинуты всякие бесполезные new и т.п. AM>Ну и вообще синтаксис продуманнее, можно всякие dsl типа compose или gradle делать.
Ну спорно. В том же C# есть Source Generator. Как в котлине?
Те же деревья выражений, IQueryable, PM
А вот грабли это конечно песня после студии.
Там такие танцы с бубном приходилось использовать.
В студии настроил конфиг файлы и проблем никаких нет.
Просто иногда в сложных проектах есть конфликты со вложенными пакетами.
Да Type-safe builders мне нравятся https://kotlinlang.org/docs/type-safe-builders.html
Но это конечно не киллер фича. Синтаксис Linq аля Query в котлине есть?
S>>>>Опять же Котлин это андроид в основном. AM>>>нет, он вполне живёт и на сервере. S>>Жить то он может где угодно. Только вот какова востребованность. S>>https://survey.stackoverflow.co/2023/#most-popular-technologies-language-prof S>>Котлин скоро Dart у будет уступать. AM>да, видимо за счёт флаттера дарт растёт S>>>>Шарп это фигаро в том числе и Xamarin для мобилок. AM>>>и сколько этим xamarin'ом пользуются? S>>https://survey.stackoverflow.co/2023/#most-popular-technologies-misc-tech-prof S>>В 2 раза меньше чем QT или Electron AM>и в 3и раза меньше того же флаттера. а если сравнить с предыдущими годами: то с 7.4% в 2018 упало в 2 раза. Похоже востребованность так себе.
Ну 3% вполне себе востребовано. Обычно Xamarin востребован там, где единая кодовая база для разных решений.
И соперничает он с тем же флаттером. Вот новый MAUI набирает популярность. Посмотрим.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, novitk, Вы писали:
N>Здравствуйте, microuser, Вы писали:
M>>Это маргинальщина какая то
N>Хочешь ближе к "топ2 банку РФ", а не к ФААНГ? N>Список языков/платформ на которых работают главные риск-системы в следующих банках(5000+ разработчиков в каждом): N>GS: slang(проприетарный язык)/jvm N>JPM: python N>Morgan Stanley: scala/jvm N>BaML: python
И где здесь js?
