sure there is some akwardness in writing in a typed fp style in typescript, because of no inherent language support for many features... so you get more boilerplate and code, I agree on that.
but working with fp-ts make sense when you decide to dive all in, or to refactor an entire module, not when taking apart one function and comparing it to the boilerplate free ts counterpart.
I think the real issue is, that you didn't convince your team(and yourself) of the gains for the price you pay,
working with fp-ts, you have consistant abstraction for computation, modularity, easy to test, to reason, simple refactoring, strong types throughout the system and so on, which many of these you can't get by simply working with ts, without falling back to creating your own abstractions that would often look awfully similar to the ones defined in fp-ts.
as for the part that talks about working in a team, understanding monads, tagless finals, free monads etc, I always find that argument weird...
no one works in a team without a structure, if you don't go the fp way, you go the OO way or some other way, each has it's jargons, it's just that in the OO world for example, you're just more accustomed to them (covariants, polymorphisem, inheritance, design patterns like visitor, builder, adapter and so on), they are not easier or harder, they just exists in a context where it make sense and you need to learn it, no difference here.
the main abstractions of fp-ts are super easy to learn and intuitive, it took me exactly 1 hour to explain 90% of what I use daily to my team, which had 0 previous experience in this way of writing or thinking.
no need to learn about category theory or monadic laws to use them, but it feels like in the fp community that once we grasp these concepts, which are really easy to explain how to use pragmatically, we just can't let go of their theory and insist to teach them the same way we struggled to learn, in a stupid loop.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
sure there is some akwardness in writing in a typed fp style in typescript, because of no inherent language support for many features... so you get more boilerplate and code, I agree on that.
but working with fp-ts make sense when you decide to dive all in, or to refactor an entire module, not when taking apart one function and comparing it to the boilerplate free ts counterpart.
I think the real issue is, that you didn't convince your team(and yourself) of the gains for the price you pay,
working with fp-ts, you have consistant abstraction for computation, modularity, easy to test, to reason, simple refactoring, strong types throughout the system and so on, which many of these you can't get by simply working with ts, without falling back to creating your own abstractions that would often look awfully similar to the ones defined in fp-ts.
as for the part that talks about working in a team, understanding monads, tagless finals, free monads etc, I always find that argument weird...
no one works in a team without a structure, if you don't go the fp way, you go the OO way or some other way, each has it's jargons, it's just that in the OO world for example, you're just more accustomed to them (covariants, polymorphisem, inheritance, design patterns like visitor, builder, adapter and so on), they are not easier or harder, they just exists in a context where it make sense and you need to learn it, no difference here.
the main abstractions of fp-ts are super easy to learn and intuitive, it took me exactly 1 hour to explain 90% of what I use daily to my team, which had 0 previous experience in this way of writing or thinking.
no need to learn about category theory or monadic laws to use them, but it feels like in the fp community that once we grasp these concepts, which are really easy to explain how to use pragmatically, we just can't let go of their theory and insist to teach them the same way we struggled to learn, in a stupid loop.