I feel like Effect is today's Ramda. So cool but it's going to be regretted by you and people coming after you in few years. Me and my team reverted to more stupid code and we are happier.

How did you find learning Effect? The sales pitch sounds great, but when I went through the docs it seemed pretty confusing to me. I’m sure there are reasons for the everything but I couldn’t grok it. In particular, I’m thinking of the Express integration example.[0] I look at that and think, I need all that just to create a server and a route? What’s the benefit there? I’m hesitant to buy into the ecosystem after looking at that. I want to like it, though.

[0] https://effect.website/docs/integrations/express

I agree about the turning point. Things have improved dramatically. And I know it probably doesn't feel the same for tons of people, but I love to see generators being used in every day code.

The learning curve just about turned me away from it at the start, but I'm glad I stuck with it.

I think learning Effect would actually teach a lot of people some very useful concepts and patterns for programming in general. It's very well thought out.

I've tried compile-to-JS languages before but their big weaknesses are:

1. Debugging can become quite a pain. Nobody likes debugging generated code.

2. You don't get to use libraries and tools from the enormous JavaScript ecosystem.

3. Eventually you'll find some web feature that they haven't wrapped in your language and then you're in for FFI pain.

In the end I found Typescript was good enough that it wasn't worth dealing with those issues.

This is so cool! I’ll have to try it out soon. Thanks!

Schema is a much powerful tool than Zod. Zod is merely a parser, while Schema has a decoder/encoder architecture.

Which is why our principle with Effect is NOT to port Haskell. For example we don't use Typeclasses which are big in haskell, we lean heavily on variance which is not in Haskell. It's an ecosystem though to write production-grade TypeScript, not Haskell in TypeScript

> It looks very similar in its ideas to fp-ts (in the “let’s bring monads, algebraic types etc to typescript” sense).

It's the next version of fp-ts, developed by the same people, AFAIK

Is there a reason why tree shaking algorithms don't prune unused class members? My IDE can tell me when a method is unused, it seems odd that the tree shaker can't.

Not only that, runtime schema validation was also way faster in my last project for larger arrays of complex objects with lots of union types. Went from 400ms to 24ms all else being equal. Since our validation was running on every request for certain reasons this made a huge difference in perceived performance for our users and less load on our servers.

Agreed. I recently moved a production app from Zod to Valibot for exactly this reason. I still slightly prefer Zod’s syntax but the performance issues were absolutely killing us.

I ran into exactly same pain point which was enough to nullify the benefits of using zod at all.

It does: https://valibot.dev/guides/optionals/#use-in-objects

  import * as v from 'valibot';
  const OptionalKeySchema = v.object({ key: v.optional(v.string()) });
  type t1 = v.InferInput<typeof OptionalKeySchema>; // { key?: string }

  const UndefinedKeySchema = v.object({ key: v.undefinedable(v.string()) });
  type t2 = v.InferInput<typeof UndefinedKeySchema>; // { key: undefined }

TypeBox[1] differentiates between optional and undefined.

[1]: https://github.com/sinclairzx81/typebox

I only see second-person "you" and not first-person "I" in the linked documentation. Am I missing what you intended to point out?

In any case, this might actually be a good use for an LLM to post-process it into whatever style you want. I bet there's even a browser extension that could do it on-demand and in-place.

I don't think you are crazy at all. The concept of professionalism is about doing things a certain way to indicate to others that you are, of course, a professional. Writing technical documents in the 3rd person is a basic part of what I would consider professionalism in the broader engineering field.

In the software field you get a large portion of people that don't buy into the concept of professionalism. For various reasons - chiefly the hacker culture and the easy of contributing to the "field" means the gauntlet one runs to become a "professional" isn't inherently a given.

As a whole this is a good thing but it does mean if you operate as a "professional" maybe sometimes you have to realize that something doesn't exactly gel with your ethos (case in point). It doesn't mean it is bad; just maybe not for you and yours.

> Or am I just crazy and this isn't an issue for anyone else?

Not an issue for me, to be honest. Why does it bother you at all?

It's a little too cute, but I don't see it as a deciding factor on which library to use.

I think a more important issue is that Valibot hasn't reached 1.0 yet. But it looks like it's very close.

Yes, that's just cringe.

On the front page there is a prominent section addressing the differences from Zod, which appear to be “much better performance”

Right. I'm aware. My point was that even though the type system is powerful, somehow, I'm able to represent everything I need to in Kotlin's type system just fine and it feels a lot more type safe because it will throw a type error at runtime in the right place if I do a bad cast.

Typescript `as Foo` will not do anything at runtime, and it will just keep on going, then throw a type error somewhere else later (possibly across an async boundary).

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.

Not to mention, there's intentional unsoundness in the type system, so even if you wanted, you couldn't really create a save subset of TS.

Then there's the issue of reading the library types of some generic heavy code. When I "go to definition" in my fastify codebase, I see stuff like this

  RouteHandlerMethod<RawServer, RawRequest, RawReply, RouteGeneric, ContextConfig, SchemaCompiler, TypeProvider, Logger>

Which expands to this

  export type RouteHandlerMethod<
  RawServer extends RawServerBase = RawServerDefault,
  RawRequest extends RawRequestDefaultExpression<RawServer> = RawRequestDefaultExpression<RawServer>,
  RawReply extends RawReplyDefaultExpression<RawServer> = RawReplyDefaultExpression<RawServer>,
  RouteGeneric extends RouteGenericInterface = RouteGenericInterface,
  ContextConfig = ContextConfigDefault,
  SchemaCompiler extends FastifySchema = FastifySchema,
  TypeProvider extends FastifyTypeProvider = FastifyTypeProviderDefault,
  Logger extends FastifyBaseLogger = FastifyBaseLogger

> = ( this: FastifyInstance<RawServer, RawRequest, RawReply, Logger, TypeProvider>, request: FastifyRequest<RouteGeneric, RawServer, RawRequest, SchemaCompiler, TypeProvider, ContextConfig, Logger>, reply: FastifyReply<RouteGeneric, RawServer, RawRequest, RawReply, ContextConfig, SchemaCompiler, TypeProvider> // This return type used to be a generic type argument. Due to TypeScript's inference of return types, this rendered returns unchecked. ) => ResolveFastifyReplyReturnType<TypeProvider, SchemaCompiler, RouteGeneric>

Other languages somehow don't need types this complicated and they're still safer at runtime :shrug:

Hint, 9 times out of 10 you only need to read the last part of the error.

Also, there are many ways to make types opaque (not show their entire verbose structure).

This. Haxe is a more sane TS alternative in 2024.

Yes, I did mention that the UX of the type errors could be improved and probably should, but once you start getting into conditional types, and nested types (which may not be fully expanded when you see the error), it gets hairy.

Not really - https://github.com/Microsoft/TypeScript/issues/16607.

ts-morph provides an easy way to use the TypeScript Compiler API to view and edit the AST before compile. Once you get your head around the API, which has good examples but isn't thoroughly documented on the web.

https://github.com/dsherret/ts-morph

Erlang/elixir is built around a "let it crash" model. The idea is that the system as a whole is robust, not individual processes.

But Yup also allows to infer types from schemas...