Programowanie funkcyjne z Arrow, Scalaz, cats, vavr itp. - korzystacie?

cześć,
korzystacie w swoich projektach z rozszerzeń do programowania funkcyjnego?
jeśli tak, to z jakich i jak oceniacie ich wpływ na kod (benefity) i learning curve który wprowadzają do projektu?

widzicie realne benefity czy tylko hype na FP?

szczególnie interesuje mnie temat w projektach z kotlinem/scalą, ale java + vavr również

dzięki :)

Po co korzystać z rozszerzeń do programowania funkcyjnego jak się pisze w języku funkcyjnym?

@tsz dlatego że wprowadzają zazwyczaj więcej funkcyjnych elementów (typeclasses, abstrakcje itd.) niż istnieje w corowym języku - np scali, kotlinie

To są różne poziomy:
VAVR - oczywiście, ale to nie żadne specjalne fp. To po prostu kolekcje, które w odróżnieniu od tych z java.util. są zdatne do użytku. (+ smaczki typu Either, Option - ale to takie fp poziom 1).
Używam vavr również w kotlinie mimo, że jest tam null safety i mimo, że kolelekcje są mniej problematyczne niż w javie.
Tu odpowiadam na zarzut, który może się pojawić - to nie tak, że java.util. jest totalnie złe - to są niskopoziomowe rozwiązania, które mogą być przydatne w jakimś 1 promilu kodu, w całej reszcie są upierdliwe (przez słabe API) i (niebezpieczne (przez mutowalność) lub nieefektywne) .

arrow-kt nigdy jeszcze sensownie nie użyłem, bo - nie rozwiązuje problemu kolekcji i wchodzi mi w konflikt z Vavr (przez Either). Przez braki kotlina - nie wiem czy to kiedykolwiek będzie miało sens - brak HKT powoduje, że wiele fajnych funkcji (typu mapM z haskella) nie da się napisać (wiem, że arrow - próbuje to łatać jakieś pluginami do kompilatora... ale mnie takie rzeczy raczej zniechęcają (przypomina mi się lombok i adnotacje).

Scala - używałem troche ScalaZ, głównie ze względu na Task. Który to jest niezepsutym Future, a troszkę jak monada IO. Jeśli chcemy iść w pełne FP i obsługiwać efekty uboczne to tego typu biblioteki się przydają.
W scali troszke reset w tej działce zrobił John De Goes z biblioteką Zio - monada IO na nowo. Ale nie mam z tym doświadczeń - z daleka podoba mi się.
Gdybym więcej w tej Scali pisał to pewnie by to zaszło dalej.

dzięki @jarekr000000 za odp

a jak oceniasz korzyści vs learning curve w projekcie po wprowadzeniu takich bibliotek?

tematy fp raczej nie są trywialne, a jeśli projekt pójdzie w fp to wyobrażam sobie, że znacznie podwyższa to zrozumienie kodu dla kogoś kto dużego pojęcia o fp nie ma i nagle widzi wszędzie dziwne konstrukcje

ma to wymierne korzysci?

vavr to generalnie jest prawie żaden learning curve. wręcz dużo mniej trzeba umieć niż przy standardowych kolekcjach.|
Korzyści to są takie, że nie potykamy się o własne nogi i to widać. Vavr + Option jak wlezie w projekt to od razu widać poprawę (w javie).

Jedynie nad eitherem jest dyskusja, ale to wręcz 1-1 ta sama dyskusja co kiedyś nad exception handling i checked vs runtime exception. Tylko zamiast checked exception wpada Either i wszystko ma nawet większy sens niż wcześniej. Z drugiej strony - jakbym miał w dolarach zmierzyć korzyści z samego Eithera vs Exceptions to te akurat są niespecjalne różnice. To już bardziej kwestia religijna i nie kruszę o to kopii.

W kotlinie jest ciekawszy problem: Option<T> vs T?. I czy warto iść w vavr skoro kotlinowe kolekcje nie są aż tak problematyczne. Tu zdania są podzielone. Przy czym nie ma problemu z uczeniem, problem jest z tym, że nie każdy widzi sens (w kotlinie) i nawet to rozumiem. Na pewno zysk z vavr jest istotnie mniejszy niż w javie.
Ja tego vavra w kotlinie uzasadniałem tym, że dzieki temu mamy spójne i ładne API dla kodu w javie ( mam projekty mieszane kotlin + java).
Z tym, że praktyka pokazała, że i tak nowy kod powstaje raczej w kotlinie, więc tak naprawdę nie ma specjalnie tej potrzeby....

Co do Scali - powiedzmy sobie uczciwie - mam tu słabe doświadczenia z pracy w zespole (złożonym z typowych javowców), właśnie z tym, że ludzie nie ogarniali - bardziej niż tego oczekiwałem. Dlatego jadę w ten kijowy kotlin - jak się ludzie nauczą w kotlinie w miarę pisać - to pewnie znowu będę zachecać do Scali. Przy czym tu problemem nie były raczej biblioteki fp , a sama Scala i ekosystem - za dużo do nauczenia. Nie doceniłem tego. Można szybko zrobić z javowców zespół piszący w Scavie. Ale taki zespół jest bezradny przy próbie korzystania z typowych Scalowych bibliotek (oraz stack overflow). Scala to jezyk, którego nie da się nauczyć metodą na rympał (IMO).

VAVRa jest raczej łatwo się nauczyć ;)
Ciekawą, inną zaletą VAVRa jest to że ichniejszy Option jest serializable

