S10 E4 | Validation Via ArkType | David Blass - The Angular Plus Show

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:08):
Welcome to the Angular plus Show. We're app developers of
all kinds share their insights and experiences. Let's get started.

Speaker 2 (00:21):
Well, Hello everyone, and welcome to the Angular Plus Show.

Speaker 3 (00:24):
My name is Brooke Avery, and on today's show we
have j Bell Hello Jay Stoke.

Speaker 4 (00:32):
To talk about typescript.

Speaker 3 (00:33):
Love typescript definitely, it's going to be great, and also
we have Brian Love.

Speaker 4 (00:41):
Good to be here. I guess I like typescript. I mean,
it's been like, it's been a great thing. I always
it's funny. I think back to you know, there's a
lot of people that were like, I don't know if
we need this thing, and this seems ridiculous. And I
guess there's still some paters out there, are people that
maybe don't like it. But it seems like these days,
if you're writing a JavaScript, you're writing typeescripts. But so

(01:07):
I'm excited to hang out with David and learn from him.

Speaker 2 (01:09):
If you're not, I'd be interested to talk to you.

Speaker 4 (01:14):
I think there's still a few folks out there, and
I think that I think, on one hand, maybe they're
really happy with their decision because typescript doesn't get in
their way and they don't have to deal with maybe
build errors, or they don't have to deal with some
complexities around things, or maybe even they're trying to like
write a really interesting library or package with a bunch

(01:36):
of overloaded methods and they're not sure how to do
it with Typescript, or they don't know why it doesn't work,
or they're getting these really funky generic errors and they're
just like, oh, this thing sucks, and like to one intent,
I think like they might be right in that maybe
some of the errors are really confusing or it's hard
to write your head around things. But I think in general,
I think that most people have said that, hey, this
is a good thing, and if it balks at me

(01:58):
too loud, I'll just ignore it.

Speaker 2 (02:00):
Awesome.

Speaker 3 (02:00):
Okay, Well, after all of this introduction about typescript, we're
actually feeling really lucky today because we have the opportunity
to be sitting down with the creator of arc type
dot io. So everyone, this is David Blass, and well, yeah,
welcome to the show.

Speaker 2 (02:20):
David.

Speaker 5 (02:21):
Yeah, thanks so much, very excited to be here. Love
to talk about typescript, arc type, talk about trade offs
of typescript and JavaScript and all the naysayers and all that.
But yeah, I've been working on open source full time
for the last five or so years, most of it
on arc type and some of the early evolutions of
ARC type and the two point zero release, which was

(02:43):
a huge major stable release came out towards the beginning
of this year and have some really excited features. These
features I'm very excited for coming up in store that
maybe I'll give a little preview of at some point
if we have time for that as well. So just
very excited to be here talk about typescript and everything
really awesome.

Speaker 3 (03:01):
Yeah, we're really eager to hear more about it and,
like you said, kind of your vision, what it does,
what it's for, why an everyday developer would care all.

Speaker 2 (03:11):
Of those questions. But tell us a little bit more about.

Speaker 3 (03:14):
Your background as well, where you know, maybe how you
got into programming and your journey to where you are now.

Speaker 5 (03:21):
I actually didn't start coding until I was in college.
I took a couple of computer science classes, was at TOUGHS,
and I was always a pretty horrible student, and I
really like to like do my own stuff and do
my own kind of like learning, and I'd be really
obsessed with certain problems but then wouldn't do the homework

(03:42):
kind of person. So I ended up dropping out of
tough once I already had a job. I got a
job like in a summer internship, and then ended up
getting a full time job out of that.

Speaker 6 (03:50):
And then I was like, wow, I really hate school.
I should just leave.

Speaker 5 (03:52):
And I'm already have a salary and stuff, so why
would I subject myself to this? And so yeah, and
that turned out to be great for me because I
am very sort of like I guess self motivated in
the right situation. If I feel like I could work
on a cool project and have autonomy and try to
build something that other people find useful, versus like if
I'm having to do exercises, I suppose that that was

(04:13):
more difficult for me. So as soon as I started
to get into that, I became really obsessed with coding,
and I have mostly struggled.

Speaker 6 (04:21):
With work life balance since then.

Speaker 5 (04:25):
Most my most recent job in the industry was I
mostly was working on developer tooling, so as an estet
at Amazon, I was working on building building a test
framework for the Alexa devices so you could like easily
test voice interactions. And I also work with the visual
team like Echo show, so you could you know, test
like screen interactions and things like that and make assertions

(04:46):
about that. But Archetype and all the open source work
was kind of the next natural evolution of that because
I was thinking, like, well, Amazon's already pretty big company,
and if I can work on dev tools and share
it with all these people, and that's really exciting. You
know what, if I could work deaf tools that I
could share with everyone, that would really be the ultimate thing.
The only downside is you don't get paid for it,
so I don't know what I was thinking there. But

(05:08):
outside of that, like slight minor hiccup, it's been it's
been quite a journey. That's pretty much brings us up
to date with all my all my work on arc
type over the last few years.

Speaker 2 (05:18):
What do you need money for? Come on, I.

Speaker 5 (05:21):
Mean totally, I you know, we can just find ways
to scavenge. I've found mushrooms around locally. I'm sure we
can make it work.

Speaker 4 (05:29):
Just mushrooms all day.

Speaker 3 (05:31):
Yeah, teted motions, Oh my gosh. Okay, well, I definitely
we want to get into more about ARC Type. I
do have a burning question for all of you though,
because it's arc type, So everybody, it's spelled a ark type.

Speaker 2 (05:49):
Like an arc. And I do have to say, David,
looking at the website, I love the boat that goes
across the top.

Speaker 5 (05:56):
Ah.

Speaker 2 (05:57):
I just think that is the most fun little features.

Speaker 3 (05:59):
So yeah, everybody definitely check out arc type dot I O.

Speaker 2 (06:04):
But that said, and and you know, I don't think it.

Speaker 3 (06:08):
Matters like what your your background is are, like maybe
your beliefs. But like if we're just talking about Noah
and his arc in like in fun right, Uh, if
you had all been there, supposedly at this moment when
this boat is being filled with animals, right, what animal

(06:30):
would you have absolutely insisted make it onto that boat?

Speaker 5 (06:35):
Oh?

Speaker 6 (06:35):
Wow, I wish I was prepared for this.

Speaker 4 (06:39):
What animal would I have insisted to be on the boat? Yes,
I guess myself. I don't know. I'll skip. That's my
terrible answer, and I'll skip and jay your next no person,
what what.

Speaker 7 (06:57):
Do you get the most amount of time?

Speaker 5 (06:58):
I think, well, sorry, it's actually feel like I can
answer this if I want to fellow buster a little bit.
I'm a huge I'm a big animal over for sure,
and so I have lots of animals that I would
I would really want to preserve all them.

Speaker 6 (07:13):
But I think if I had.

Speaker 5 (07:14):
To choose one animal, it would probably be a vulture
of some sort. So I mean, if I was going
to be maybe like local to the area here I'm
in Boston, i'd probably say like a turkey vulture or
something like that. But more broadly, my favorite bird, and
maybe my favorite animal in general, is like the California condor.
I don't know if you've heard of those, but yeah, yeah,

(07:34):
so they're huge and they almost want extinct, but they're
kind of making a slow recovery hopefully. But so as
an animal over, I'm also vegan, so you might think
it's weird like vultures while they're eating dead animals all
the time, But like, if you think about it, they're
like the ultimate ethical animal, right because like they are
only like doing a service to animals that are already

(07:55):
dead and like cleaning them up for everyone else and
avoiding the spread of disease. So like they you know,
sort of a very important role in the ecosystem. And
I've always dreamed this is a little bit more a bit,
but I'm always like, you know, the ultimate way to go,
like after I die would be to just like be
eaten bug ultus, and that would be a very epic
way to like go out.

Speaker 4 (08:13):
Would be epic. Your family would be perhaps shocked.

Speaker 6 (08:17):
It's like an often it's like an opt in ceremony.
You know you don't have to.

Speaker 4 (08:21):
Yeah, that's funny. I don't know, Brooke. I guess I'm
gonna amend my answer. Like I guess I'm gonna spend
like forty days on a boat and it's like storming
outside the entire time. I think I would want some comfort,
So I guess a dog. I know that sounds lame,
but like dogs are really nice, or maybe like a
little gerbil that I could pet to like take my
anxiety out. Like I feel like i'd be pretty anxious

(08:42):
after like forty days with a boat full of animals,
and it'd be really smelly.

