Сатурн неплох, захотелось переехать после последних постов Кшиштофа на Медиуме. Останавливает что связку Akka.Streams с сервером придется переписывать и заново вникать с хитросплетенные зависимости

Вводный курс по F#. Один из участников F# community решил составить вводный курс по нашему языку программирования и у него неплохо получилось. Примерно за 2 часа вы сможете научиться основам программирования на F#. Присоединяйтесь! Подробнее: https://www.youtube.com/playlist?list=PL-nSd-yeckKji5_4YXeU79bOQE1XApEO0 #fsharp #course

А какой вариант вы предпочитаете? let getUser firstName lastName = { FirstName = firstName LastName = lastName } let getUser firstName lastName = { FirstName = firstName LastName = lastName }

О.о

Стоит думать. Но просто автор там цельную статью напилил как он щас всех порвёт перформансом

Были же бенчи, где выстрелила, нет?

скинь ссылку, я последний ран взял

Я ж спросил :)

господа, сейчас тыкаю палкой мейлбокс процессоры. Корректно ли их использовать для хранения состояния, и если да, то как примерно разбросать следующий сценарий на мейлбоксы? - Юзер шлет команды - Я команды собираю в очередь, потом ее фильтрую (убираю взаимоисключающие команды и тд) - По таймеру беру список команд и поочереди накатываю их на аггрегат.

> смело там его юзать Ну такое и имхо главный плюс фп без стейта не про "многопоточность", а краткости и выразительности. И это важно, тк мало кто пишет действительно "многопоточный код" (и никому F# так не продаш).

За базар в этом чате принято отвечать

Что не понятно во фразе "создавать поток динамически" ? Threading.Thread.StartNew или как он там. Вот эта инструкция и жжёт дорожки при скэйле системы

а вот винда этих потоков тысячами создаёт, и ничо не горит. в чём разница?

У меня эта инструкция создаёт 100 процентов нагрузки на проц в простом приложении с вебсоеетами.

У меня эта инструкция создаёт 100 процентов нагрузки на проц в простом приложении с вебсоеетами.

Не, ну по идее можно написать while(true)Thread.Start(()=>()), но я с трудом себе представляю конструктивное применение этой конструкции.

Архитектура такая. Клиент открывает вебсокет, по которому двунаправленный json rpc. На некоторые вызовы от клиента к серверу идут долгие запросы в базу. Я их запускал в отдельном потоке - и всё страшно ужасно легло. Потом долго и нудно рефакторил в асинк авейт. Ложится примерно в два раза меньше

Рекомендую почитать что-нибудь про конкаренси

Или мб у товарища очень много клиентов постоянно подключается и отключается, а он решил себе завести по треду на каждого клиента?

Может просто в го так делают?

У них там просто, я так понял, в условный тредпул это всё неявно перемещается, да и всё.

За базар в этом чате принято отвечать

по нескольку тредов на клиента. Агонь

Архитектура такая. Клиент открывает вебсокет, по которому двунаправленный json rpc. На некоторые вызовы от клиента к серверу идут долгие запросы в базу. Я их запускал в отдельном потоке - и всё страшно ужасно легло. Потом долго и нудно рефакторил в асинк авейт. Ложится примерно в два раза меньше

Ну, пока у тебя клиентов очень-очень мало, это вполне может быть ок. Если для сетевой игрушки какой-нибудь на 8 игроков, к примеру, с dedicated server.

Проблема в том, что надо запросы делать асинхронными в не по треду на них спамить

Это да. Но при этом поскольку тренды всё равно будут разные может возникнуть shared mutable state, вот что напрягает. В ноде то хоть этого нет.