ну тут типы явно даны

можно ж навести мышкой

мне просто интересно, сколько времени займет понять, что тут происходит

нормально делай -> нормально будет

и как, сильно помогает?

каким образом $language_name спасает тебя от кода с тучей одноразовых переменных и огромного количества if-else?

let handleEvents (agBuilder:AgBuilder<'Id,'St,'Ev>) (get:AgLoader<'Id,'St>) (put: Ag<'Id,'St> -> 'Ev list -> Async<Choice<'Ev list * int, 'Err list>>) (f:AsyncArrow<'Input * Ag<'Id,'St>, Choice<'Ev list, 'Err list>>) : AsyncArrow<'Input*'Id, Choice<'Ev list*'St*int, 'Err list>> = fun (inp,iden)

да С++ хотя бы можно прочитать, если знать С++. тут например знание F# не помогает

а ты можешь конкретнее написать, что именно тебе не нравится?

мне проще сказать, что мне тут нравится

confirmPick <| fcid <| userPicking.state <| request.locationId <| request.thorSku <| request.qty <| request.pickBy <| pickTicketId <| request.cartId <| request.version <| user <| plId

ну один момент все же есть. это сидит в отдельном модуле, вокруг которого я выставил кордоны, карантин и три ряда оцепления. и что у меня есть возможность не ходить туда самому, а посылать низшие чины с двумя ведрами гаек

я лишь уповаю на аллаха в том, что компилятор достаточно умен, чтобы оптимизировать это все

я лишь уповаю на аллаха в том, что компилятор достаточно умен, чтобы оптимизировать это все

не-не, стой. а тебя просили? оптимизировать? кто-то жаловался?

confirmPick <| fcid <| userPicking.state <| request.locationId <| request.thorSku <| request.qty <| request.pickBy <| pickTicketId <| request.cartId <| request.version <| user <| plId

confirmPick <| fcid <| userPicking.state <| request.locationId <| request.thorSku <| request.qty <| request.pickBy <| pickTicketId <| request.cartId <| request.version <| user <| plId

оно жрет память гигабайтами и лейтенси на апишечках измеряется в секундах

вот кстати зачем пайп влево юзают вообще

вот кстати зачем пайп влево юзают вообще

оно жрет память гигабайтами и лейтенси на апишечках измеряется в секундах

у нас есть модуль AsyncSeq для работы с последовательностями асинхронок. эти упыри туда передают List

и чо, замеры показывают, что дело таки в стэкфреймах? или хуево спроектированной БД и хевой туче лишних действий без помнимания O(n) и структур данных?

оно жрет память гигабайтами и лейтенси на апишечках измеряется в секундах

но дело вообще-то не в этом. довольно во многих аспектах мне удалось восстановить дисциплину и если будет на то воля аллаха, через год я все же привью им истинную веру

как вы считаете, чтобы было, если б был не эфшарп, а сишарп?

как вы считаете, чтобы было, если б был не эфшарп, а сишарп?

конкретно тот кусок бы распидарасило на 5 неймспейсов и 12 классов, три из которых базовых. если пишут профи, то было бы еще 5 интерфейсов. с хуевыми названиями и сомнительным API.

напомню, что в моем проекте всего 5 (пять) сущностей

ну и че? открываешь код и за 20 минут вникаешь в любой кусок

ты вник в кусок выше?

не прям вник, но я его понимаю и главное - я четко могу выделить куски ,которые не понимаю и знаю как нужно действовать, чтобы их понять, особенно при условии ЧТО НЕТ СКРЫТОГО СОСТОЯНИЯ

что он делает? какие у него гарантии, какие контракты?

гарнтии и контракты у тебя в инвариантах должны быть, я явном виде, FsCheck вроде никто не отменял