Speaker 6 (08:47):
So I don't know a lot of sense.

Speaker 7 (08:49):
Yeah, I feel like my girlfriend would break up with
me if I didn't say dogs. I'mingn go with dog.

Speaker 5 (08:54):
Funny thing about going with dog is that it seems impossible.
My dog is a Cavilier King Charles Spaniel. He's twelve
pounds and he's very adorable, but he's like optimized to
be adorable, but he's truly pathetic, Like there's no way he's.

Speaker 6 (09:08):
His species though it is a gray wolf.

Speaker 5 (09:10):
So like dogs, it's a species, aren't even a they're
not even like a distinct species from wolves, which if
you think about that, and like the variety of dogs
that exist, that they're, you know, genetically the same species
as wolves, like you may as well say wolf at
that point, which is mind blowing.

Speaker 6 (09:22):
But it's like all the same.

Speaker 5 (09:24):
I don't know.

Speaker 4 (09:25):
I think David is saying, we're going to be sitting
there for forty days petting a wolf. Yeah awesome, you didn't.

Speaker 3 (09:36):
Oh well, see now my favorite animal is the red panda,
has been since I was But like they look like
five different animals all at once. So I mean, it's
like you've got the raccoon fox, like, you know, all
these different dog cat so I feel like you get
great answer, multiple animals in one.

Speaker 2 (09:59):
But there you go.

Speaker 3 (10:00):
Okay, Well, now that we know the answer to this
very important question, let's talk about ARC type. So, David,
what is ARC type and what problem were you trying
to solve for typescript developers when you came up with
this idea.

Speaker 5 (10:17):
Arc type is meant to solve the problem of run
time validation for Typescript. So a lot of the time
you might have a type to represent a particular shape
of data that you need that you're validating an external
API payload or reading in data from a file or
checking a form submission. Any of these things might have
some shape and expected characteristics of the data that you

(10:41):
want to make sure are met before you.

Speaker 6 (10:43):
Start using it in your application.

Speaker 5 (10:44):
So our type solves that problem, allowing you to validate
the shape of your data and additional constraints that apply
to it before you're using it. And it does that
in a way that is one to one with Typescript.
So you might be familiar with the other libraries that
have this problem in the past, like JOI and yup,
and then most recently ZOD is kind of the like ecosystem,

(11:06):
the most dominant library for schema validation currently, and there
are others out there like ballabot, and there's a great
community actually have these, like Schema Runtime Validation library authors
and I like to work with them and we bounced ideas,
love each other and everything. Arc type is pretty unique
in that context because it's a very different approach where

(11:26):
it uses this type safe string syntax so that you
can write expressions that look just like typescript syntax. If
you're familiar with, you know, defining a type and Typescript
you'd write something like string or number, array or.

Speaker 6 (11:40):
Something like that.

Speaker 5 (11:41):
And in ARC type you can write identical syntax and
you'll get the type inferred out because we have this
type level string parser that can look at your string
and translate it into a type, and then you'll also
be able to use that same type at run time
to make sure that when you're you know, validating data, it.

Speaker 6 (11:59):
Map, which is what you expect.

Speaker 5 (12:01):
All of arc types API, or I won't say all
of it, because there are some things, if all, outside
this domain. But like the biggest question that inspired the
core API was what's the closest we can get to
typescript at run time to native typescript types at runtime.
And so all of the API is essentially just derived
from that question of like how close can we get

(12:22):
to the experience you get with native type with defining
a native type and bringing that to run time without
sacrificing anything, and perhaps in some cases even with gaining
some things and some new capabilities that will help out
with runtime validation.

Speaker 8 (12:37):
Sounds complicated, okay, so I'll try to do the like
ELI five would be, like, I need to check that
my data has the correct properties before I use it
at the boundaries of my application, and ARC type is
a way to do that that is unique.

Speaker 2 (12:56):
Okay.

Speaker 7 (12:57):
Are you one of those people that builds like ring
machines and games out of typescript rejects and stuff like that?
Like that is that who you are? Because this sure
sounds like it based on how you described how the
internals work with all the stringers.

Speaker 5 (13:11):
Yes, yeah, basically I would say that I have to
honestly answer yes. So like I did work with Dimitri,
who did the bulk of the work by far, I
don't know how he was like this obsessed and dedicated
to this project. But like if you've heard of the
typescript like doom and typescript types thing I did, I
did help with that, and so yes, like I am

(13:33):
sort of like, let's do crazy stuff with typescript types.
Person to me, the coolest thing when I first had
the idea for our type.

Speaker 6 (13:41):
Like that this this would be the closest if I
could get.

Speaker 5 (13:43):
It to work well to having native type but that
you could use at runtime without a compilation step. And
I thought, okay, well, I could probably write some kind
of parser, but there's no way it's going to be
efficient enough that it'll be viable at scale. It's gonna
be really slow because I'm doing all this like complex
you know, iterating over characters and trying to figure out

(14:03):
what an expression means, and it's gonna be really expensive.
But it turned out that there's after lots of iteration,
I found that there are ways that type can actually
solve that problem really efficiently. I ended up using this
like shift reduced parser method that does a lot of
the stuff you're talking about in terms of like crazy
type level logic, where it's iterating over one character at
a time, and it has this state of like, hey,

(14:24):
have I parsed like an open parenthesy?

Speaker 6 (14:26):
Is there a group open that I need to have closed?

Speaker 5 (14:29):
Or is there you know, what branches of a union
am I currently parsing, And then it will kind of
be able to give you native quality type errors as
if you were like writing the code directly in your editor, right,
so it can say things like if you forget to
close a parenthesy in your type or something. It will
say like missing closed parenthesy before these characters. If you say,

(14:49):
like you know, Booley and less than five, it'll say
like the less than operator can only apply to a number.

Speaker 6 (14:54):
A string or an array or so.

Speaker 5 (14:56):
So you get these like native quality type errors, which
I feel like is really important to that core proposition
of like we want native quality DX and like the
same experience you'd get defining native types, but extended and
available at run time. So you could just take that
same thing with no compilation step in vanilla JavaScript and
Typescript and.

Speaker 6 (15:15):
Just use it to validate your data as well.

Speaker 5 (15:19):
Wow, that's crazy.

Speaker 7 (15:20):
So on the performance you were like, oh, I wasn't
sure if we could do this in a performance way,
and you don't, like not surprised, like it sounds super complicated, right,
and typescript is written in Typescript as well, so not
the most language. So moving forward then to say typescript seven, right,
have you benchmarked our type against TSCO yet and seen
what the the like? You know, you said it's already

(15:41):
like faster than you're expecting just in the Teescript compiler,
but like, have you try what's the increase you're getting
from the TSCO compiler or.

Speaker 6 (15:49):
Yeah, so's yes, it's very good.

Speaker 5 (15:51):
It's about five times faster and TSCO, which is pretty
consistent with like the sort of lower bound of most
libraries across the board. So I think the like ten
times is probably mostly if you have you've seen the
I think they say ten times faster a lot. I
would say that that's mostly if you have like a
lot of a lot of like flat types that don't

(16:14):
necessarily relate to one another the way that types defined
using a library would relate to this like central file
that would have to be type checked by every parallel process.
So for those kind of types in any library, you're
never going to get quite as much benefit out of.

Speaker 6 (16:26):
The paralyzation that go offers.

Speaker 5 (16:28):
But just the native speed up, I guess like guarantees
it's going to be at least five times faster, which
of course is really exciting and means that these methods
of like it all. To be honest, it already wasn't
a barrier to like scale for archetype. The type performance
is really good. It's already like which blew my mind.
But it was already especially before ZOD four was just released,

(16:50):
but especially compared to ZOD three. It was much better
in terms of type performance. ZOD four improved a lot
of that, so it's closer in their more trade offs
depending on you know what, what particular operation you're performing.
But the fact that it's very comparable and sometimes better
than ZOD four, which uses chaining and like much more
traditional approaches for an API and it's doing string parsing

(17:13):
is like vastly it vastly exceeded my expectations for what
the ceiling of that kind of approach would be.

Speaker 6 (17:19):
So I was.

Speaker 5 (17:20):
Really really pleasantly surprised, and I think, like, it's funny,
I don't I don't think people in the Typescript team
would have anticipated that that would have worked so well. Either.

Speaker 6 (17:29):
It's just kind of one of those things that you discover, Oh.

Speaker 5 (17:32):
Wow, Typescript is really efficient at this method of string parsing.
And I'm very grateful that it just this came together,
because I could have imagined putting a lot of that
initial work in just to get to a sort of
roadblock that's like, well, this is great for like a
toy project, but this isn't going to scale the way
you'd wanted to for you know, a much larger mono repo,
but not having to like make any of those disclaimers

