Add "usages of effect in the wild" section

[sambacha]

What is the problem this feature would solve?

Better than "social proofs", add some statements as to practical use cases for using Effect.ts

e.g.

microsoft/TypeScript#56365 (comment)

I understand your concern about reliability, but please respond:

I spend about half my "writing responses" energy explaining to people why we shipped a feature that seems incomplete or imperfect -- they will tell me we shouldn't do anything if it can't be done perfectly or at least near-perfectly. From what we can tell, any feature here would be well short of any reasonable expectation.
Part of the reason TypeScript is enjoyable to use is that it isn't chock full of mostly-broken functionality. The absence of those features isn't particularly palpable, but it matters when a language tries to do things it can't and fails. And honestly the features I regret the most are the ones we implemented due to popular demand despite knowing they wouldn't work out well in most cases.

you know, I understand that you want to do it perfectly. I want to do the same thing.

I'm trying to write a project right now. You know why I'm trying? Because I've been racking my brains for a month now because I have to use a separate library called Effect for error typing so that I could just have a display of errors and process them. And it's even funnier when you have to cache it. And I can't, because Effect is a non-serializable value. I would have to encode it on the server and decode it ON THIS server just to be able to cache it.

Just so I can have error prompts. What do you think?

What is the feature you are proposing to solve the problem?

These sort of benefits would be useful to highlight rather than just "implement some service using effect" (TODO App in Effect as example) for getting dev buy in

What alternatives have you considered?

No response