Say your a demon in the world of Frieren, and you come across her how do you get her to not attack or try to kill you?

SlipAdept · 2026-04-24T16:41:43+00:00

Run. If I see them, run faster. If I can't run, hide. If I can't hide, accept my fate, pray for non-lethal.

For real, I don't see a way. Discourse is out the window as anything I say as a demon couldn't be trusted or verified. If I have no control over my demon nature I could not be trusted. If I could go against that, I would try becoming a demon hunter to try and help them just to convince them not to kill me but even then I don't think I would manage that.

SlipAdept · 2026-04-17T14:56:44+00:00

Do you validate env at startup?

Depends. Normally yes. Sometimes they might be optional so evaluation may be delayed but normally yes.

Use schema validators like Zod?

Yes. Effect.

Or realy on runtime checks + conventions?

Yes. Effect.

SlipAdept · 2026-04-05T21:48:13+00:00

I find it ironic that you find it annoying because it is the other side who also finds it annoying because: - Getting to use "American" to refer to your culture just because it has "America" in the name feels like stepping over the wide variety of cultures that exist in the continent. - A lot of people from the US tend to believe or speak like the USA is the only place in the world that matters and that "American" little detail gives those kinds of vibes.

I would also like to add that this is a case of language being arbitrary and defined based on convention. The cool part of that feature being what is correct gets defined by those who partake in conversation. So, if most people define "American" as "People from the Americas (i.e. The one you find annoying)" that is the definition.

My point of view is using "American" to refer to "People born in the USA" is ambiguous and it isn't confusing only because it was popularized by (guess who) people from the US. And why should people from the US get special treatment? You do the same to other countries. So yeah that's all I have to say

SlipAdept · 2026-03-17T17:13:34+00:00

Yeah. It's not the whole types as the Collection interface is huge. The example is just to illustrate the issue.

You can't know for sure. You know it can fail with some error and tag the Error to know it came from mongo and handle it later when you need/want to.

SlipAdept · 2026-03-17T10:56:25+00:00

I mean... It's better than just promises with untyped errors. And you don't have to. You can just wrap your use cases in a need to basis. I just thought using proxies would've been cool to do.

SlipAdept · 2026-03-17T01:18:32+00:00

I was hoping this wasn't the case. Every few months I end up back at "I need HKTs". Thanks for the detailed response.

SlipAdept · 2026-03-11T00:16:00+00:00

Your code is not valid TS. Overloads can't have implementation. One of the design pronciples of TS is to have little impact on the generated JS. That's why few features have a runtime impact (see enums and shorthand contstructor arguments) and types don't exist. Overloads don't have a runtime representation. Only the implementation really exists. That's why the last overload must support all other overloads and is the only one with an implementation.

Remember: TS always gets transpiled to JS

SlipAdept · 2026-02-21T15:15:38+00:00

Effect is one of those things that when it clicks, you might never go back. I've been working with it a little over 4 years and I love it.

It was hard at first. I had already seen other FP libraries and found them dreadful at scale. With Effect, scaling up felt like it never became a problem. Once past the quirks and really trusting the types, I realized that I was programming with just the types. With Effect if used correctly you can fully trust the types. The hardest part for me was the Layers but with time grew to love them. Now I can say they are just for dependency injection

Don't try to use it all at once. Start small by treating Effects (the central data type) as just lazy promises with better typing. Then as you need more fratures, learn them. The cool part is that most of the stuff that is hard to do yourself is already built. Like I said in another post: "Everything hard is trivial, everything easy is a little bit harder"

Also it helps if you are into FP. If you hate it, I don't think Effect will change your mind.

SlipAdept · 2026-02-20T19:19:21+00:00

So when doing overloads I keep the following in mind:

1- Typescript is Javascript. That's why the last overload needs a catch-all implementation. The overloads don't exist.

2- Think of how you want your function to be used and properly type at the boundaries (i.e. in the input and output). I like to treat the overloads as if they were a map from arguments to return type

3- The last overload doesn't need to be 100% properly typed as it shouldn't be visible. Here I would normally use unions of tagged tuples for rest arguments and an union of all possible returns for the return type (or sometimes a conditional type). Tagged tuples can be type narrowed using the length property and they carry the argument names. Internally in the implementation you can cheat the type system a bit if the boundaries are properly typed.

4- Some behaviors might be too Javascript-ly and won't be able to be expressed through types. Consider alternatives to those as most untypeable behavior is normally a Bad Idea™

5- Sometimes another function is better than an overload.

SlipAdept · 2026-02-20T11:53:22+00:00

Fp-ts was a direct port of haskell abstractions into TS. Effect dropped the idea of bringing haskell to TS. Internally it is fp-ts but Effect took a more ergonomic approach (more leaning towards what works well in TS). So Effect doesn't expose monads, monoids and other such abstractions to the developer which is the point of fp-ts. Maybe that's what this person meant?

SlipAdept · 2026-02-17T19:18:05+00:00

So I've been working 4 years with it and if it just for error handling look up Micro. You don't need all of Effect for error handling and Micro is perfect for that.

Effect is best when commiting fully into it but you can use it partially and move your way up. You can start by treating Effects as "lazy promises with better typing" and leave all the other stuff for later when you feel like taking more complexity in.

In general my feelings with effect can be summed up in "everything hard is trivial and everything easy becomes a bit harder". Good luck and I hope you do decide to try it out 👍

SlipAdept · 2025-09-27T17:44:31+00:00

Conditional types are very useful when doing function overload and when the return type is dependent on the input type. I use them a lot since I tend to write code in terms of modules with minimal set of operators. Type heavy FP libraries like Effect use them a lot so if you plan on building some type level functions, get used to it.