(17:52):
about scale and just having that you know, really excellent
DX be able to scale to whatever level you needed,
especially with TSCO. Now is is you know, really awesome,
and it makes it a much more a much more
like real solution than I ever would have anticipated when
I was first brainstorming.

Speaker 4 (18:09):
David, I have two questions for you, I guess the
first question is, I'm sure you get this a ton
of times. So on one hand, I think this will
be beneficial, but I think also you'll probably be like, oh, yeah,
here it comes. What tell us just I think a
lot of people are gonna be familiar with ZOD, tell
us kind of how our type sits in relation to ZOD,

(18:29):
and maybe what are something in your mind obviously, like, so,
what are some of the reasons why you might choose
arch type over ZOD and also why you might choose
odd over arch type.

Speaker 6 (18:37):
Yeah?

Speaker 5 (18:38):
Sure, So I'm like good friends with Colin, and like
I said, we have a great community of Schema Library authors.
We like to bounce ideas of each other, and I
think there's a lot of mutual respect there, and especially
I think with a lot of the improvements that were
made in ZOD for it's right and so like, I definitely,
I definitely don't think it would ever make sense to

(18:58):
say like this is a terrible outdated library that you
shouldn't use or anything like that.

Speaker 6 (19:01):
It's great and it's certainly do just its strength.

Speaker 5 (19:05):
I would say, like some of the older solutions like yep,
maybe like though those feel like they've really fallen off
quite a lot. If you do like performance metrics or
any of these other type in friends capabilities like, you
probably not want to go back that far. But ZOD
is great, and especially with the updates and before.

Speaker 6 (19:19):
So I would say that the.

Speaker 5 (19:20):
Biggest advantages of ARC type so the definitions being like
using that syntactic approach mean that there are a lot
more concise. On average, the definitions are usually about half
as long as odd right, So I'd say, like the
concision and the readability is really a lot better.

Speaker 4 (19:42):
I noticed that the readability is really excellent because it
looks so much like typescript types that it's like anxiety exactly.

Speaker 5 (19:48):
Yeah, it's funny because you so have We've really tried
very hard to like make the hover a core part
of the d X that like, if you want to
see the shape of an arc type type, is you
can hover yes, and you just.

Speaker 6 (20:01):
See the typescript type and it's very very clear.

Speaker 5 (20:03):
Yes, Whereas like with ZOD or other libraries, you would
often see the entire ast and then you have to
like z infer to get the type out. In arc type,
you just you see the type itself and then we
can derive what we need to from that. But the
ironic thing is is that like with this like native type,
say string syntax, when you're defining in arc type schema,

(20:24):
you often don't even need to hover it because like
you're literally looking at the type, Like oftentimes you can
just look at what your definition is and hovering it
would almost be redundant because it's it's one to one.
So like that's a huge benefit just in terms of
mental overload of sort of like okay, what is the
shape of this schema again, and like how do I
use this and what is this supposed to be representing? Well,
like if you can just look at the definition and

(20:45):
see that stuff immediately, or hover you know, one of
the imported and see it immediately, Like.

Speaker 6 (20:50):
I think those things are big advantages.

Speaker 5 (20:52):
There's a lot of work that went into optimizing performance.
ZOD four got better in that area as well, but
archtypees go about twenty times faster for validing objects like
pure validation. God can be better if you're doing a
lot of transformations because it has a different approach where
it builds the object up. So that's that's that's one
area where there's a trade off that like archtype is
faster for pure validation, whereas ood is a little bit

(21:14):
faster for if I need to like pipe a bunch
of strings, our type has good APIs for doing that,
like you know, it's at a pars of Parson number
from a string or that kind of stuff, and then
create a new object. Arc type will still be fast,
but ZOD for with the optimizations that he added there
is going to be faster for some of those scenarios.

Speaker 6 (21:30):
Whereas if you're like I just need.

Speaker 5 (21:31):
To check the data and then I'm gonna do things
with it afterwards, archetype will be significantly faster.

Speaker 6 (21:37):
Arch Type also has really good error messages, so.

Speaker 5 (21:41):
Both when you're defining the schema is like, but that
that's kind of you need that, Like I said, like
you really want. You wouldn't want to use this like
string API if you didn't get like native quality editor errors.
I feel like at a type level using it, so
I feel like I can't really say that that's an
advantage because because like it's part of the it would

(22:01):
be a cost that would be like incurred by the
form of the API, and I'm kind of just compensating
for that cost.

Speaker 6 (22:07):
So it doesn't feel bad, but it feels very good
to use.

Speaker 5 (22:09):
But I would say at run time, the errors you
get when validation fails are really polished and really very
good out of the box, even for unions and things
like there's a lot of logs around trying to simplify
down the error messages and condense like what you'd get
even if there are multiple branches. We try to like
provene out redundant stuff and like automatically discriminate your unions

(22:29):
for you so that we're going to give you as
like concise and clear and error message as possible. I
would say that, so that could be a big advantage
for ARC type. I think ZOD right now, the story
around like customizing individual parts of an error is a
little bit easier. I would say that like ARC types
errors are much clearer and like more flexible by default,

(22:51):
and there are lots of ways.

Speaker 6 (22:52):
To customize them.

Speaker 5 (22:53):
But the tricky thing with ARC type and with some
of the trade offs around having that like typescript syntax
versus having the like pure z dot that approach that
creates an AST is that it can be harder intuitively
to like granularly associate a specific.

Speaker 6 (23:10):
Error with like one constraints.

Speaker 5 (23:12):
So if you're like I want a string that matches
this rejex and is less than five characters, there are
ways you can do that with chaining, and there's chaining
APIs and ur type two. There's like a fluent API,
but it just like you're a little bit off the
kind of like beaten path. You have to like know
that those things exist and you have to kind of
go a little bit out of your.

Speaker 6 (23:30):
Way to like customize those the way you want.

Speaker 5 (23:33):
So that'll be something we're working on in upcoming releases that, like,
I think Zod's error message customization is probably just more
intuitive because you don't have to change anything about what
you're doing, whereas if you imagine an expression that's like
here's some rejects, and then it's like less than ten characters, Well,
if you wanted to say, like, if it's less than
ten characters, what error message.

Speaker 6 (23:49):
Should I give?

Speaker 5 (23:50):
Specifically because you don't like the one that you get
out of the box by default, you can't just use
a string syntax because that wouldn't look good, So you
need to like revert to a chain chained API for that.
And again those things are in the docks. But like,
I still feel like zod is like has a little
bit of an advantage there with some of that like
regular customization. Yeah, I mean that's a few of the things.

(24:10):
The biggest thing, like internally that I always get really
excited about is that arc type when I said, like
it kind of brings Typescript to runtime. It also has
all the kind of like introspection capabilities of Typescript at runtime,
which is really cool if you're a library author or
using the framework in like a more meta kind of
way where you want to say, like, is one type
assignable to another type? Like if I pass in this schema,

(24:33):
does a guarantee that all the constraints of this schema
are satisfied? And so like arc type has a bunch
of it's all based on this like set theoretic approach
where everything is normalized and reduced to its simplest form,
and we can actually compare types to one another and
say like these two types have no overlap, or like
these two types like this one is a subtype of
another type, and those are things that like no other
validator can do. And so, like I said, I don't

(24:56):
think that on a day to day basis. If you're
just like I need to validate a form or I
need to validate a hayload, you probably don't care about
the fact that we have that introspection capability. We just
use it internally to kind of optimize, you know, make
sure that the validation is really fast and make sure,
you know, help you not create types that are unsatisfiable.
And there are benefits that we kind of capture directly,

(25:17):
but I think externally, there's also a lot of opportunity
for other library authors to make use of those deeper capabilities,
like again having like a real run time type system
for JavaScript, which is kind of the goal of our
type is to take typeescript and bring all the best
parts of it to run time so that you can
use it dynamically, you know, to to do all sorts
of things that would otherwise not be possible.

Speaker 4 (25:38):
Yeah, thank you so much for that. That was a
phenomenal answer. Think you here running through all the pros
and cons on that. I didn't mean to cut you off, Brook,
Was there's something else you want to type in? I
have another question ahead? Yeah, sure, David, I think I
guess I'll be the AI person on the show today.
For those developers that are using open ayes APIs it

(26:01):
expects Jason schema? And then also I think gemini is
open API does the does archetype work if I'm used,
If I'm an AI engineer and I'm using something like
structured data and I want to get a Jason schema
back from an l l M, is that something that
I can use arch type with or you know, I

