> Not that different from wrapping every result into seventeen layers of functional abstractions. What do you think flow or flatMapEither does?
It changes what functions return without having to adapt them to particular use-case.
> Of course it does. That's what the catch is for.
To achieve that, the catch has to assume that the functions throw exceptions with particular data. This cannot be enforced with type system, and once again, tied implementation of these functions to this particular context where they're used.
> Of course it adds runtime performance overhead. Any additional function call adds a performance overhead.
The function call overhead is a couple of dozens nanoseconds at best. And we're talking about a remote call that takes 30 seconds to complete and costs $0,05 per OpenAI's API.
The overhead you're talking about is 0,0000001% in time and I think a few orders less in cost.
> If the alternative is more readable
It's not. An alternative that would actually have all the same functionality would be 4 times as long and more importantly, much more complex to change in a meaningful way.
> more traceable, has better stack traces for errors
But that's the point: we don't need stack traces. We don't need exceptions for errors that we know how to handle.
That's like complaining that a GC-based language doesn't have a tool like valgrind to handle error allocation and deallocation issues.
> doesn't require an unstable ever changing dependency...
I've never had a breaking change from fp-ts and don't expect it to ever happen because of the nature of the library.
But that's not... what they actually do?
> Not that different from wrapping every result into seventeen layers of functional abstractions. What do you think flow or flatMapEither does?
It changes what functions return without having to adapt them to particular use-case.
> Of course it does. That's what the catch is for.
To achieve that, the catch has to assume that the functions throw exceptions with particular data. This cannot be enforced with type system, and once again, tied implementation of these functions to this particular context where they're used.
> Of course it adds runtime performance overhead. Any additional function call adds a performance overhead.
The function call overhead is a couple of dozens nanoseconds at best. And we're talking about a remote call that takes 30 seconds to complete and costs $0,05 per OpenAI's API.
The overhead you're talking about is 0,0000001% in time and I think a few orders less in cost.
> If the alternative is more readable
It's not. An alternative that would actually have all the same functionality would be 4 times as long and more importantly, much more complex to change in a meaningful way.
> more traceable, has better stack traces for errors
But that's the point: we don't need stack traces. We don't need exceptions for errors that we know how to handle.
That's like complaining that a GC-based language doesn't have a tool like valgrind to handle error allocation and deallocation issues.
> doesn't require an unstable ever changing dependency...
I've never had a breaking change from fp-ts and don't expect it to ever happen because of the nature of the library.