Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Parse, Don't Validate – In a Language That Doesn't Want You To

cekrem.github.io

Post reply on HN
Print view View original

101–107 of 107 posts

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#101

Post by WorldMaker »

jerf wrote: post #45
Altern4tiveAcc wrote: post #17

Zod is by far the most ergonomic way to express those ideas in TypeScript these days. I miss it when writing code in other languages. The friction with the rest of the ecosystem is real, though. Most code out there expects you to handle errors with exceptions. I get the impression that polymorphic return types could get in the way of JSC/V8/SpiderMonkey's JIT, but I haven't measured it and I'm not sure of the actual…

I haven't done a lot of Typescript, but I've done at least a couple of month's worth now, and every time I have to type "as" my inner Haskell programmer screams. If I could add one feature to Typescript it would be something like "as" that actually validates the result against the type system and can fail. Unfortunately, that's way, way easier said than done. It's the bad type of keyword that has unbounded runtime co…

In addition to exploring `satisfies` as a better `as` (compile checks, that don't assert), you may also be looking for `is` aka Type Guards (runtime checks that assert types).

If you have a validator function `function isSomeSpecificType(obj: unknown): boolean` you make it a Type Guard by changing the return type to be the type assertion you need: `function isSomeSpecificType(obj: unknown): obj is SomeSpecificType`. Typescript's narrowing is pretty good about using Type Guards to good advantage.

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#102

Post by Altern4tiveAcc »

IshKebab wrote: post #56
Altern4tiveAcc wrote: post #17

Zod is by far the most ergonomic way to express those ideas in TypeScript these days. I miss it when writing code in other languages. The friction with the rest of the ecosystem is real, though. Most code out there expects you to handle errors with exceptions. I get the impression that polymorphic return types could get in the way of JSC/V8/SpiderMonkey's JIT, but I haven't measured it and I'm not sure of the actual…

> I miss it when writing code in other languages. You can use Pydantic in Python and serde_derive in Rust. I assume most languages have a thing like that.

> I assume most languages have a thing like that.

You're not wrong, I assume. My problem is specifically with the remaining languages without anything like that. :')

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#103

Post by epolanski »

cptmurphy wrote: post #97
steve_adams_86 wrote: post #80

Earlier quoted context omitted.

I can’t think of a single functional language that offers what effect gives you, though. A fully typed and declarative error channel, managed dependency layer with compile time safety, excellent resource management, the best parsing/validating/serializing library I’ve used in TypeScript, concurrency, streams, cache, otel primitives baked in… In all fairness it does require buy-in and gradual adoption isn’t perfectly…

Scala. Zio/Cats/Kyo

Relevant talk by John De Goes: Why Effect is more important than ZIO:

https://www.youtube.com/watch?v=Ei6VTwhI8QQ

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#104

Post by KPGv2 »

> if (!user.email.includes("@")) return false

I know this was't meant to be rock solid code, but I still thought it was a great example of why you shouldn't bother validating an email ever by looking at its construction, for any reason. Because "@" is not required for an email address! The very first check is already wrong :)

The proper way to validate email is to send an email with a link to validate it.

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#105

Post by whilenot-dev »

terminatornet3 wrote: post #95
whilenot-dev wrote: post #84

Earlier quoted context omitted.

> Their implementation of an exhaustive check will give you a compiler error if you miss a variant in your switch statement. I much prefer a compiler error over a run time error. What are you talking about? You'd still get the compile error just the same. Falling back on returning the input argument doesn't even make sense in the typescript docs: type Shape = Circle | Square; function getArea(shape: Shape) { switch (…

you don't need a runtime error if you have a compiler error. best of luck with your PR

> you don't need a runtime error if you have a compiler error

LMAO no, we're doing TypeScript here, not Haskell.

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#106

Post by ivolimmen »

jve wrote: post #18
ivolimmen wrote: post #11

One of the pillars of Domain Driven Design. I love working on a pure DDD application but I do not often convince my team (I am a constant) that this is the best way ...

> I am a constant What did you mean by that? You don't accept mutability or any inputs on your state of mind?

It's a typo: I meant consultant

Re: Parse, Don't Validate – In a Language That Doesn't Want You To

#107

Post by dolia »

jerf wrote: post #81
dolia wrote: post #66

Earlier quoted context omitted.

"every time I have to type "as" my inner Haskell programmer screams." - most of the times you don't have to. You choose to. "If I could add one feature to Typescript it would be something like "as" that actually validates the result against the type system and can fail." - I don't think it's fair to expect that since most of the statically typed languages will not guarantee things in runtime unless you specifically r…

"I don't think it's fair to expect that since most of the statically typed languages will not guarantee things in runtime unless you specifically run a validation code in runtime." If I have a value of type X in a static language, then I know that it absolutely conforms to the layout of type X. It isn't even that we have to provide a "validation function", it is that it is quite literally physically impossible for my…

Ok, I checked what Go does. It indeed can generate runtime validators from types. Neat, TIL. I'd argue it's not by default a capability of statically typed languages, rather something that a language creator can choose to add via reflections or some other mechanisms. So in my mind it's not really static vs dynamic systems.

In Typescript you would need to use additional libraries like this: https://typia.io/

Post reply on HN