(26:22):
see on open AI's documentation use of ZOD A lot
of document a lot of blog posts and stuff, you
know use ZOD. I think they stip help their function
or of some kind, maybe even ZOD function or something
like that. Yeah, yeah, is that something that y'all are
doing as well? Or like, yeah, can you reach for

(26:42):
arch type if I really like what you're talking about
and I want to use this, but will this work
in this scenario? I'm just curious.

Speaker 6 (26:49):
Yeah, definitely, so most I would think so. Yeah.

Speaker 5 (26:53):
So there's a few parts of this. I think one
of them is that it's funny the way that l
L M use zod or use a validator because they're
not actually using the validation logic at all. They're just
translating it to Jason schema and then they use the
Jason schema. So yes, luckily most of them at least
have some kind of it's it's almost bizarre to that

(27:16):
they even have something that's like here we have like
native support for zod or use Jason schema, when really
they're just using this hot to give you the Jayson schema.

Speaker 4 (27:25):
So you can almost in the narrow subset of that too.
Let's be clear, like some of them, some of the
can't even do like if you have a number like
a men in max, let's say it's like a range
of zero to one hundred. I think just recently Gemini
supported that or one of them just launched where they
actually support a men in max and so you can
actually do things with the schema language that is fully
supported and baked like men and max. And then you

(27:47):
go you put, you convert that to Jason Schema sent
to l LAM, and then it gives you two hundred
and fifty and you're like, what I told the the
men of Max, what is happening here?

Speaker 5 (27:55):
Right?

Speaker 6 (27:56):
Yeah?

Speaker 5 (27:56):
Yeah, there's a lot of limitations there still, sure, I've
worked on this problem from a couple angles, so one
of them is in our Every type has a two
Jason Schema method on it, so it's like natively supportant.
So I think it's it's very very easy to translate
types to Jason Schema. There are some big advantages in general,
like this is very granular system you can use if

(28:18):
you need it to be able to control how all
sorts of constraints are are converted to Jason Schema, and
especially for non serializable constraints, which there's so many of them.
So if you think about things that archtype can represent
that Jason Schema can't represent, there's I think there was
like twelve or something different categories of things that Jason

(28:38):
Schema doesn't have a way to represent it, And so
you can kind of granularly control like what if I
have a custom validation function, what if I have a transformation,
what if I have you know, just bizarre stuff like
intersections of regex is not something that Jason Schema can
can represent. But like archetype is this very robust type
system that reduces things. And like if we have for
whatever reason you say it, it's the mass the two rejects,

(29:01):
we need to do something in that scenario. And so
there's all these different categories of things that we need
to say, Okay, we can't translate if we can't translate
this to Jason Schema safely like on our own in
a one to one way, we need you.

Speaker 6 (29:12):
To specify what we should do.

Speaker 5 (29:14):
And so it's a very easy way to say, like
just ignore it and fall back and pretend the constraint.

Speaker 6 (29:17):
It's not there.

Speaker 5 (29:18):
But you can also you can also configure it to
do whatever you need. We'll handling constraints like that. And
then so separately though, I'm you may have heard of
Standard Schema, which is this yeah, okay, well this is
a great solution for these kinds of problems.

Speaker 6 (29:36):
So so I.

Speaker 5 (29:37):
I and uh Fabian who works on Valabot, and Colin
who works on ZOD have teamed up to create this
spec called Standard Schema, which is a very simple validation
sort of like schema aspect for any any schema that
can validate data and type script and infer the type
of what they've what they're validating. And so essentially, if

(30:00):
like in the past, you were a library and you
wanted to accept a schema, you'd probably directly define that
you accept you know, ZOD or yup or you know,
whatever that it is you want to support. And then people,
as archetype was getting popular, people will start to add
support for arch type. But first of all, I mean
that's not sustainable for library authors.

Speaker 6 (30:18):
And second of all, what about the next generation of
like schema validators.

Speaker 5 (30:22):
You want it to be an open ecosystem where people
can compete on even footing. So we define this standard
scheme aspect where as long as you implement a standard
property that has this valid eate function attached to it
and has a way to infer the types, libraries can
now just accept a standard schema and then they can

(30:43):
be agnostic to what library is actually providing that standard
schema implementation. So you can pass an archtype type, you
can pass the odd schema, you can pass a Valibot schema,
et cetera. And so I think that's a really big
win for the ecosystem, and it has already been very successful
and it's been pretty broadly adopted by library others, so
I think that's really promising. And as a sort of
like preview, we are just wrapping up our new spec

(31:08):
for a Jason Schema source as part of the standard
schema definition. So this will provide away a solution hopefully
to this problem of you know, why does open AI
and why does you know the versell AI S d
K or whatever that it is like that just need
to generate Jason Schema. Why are they asking for odd
schemas in particular or anything like that, because they'll just

(31:28):
be able to say, we'll accept a standard Jason Schema
source and then anyone can pass in an archetype type
or there might be a little It's one nice thing
about our type is like, since we have that too
Jason Schema that attached directly to the type, it'll be
really easy. In ZOD or valid bot. I think there'll
be maybe some it might be a utility function or

(31:48):
something you call to get a Jason Schema source from
or schema or whatever, but basically there'll be a solution
so that you can you know, use whatever scheme of
validation library you want, and any of them can generate
Jason Schema, which is very As you mentioned, this is
like a big problem in the AI world. This is
what everyone wants is to be able to generate Jason

(32:08):
schema so they can generate, you know, invalidate their data
that way. So there'll be a solution to that that
we're working on. So, yes, it's something that's very doable
in our type and you should be able to use
as is. You should be able to use the like
utility version of the methods that just accepts Jason Schema directly,
which I think are available hopefully in those contexts. So
if you just do our type you know, type two

(32:31):
Jason schema, you can use that. But then I hope
that the ecosystem in general will be moving more towards
as we release and publicize this standard Jason Schema source solution,
hopefully the ecosystem will move towards adopting that so that
everyone can again just use the schema library that they
want and it's easy to pass Jason Schema wherever you need.

Speaker 4 (32:49):
Yeah, that's fantastic. Yeah, And for the listener, will drop
some links in the show notes, but you can check
out standard Schema dot dev where you guys have some
more information about that. That's really fantastic. Thank you so
much for answering both my questions.

Speaker 9 (33:02):
Good morning. You know that moment when your coffee hasn't
kicked in yet, but your slack is already blowing up
with Hey did you hear about that new framework that
just dropped?

Speaker 4 (33:11):
Yeah, me too.

Speaker 9 (33:14):
That's why I created the Weekly Dev Spur, the newsletter
that catches you up on all the web death chaos
while you're still on your first cup. Oh look, another
anger feature was just released, and what's this typescripts doing
something again? Look also through the poor requests and change
slot gramma. So you don't have to five minutes with

(33:36):
my newsletter on Wednesday morning, and you'll be the most
informed person in your standard Ah. That's better the Weekly
devsper because your brain deserves a gentle onboarding to the
week's tech madness. Sign up at Weekly Brew dot Depth
and get your dose of deaf neews with your morning caffee.
No hype, no clickbait, just the updates that actually matter.

(33:58):
Your Wednesday morning self will thank you.

Speaker 3 (34:00):
Yeah, of course, so I'm I'm wondering because you know,
as you've kind of been comparing two other validators, how
how do you go about measuring performance and reliability for
a library like arc type.

Speaker 5 (34:14):
Yeah, so it's a it's a hard question. It's a
hard thing to do in a neutral way. You know,
you see a lot of benchmarks that are very tailored
to to what a particular library is good at. So
I think one of the better solutions is to have
a a core set of benchmarks that's maintained by someone

(34:36):
who's not a first party maintainer of any of the
validation libraries, which is does exist in the typescript ecosystem.
There's something called Moltar's Typeescript runtime benchmarks, and they're really
just some like simple object validation benchmarks that people use
to generally compare scheme of validators to one another.

Speaker 6 (34:53):
So that's what I use. Like, if you look at
the homepage.

Speaker 5 (34:55):
Of arc type dot io, you will see some graphs
comparing you know, archtype odd for and yeah and all
that stuff. And so I'm just referring to that. So
I cannot answer questions about the validity of such benchmarks.
That it's good to like have some external party that
you can defer to. There, I still think it's a
problem because people will then optimize around those benchmarks, and

(35:17):
like you know, there are there are very tricky aspects
of this kind of thing. I think the best thing
you can do, like realistically, what would be best for
our ecosystem is if we had probably like a broader
spectrum of benchmarks.

