Reading “about FP” will yield you a list of theoretical books, but the moment you step outside to find those focused on building programs in functional languages there is a whole class of specialized books that are still good: Realm of Racket, Real World Haskell, Real World OCaml, Scala with Cats, Functional Programming in Scala, Web Development with…
F# For Fun and Profit and Functional and Reactive Domain Modeling should get you cover on that front. Clojure for the Brave and True is also good when learning to work with data.
There is no question in my mind that Type-On-the-Right is here to stay. Strongly typed programs are more robust, and since type information can be quite complex, it is more sensible to use “name : type”. I am not a big fan of dropping the colon, one must be very careful to not create a language which has all sorts of implicit order-is-significant syntax features.
I was never able to understand RxJava or something like that, that’s why I learned about coroutines in the first place (back in 2017 when it was still experimental). That was by far the best explanation I ever seen about the difference between hot and cold streams. =)
I’ve liked the type on the right style since Algol 60, But since the old-style languages that did it that way did it without any sort of type inference I suspect it’s more a style thing influenced by languages like Haskell and ML.
But then I’m also old-fashioned enough to go with Dijkstra and feel like everything ought to be declared and that type inference is hazardous.
It also has to do with how the inference is determined and how that inference is intended to be used. In Java, for example, it’s common the supply the abstraction on the left and the code to satisfy it on the right. By doing so the left hand side is polymorphic without relying on a right handed function returning that abstraction to be so.