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).