fp-ts: Which ring?

[datalek]

Hello everyone! 👋

Many projects¹ at PagoPA use fp-ts. It's likely that, at some point, the library will be overshadowed by effect-ts, with the consequent risk of not being maintained properly (or maybe not? ²). In your opinion, in which ring fp-ts should be placed?

Footnotes

1. https://github.com/search?q=org%3Apagopa+path%3A**%2Fpackage.json+%22%5C%22fp-ts%5C%22%22+&type=code&p=1 ↩

2. https://github.com/gcanti/fp-ts/discussions/1852#discussioncomment-5687771 ↩

[gunzip]

I won't put it under "adopt", since in the adopt ring we only include items when we think it would be a poor and potentially irresponsible choice not to use them given the appropriate project context, which is not the case imho.

Currently, there's no signal fp-ts will be discontinued, moreover, it would be relative easy to maintain the part we use ourselves.

I wont' put it under 'hold' neither, until we have assessed effect-ts (read: until effect-ts goes into triel or adopt).

My vote goes to 'trial' for fp-ts and 'assess' for effect-ts.

[balanza]

Also, consider that is a package with zero dependencies and no reference to runtime-specific features.

That means that the only thing that could outdate fp-ts is a breaking change in TypeScript itself.

[lucacavallaro]

@balanza to "break" it yes, but JS continually evolves - we risk being reduced to using only a small subset of the language

[datalek]

I like the idea of ​​putting it on trial, and I think it reflects well the current state of fp-ts in the company. It is widely used at the moment and we are monitoring to see how it evolves.

[lucacavallaro]

In my opinion we should put fp-ts on hold
Based on our codebase, we don't appear to know functional programming and the right use of this library.

It is an utility library that we mix with imperative code (example: if (E.isRight(something))) without valid reason.

effect-ts can be introduced as asses if we want to see if it can be useful to us

the alternative of fp-ts in not necessary effect-ts, it can be "nothing" so to me these libraries are not related

[gunzip]

Indeed, the trade off of not using fp-ts would be, at the bare minimum, reverting to:

1. null checks
2. exception handling using try / catch
3. nested function calls instead of pipe
4. some other utillity library to handle aysnchronous composition

[lucacavallaro]

I agree on usefulness of Option and Either (and maybe, there are better implementation of them in other libraries? without math abstractions and HKT emulation? we can explore this, because fp-ts it's hard to debug and if gli astri non sono allineati is a source of compile errors, maybe effect-ts can save us).

I think that the "constrained style" has made the approach to the code much more dogmatic than practical, for example the railway oriented programming (that we use indiscriminately) despite being cool and useful in many cases, it doesn't always fit well. But when we write backend code, just because we have to use fp-ts we adopt this pattern and we wrap everything (more code to maintain).

My idea is not to "stop using fp" or fp-ts, but make sure it is a conscious choice and regulate better the use case and the subset of the library to recommend.

[balanza]

make sure it is a conscious choice

💯 agree. That applies to TypeScript, too (can't count the times I had to request changes to PR due to the abuse of manual casting)

[gunzip]

[balanza]

more dogmatic than practical

I wouldn't say dogmatic, I think sometimes you have a solution for a problem and you just want to take it for granted and move on 🤗

[lucacavallaro]

I proposed a guild to asses and study https://effect.website

https://pagopa.atlassian.net/wiki/spaces/ENG/pages/908001327/Effect