Speaker 6 (35:29):
So the benchmarks that exist.

Speaker 5 (35:31):
Now really only cover like simple or nested object validation
scenarios and a few different variants of that. But to
be honest, like as someone who spent a lot of
time on optimizing these scenarios, they're actually not very distinct
from one another in terms of like you wouldn't really
expect the performance characteristics for libraries to be drastically different. So,
like what I would say would be like a best

(35:52):
way to capture like a more real performance would be
if they added benchmarks for or other types of validation scenarios.
Like Okay, so how fast is it when the data
is invalid?

Speaker 6 (36:07):
How fast is it when there's a large union?

Speaker 5 (36:09):
How fast is it when you're checking to see if
the data is valid as a binary versus you're traversing
the data and giving a full error message and detailed analysis,
and like these are the kind of things that just
get very messy because I mean archetype basically prioritizes being
as fast as possible for valid data because that's the

(36:31):
reality of what you're going to be validating most of
the time, especially for server payloads, like it's mostly going
to be valid input, and so you want to be
as fast as possible in that case, and in the
cases where something is failing, you want a detailed error message.
So that's kind of how the process works in our
type to try to get the best of both worlds.
Is that we have like a very fast path for

(36:52):
valid data, and we make sure it's valid, and then
if it is, we can just return the valid data
and that's very very fast. If it's not valid, which
we can determine very quickly, then we go in into
another past that keeps track of context and can piece
together a detailed error message. It'll help you find the problem,
but that's a lot slower. But the question is like, well,

(37:13):
so how do you measure that, because then you're incentivizing
people to give worse error messages and you don't want that. So, like,
you know, realistically, you have some very complex set of
benchmarks they would try to give us side by side
of like here's what the error message you get would
look like, and here's how long it would take you
to get that level of detailed error message. But you
can see how this gets into like very kind of

(37:36):
like nitty gritty territory with a lot a lot of
trade offs and a lot of ambiguity. And people just
like numbers that they can just compare and say the
bigger ones better, the smaller ones better, and you know,
just choose based on that.

Speaker 6 (37:47):
So it's a tricky question.

Speaker 2 (37:50):
I think.

Speaker 5 (37:50):
Another interesting aspect of it, which really isn't measured at
all outside of of arc type and it's not really
centrally measured, is like this idea of type performance.

Speaker 6 (37:58):
So a part of our as part of building.

Speaker 5 (38:00):
Archetype, I built this library called a test, which is
a type testing library and type benchmarking library.

Speaker 6 (38:07):
And that's actually like.

Speaker 5 (38:08):
How I made the type level parts of really fast
is I built this library that could capture, for like
one block of code how efficient the types were, or
particularly like how many type instantiations that code resulted in,
and that made it really easy to like iterate granularly
and say, like if I make this one change to
this type and then rerun this benchmark, does the number
of type instantiations go up or down? And so like

(38:30):
that's pretty much how I learned to write efficient types,
and that's how I got archetypes of parts to be
as efficient as it was, as like many many rounds
of iteration for that. But that isn't something that is
like there's a centralized benchmark for like how many type
instantiations do all the run time validators create just because
no one is like taking the initiative to create something

(38:51):
like that, And I don't want to be the person
to do that because again I think it's best that
it's like a non interested third party. It's still a
little sketchy because I built the library that measures the
type instantiations, so like maybe they'd come up with another
way to isolate those that wouldn't involve the particular logic
I wrote. But like that's another really important aspect of
performance that there's a very few benchmarks out there to

(39:12):
try to capture, and archetype uses those a lot internally
to try to optimize. But like it's hard for people
wanting to get an idea of like, hey, which you
know scheme of validation libraries are kind of break my
typescript server and make my editor crash most likely, and
which are going to be fast and be able to scale. Well,
you know, it's all very anecdotal for the most part,

(39:33):
outside of like some of what we've done internally to
try to attach granular numbers to some of those things.

Speaker 4 (39:39):
That's really interesting. I thought the way that you explained
the error checking and the like the first pass through
the validation and stuff, that makes a lot of sense
to me. I'm also interested in just the error validation again,
just from like again, if you're using like an LLLM
or something that you can almost have like a self
healing like a gentic feedback loop where you're like, no, no, no,

(40:02):
you're giving me the wrong data. Here's a very detailed
error of where that data is and why it's wrong.
Send that back to the outline, validate again, and you
can have this kind of like flywheel right of almost
like this loop of validating that Jason schema using that
that yeah, the validation and the error pass, but having

(40:22):
this checking for that successful validation first and optimizing against
that makes a ton of sense to me, because I
think you're right, like, historically we do expect our APIs
to return very deterministic data, and so we know that
it's going to come back with this data, we want
to validate really quickly and.

Speaker 5 (40:37):
Move on to the next thing.

Speaker 4 (40:39):
That makes a lot of sense to me. So and
I just really loved your just your transparency in answering
that question. That was really phenomenal, So thank you, David.

Speaker 5 (40:49):
Yeah, yeah, of course, I mean I think I think
any developer who works on this kind of stuff will
tell you, like, this is territory. Yes, it's very hard
to be objective and hard to like and of course,
like that's that I'm choosing. What I'm doing marketing is
absolutely going to be somewhat biased towards things that make
me look good, right, Like there's no affording that, and

(41:09):
so like I think just owning that and and is
the best way to go. Just try and walk the
line of being of being fair with without uh yeah,
with be be fair, but also like yeah, make make
your things look good and show off the advantages of it.
So I try to walk that line as much as
I could, And like I said, I think it makes
it easier that. I feel like I have a lot

(41:31):
of respect for the other scheme of validation librais that
are out there and what their strengths are. So it's
easy to say, hey, we're great at this stuff, but
you know, they're great at this other stuff, and we
can kind of just try to, you know, give people
a good range of options that so they can choose
the one that fits their needs the best.

Speaker 7 (41:47):
I think the fact that you three or more what have,
however many it is or together is fantastic. I mean
that just yeah, well I also have to yeah, I
mean and I have to give call In a lot
of for this, in particular because I think that as
the maintainer of the most prominent scheme of validation library

(42:09):
in the ecosystem right now, the fact that he was
sort of like initially spearheading this effort and like wanted
to get us involved in this says a lot about
his character because of course, like he kind of theoretically
has the most to gain if he's trying to optimize
around like locking down the ecosystem for something like this
not existing and.

Speaker 5 (42:26):
People just ass supporting ZOD directly. So the fact that
he feels like it's more important for the ecosystem to
be open, even if that's at the expense of potentially
like that he would have to then compete on equal footing.
It just says a lot about his character. So I
think he deserves a shout out for that.

Speaker 7 (42:44):
Yeah, agreeably, I mean that true open source maintainer, right, Like,
that's that's why all of us contribute to well, not
all of us on this call, I think not all
of us in general contribute to open source, right, because
we want everybody, that's all of the things that thrive, right,
not just our thing to thrive, which I think is
a huge part of what it truly means to support

(43:08):
open source.

Speaker 3 (43:10):
So the other part of this that fascinates me too
is that creator aspect. You know, we've talked so much
about archetype itself, what it does, why you'd want to
use it, But I'm equally as fascinated in the creation
process and what you went through and actually building this,
And so I'm wondering what advice you would give to

(43:31):
others who may be thinking of creating their own programming
tool or library of sorts.

Speaker 5 (43:38):
Well, I mean, I'll be honest, like, it was a
hard time in my life, I will say that like
working on an open source project without money and something
that you're really passionate about the vision for and want
to realize. And I mean I'm someone who's prone to
like being obsessed with things and sort of like like

(44:00):
I said, work life balance issues and you know, uh,
it's hard. It's hard to do something like this and
to be honest, especially depending on what you're trying to create.
So like arc Type, I would say stands out as
probably like the most ambitious.

Speaker 6 (44:18):
Solution to this problem.

Speaker 5 (44:19):
That doesn't mean it's the best, but like because it
has this type level parser, because it has this run
time type system, and I was like, I want to
bring type script to run time like this is it
was a huge, huge undertaking to like get the initial
releases done, the one point oh release and the two
point oh release, and like so I think there's I mean, look,

(44:40):
I'm not gonna tell anyone who's like really excited about
a particular vision they have for a project to not
pursue that because I'm very very grateful that I have
the opportunity to work on arc type and I think
it's like a really beautiful problem and so like and
in a lot of ways. I really like would not
trade that for anything. But at the same time, I
think you really have to be pragmatic about getting into

