My experience with fp-ts and io-ts was that we quickly got to a point where the team was divided into a small group of people usually with postgraduate CS degrees who really understood it, and then everyone else who saw it as black magic and were afraid to touch it.

Nowadays I’d rather rely on libraries that don’t require a phd to use them properly.

> Me and my team reverted to more stupid code and we are happier.

This is 100% how to write more reliable software. We are in the process of reducing our TS dependencies to effectively just express and node-postgres and everything is becoming infinitely easier to manage.

I agree in some contexts. Kind of like Rust, I see a place for more durable code that's harder to reason about in some cases.

I wouldn't use Effect for a lot of things. For some things, I'm very glad to have it. One thing Effect has going for it that Ramda didn't is that it's much less abstract and it's quite a bit more opinionated about some more complex concepts like error handling, concurrency, or scheduling.

Kind of like state machines. You shouldn't use them for everything. For some things, it's a bad idea not to (in my opinion).

Then of course subjectivity is a factor here. Some people will never like conventions like Effect, and that's fine too. Just write what feels right.

Don't judge Effect based on Rambda they have completely different objectives, Rambda focused a lot on abstractions similar to fp-ts, Effect focuses almost exclusively on concrete implementations

I think going all-in on Effect in its current state is not something I'd do. However there's a subset of its functionality that I'm currently replicating with a bunch of different libraries: ts-pattern, zod, some lightweight result / option wrapper like ts-belt, etc. Pretty much trying to pretend I'm writing ML / OCaml. Having those all in one package is quite convenient. Add in TypeScript's the much needed story around retry / observability / error handling—I see why people lean into it.

Having experience with ZIO / FP in Scala, I'm a bit biased in seeing the value of Effect systems as a whole, but taking on the burden of explaining that mental model to team members and future maintainers is a big cost for most teams.

Yes it's quite sad.

I liked the idea of Ramda until I saw code bases that where using it for everything.

I'm doing JS for over a decade now and I couldn't understand a thing.

Effect is not only much easier to get productive on than Ramda, but it provides an entire ecosystem.

Our team is full effect from two years and juniors can pick it and start working on it with ease.

that is certainly a possibility

Hands down, the best (free, no email) resource to learn Effect is here https://www.typeonce.dev/course/effect-beginners-complete-ge..., as opposed to the docs. The link referenced gives a holistic view of how to incorporate it.

Yeah, looking at that example feels like jumping straight into the deep end of the pool. I think it helps going through a tutorial that breaks down the why of each piece. I really liked this tutorial on it: https://www.typeonce.dev/course/effect-beginners-complete-ge...

Some core things from Effect though that you can see in that Express example:

* Break things down into Services. Effect handles dependency injection, that's typed, for services so you can easily test them and have different versions running for testing, production, etc. * Fibers for threaded execution * Managing resources to make sure they're properly closed with scope

I think a lot of these things though often aren't truly appreciated until you've had something go wrong before or you've had to build a system to manage them yourself. *

I agree, some of there examples are a little overly complicated by their quest to be hyper composable. In fact they should probably remove that example. I am currently using it with Remix, and using their @effect/platform package to produce a simple web handler (request: Request) => Response (thank remix for heavily promoting the adoption of web standards).

I fully agree parts of the ecosystem are complex, and likely not fully ready for broad adoption. But I do think things will simplify with time, patterns will emerge, and it will be seen as react-for-the-backend, the de facto first choice. effect + schema + platform + cluster will be an extremely compelling stack.

An infinite loop of crashing isn't very useful though. "Let it crash" doesn't lead to a whole system being robust all by itself since you can also just say "let it throw exceptions" in just about any language. Erlang's whole-system robustness emerges when far more than just how you handle exceptions and crashes is implemented to support things that crash. It expects parallel processes and even redundant computing infrastructure to exist to handle those things that are crashing, and hopefully those redundancies behave in a way that doesn't also crash in the same way. Erlang only achieves its robustness because nobody really chooses Erlang without also knowingly buying into the entire setup that it requires to succeed. And if they don't then it won't actually achieve that robustness and succeed in that way.

