proposal-error-cause VS fp-ts

:::note When using remote APIs, we often have the possibility to generate the types automatically from a JSON schema for REST APIs, from protobuf files for gRPC-based APIs, from a database schema, etc. You might even be using an external API through an SDK that already provides you with all types. In such cases, the creation of specialized Error classes is not mandatory. However, it might still be a good idea to do so to provide application-specific errors rather than bubbling up 3rd-party low-level errors. For such cases, the upcoming Ecma TC39 proposal for Error Cause is useful as it allows to chain errors. Polyfills exist: Pony Cause or error-cause. :::

Error Cause : .cause property on all Error types slides.

The impact and cause provides the most value when paired with the other, and that's what Error Cause enables and what Pony Cause is is a ponyfill for and provides helpers for.

Well, we have error-cause on stage-3 for the same and with which we could do something like:

Error Cause: Enhancing errors with a distinct "cause".

Error Cause

I think it’s great that functional programming is making its way into traditional imperative languages - even JavaScript (I recently came across https://gcanti.github.io/fp-ts/ as a pretty extreme example)

Elixir/Erlang has function-level pattern matching, which I really like. I’ve yet to see it anywhere else, though my understanding is it came from Prolog.

While I certainly agree, I've found that this is often an indication of too-complex an architecture, and a fundamental re-think being necessary. I've had projects that depend on [fp-ts], which end up incredibly generic-heavy, but still make it entirely through a typecheck(not build- typescript's just worse at that than other tools like esbuild) in seconds-at-worse.

Obviously depends on your organization/project/application, but I do like these things as complexity-smells.

[fp-ts]: https://gcanti.github.io/fp-ts/

Unlike more comprehensive functional libraries like fp-ts, each module can be imported and resolved separately. If you just need options, simply add the option module and you're good to go.

While it's quite abstract, I believe it may be useful to those of you who is interested to learn more about functional programming [in Typescript] and also get more intuition on diverse programming ideas. I use fp-ts as a functional programming library there.

The library for TypeScript that this is influenced by is here:

https://github.com/gcanti/fp-ts

Interesting how both languages with this library converge to a similar syntax, due to heavy use of functions.

Learn something that pays the bill first - nowadays it's Golang/Rust react/typescript. Then you can try some pure fp libs like fp-ts and fp-core.rs, and look through existing scala cats docs. If you'll feel bad about it - that's totally fine and expectable, fp takes a paradigm shift and not that many dev able to shift their brains way of thought due to basic psychological rigidity) (inability to change habits and to modify concepts/attitudes once developed). And that's purely a staffing and management issue - folks hired randoms out of the blue, and called 'em a team.

fp-ts, a library that caters to functional programming in TypeScript, comes with some micro-abstractions that already solve a few of our needs.

Also, don't underestimate how powerful TypeScript can be in capable hands (namely Giulio Canti's). Check out fp-ts, for instance.

You are able to type it using function overloads, an example can be found here - link, line 236.

looks like more ergonomic/focused version of fp-ts[1]

[1] https://gcanti.github.io/fp-ts/