(45:03):
something like this, And I'll say that, like for this
kind of project, you have to be that obsessed to
like really see it through, Like you're not going to
be able to build something like that or like a
real competitor really to any of these scheme of validation libraries,
Like if you want to build something of that scale,
like you have to be obsessed and like you're going
to have to put in a lot of time to
do that. So I'm I'm the last person who who

(45:24):
would try to like deter people from doing that. But
I think like you could do a better job of
it than I did. To be French, you could probably
like have more specific plans about like how it's going
to be financially sustainable for you, Like how you're going
to kind of like make sure that you're balancing you know,
the other aspects of your life like while you're working
on something like this and still like making the time

(45:45):
you need, which is going to be really significant to
be able to see something like this through with and
potentially you'll have times where you don't necessarily have like
a lot of external support, especially while you're trying to
gain users initially and like get people excited about your
Like that's that's really hard. So yeah, I mean I
would tell people, like whatever, I'm not going to tell

(46:06):
people want to pursue their dreams, because you totally should,
like if you have something you're really excited about, like
find a way to make it happen. But I would add,
like try to be pragmatic also and have plans ahead
of time, like I ended up eventually like doing I
do typescript consulting. I'll like help help teams optimize their
types after having type performance issues. So like that ended

(46:27):
up being something that can make make this financially sustainable
for me.

Speaker 6 (46:31):
But I regret not having pursued some of that stuff sooner.

Speaker 5 (46:35):
So like I would tell people, like I had a
you know, I had a job that was paid well
at Amazon, and like try to think through every aspect
of how you're going to like create something like this
and and how you're going to see it through, and
how it's going to be sustainable in the meantime, like
earlier rather than later, because I think, you know, yeah,
I could probably have avoided like a lot of the

(46:55):
really hard aspects of creating something like this if I had,
if I knew what I knew now about some of
those challenges ahead of time, There's a lot of things
that I would I would do differently.

Speaker 3 (47:06):
It's interesting to me because it's like I see so
many benefits professionally for you, right, like you did pour
in all this time and dedication, and I would hope
that along your career path that will come back to
just serve you. You know, you're making all these great
connections you're networking with people. I think it shows tremendous

(47:27):
tenacity on your part, and I can't think of any
employer who wouldn't want that at their company.

Speaker 5 (47:33):
It's yeah, that's true that I think, Like, I don't know,
if you are obsessed with something enough that you're willing
to spend all your time doing it. Like again, there
are some real downsides and things you have to be
very careful about, I think, depending on what your life
situation is. But like, yeah, I mean, if you spend
that much time in something, and for me, I think

(47:54):
the things that I really spent a huge amount of
time on would be like writing complex types, optimizing types
and like this like set theoretic type system stuff. So
like I spent so much time on those things, like
many many thousands of hours, like and so you get
to a point where, like you kind of can become

(48:14):
the expert on this subject. And if you're the expert
on a subject that like almost anyone cares about, that
that's valuable in people. And then you can say, like, hey,
if you need to optimize your typescript types, you can
hire me to do consulting and this kind of stuff.
But I mean, yeah, there's other aspects of it as well,
Like you know, trying to build a social media platform
is probably very important. I don't think even with like

(48:37):
having some of the expertise, I don't think it would
have got me very far if I hadn't been building
an audience of people and building like kind of name
recognition and so that then when I was like, hey,
I'm looking for consulting work, that I would have people
reach out to me who would be interested. So there's
like a lot of stuff that if I could go
back in time and do this stuff earlier, that would

(49:00):
have been super helpful for me. So that's honestly the
biggest piece, because, like I know, in my position where
I was at a few years ago, I would never
listen to advice to do anything other than see through
my vision and like do everything I could to make
that a reality. That was what I wanted to do
more than anything, and I'm glad that I had the
chance to do that. But I think that, like, if

(49:21):
you were in that position, you should think about all
these other peripheral aspects of it also because they're extremely
important to like what your quality of life is during
a period of time if you're going to be putting
that much effort into something like have a plan for
building a social media presence, have a plan for how
you're going to be monetizing this thing, or how you're
going to be monetizing your skill set or you know,

(49:44):
your name recognition or whatever it is. You know, you
want to like plan these things ahead of time. Because
the open source ecosystem itself, like there are initiatives to
try to get companies to be supporting the open source
projects they use more, but frankly, there's still far too
much in their infancy for that to be a reliable
source of income for anyone, even for very popular projects.
Never mind people who are just trying to get started.

(50:06):
So like having plans around all these things, like, I
can't really overstate the value of that unless you're just
like a trust fund kid with millions of dollars in
the bank for some reason or whatever. Maybe do whatever
you want and you'll probably be fine. But if you're
not in that situation, like, these are all very valuable
things to think about.

Speaker 2 (50:22):
Well, I'm what you're when you're spending that much time
focused on this, My biggest question is what are you
not spending time doing? You know, does that mean it's
pulling your attention away from your job from other things?
So yeah, I think just weighing out.

Speaker 3 (50:37):
If I focus on this, that's great, that's wonderful, but
it also means that I'm not focusing on X, Y
and Z.

Speaker 2 (50:44):
So yeah, way that.

Speaker 6 (50:46):
Much, hundred percent.

Speaker 5 (50:47):
I mean I think I probably worked like eighty to
one hundred hours a week for four or five years,
So I mean, what else am I going to do? Like,
you know, that's it's going to be hard to fit
other things in at that point, right, So yeah, that's
I think. Okay, So here are ideas for like ways
that this could be a better situation. So, like, let's
say that you are working at a company and you're

(51:08):
kind of in a position where you know a lot
of like what I did for Amazon, for example, I'm
building tooling that lots of developers can use. I'm building
tooling that lots of other developers can use, and I wonder,
for example, at Amazon, maybe it'd be questionable, but like,
is there a way that my company might support me

(51:29):
open sourcing the work that I'm doing already for the
developers internal to my company while I'm getting paid, and
then I'm just getting paid to work on my open
source project, Like that stuff could be totally viable in
many circumstances, like if you're building tooling for the developers,
like that might if it's filling a need at your company,
as long as there's many scenarios like that where that
need could actually be met more broadly and you could

(51:52):
be in a position where you're just getting paid to
like work on an open source project for your job.
And I think for a lot of situations like that
of sitution, that that that setup is going to be
a lot more sustainable. And then if eventually, you you know,
end up wanting the freedom and you can like leave
and work on that full time once the project is
grown or something. There's probably a lot of ways to
get involved a little bit more incrementally, and in that

(52:14):
situation isn't even obviously the most incremental. The most incremental
thing would be probably, like, you know, finding ways to
contribute to existing projects that you're excited about so that
you're not having to build something from scratch and do
all the marketing and documentation and everything involved with trying
to get traction there, unless you just want to do
that for fun. But if your goal is really to
like impact something positively, it's probably much easier to get

(52:36):
involved with contributing to an existing project.

Speaker 7 (52:40):
Yeah, the best way to the best way to get
involved is to literally just get involved in something that's
already going, right Like, And it can be as simple
as helping write docs or fixing spelling mistakes and dogs
or whatever. Yeah, right, Like, it doesn't you don't need
to go and like add a new feature or like
improve the performance by three three percent, right Like. Any
kind of up towards open source projects is as long

(53:02):
as it's.

Speaker 5 (53:03):
Yeah, Yeah, I mean I would say that, like definitely
as a maintainer, I think the main thing, like you're
never going to be upset about someone reaching out and
asking how they can help, and you can always have
a conversation and say like, well, you know, all right,
what kinds of skill sets you have, like what kinds
of stuff you like to work on? And I'm sure
there's almost always something that you'll be able to find
that would be, you know, somewhat useful to the project,

(53:25):
even if you don't have a ton of experience yet,
Like I think if it that's a great way to
do it, because I will say that the thing that
you don't want to see is like some big pr
that gets opened out of nowhere that like changes a
bunch of stuff that you are not actually going to
change and you weren't warned about. And then and then
then you have to say like, well, I'm sorry, but
I'm not going to emerge this work, like I wasn't

(53:47):
told that this was happening, And so it's good to
be proactive.

Speaker 6 (53:51):
But I would say that a good first step.

Speaker 5 (53:53):
Would be like reaching out to a maintainer and having
a conversation about like what might be a good fit
in terms of contributing, as opposed to even if you're excited,
it's probably not best to just jump in and build
something and then say like here, you know, take this
pr for this massive overhaul of your implementation. So yeah,
but there are there are lots of good ways to
get involved incrementally, and you know, hopefully, I think I

(54:15):
think the vast majority of the open source community is
going to be really receptive to.

