Take a look at Optics By Example (@opticsbyexample): https://twitter.com/opticsbyexample?s=09

Вот чем Rust реально напрягает, так это немного деревянной системой типов за счёт отсутствия специализации и энфорса статического связывания.
Пишешь такой себе абстрактный код, наворачиваешь абстракции, всё хорошо, всё красиво, без лишних клонов, с заимствованием как надо, а потом в самом конце вся эта лабуда не сходится и не компилится, потому что conflict trait implementation для какого-то From/Into/AsRef/Borrow, и... сидишь у развалившегося корыта и чешешь репу часами 😕

В той же Гошне порешалось бы сразу через какой-то interface cast, ибо там в астрактном коде одна динамика. А тут приходится совсем нетривиальные хаки надумывать.

Постоянно на этом момент обжигаюсь.

All Algorithms implemented in Rust

https://github.com/TheAlgorithms/Rust

вот переделал без функции, кажется ничего не изменилось, но стало понятнее что я пытаюсь сделать
https://pastebin.com/h78MC1y8

https://github.com/carllerche/tokio-serde-json/blob/master/src/lib.rs
вот тут тоже без poll и ручного написания Stream и Sink не обошлось

Растишки переизобрели ReaderT: https://github.com/anp/moxie/blob/master/topo/src/lib.rs

https://gist.github.com/sopvop/4de6dcc3a5a4383600ec60ac235844c2 типа

https://t.iss.one/haskellru/211436
Maxim Koltsov:
Подскажите какие-нибудь статьи для понимания monad-control и штук около того?

Kirill Valyavin:
Если unlift годится, фпкомплитовские статьи есть вроде

Зигохистоморфный Препроморфизм:
https://lexi-lambda.github.io/blog/2019/09/07/demystifying-monadbasecontrol/

Maxim Koltsov:
Спасибо

Apfelsinchen Ritter:
Мне кажется, что проще понять unliftio, а на основе этого знания MonadBaseControl. Снойман статейку на fpcomplete когда-то писал.
https://tech.fpcomplete.com/blog/2017/07/announcing-new-unliftio-library

Alexander Vershilov:
используй unliftio

или руками аналог сделать

Maxim Koltsov:
Ну знаешь, в некоторых либах прикручен MonadBase, MonadControl

А почему?

Alexander Vershilov:
Там просто используй его

MonadControl переусложнен из-за того, что там может быть разный base

В итоге инстансы писать действительно не просто после перерыва

Maxim Koltsov:
Ну, я вижу что его используют в библиотеках и хочется понимать :)

Denis Redozubov:
ну идея то простая

Alexander Vershilov:
Напиши 3 инстанса - поймёшь

Denis Redozubov:
был MonadIO m

Alexander Vershilov:
идея очень простая - собрать состояние и воссоздать стек внутри продолжения

Denis Redozubov:
отлепили IO от Monad и параметризовали по нему

ну это уже реализация

Alexander Vershilov:
Ну это идея за monad-control

отличающая его скажем от unliftio

ну часть, которая "автоматом" это отличие

λeonid Onokhov:
идея в том что-бы изнутрей m a выполнять FooT m b

а сам m a выполнять внутре FooT m a

Apfelsinchen Ritter:
Есть у нас стандартная функция

withBinaryFile :: FilePath -> IOMode -> (Handle -> IO a) -> IO a

А в проекте у нас есть вместо IO MonadIO, то есть

withBinaryFile' :: MonadIO m => FilePath -> IOMode -> (Handle -> m a) -> m a

unliftio дает нам возможность сделать вот так

withBinaryFile' :: MonadUnliftIO m => FilePath -> IOMode -> (Handle -> m a) -> m a
withBinaryFile' fp mode inner =
withRunInIO $ \runInIO ->
withBinaryFile
fp
mode
(\h -> runInIO (inner h))

Если для нашего m есть инстанс MonadUnliftIO.

Так делать приходиться поскольку есть проблема с позицией аргументов завернутых в m.

https://tech.fpcomplete.com/blog/2016/11/covariance-contravariance

Maxim Koltsov:
Ага, и это обычно бывает только для ридеров всяких

Apfelsinchen Ritter:
Вот для ридеров всяких unliftio и подходит, то есть, там где нет стэйта.

А там где нужен появляются monad-control, monad-base-control, которые могут и стэйт иметь.

Alexander Vershilov:
Ну это не то, чтобы точно

с unliftio или аналогами стейт никто иметь не запрещает

Apfelsinchen Ritter:
Но эти пакеты и более сложные в использовании.

Alexander Vershilov:
С другой стороны у monad-control стейт "чистый"

Apfelsinchen Ritter:
Это да. Тут уже на совести разработчика.

Alexander Vershilov:
И весьма неочевидно себя может вести в присутствии исключений, хотя в lifted-base аккуратненько всё сделано

Сразу скажу, &String тебе нужен примерно никогда

Потому из-за deref coercion на у &String доступен весь API &str, а единственное, что ты можешь сделать, что в это API не входит - это метод .capacity(). Знать ёмкость строки, не имея возможности её поменять, не имеет большого смысла

Эх, блин, прям разочарование года. 😞
Не выходит конфетка из раста - упёрлись видимо в лень разработчиков и фобию бампа мажорной версии. В итоге получим те-же грабли как и в языках с исключениями, когда эти исключения просто игнорятся и не обрабатываются. И это даже сложно будет отследить - толи это разработчик схалтурил и запилил дефолтную ветку, или это была необходимость для сохранения совместимости с новыми версиями другой библиотеки, где может появится новое значение в enum-е.

в чем проблема использовать failure? последний раз вручную написанные энамы видел год назад

Αλεχ Zhukovsky:
@lkppl слушай, ты помнишь спрашивал про то, вызывает ли УБ в си УБ в расте? где тебе отвечали?

Roman Proskuryakov:
в ишью Ральф ответил, что да. И дополнили доку пунктом, но потом это удалили, хз почему

Αλεχ Zhukovsky:
https://github.com/rust-lang-nursery/reference/issues/485

сам нашел)

Arrows
https://softwareengineering.stackexchange.com/a/118884

А если обмазаться типотой и генератой — будет тяжко

Вон, у Сноймана, наверное, всё ок с RIO