Есть и inline function и computation expression c CustomOperation для написания своих DSL.
есть еще много чего, чего нет в котлине, например выделение памяти на стеке.
Котлин хорош, но печалит, что вокруг все равно всё Java.
Кроме того, на бэкенде многие также не используют Котлин
все заточено на иммутабельность и отсутствие синтаксических нагромождений, вроде top-level функций, отсутствия ';', все поля класса — на самом деле сразу свойства, и т. п.
Да вряд ли F# когда-то станет аналогом хаскеля, потому что использует тот же рантайм что и C# и нужно поддерживать интероп в обе стороны. Если я все правильно понял, то HKT по этой причине и отсутствует (нет поддержки в рантайме), а по пути скалы не хотят идти (стирание типов). У HKT есть еще обратная сторона медали — тайп-астронавтика, примеры: Cats и ZIO из скалы, некоторые запрещают их использование. Также это очень странно, когда люди ругают F#, и при этом пытаются писать на c# как на хаскеле.
Непонято, чего вы спорите, как написано в статье, конкретно с таймерами проблема исправлена, хоть в 4.8 по умолчанию используется старый вариант, я не смог воспроизвести. Если что, мне это интересно чисто в академических целях, ну чтобы лучше понимать как вообще всё это работает.
Из описания проблемы понятно, что она существует только когда много потоков одновременно пытаются блокировать один ресурс. Но не написали какое количество потоков приводит к этой проблеме, интересен хотя бы порядок.
Тредпул .NET по умолчанию ограничен очень большим числом потоков (на моей тачке 32767), но в реале по умолчанию использует количество потоков равное количеству ядер. При этом если потоки блокируются, то похоже рантайм это отслеживает и увеличивает тредпул автоматически (и уменьшает кстати тоже). И тут вопрос — где описано это поведение? И второй вопрос — можно ведь сразу ограничить размер тредпула количеством ядер, и тогда, как мне кажется, можно избежать этой проблемы?
ThreadPool.GetMaxThreads(out int workerThreads, out int completionPortThreads);
ThreadPool.SetMaxThreads(Environment.ProcessorCount, completionPortThreads);
Эта идея с автоматическим увеличением тредпула наверное хороша для какого-то легаси. Но кажется для новых проектов, особенно на net core, было бы разумно сразу ограничивать размер тредпула каким-то разумным числом, не сильно большим чем число ядер.
У меня серверные приложения, я работаю на Винде, а приложения на линукс в докере. Я не выбирал между железом и виртуалкой, я выбирал между разными виртуалками. Я заметил, что на виртуалбокс работает медленнее, сделал небольшой тест который подтвердил это. Кроме того, сам виртуалбокс довольно глючный, за год у меня несколько раз отваливалась сеть, так что потом она поднималась только после танцев с бубнами. А подключенный usb девайс на 6 виртуалбоксе отваливался стабильно каждые 3 часа, а на 5ом раз в сутки. На hyperv теперь все стабильно, usb правда пришлось прикинуть с линуксовой тачки.
Есть и inline function и computation expression c CustomOperation для написания своих DSL.
есть еще много чего, чего нет в котлине, например выделение памяти на стеке.
Котлин хорош, но печалит, что вокруг все равно всё Java.
Кроме того, на бэкенде многие также не используют Котлин
это всё есть в F#
Только следующая LTS будет не 5 а .NET 6
Как вариант погладить утюгом
А за тканевые перчатки тоже будут штрафовать? Мне кажется нет, вот и проблема решена
Да вряд ли F# когда-то станет аналогом хаскеля, потому что использует тот же рантайм что и C# и нужно поддерживать интероп в обе стороны. Если я все правильно понял, то HKT по этой причине и отсутствует (нет поддержки в рантайме), а по пути скалы не хотят идти (стирание типов). У HKT есть еще обратная сторона медали — тайп-астронавтика, примеры: Cats и ZIO из скалы, некоторые запрещают их использование. Также это очень странно, когда люди ругают F#, и при этом пытаются писать на c# как на хаскеле.
А два разных ключа нельзя иметь? Когда один теряется, его отзываешь, пользуешься вторым и делаешь третий.
Тем что эта премия не чтобы давать, а чтобы отнимать.
потом можно запустить готовое приложение без докера:
dotnet new console
dotnet run -c release
Так кешировать надо было Task и вообще для таких случаев в c# придумали ValueTask
только на скриншоте ни одного жрущего процесса я не увидел, у дотнета максимум 250Мб, а всех прожорлевее жава
Хороший пример кстати, я увеличил количество таймеров до 100к, у меня получилось что GO расходует раза в 2 больше процессора и раз в 10 больше памяти.
Непонято, чего вы спорите, как написано в статье, конкретно с таймерами проблема исправлена, хоть в 4.8 по умолчанию используется старый вариант, я не смог воспроизвести. Если что, мне это интересно чисто в академических целях, ну чтобы лучше понимать как вообще всё это работает.
Из описания проблемы понятно, что она существует только когда много потоков одновременно пытаются блокировать один ресурс. Но не написали какое количество потоков приводит к этой проблеме, интересен хотя бы порядок.
Тредпул .NET по умолчанию ограничен очень большим числом потоков (на моей тачке 32767), но в реале по умолчанию использует количество потоков равное количеству ядер. При этом если потоки блокируются, то похоже рантайм это отслеживает и увеличивает тредпул автоматически (и уменьшает кстати тоже). И тут вопрос — где описано это поведение? И второй вопрос — можно ведь сразу ограничить размер тредпула количеством ядер, и тогда, как мне кажется, можно избежать этой проблемы?
Эта идея с автоматическим увеличением тредпула наверное хороша для какого-то легаси. Но кажется для новых проектов, особенно на net core, было бы разумно сразу ограничивать размер тредпула каким-то разумным числом, не сильно большим чем число ядер.