Speaker 7 (54:18):
That totally open issue, open a discussion, propose something suit
maintainer thinks if they apply to you, then tweeted them.

Speaker 5 (54:29):
Yeah, I mean the even simple stuff like yeah, even
simple stuff like I have people. So there's an ARC
type discord that's at arctype dot io slash discord and
it's a great community of people. And like, I cannot
overstate how much I appreciate the people who answer questions
in the ARC type discord because like, as a maintainer,

(54:49):
you kind of feel like, okay, well, especially where like
I don't have a ton of other people making huge
contributions to archtype, Like people make these kind of you know,
smaller contributions and things which are good. But I'll say
like those honestly, like, in a lot of ways, sometimes
the smaller contributions don't always feel like they're saving me
a ton of time. Like it's like, Okay, well I

(55:10):
talk with you for a while and then you fix
something that I probably could have fixed pretty pretty quickly.
But still, like I appreciate that interaction. But when I'm
thinking about, like what makes my day to day life easier,
Like it takes me a long time to like answer
someone's rambling question about like how to use our type
and like their five follow up questions that they inevitably
ask afterwards. If someone else does that for me, like

(55:30):
they are saving me like thirty minutes probably of my day.
And I view that as like my responsibility to do
if someone else does not do it, So like that's
a very important part of like I guess, I guess
supporting a project and contributing to a project, even if
that specific contribution doesn't show up on the like you know,
GitHub commit charts or whatever. Like I try to call

(55:50):
people like that out as much as I can. And
I'll say this one person in particular, whom my discord,
I'll give a shout out to Tizzysaurus because they have
always been They've also made some contributions, but they've always
been so fantast think answering lots of questions, even at
times where I fall a little bit behind, like I'll
come back and they'll have answered five or six questions
that have come up in the meantime for people, And
I think that kind of support for a project means

(56:12):
a ton as well. So there are lots of ways
to contribute.

Speaker 4 (56:16):
I really love your answer previously just in terms of like,
it seemed to me that in your answer that ultimately
it seemed like you believed that this needed to exist
in the world, and that you felt like this is
something way that you could contribute and build this thing.
And so you clearly faced a lot of challenges through

(56:37):
that process, but I think that ultimate belief or that
purpose really kind of guided you through a lot of
that because you felt strongly that, like, this solution, this approach,
this needs to exist, and so I'm going to go
out there and do it and share it and hopefully
improve developers lives and experiences as a result of that.
So I think that's really awesome. I think the only

(57:00):
last question that I have is just I wonder if
some people are curious in terms of, like, are you
using any sort of like AI tooling to help you
build art type. I think my experience briefly has been that,
you know, AI tooling today, whether that's Cursor or codex
or claud, it's really good at maybe like building apps

(57:21):
and these kinds of things. And that's argue. I'm sure
you could argue even within the space of what I said,
whether it's really good or not, or what it gets good,
what what's it struggles with the mistakes it makes? But
are you finding any success in terms of building a library,
specifically art type and a typescript library with using AI
generated tools. My experience has been not very much, and

(57:44):
so I'm curious to hear kind of are there any
tools that you're using or yeah, kind of where are
you operating in the space as a library author? Where
do you kind of see some of these l M
power tools that developers are latching on too prett quick.
Where are you seeing those as beneficial to you or
are there or not? I'm just really curious as because

(58:06):
you're I think you stand apart data from maybe a
lot of our listeners that are writing applications using whether
to react or Angular, you know, versus what diverse sell
or whatever it is. You know what I mean? You
kind of as a library author. I think you're kind
of in your own kind of space in terms of
the code that you're authoring, much different than the code
that a lot of folks might be authoring in the

(58:27):
app development space. So yeah, curious to hear your answer.

Speaker 6 (58:31):
Yeah.

Speaker 5 (58:31):
I think my experiences largely or consistent with what you
described that I keep trying to use AI more and
I think that I'm going to figure it out. I'm
going to figure out like what the right kind of
problems that I can like prompt cloud code or something
with are that you will be able to solve in
a way that's not wasting my time. But it's definitely harder.

(58:55):
And I think our type is like the ultimate sort
of problem for this because it's so like it really,
like I said, it's very distinct in terms of it's
there's not even other library code that's very similar to
I mean, like libraries are all unique, but like's a
type level parser, so there's like a run time implementation

(59:16):
of a part.

Speaker 6 (59:16):
Of the parallels types, which is very weird.

Speaker 5 (59:19):
And then there's this internal like set theoretic type system
that has this like very specific set of rules that
it has to operate on about fully reducing things and
like so that it is challenging. I think because the
training day that it has really doesn't have very much
that would allow it to solve these kind of problems
other than like very specifically what it can understand from

(59:42):
within the repository itself. So I think I think it
probably can do a great job with stuff that's like
I want to add a new keyword that is like
string dot. I don't know what what string keywords do
I not have currently, like I do on a telephone
number that was when I specifically some.

Speaker 4 (01:00:03):
Zip code for very ambiguous whatever.

Speaker 5 (01:00:05):
But if there's some yeah, some something that I'm like, okay,
add a new keyword that's this, and it's a very
concrete task, like I'm sure it can do that successfully.

Speaker 4 (01:00:13):
But then and use the existing source code in to
provide that context like okay, here's how this one was built.
Here's how this one was built.

Speaker 5 (01:00:20):
I can do this other thing, yeah sure, yeah, So
like how much time is that realistically saving me?

Speaker 8 (01:00:24):
Though?

Speaker 6 (01:00:24):
Is like less of a sort of win.

Speaker 5 (01:00:26):
I'd say the areas where it saved me the most
time are like writing the docs.

Speaker 4 (01:00:31):
And like I was going to ask about the docks, yeah.

Speaker 5 (01:00:33):
Or like maybybe not even maybe I'm just overly particular
sometimes about wording and things where I'm like I mostly
want to write my own docs, but like creating the
docs website, like especially stuff like the playground. I used
llms a lot to like iterate on if you've tried
the like ARC Type Iioslash playground, arch Type Slage playground.
It's like, so it tries to create this like native

(01:00:54):
development experience, like in the browser where it's using Monaco
and using all the different things to like get autocomplete
and get the error messages in line the way you
would if you're using it locally with the extension, and
like there's so many nuances to that are a huge pain,
but like it's these tools have generally.

Speaker 6 (01:01:10):
Been pretty broadly used. And also I'm not like a.

Speaker 5 (01:01:12):
Good front end engineer, so like iterating on that and
having that like feedback that I guess helpful, But that
falls more to the like app category that you were describing,
so I would say, like, probably my findings are largely
consistent with what you describe that it's like very good
at if it can find lots of patterns for something
and adapt that pattern, then it's going to be successful

(01:01:32):
if it's working on solving something more unique like and unfortunately,
like what that kind of aligns with for me is
still like the work that is the hardest. I'm not
really getting a lot of help with. You know. Maybe
for humanity that's like kind of a good thing because
it was like, oh, we can solve all the hardest
and sheering problems by itself, and like what are we
all doing here?

Speaker 6 (01:01:50):
You know, so maybe that's maybe maybe that's okay.

Speaker 5 (01:01:53):
I guess a funny side note though, I don't know
if you've heard about this, like Ultimate Ultimate Coder like show,
the series that's coming up. Okay, so there's you should
just look up like Ultimate Coder on X or something.
I guess it's pretty new that they just started announcing it.
But it's gonna be like there's a series of contestants.

(01:02:15):
We're like working on a typescript API at a villa
in Malaga in Spain or some nonsense, and so we're
gonna for it all the time.

Speaker 4 (01:02:22):
You're doing this, yeah, yeah, yeah, the recording.

Speaker 5 (01:02:27):
Is gonna be it's gonna be later this month, and
so I know that it's at least gonna be me.
And Okay, I know that they alread announced people. I
don't want to talk about anyone that they might have announced,
but definitely like anderst if you've seen him in the
type script community, is like a massive figure and a
good friend of mine who works in the compiler a lot,
and then demet you the guy who did the typescript
doom types.

Speaker 6 (01:02:45):
So they'll be like a lot of really fun people.

Speaker 5 (01:02:47):
And the whole premise of it is actually like this
AI that we're like battling against the design and this
a PI and they try to kind of dystopian like
the AI is like taking over and it can you know,
you can reread all these APIs, and the typescript developers
are absolutely I'll say that like I'm not that I'm
more worried about the other contestants because I think right now,
when it comes to these like API design problems and

