Ramda is beautiful and works pretty well in isolation, until you start to use 3rd party code that doesn't work with it well, or you need to interface with non-ramda code in your system, or working with built-in DOM functions or any other number of reasons why you'd need to hop out of the ramda ecosystem.
Then I end up spending most of my time trying to figure out the best way to shove X, Y, and Z into the "ramda way", and often fucking stuff up in the process producing more harder to understand and track down bugs.
Then without perfect buy-in from the entire team, we end up with 3 different ways of filtering exceptions, people using native .map and mixing it with ramda's R.map, uncurrying, reordering, and re-currying functions, and places where the nice control flow is interrupted when it had to dive into 3rd party or native code.
It just ends up hurting every time I go for it, even though the functional style works amazingly in OCaml or Haskell or Rust.
I love ramda and i love fantasy-land but the problem is simply that likely 99% of your colleagues wouldnt understand it. That sucks but is the reality that i often encountered.
I used it also on greenfield projects where I then brought juniors in, and the learning curve for them was hard - at least..
So I kinda avoid it now, though using it taught me much. Even for my embedded C code.
I'm facing the same dilemma, do I go with what junior developers are going to be more familiar with or do I think of it from a 1st principles perspective and build in a way that makes the most sense from a pure engineering perspective. Unfortunately, I don't really see a way to scale past a certain point without these patterns.