ok dla takich typów jak Option czy Either to ja widzę wymierny zysk

zastanawiają mnie bardziej złożone konstrukcje np IO z Arrowa - widzę, powiedzmy, w tym benefit ale czy jest na tyle duży, żeby to wprowadzać - mając na uwadzę ilość WTFów które poleci jak ktoś pierwszy raz zobaczy kod... to sam nie wiem

gdzie IO to obok Either czy Option raczej popularna konstrukcja; Arrow ma ich wiecej, nie mówiąc o scalaz

Jak dla mnie to zależy od zespółu. A ja w zasadzie nigdy nie byłem w zespole, gdzie byłby sens wprowadzenia arrow lub cats, scalaz. Za dużo kroków.
Jak się pisze samemu lub w małym zespole do tego/na konferencji/warsztatach - bez męczącego głowę biznesu, to nawet najgłupsze praktyki całkiem się sprawdzają, więc nie bardzo można z tego wyciągać wnioski.
(na dziś mój wniosek byłby taki - jak już mamy użyć arrow, ScalaZ, Cats... to czemu nie napiszemy tego po prostu w Haskellu? paru moich znajomych zresztą przelazło na Haskella (po scali)).
EDIT:
w tym sensie sam sobie odpowiedziałem na pytanie i widzę::
biblioteki fp do kotlina, scali pozwalają Ci ogarnąć programowanie funkcyjne i służą jako pomost do Haskella. Bo prędzej czy póżniej ogarniesz, że te języki jednak się do pełnego fp nie nadają (niszczą wiele z korzyści).
Kotlin to totalny dramat - szkoda dyskutować.
A Scala ma jedną, ale paskudną wadę - ma statementy. Mnie to mocno odrzuca. Wiadomo, że nawet haskell ma IO () - czyli taki haskellowy void, ale ryzyko popełnienia przypadkowego błędu na tym jest dużo niższe niż w Scali. Niestety, z tego co kojarzę w Scali 3 nic jeśli chodzi o statementy się nie zmienia (very szkoda).

Dlaczego nikt tu jeszcze nie wspomniał o Clojure?

Z perspektywy Scali to dodanie cats daje bardzo dużo nawet jeśli nie stosujesz hard FP. Jest bardzo dużo zdefiniowanych metod, które przydają się tak po prostu na codzień. Jeśli chodzi o próg wejścia to wszystko zależy od tego jak bardzo idziesz w FP:

• Projekt oparty o Scalowy Future wymaga tak de facto znajomości Scali. Zazwyczaj w projektach masz dodane chociażby zwykłe cats, ale głównie z powodu który wymieniłem na początku.
• Projekty oparte o Monix/Cats-effect wymaga już więcej od programisty. Często musi ogarniać hierarchię type class, koncepty co i gdzie ma sens i po co to wszystko. Tutaj bym powiedział, że ktoś musi dość dobrze ogarniać Scalę i znać chociaż podstawowe koncepty FP żeby w dość sensownym czasie zacząć korzystać z tych bibliotek.
• ZIO - nie mam zbyt dużo doświadczenia w nim ale reklamują jako "noob friendly". W teorii bardzo dużo rzeczy masz do użytku out of the box, a w praktyce jak próbowałem zrobić kilka rzeczy to to wcale tak kolorowo nie wygląda i błędy w konsoli potrafią straszyć ;)
• Tagless final i inne cuda - największy próg wejścia, aktualnie hype spada i jest stosowany głównie w bibliotekach. W kodzie aplikacyjnym aktualnie jest coraz częściej uznawane jako anty-pattern

Ostatnio się rekrutowałem i odnoszę wrażenie, że w większości projektów są dodane koty (nie było rozmowy gdzie by się o to nie pytali ;)). Hard FP występuje zdecydowanie rzadziej bo musi być w zespole chociaż jedna czy dwie osoby które rozumieją biblioteki, wiedzą po co są, a i jeszcze muszą nauczyć pozostałą część zespołu co i jak.