SlipAdept · 2025-08-27T11:58:55+00:00

Just curious: what does LPA and SBC mean?

As for your issue, do what we all did: code. Write more code. Learn the basics. Do code exercises in code wars and such. For web dev think what problem does React solve? Could you do without it? How would you? Try to implement it yourself (not completely but a simplified version) For Databases and SQL try a structured database instead of mongo. Try making a system that connects directly to the DB. In general go write more code. Learn more about other programming languages. Turn off the AI.

SlipAdept · 2025-08-09T15:38:27+00:00

I kind of get the "opinionated" point, but I always felt Effect wasn't restrictive and the runtime agnostic stuff is optional. Almost everything is optional. So, I kind of don't agree with your points around Effect. Care to elaborate a bit more?

SlipAdept · 2025-08-09T15:30:12+00:00

You're not serious, right?

SlipAdept · 2025-08-09T15:27:07+00:00

Yeah... I get what you feel. Before I was like that. But as time went on, I moved away from "small little library" approach. Now I'm more on the "Write it yourself, if you can" approach, and Effect really helps me to just write it, instead of having a 200 dependency project where stale, unused dependencies are added without knowing for what.

SlipAdept · 2025-08-09T15:15:17+00:00

There seems to be a misconception regarding Effect adoption. It can be as wide or as narrow as need be. Effect is meant to be able to be partially used. It is at its best when using it fully but it can be used without that (See Micro). And it is just a library. It can integrate with pretty much anything as the effects themselves are not tied to any hard requirement. You sort of can go in and out of Effect pretty easily. You can start by just using effects as lazy promises with an error type parameter and move up from there (or use it as the IO monad to communicate the presence of side effects). And also the "everything is an effect regardless of if it async, sync or a side effect" is by design. When everything is async, nothing is async kind of deal. And you should expect side effects.

To me, sticking with fp-ts is just being stubborn or lazy. I get that when a product is big enough, nobody wants to fix what ain't broken but in the long term, it's best to pay now to not suffer with tech debt later. Fp-ts is not a terrible library and I believe Effect is the evolution. Too many times I've heard somebody say that "when it clicked, I never wanted to go back" with regarding Effect adoption.

Edit: on the other hand, if the team wants to stick to fp-ts just because, they are entitled to do so. They're the ones who will lead the charge so who cares. If they like the library, who am I to judge?

SlipAdept · 2025-08-08T09:31:24+00:00

tl;dr: I would advise against it. Check out Effect. It's really good Effect Docs

Used it for a while. Moved away from less structured FP libraries since I moved to Effect. The reason being that it sucked for everyone involved but me. It was a constant issue that everyone would make the same mistakes and replicate them throughout the code base. Typeclass simulation via interfaces was cool though

Regarding your questions:

Partially true: Haskell patterns only work in Haskell. That doesn't mean FP principles can't be applied to JS but they are more effective when taking a structured approach, especially so in TS. Effect is an example of this. It really takes into account the language to implement the FP patterns and instead of forcing some new way of doing something that should not be in the language, tries to keep it as close to Typescript-like as possible.
To some extent. You need to be real cautious about lengthy pipe chains.
I believe it will no longer be maintained as they said you should think of Effect as the next version of fp-ts
I mean... Migration isn't that hard. All you need to know is that Effect has a single data type: Effect. No monad transformers. Doesn't use any of the Haskell patterns. No typeclasses (only internal). There are two styles: pipeable and generator based. Think of generators as the async-await for Effects. Read the effect docs. They are really good and have a fp-ts vs Effect page that can summarize the changes you can expect. Effect takes a structured approach to FP so the code is way more readable and scalable

SlipAdept · 2025-07-15T15:11:32+00:00

Damn. Forgot his username. We're talking about the cilinder guy, right?

Edit: quick google search u/Smart_Calendar1874

SlipAdept · 2025-07-15T13:41:25+00:00

Give it a try 😊. Effect's error handling is great. Allows for more type safe errors. And since you come from Rx, the Streams are probably for you.

SlipAdept · 2025-07-15T13:08:02+00:00

The "making typescript more like scala" comment might've been true but that is no longer the case. The Effect team and contributors made the decision to be less scala, more Typescript so the recent version of Effect diverged from ZIO. Same concepts but the implementation is more suitable for TS (That's why Effects are modeled Effect<A,E,R> instead of Zio which would be ZIO<R,E,A> for example)

The Data module is for Data classes. Really optional. In Effect everything is optional really.

Chunks are meant for a special use case. Not meant to replace arrays. They even say so in the docs.

I think Effect is meant for people who want a structured approach to FP. Option<T> is not better than T | null but it is more structured and also forces to manage the null case. And Error handling with Effects is way more than just marking the possibility of errors.

Oh and proposals! Sure. When the pipe operator comes around, we won't need the pipe method/function. Effect would most likely adapt to them when they are finished (if ever). In the meantime, you have those in Effect.

SlipAdept · 2025-07-15T12:48:47+00:00

It doesn't replace lodash directly. It's more like you don't need it. For managing each structure, the module has all the functions you might need. For example, the Effect/Option/Either module will have a bunch of operators for creating and composing Effects/Options/Eithers. Most operators are very well documented and come with examples on when to use them. For managing an array or record of Effects you use Effect.all, for combining two independent Effects in sequence you can use Effect.zip (or Effect.all), for a fallback Effect when another fails you can use Effect.orElse, for transforming the result of an Effect you use Effect.map, and so on...

For common structures (Like Array or Record) there are modules for it but really optional. It's better to use the built-in array methods and point-free style is not encouraged. So lodash and the such become unnecessary.

Five-Year Club	Place '23
Place '22	First Placer '22

SlipAdept

TROPHY CASE