The phone systems that Erlang's design emerged from naturally had these parallelism and distributed system properties that they could leverage and build on. Running Erlang on a single core SBC like to display virtual signage and limiting it to a single thread and not letting it have any redundancy in any way and then taking the approach of "let it crash" is not going to create a famously robust Erlang setup either, it's just going to create an Erlang-powered signage system that crashes and halts the same as any other runtime would. Erlang/OTP is a physical systems building and software design approach that you can't just put anywhere or bolt onto any arbitrary thing. You're not going to build an OTP-like Single Page Application because if you reliably crash the browser tab's process every time you start up, it's just going to keep crashing no matter how many times you refresh the page.

If your i.e. server process kills itself when validating data, that's not the Problem of ZOD. The violation failing is an expected case, that is the use case for such a library.

Because you can write `this[anything()]()` and it's impossible to analyze it. IDE false negative will not do anything bad, but treeshaker false negative will introduce a bug, so they have to be conservative.

Does that work for all class members? I think I've only ever seen that on private members, though I don't know whether that's because it's so much easier to check whether a private member is used or because an unused public member isn't an issue for eg a library.

This feels like an issue that reduces down to the Halting Problem, though. Halting is a function that could be made a member of a class, so if you could tell whether that method is used or not then you could tell whether the program will halt or not. I think it's one of those things that feels like it should be fairly easy, and it's really really not.

It requires flow analysis, which is really hard to get right. I don't think there's a tree-shaking library that uses the TypeScript compiler API for static analysis purposes. Maybe because it would be slow?

edit: The creator of Terser is working on flow analysis for his new minifier, according to him[1].

[1]: https://github.com/terser/terser/issues/1410#issuecomment-17...

Really? For example under "Main concepts" on the "Schemas" site[0], I see stuff like this:

- I support the creation of schemas for any primitive data type.

- Among complex values I support objects, records, arrays, tuples as well as various other classes.

- For objects I provide various methods like pick, omit, partial and required.

- Beyond primitive and complex values, I also provide schema functions for more special cases.

Same for "Mental model", "Pipeline", "Parse data", "Infer types", "Methods" and "Issues" - I'll assume the other sections also follow this style. That's all not showing up for you?

While the LLM suggestion is nice, it's not something I'm comfortable with unless hallucinations are incredibly rare. Why would I use a library whose documentation I have to pass through an unreliable preprocessor to follow a normal style?

[0]: https://valibot.dev/guides/schemas/

I'm not exactly sure myself, but every time I open one of the pages, I mentally stumble over the formulations. I think there are two components:

1. The biggest part is that I've simply never seen documentation written in this style, any mentions of "I" or "we" are usually explaining the choices made by the author(s). When skimming documentation I pay more attention to those parts. Here those parts don't have a comparable meaning.

2. The smaller part is that the writing style reminds me of the way brands use mascots with first-person writing to advertise to children. There's not really any other association I have with this way of writing, and it makes me feel like the author either isn't taking the project seriously, or me.

I'm not trying to argue that the documentation should be understood this way, or that it should be changed - but I've stumbled over this multiple times, and can't imagine that it's just me.

The complexity of the types you see in traditional nodejs web servers is there because all of them tried to work as a god-function multitool. The type of a router handler literally incorporates the types of all constituents of a generic request-reponse process and additional server-specific data, all packed into (req, res). This only happens in ultra-generic code that is basically web servers only.

Iow, don't go to the definition of a web request handler. Go here: https://fastify.dev/docs/latest/Reference/TypeScript/

Other languages (libraries really) separate these parts, e.g. Spring Boot seems to hide routing away into a method decorator which infers the body type from a target signature and the server is somehow implied(? through a controller?..). Anyway, it's all there, just not in one place. It has nothing to do with Typescript, it's a js library legacy issue.

I don't write Kotlin, but what that does (assuming I'm guessing at it correctly) requires far more awkward code in most other languages. That looks like it will allow you to extend the types of objects deep inside the library so that you could e.g. create your own Request object without having to type cast inside the HTTP handlers or wrap the entire library.