(01:03:10):
uh like these kind of like any any sort of
complex implementation of a library like arc type, I still
haven't seen it get to that point where it's great
at nailing those things. But anyway, just a shout out
to that that because it should be a ton of
fun and and kind of this whole idea of like, yeah,
what is AI good at and where is it still struggling?
So it'll be recorded later this month, so Ill went

(01:03:30):
to Spain for that. I don't know when it's going
to be aired, but keep an eye out for sure.

Speaker 4 (01:03:34):
That's so sweet.

Speaker 7 (01:03:35):
Yeah, there's just that they haven't they haven't. There's gonna
be five veal looks like, and three are announced and
two are still loading.

Speaker 5 (01:03:41):
As says, yeah, I'm I'm glad that I haven't spoiled anything.

Speaker 4 (01:03:44):
Then that's very cool. Yeah, we'll keep an eye out
for that. I was on the It hasn't come out yet,
but I did the web dev Challenge a couple of
weeks ago and it was so fun just to do
the recording. So I hope you have a great time,
and I hope it's really enjoyable and it's and just
being around people and the energy and everything, and definitely

(01:04:05):
it is entertainment, but it's also like coding and fun
and nerdy and it's just yeah, So.

Speaker 5 (01:04:09):
I hope I saw that it was a I definitely
thought it was a scam when I got an email
that's like, hey, you come out out Spain and compete
writing writing typescript types like that didn't sound like a
a real thing, but.

Speaker 4 (01:04:24):
But whoever did it? Like that takes some good like uh, yeah,
that takes some guts or whatever you want to say
some yeah, yeah, yeah, I'm gonna like go create a
show about this, like yeahohn you.

Speaker 5 (01:04:34):
John de Ghosts if you've heard of him, he worked
on like Zeo in Skala. I've seen him speak before
when I spoke at Effect Effect Days and uh he
was also a speaker there. He was amazing. So I'm
it should be a lot of fun. I think it's
a crazy pivot for him to go into this like.

Speaker 6 (01:04:50):
Awesome dev dev entertainment or whatever that it is. I'm all,
I like it for it.

Speaker 4 (01:04:57):
Me too, me too, I can't wait. I'm excited to
see that this is get.

Speaker 5 (01:05:02):
Yeah.

Speaker 4 (01:05:02):
Yeah, I'm here for it. I think it'll be really wonderful.
I'm excited for some of the Developer entertainment that's coming
out myself. So yeah, that's really cool man. We'll definitely
we'll drop a link Ultimate Codeer Do Show in the
show notes, so go check that out, folks.

Speaker 2 (01:05:17):
He's his feather out there for being selected to be
on the show next as well.

Speaker 4 (01:05:26):
I don't think I can like hold my own barely.
I'm sure David would be able to do circles around me.
And and a lot of the typescript challenges that we
faced with hash Brown, Mike was was the he you know,
he wrote a lot of the string parsing stuff in

(01:05:47):
anger X types to do all of that, and I
see some of that and it's just like nested and
nested and yeah, it's like the first level. I'm I'm yeah, yeah,
So I'll leave that to the experts David and others.
So but yeah, man, I just want to say thank you.
I think it's done a PLI you're having on the
show and just listening to you, your your humility and

(01:06:10):
your your transparency and all of it, and also just
like yeah, your your knowledge dropping has been wonderful. So
thank you so much for all that you've done with
ARC type and in the type script community broadly speaking.
I think it's benefited of all of us, and so
certainly a big thank you to that. I know that
doesn't pay your bills, but thanks for thanks for all
of that, and yeah, thanks for coming on the show.

Speaker 5 (01:06:31):
It's great to meet you.

Speaker 6 (01:06:33):
Much appreciate it. I had a great time as well.
If I'm gonna give one last shout out.

Speaker 5 (01:06:37):
Just these people might be excited about an upcoming feature.
So speaking of things that might help the typecript community
in general, the big feature that I've been working on
for two point two is actually something that's going to
go into arc type, but it's also going to be
available as a standalone package called ARC Rejects, which basically
uses all the same optimized parth parsing type parsing methods

(01:07:00):
that arc type uses for its core parser to solve
the like untyped rejects problem in type script where you write,
so you write like a rejects expression with like new
rejects or something like that, right, And this would give
you like what the pattern looks like as a template string,
and would give you all the all of the index
capture groups and all the name capture groups with the

(01:07:21):
proper types for all of that, and will also like
give you those specific parse eras at a type level.
If you like miss a parenthese or a bracket, you'll
see in line like missing bracket here or whatever. That
is the way that art type works. So I'm really
excited about this one because like I mean, arc type
will use it too. You can use it like in
an arc type string and say, you know, you could
write like an index signature that say, all the keys

(01:07:42):
have to start with fou and then matches pattern it
will infer that, which is pretty cool. But just more broadly,
even if you're not using arc type at all, you
can use ARC rejects and it will just be a
drop in replacement. It's no runtime code. It's only like
a wrapper around new rejects that has types and you
can just take anything you were passing to new rejects
and all of a sudden it will have types of

(01:08:03):
what the string looks like that you're inferring, and all
the capture groups and all that.

Speaker 6 (01:08:07):
So I'm really.

Speaker 5 (01:08:09):
Excited that that's been something that's kind of evolved out
of a lot of the optimized parsing strategies that we
found in arc type, and I think we'll like it's
just such are there, you know, It's just such an
easy drop in replacement for something that everyone's doing already
and just makes everything safer and clearer. So like that
that's gonna be a big one that I'm really really
excited to finally get in people's hands.

Speaker 4 (01:08:30):
Nic script is crazy does yeah, very cool, very cool.

Speaker 2 (01:08:35):
Well, so, David, if people want to connect with you,
since you've been building your social networks, how can they
do that one of the best ways that they can reach.

Speaker 5 (01:08:44):
Out to you, So we could definitely I will not
say to reach out to me on on X because
like of the amount of amount of spam is unbearable
and I kind of like seldom check because it's always
like I have like one hundred messages from bots in
my inbox holder, So don't probably don't reach out to
me there unless you're like tweeting at me or something.

Speaker 6 (01:09:04):
That's fine, So it's solved.

Speaker 5 (01:09:05):
Divide my name backwards or search for like David Blast
on X or arc Type. I like pretty much post
about arc Type every day from the arc type io
account on X and same thing with blue Sky. Hopefully
maybe there's links in the description of this or.

Speaker 6 (01:09:17):
Something like that you can that you can that you
can check out.

Speaker 5 (01:09:20):
I would say the number one way if you want
to talk to me directly is probably on discord. Like
you can find me in the arc Type discord and
you know you can feel free to pay me there.
We ask answer questions or if you want to DM me,
you can definitely find me with whatever fun stuff you
want to DM me with. It's always a good mix
of stuff that people come up with the message when

(01:09:40):
when they want to message you directly, you never know
what you're going to get, So hopefully I'll get something
fun from the audience here and it'll be uh. I'm
always happy to talk about you know, type script types
or any of this like type testing, type optimization stuff
or you know, if you have some ideas about uh
the rej ex type level partser feel free to hit
me up there and I will be happy to engage
in conversation.

Speaker 2 (01:10:00):
Excellent, Okay, Well, thank you so much.

Speaker 3 (01:10:02):
We definitely learned a lot and uh yeah, had a
lot of fun just learning about your process and everything
that went into creating art type.

Speaker 2 (01:10:11):
So thank you so much.

Speaker 5 (01:10:14):
I'd agree, so thanks so much.

Speaker 6 (01:10:16):
Yeah, bye Ron Bye.

Speaker 7 (01:10:20):
Hey.

Speaker 10 (01:10:20):
This is Prestol. I'm one of the NNGI Champions writers.
In our daily battle to crush out code, we run
into problems and sometimes those problems aren't easily solved. NGCOMF
broadcasts articles and tutorials from NGIE champions like myself that
help make other developers' lives just a little bit easier.
To access these articles, visit medium, dot com, Forward, Slash, ngcomp.

Speaker 1 (01:10:42):
Thank you for listening to the Angular Plus show in
Chiecoff podcast. We'd like to thank our sponsors, the NGCOMF
organizers Joe Eames and Aaron Frost, our producer Genebourne, and
our podcast editor and engineer Patrick Kay's You can find
him at spoonful Ofmedia dot com.

Speaker 6 (01:11:02):
Has a intan in it intation

All Episodes

S10 E4 | Validation Via ArkType | David Blass

Episode Transcript

Popular Podcasts

Stuff You Should Know

Dateline NBC

The Breakfast Club

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}S10 E4 | Validation Via ArkType | David Blass