That shifts the complexity of doing that out of the runtime and into the Typescript preprocessor where it's not going to mess with your production instances.

I also don't think it's all that bad; it's a lot of generic types, but it doesn't appear to be doing anything particularly complicated.

I do think they get awful, though. This is something I've been hacking on that I'm probably going to rewrite https://pastebin.com/VszX3MyE It's a wrapper around Electron's IPC and derives a type for the client from the type for the server (has to have the same methods and does some type finagling to strip out the server-specific types). It also dynamically generates a client based on the server prototype. The whole thing rapidly fell into the "neat but too complicated to be practical" hole.

> You can, in theory use very strong lint rules (disallow `as` operator in favour of Zod, disallow postfix ! operator), but no actual codebase that I've worked on has these checks. Even the ones with the strictest checks enabled have gaps.

That's surprising. I've worked on a few codebases with reasonably mature TS usage and they've all disallowed as/!/any without an explicit comment to disable the rule and explain why the use is required there.

My company’s codebase disallows type coercion. You can disable the lint rule if there’s a legit reason to but then we ask to explain why.

It's apples and oranges. The type system in Kotlin is integrated into the language. TypeScript is a preprocessor for JavaScript that isn't allowed to change the JavaScript language, or have any runtime.

The "as Foo" construct is for you to tell TS that you know better than it, or that you deliberately want to bypass the type system. You can have a runtime check, but you have to write the code yourself (a type predicate), because TS doesn't write or change any JavaScript*, it just type-checks it.

I've certainly worked in new codebases where a relatively simple subset of TS types were used. Even then there were a few places the crazy type system was helpful to have. For example, we enforced that the names of the properties in the global configuration object weren't allowed to have consecutive uppercase letters!

(* with minor exceptions like transpiling for new JS features)

Which begs the question of why they don't rearrange that part to the first in the error message. Like you said, 9/10 times I scroll down without thinking which is silly.

Haxe is amazing, has macros etc. A force multiplier if you are a solo developer for sure. But damn, you feel kinda alone if you are using it. Not everything is an npm install away which negates your velocity gains from using a saner language.

Ironically Haxe was inspired by ActionScript 3 which was the basis for the EcmaScript 4 proposal which was abandoned back in 2008 or so.

It's Haxe still been actively developed? I loved it back in the day. The blog hasn't had an update in years.

Nope. For thins you pick Haxe (https://haxe.org/), it has an awesome macro system, and a state of the art compiler thats really, really fast.

Sorry, might have mixed up Yup and Joi. Anyways, I prefer Zod to both of them.

I'm not 100% sure, they most likely scraped the author emails of all NPM packages that (transitively) depend on ajv. Here's the GitHub issue from back then: https://github.com/ajv-validator/ajv/issues/1202

You can’t reflect types out of Ajv. TS types are compile-time, Ajv consumes JSON schemas at runtime.

From my understanding trpc is very similar, however, the rpc mechanism is not a standard. ts-rest produces openapi schemas and speaks REST over http, as well as a typed client.

That being said, I am actually slowly migrating off ts-rest and adopting @effect/schema and @effect/platform/HttpApi, I foresee this being the direction the typescript ecosystem heads in over the next few years. However, the APIs are not stable yet and it has a bit of a learning curve, so would not adopt lightly

I really wanted to adopt tRPC but the deal breaker was it being opinionated on status codes without allowing configurability. Because I needed to meet an existing API spec, that meant ts-rest was a better option. I think there's an aditional option with a native spec generator in frameworks like Hono, and maybe Elysia.

> Other statically-typed languages do have to deal with the problem of parsing external objects.

Well that's just blatantly not true. Which languages are you thinking of? I'm sure I'm misunderstanding what you said.

I can't think of a single server side language that doesn't have to parse external untyped objects. That's where these serialization libraries come into play.

For example, in Kotlin, you declare a data class and mark it as @Serializable and it generateds `toJSON/fromJSON` for you. IMO it's a much better experience than Zod.