Creating YAML with Ingy döt Net

Justin Garrison (00:01.346)
Hello and welcome to Fork Around and Find Out, the podcast all about forking around and finding outs. Today on the show, we are bringing you all stuff about YAML. And if you don't know, we are gonna have some load-bearing white spaces in this conversation. Try, Autumn, don't take your head. It's okay. It wasn't a good joke, but I tried. So I am excited that today on the show, we have ingy.net's...

a creator and maintainer of the YAML spec and really excited to have you hear how it started, what you've been doing with it, and kind of what the future is.

Ingy (00:39.815)
Thanks Justin. Thanks Adam. Yeah, so my name's Ingy and I created YAML with Clark and Orin Beck. We started in 2001. Those guys were working on simplifying XML, which was going to take over the world around, you know, 1999, 2000, 2001 era and beyond. But yeah, and so they were part of this.

mailing list called SML and simplify XML and then they kind of got sick of it and Clark was a Python guy so he made up something that looked like Python and he called it yet another markup language and YAML and he got yaml.org and interestingly I had I was working in a place called ActiveState up in Canada in Vancouver and they were famous for putting Perl on Windows back in the late 90s and

Yeah, so at ActiveState, they decided they were going to be the enterprise based of open source software, know, back in late 90s. so, yeah, so they got like some of the top guys like the guy, the Perl release manager at the time was Gurusamy Sarati and then the co-author of the Big Fat Python book from remember that one from way back when the O'Reilly book. Yeah, so David Asher and a bunch of other

Justin Garrison (01:59.63)
end of day.

Ingy (02:04.263)
you know, really heavy open source guys and me. I just like it. I've done something cool in Perl and got on the front page of the Perl Journal or something. I saw these guys at OzCon and they had the coolest shirts on like, I want to go move up to Vancouver from Seattle and work with those guys. Anyway.

Justin Garrison (02:20.12)
Cool shirts, how to get into a project. Have a cool show.

Autumn Nash (02:22.147)
what was on the shirts, because I feel like this is important to the story.

Ingy (02:24.935)
Oh, those, they just had good branding after state data. was like, it just said, A. S. and it kind of had this, this is kind of white stripes. Right. Because it had a, was before the white stripes. had a well, black, red and white was kind of the, the color theme and it just looked cool. Anyway, so I moved up to Vancouver and worked there, but at that time I had made a

A Perl serialization thing that looks like Python and it was called data denture for indented data. It was just a CPAN model. You know, it's still out there. says go use YAML instead now. somebody saw this SML project and data denture and wrote an email to the two of us. It's like one line saying, Hey, you guys should meet. So Clark and Clark called me on the phone. gave my phone number. He called me, we talked for four hours and YAML was on its way. just like worked on it every day for the next five years over email. So.

Justin Garrison (03:04.685)
You

Ingy (03:23.367)
I don't know if you knew that, why would you? yeah, Yama was entirely specked over emails about 20, 30 emails a day for five years. And it was,

Justin Garrison (03:34.798)
Now, the original goalie though was people hated writing the brackets of XML.

Ingy (03:40.688)
Well, that was their take on it. they wanted to... People were starting... XML wasn't really made for data, if I may say that, because it was made for textual markup, right? That's actually a markup language. And so they're trying to serialize data with it. And data, even then, Perl and Python had the same hash array, scalar, or single value data model.

and then other languages follow suit. you know, but I caught the JSON data model. so, yeah, so XML doesn't fit well into that at all. You can try to fit.

Justin Garrison (04:20.174)
Where do you draw the line? Where do you draw the line there of like a markup language versus strictly data?

Ingy (04:25.371)
Well, OK, so like, you know, if I say I love Justin Garrison's podcast and I want to bold love, you know, then I would mark up the word. But like in, you know, in data and in Python data side, you you wouldn't really do it that way, right? You do. Yeah, yeah. So Mark, these Markdown another that's another markup language trademark, obviously in the name.

Justin Garrison (04:45.762)
You bold part of your query.

Ingy (04:52.987)
So yeah, after like about six months of working on YAML, I'm like, you guys know this isn't a markup language, right? And they're like, yeah, it's a serialization language, which means, you know, write your data out to disk and read it back in or send it across the wire to some other program, read it back into memory. So we're like, yeah, but we already got the domain name. We already got the name. then I think Orin came up with it. And Orin thinks I came up with it, but I'm like, how about, so one of us said,

Justin Garrison (05:15.298)
you

Ingy (05:21.723)
GAML ain't markup language, you know, it's just the kind of recursive backronym. Yeah, so.

Autumn Nash (05:27.653)
That's so cool.

Justin Garrison (05:28.814)
What was the comparison or possibly competition with JSON?

Ingy (05:34.96)
Well, that's kind of funny. you know, I thought JSON came out in 2006. That's when we all saw it. That's when the world saw it kind of overnight. And it was so easy to implement that the implementation is just like, it's almost like when Tom came out a few years later, you know, somebody put out a spec and made it pretty simple. And then everybody jumped on it. like, I want to be the GitHub inventor as a author of his markup language, which was, I don't know if you ever saw the first spec of that, but it was like,

just a big attack. was just anti-YAML, right? It was like literally said, and then it ended with, and if you don't believe me, you haven't had enough whiskey or something like that. It was just a silly spec at the time. Thank you.

Justin Garrison (06:10.049)
You

Justin Garrison (06:15.854)
You

Ingy (06:24.288)
I was just delivered coffee, so I had to take a sip there. Okay, so.

Justin Garrison (06:30.222)
But JSON was around 2006, you all started this 2001.

Ingy (06:31.911)
Yeah, so right, we started in 2001. And then we looked at it and we're like, oh, that's our flow form looks exactly like this JSON thing. And then we're like, look closer and we're like, oh, it is exactly the same except for three really minor details. between a key value pair, you need a space after a colon and YAML. And in JSON, you don't. But JSON always uses the curlies.

for mappings and it always quotes its keys. It only uses string keys. So we're like, okay, if you're in a curly brace thing and you have double quoted key, then there's not a space isn't required after the coding. So then we're JSON compatible. Is it like a minor thing that we did to the spec? There's three really minor things that we did to the spec. we made, so at YAML 1.1 was out and we went to YAML 1.2. One of the main points of that was just to make

us a superset of JSON or JSON a subset of us officially. And so, yeah, but I look back in history, JSON was started in 2001. So, you know, it's just like, I think we started to get traction within the Ruby language, which I really credit for getting us off the ground. You know, they shipped it with core probably 2003 or fours, so way too early, but you know, they were just, they were kind of new kids on the block at the time and it was pre-rails.

era and yeah.

Justin Garrison (08:03.832)
What were some of the surprises along the way? Like you mentioned getting in Ruby is one thing. I feel like the YAML explosion of Kubernetes has been just, it became the thing everyone loved to hate at some point. And it's just like, we've got to write YAML. Well, it's actually, it's been around for a long time. Like what are those surprises along the way after 24 years of maintaining this?

Ingy (08:13.393)
Yeah, well.

Yeah, well...

Ingy (08:25.479)
Well, Justin, we actually met at at KubeCon. don't remember if you like remember our reaction is like, think it was JJ from IBM and said, Hey, Justin, here's the the YAML guy. And you like raised your fist, like you're going to, you know, hit me in the head or something like that. And I knew you were kidding, but yeah, I'm like that guy. And so this was my first KubeCon was last fall and I'm expecting

Justin Garrison (08:28.809)
Keep going. Yeah.

Ingy (08:53.447)
you cause you get all kinds of hate online rates, like, not a whole lot of love, you know? So it's just like, is going to be terrible, but you know, I'll go on it. That's fine. And, um, and I got some exciting new stuff to share, but I went out and like, you know, besides like you and a couple other people, like, you know, mock hating. was, was all love. was like, it was crazy. I mean, like you've got the people and it's like,

You know, they're kind of excited to meet the YAML guy and get a selfie, some of them, but they're like, you know, they, truly like, I'm like, tell me what you don't like. It's like, I like it. It's great. You know, I trying to explore, um, you know, and there's like, got to be just almost running on 20 competitors to the YAML crown. As it were somebody at KubeCon calling that I didn't come up with that, but, uh, you know, and that's fair. I mean, it's like, there's always, yeah, almost just one way to do things, but, uh,

It seems to be growing popular. So you asked about along the way, the first one was Ansible. you know, all of sudden there was a company whose whole product was front-ended by YAML. That was the first time I'd seen that. I'm like, that's pretty cool. And then, you know, YAML was already like catching on. It's just, it's just kind of, it's, I don't even know what part of the exponential curve it's on. And it's not slowing down. It should be.

but it's not quite yet and there's zero money behind it which is you know it's a good testament but also

Justin Garrison (10:27.074)
I mean, should there be money behind specs? Like that seems like any spec might die if there's money. Like I look at HCL from HashiCorp, right? Like it's their spec that they invented for simplified JSON. And the more and more I see that evolve over time, like I don't think that has the lifespan of YAML because of just the...

Ingy (10:36.518)
Mm-mm.

Ingy (10:49.495)
I could say all kinds of things about it. It's like, don't want to offend Hashimoto or anything. But I find it hilarious. Well, kind of riffing off of, you know, all JSON is VML. And actually there's an attack probably around 2018 where some guys like, there's these edge cases having to do a surrogate pairs or the C1 section of unprintable characters.

Justin Garrison (10:55.916)
I think Mitchell made his money. He's pretty good.

Ingy (11:18.627)
And we're like, OK, we had to get together. have a group of five of us now that are on the core maintenance team. And we got together and we like, and it was a hacker news thread. And so people kept finding little edge cases. And we had to take on, think, five of them. And we're like, yeah, it's only a subset as far as we know. We could be proven wrong. And people come every once in while. And we just turned out on the right side of it is.

a subset, you know, but it doesn't mean I kind of say, you know, by anybody up here who can find that the case where it's actually not.

Ingy (12:02.855)
One beer. but back to HashiCorp. like JSON, if you don't like Hashi, HCL, you can use JSON, which means you can use YAML, but that is never mentioned by HashiCorp. I think it's just like, they're like, we don't, because YAML was well out by the time all this Hashi stuff came up. Hashi, tools are great.

Justin Garrison (12:03.981)
Monday.

Ingy (12:32.219)
But it's like, you you could say that you could use the animal. It's like, this would be people's choice. If ATL is your preferred, then I never try to make technologies that like say, don't use his or hers, use mine. Right? I just say, I put myself out there and use it if you want. So, type of thing. But, so we'll talk about why's, this is how I pronounce the animal script is YS. So it's like a.

Two letter Ys would be pronounced Ys, right? But you can put it on it. So I gave a talk on Helm-Ys, is YAML script applied Helm charts at that talk. And that went over really well. the thing that when people saw a side-by-side comparison of Ys, charts done with Ys compared to charts done with Go templating, which by the way, when you have Go templating in your YAML files, they're no longer valid YAML files, right?

Justin Garrison (13:04.675)
wise.

Ingy (13:31.195)
Not until they're rendered, but wise embedded is like makes them half the size. That's the same thing. And is valid. YAML. So you could use YAML tools in it. Anyway, I'm kind of jumping ahead of that, yeah.

Justin Garrison (13:42.062)
So wait, that gave me a question. So I was a maintainer for a Helm chart for a very long time, and I hated Go templating.

Ingy (13:47.971)
cool. I'm on the helm team now. I have been since November. I meet with Farina and all the guys every week.

Justin Garrison (13:56.182)
It was a Microsoft hackathon that I showed up at, which it was probably before a KubeCon at some point. I went to the Microsoft offices and they're like, we want people to do helm. And so I learned how to write a helm charts. And then I PR'd it to the repo and then I became the maintainer for it. And I maintained it for years. And I was like, I don't use this software. I just used it to learn how to write a helm charts. So hopefully it works for y'all. But it was a thing that I was building. I was like, I don't like this go templating. I don't like templating in general in always.

always kind of has edge cases, right? Like whether it's Go or Python or whatever, right? Like at some form, like Ginges is going to fall apart just as easily as Go templates.

Ingy (14:35.527)
It's an attack vector, certainly in some cases. I took a close look at the Go templating a couple of years ago and I'm like, I can't say it's as bad as I thought it might be. I looked for ways that it could go horribly wrong and I'm like, that's not too bad.

Justin Garrison (14:51.192)
But then you're saying so like, why is a YAML script is an alternative for that helm wise is an alternative for doing Go templating.

Ingy (14:53.881)
Yeah, Helmwise,

Ingy (15:00.089)
Yes, currently it's a post render. You could actually go to search for Helm.YS. anyway, it's a post render such that you can replace a little bit. It'll work with the Go templating, or you could replace all the Go templating. If you replace all of it, then your template files are valid YAML. it's just a, if you were to go to yamlscript.org slash Helm.YS, that page is just a side by side comparison. can see it in front of face.

Justin Garrison (15:29.794)
But let's-

Ingy (15:30.116)
But I'm working with the Helm 14 to make it our first class citizen of without the post rendering factor if possible.

Justin Garrison (15:41.682)
I guess let's take a step back. What is the point of YAML script?

Ingy (15:43.11)
Yes.

Ingy (15:47.941)
Yeah, it's a great question.

It's kind of funny because people like, you know.

Ingy (16:01.873)
People ask me to describe the use case for Uniscript. It's like, well, you have an hour. It's just like, it's like, there's not an elevator pits or I haven't got the perfect one yet, but. okay. There we go. So this year I focused on, wise is going to be focused on helping DevOps. So I mean, there's a wise is a complete programming language with a complete ecosystem because it builds on top of another language.

Justin Garrison (16:07.234)
You

Well, we got at least 40 minutes here, so.

Ingy (16:30.983)
and inherits all of the goodness of that language. There's a lot of great things about it. But where it really can hit a mark for people is to use it in conjunction with whatever DevOps tools you're using. even with that, like so say you had GitHub actions or CircleCI or a couple of that I've played with, even though they don't load YAML files with with Wwise, which by the way, YAML script

ships as a wise CLI. That's one way to use it. And it also ships as a YAML replacement loader in every language, where every is 11 so far. But I have a list of 45 languages that I want to ship this to in the next two years. And they're really simple. It's FFI binding to shared libraries. it's really easy to create the next language I just need. Usually I try to find somebody else to do it. I'm like, you want it on?

This language, actually somebody did that last month at KubeCon. They're like, Hey, do you have crystal yet? I'm like, no, you want to add it? And they did. I got a pull request three days later. So I don't know you've heard of the crystal language. Yeah. So that was really cool. Yeah. and it gets more people involved. try to get people involved in the project that way. But yeah, it's basically think of all the things that people try to bolt onto YAML, right? I mean, what's, what are the major problems with the animals? You have these 5,000 line YAML config files, right?

Justin Garrison (17:35.555)
Thanks.

Ingy (17:58.248)
I mean, it's really great to start your project in YAML where you're using it in a small super clean and then it just starts growing and growing. And then you have these 5,000 lines. What if you could just compose it like you wouldn't write a 5,000 line Python program, right? You break it up into libraries and subcomponents and all that. Why is you can do that easily, right? Or you can use modules from, it's not all 100 % working yet, but I will have modules working from

Either written in Wwise, written in Clozor, written in Java, in... Because those are base things written in Wasm. That's something I've been working a lot on, on different Wasm technologies recently. Or we actually right now we have a system where you can write it in any language, but the linking mechanism is just basically sockets. So it uses local sockets to communicate. it's more of an R piece.

RPC type of thing. basically, as far as you're concerned, you just load the SQL light mights, all that happened to be written in Python and that just works, right? So from a wise perspective. But then you want interpolation. want to be able to take different parts of your data and repeat loops on them. And one of the problems with that with YAML, I'm sure you've heard of anchors and aliases, right? Are you familiar with that feature of YAML? That's where you have to give a label to

Justin Garrison (19:21.39)
Mm-hmm.

Ingy (19:25.891)
a node and then you can reuse it again later in the document. So people will do things in pure YAML. I mean, there's all kinds of frameworks. The one thing about YAML being not quite finished the way we want it to is it opened up the doors for dozens of projects to actually make money by, you know, fixing YAML for their own specific use case. I've always wanted to fix it for everyone. I've always wanted to do, we set up to

You know, even Clark and Orin set out to replace all the XML landscape. So that includes, um, you know, DSL languages, transformation languages, query languages, all the stuff that XML, all the extras that XML came with. Um, yeah. And then by the time we got the 1.2 spec out in 2009, they were just moved on to other stuff and I stuck around, but it was around in, uh, 2023, all the pieces came together where I'm like, oh, this is it. I can make YAML script.

because all the components are there. It was a combination of this closure language, is C-L-O-J-U-R-E, but it's pronounced closer. And it's just a, it's a Lisp that compiles to JDM bytecode, so jar files. And I had never programmed Java before and I'm like, I'm not going to, you know, go down this route, but then there's another thing called growlVMNativeImage that will take any jar thing and compile it to

native binary or a native shared library. And for 20 plus years, I've been looking for the perfect language to write really high level code instead of C and make shared libraries such that I could bind it anywhere. And then this all came together and I'm like, and if you look at the YAML script source code, mean, it's really tight functional code. So, and it produces this whole thing, but then I could instantly, within a few months, I had it bound to six languages, you know, and

I could concentrate on binding it to more languages. always, but it's just kind of go with wherever people want me to take it next.

Justin Garrison (21:32.504)
But the use case is still focused in for like DevOps professionals in that sort of ecosystem where people might be doing stuff with Kubernetes, where there is a lot of YAML, something else on the like CACD pipelines, where it's GitLab or something else where it's like this is defined in YAML as well. And that's those areas because there's so much of it. Is that why you're trying to just, you're trying to attack that as a place that people should be using YAML.

Ingy (21:59.782)
I want to make YAML, like any problems that people have with YAML day to day, YAML script can solve about, you I'd say 90 plus percent of those. my standpoint.

Autumn Nash (22:13.871)
Is there anything that people have ever done with YAML that you weren't expecting, like a use case or just something that was completely out of left field?

Ingy (22:22.727)
Yeah, I mean, and that I love it. Now I want to do it. Okay. So let me give you the example. Um, comments in the YAML spec comments and YAML from the beginning were thrown away. They don't fit into the model. They don't fit into the JSON model. like, and you can put them anywhere, right? In a YAML document. it's like, we wanted to keep comments around, but like now there's probably 50, 60, 70 YAML frameworks out there. That's what I would call a YAML implementation.

different languages. Now there's probably half a dozen ones that will do comment roundtripping, but they all do it differently, right? So at this point I'm like, yeah, we need to actually put out a of a side spec of this is maybe the preferred way to do it. So just thought, this is related. So something huge in YAML just happened.

three or four weeks ago, Gustavo Niemeyer wrote GoYAML. I didn't know this, but it's by far the biggest YAML asset in the world. It's the YAML module that's behind all of Kubernetes. Even the Kubernetes SIGS YAML actually just has all of that code embedded in it because Gustavo, three years ago, stopped maintaining it.

I've talked to Gustavo now and the reason he stopped maintaining it is because he has a very high level job that demands his full attention. It wasn't that he wanted to abandon it, but he just had to. There's no time left in his daily life to work on this anymore. So, and he said, I can't give it away because I don't know if it'll fall into disrepair. And at first that's like, well, why can't you give it away? But you know, after...

Reaching out to him and he's like, well, I could consider giving it to the YAML organization, but it's still kind of have the same problem. So I'm like, well, we'll just take it over and run with it, but not as a, know, you won't give it to us. We'll just make a fork as it were a copy and say that we're carrying this forward. And if you want to, could, it's a couple of weeks away from launching this, but, officially like.

Ingy (24:43.771)
This is the new way to use GoYaml. But it's going to be a huge boon to Go programming and the Kubernetes thing to have all of this unforked. like the Kubernetes SIGs fork is going to use us as it's upstream because, you know, I reached out to them and I'm like, why don't you join us? So they got one of their top guys. You know, I just reached out to anybody who's really involved in this and had a stake in it and was like, yeah, join the team. You know, if...

will never break a release will never break your stuff because you're on the team. You'll make sure it never breaks that kind of thing. So that's really exciting.

Autumn Nash (25:20.335)
That's why, that's why I'm not sure why people are more ready to put developers behind open source projects because having a seat at the table and knowing that you won't get broken and being able to contribute is huge.

Ingy (25:35.078)
Hmm. Yeah. And I was trying to tie this back to comments. Gustavo, when I did talk to him for, he was so busy, we got to talk for 15 minutes. But he said that he had ad comment support to go YAML, which I don't know. And I don't think a lot of people use, it's a, yeah. So comments was something that people just did. you know, I mean, we didn't know what YAML was going to be for back in the day. And we, we made a little list of use cases and anti-use cases and

configuration was in the anti, we're like, people won't want this for config. I I don't know why we thought that at the time and that's all people use it for right now. Yeah. I think we're leaning towards grocery lists. I don't.

Justin Garrison (26:08.206)
Hehehehehe

Autumn Nash (26:11.579)
that's funny.

Justin Garrison (26:18.616)
When I look at the Dammel script homepage, the examples here on the homepage have a lot of colons that remind me of Pearl. I don't know that's a closure. I don't know if that's something coming through, but is there a reason that this, it to me feels like it's different or it's a lot different than.

Ingy (26:28.583)
Collins.

Justin Garrison (26:40.14)
than what YAML typically was. When I first envisioned, when someone told me, when you told me YAML script, I was like, okay, this is gonna be like YAML with some like embedded commands, almost like bash has escape shells, like subshells or whatever. I'm just gonna have some back ticks in my YAML that does something. This feels different with multiple colons and my imports and data. Is there a reason you're going?

Ingy (26:55.162)
I see.

Justin Garrison (27:05.91)
You want it to be a lot different, probably because of, to lose some historical baggage? Is there a reason you want it to look like certain languages were adopted by something? Is there something that inspired you to do it this way?

Ingy (27:18.203)
Well, I know what you're talking about. you'll see a double colon instead of a colon between a key and a value. Well, here's the deal. Every YAML file that you know of is valid YAML scripts, right? And it just does exactly what it did. YAML script will load that perfectly. And then you can use whatever the tool does. can convert just loads of this data and you can convert it to different formats or whatever. But it's a YAML loader at the end of the day.

bang, YS at the top. Then you said, okay, this is still YAML, but like, some of these things might be variables or function names rather than strings, some of the unquoted things. So any mapping array or scalar, those are the three nodes that make up the YAML or a JSON document can either be code or data.

Justin Garrison (28:01.975)
Mm-hmm.

Ingy (28:18.105)
So, you know, if you were just writing a program in YAML script, would be almost, you wouldn't really use data mode unless you needed a clean piece of data somewhere. know, but for the use case that we're talking about where we're helping DevOps stuff, they're starting with their YAML files, but then they want to split it off and then load in a different part, or they want to call a merge function with a specific thing. So double colon says switch from.

The key, is in data mode, the value here is going to be code. And it's going to be a code expression. And there's a lot of really clean ways to do code expressions. But then for the next key, it'll switch back to data mode in my view. So that's why you see, if you look at those lines where you're seeing double colons, you'll see the thing on the left is probably just a string. But it's unquoted because that's the clean way to write YAML. You can put quotes around it.

And the thing on the right is an expression.

Justin Garrison (29:17.998)
Yeah. And the idea here is to allow people to incrementally adopt, right? Like where you say, oh, can take out this one time. have this one variable that I use eight times in my YAML file. It was like, use the name of Kubernetes cluster, whatever it is, right? It's like, oh, I could just store that as a value at the top and then replace that value. So if I need to rename it or reuse this file or load from somewhere else, you can do that.

Ingy (29:36.22)
Hmm.

Justin Garrison (29:45.3)
easily without saying I have to rewrite everything in this new language.

Ingy (29:49.574)
Yeah, let me tell you a little story. and this is really cool. And I've done this with a number of CID systems. So let's take GitHub actions. So a friend of mine had a really hairy set of workflows and I looked through them and I'm like, yeah, YAML script can help out here. So what I did was I first, and there's a number of ways you can do this, but like, let's say you put all of the YAML script files in one directory, but they're going to generate

the original YAML that you had from clean sources, right? So the first step, if I take on a brand new repo of doing this, is I would copy all of the YAML files, which are YAML script, I've already said that, into the new source place. And then I will call YAML script on those to gen all of the files in the place where they're supposed to be. And then one time I will do a, I have a little script that will make sure that they're semantically equivalent.

Was there something about that conversion that made them not be semantically equivalent? Even though they're syntactically correct, they could be slightly different somehow. yep. And then once I've done that, then cleaning up, I just make the sources look as beautiful. I try different things. I'm like, oh, he reuses this a bunch of times. I'm to put this in another file and then include it. He uses all this repeating things. I can make a function by just calling that function 20 times instead of.

Justin Garrison (30:57.858)
Yeah, a checker.

Ingy (31:18.343)
That big blob of data. and, but every time I do this, I'll make a small change and then I'll run the, you know, make update or whatever, however, I, um, the command that I did that will convert all the files. And if there's any diff in the result files, then I've done it wrong, right? I haven't cleanly refactored. So it's just a great workflow. And then I just, you know, you know, I'll just spend like a big whack up time doing this. And then I, you know, I presented it to him he's like, this is amazing. And then he took it even further and.

Really dope, Anna. I'll share that in the comments. I assume there's comments.

Justin Garrison (31:52.408)
We can add a link in the show notes. Yeah.

Ingy (31:54.224)
Yeah, So remind me to do that.

Justin Garrison (31:58.958)
How does that compare to the workflow that someone might have with like Q lang, right? Like I look at Q as a way to generate YAML and I can say, I can take the output. In that case, you're starting from scratch, right? Cause Q lang is a different, it's not necessarily taking in the valid YAML, but I know there's a lot of...

Ingy (32:05.671)
Yeah.

Justin Garrison (32:18.988)
tools and options that people have been trying to do. like, well, I want to write real code or I want to write Python or I want to do something more powerful. Where's that trade off of the YAML script lets you start from what you have and slowly kind of change it over time versus one of those tools where it's like, I can go right to what I think the end goal is of let my engineers write code in whatever language they want and just generate the YAML from that.

Ingy (32:46.183)
Well, I think that you answered the question that you were asking. mean, you were saying if you want to decide to do that, you know, if you're already a Python team and you're on a brand new project and we're going to like, yeah, we're going to write Python code that generates our config.

Justin Garrison (32:59.79)
Oh, hold on a second, you're breaking up for me.

Ingy (33:05.255)
That's

Justin Garrison (33:05.73)
I don't know if your video froze.

Ingy (33:08.845)
That's weird. Let me try something. experiments.

Justin Garrison (33:14.05)
Are you back?

Ingy (33:15.751)
I'm still here. I'm just seeing like a.

Autumn Nash (33:19.843)
I can hear you now but your video is really slow and blurry.

Justin Garrison (33:23.15)
Yeah, your video went real blocky and then I lost all audio for a bit.

Ingy (33:25.745)
So what should we do? What do you, I could leave and come back like that, but I don't know if that would mess you up. Okay. Yeah, yeah, yeah. Sure. We can try that. So we all kill it or just me.

Justin Garrison (33:31.362)
Let's try killing video and see if the audio clears up.

Justin Garrison (33:39.062)
I can, I mean, can kill it too, let's see. Let's see if that audio is good. I hear you much better now. Sweet, let's start, you can start that answer, that question again.

Ingy (33:43.833)
Okay, how's it going so far? Okay, great.

Ingy (33:51.767)
Yeah, I don't remember the question.

Justin Garrison (33:53.614)
starting either with, you know, from where they're at with YAML script and saying, or with YAML and saying, I want to go from, from YAML to YAML script and clean this up or starting with something like a QLang or something else that's is a, is a all from scratch sort of rewrite that generates the same YAML, which can give you the same workflow that you're describing, but in different contexts, right? Where one is iterating in checking versus starting from scratch and checking.

Ingy (33:58.147)
All right.

Ingy (34:11.975)
Mm-mm.

Ingy (34:20.303)
Yeah, so Qlang is, I mean, it's awesome. So I look at it and I look for stuff to steal, right? I mean, that's how you make a good language. You look at what's great and you see if that fits into your language. YQ is another tool that's really great and that uses YAML and does things that YAML script can't do yet. And YAML script does things that YQ can't do.

Justin Garrison (34:29.205)
Hehe.

Ingy (34:51.115)
When I actually ask the LLMs, I'm like, tell me about Q. it's like, here's the advantages and disadvantages. And some of the disadvantages would be that people really are used to YAML and they have to learn this new system. But if you're starting as a Q shop, great. If there was a tool that could turn all of your YAML files into Q, and maybe there is, I don't know, great. That's a free one. Whoever runs Q.

Justin Garrison (35:06.382)
Mm-hmm.

Ingy (35:19.749)
I that idea for free. But yeah, so I, cause I do the same thing. I'm like, you know, somebody told me all the stuff that you're doing is great, but if somebody has YAML files that are 5,000 lines long and they work, they're not going to switch to YAML script. And I'm like, fair. And they're like, unless you give them a tool that does it for them automatically. And I'm like, yeah, good point. So I think I want to make,

YAML is great, but it was extremely limited. The whole point of YAML script is, or why is this that it...

it tries to make YAML as good as, better than Python, better than, thank you, at least for certain things. So, and, you

I know. I have no problem with doing that. Like I said, I'm not trying to compete. I'm just trying to make great stuff. So I was talking to Amazon AWS the other day to a guy in there and I was asking about his products. And so one is the CDK, the cloud development kit. And basically they're doing exactly what you said. They have like

you know, half a dozen languages, that make YAML that, you know, your team might already be familiar with. And I'm like, well, you should throw YAML script. And as one of those languages, you don't have to throw the others out, you know, but I bet YAML script would fit really nicely in there because like, like you said, if you're starting and you already have YAML, you kind of have to, it's like converting anything from phone system another is usually kind of a waste of time in my opinion. It's like,

Ingy (37:08.517)
A lot of companies will switch from like say a language like Ruby to Java or Go and they'll come up with reasons, you know, because they can hire more developers or that kind of thing. And maybe those are true, but it's, know, you have a working system, build the new stuff in Go or Java or whatever, and keep your old stuff working if you really company wise. I'm always, you know,

Justin Garrison (37:41.634)
I feel like my experience, my experience is new things come in from the new.

Ingy (37:41.737)
Do what works. Yeah.

Justin Garrison (37:48.428)
new projects, the new whatever initiative that says like, hey, we want to do the same and we no longer write, we don't like Ruby anymore. We're going to do Rust because whatever reason, right? Like people are interested in it and that helps getting that excitement in a developer that says like, hey, I get to write something new. I really want to work on this project. I don't want to write the same Rails app that I did for the last 15 years or whatever it is, but.

At some point, there's a tipping moment when enough of the new stuff is written in the new language and you kind of lose the ability to modify and change and maintain the old languages, whether because those people have moved on, whether because they just got so kind of kind of old and people didn't know how it worked anymore. That's just like, wow, we got to have, we have one Ruby developer now that has to maintain 18 different projects.

Ingy (38:43.431)
Fair, fair, but like, you know, when you first did the decision, just like, we're not going to be a Ruby shop. We're going to be a Haskell shop. I don't know. I just made that up. you know, we're going to be a Rust shop. Does that mean you have to go and replace every piece of Ruby code, you know, because it's not Rust? No, it doesn't. You know, it's like, you know, I just, I think a really smart CEO or CTO.

builds off of what they have and moves to the new thing. And then it's like, yeah, we're losing all our Ruby stuff. It's like, okay, well, maybe we need to take our more important things and convert them over now. you know, it should never be the goal of a company that's trying to survive and make money and keep their people employed to, you know, replace every line of code from the old to the new. think that's personally.

Justin Garrison (39:36.63)
Well, I don't

Most companies don't decide they're going to be a new type of language. They're going to kind of experiment with it. And then at some point they realize they are mostly writing in that new language with the engineers. So it kind of evolves over time, but I also think that in general, at least with big technology companies or, large companies in general, there's always a state of flux where people are. There's, there's always some re re-platforming or initiative to modernize or move either documentation to

Ingy (39:44.391)
Mm-hmm.

Justin Garrison (40:09.552)
a new wiki, code to a new CI CD, apps to new languages, like that's always happening and things don't ever stay still. And that's not necessarily a bad thing, but there is just always this like constant busy work that happens of none of this is making us money. This doesn't.

Ingy (40:27.129)
It can happen that way. mean, all you said is valid, but I think there's also times when you get a new CTO and he has to make a name for himself. So he's like, we're going to switch all of the developments of this. that's the kind of thing that I think is, you know, then, yep, exactly. Thank you, Adam.

Autumn Nash (40:41.561)
Yeah, empire building.

Justin Garrison (40:42.946)
Yeah. Well, they make that big impact to earn their giant stock piles.

Ingy (40:50.008)
Exactly, right? Right, right.

Autumn Nash (40:51.033)
Well, it also seems like right now people, were big tech companies are almost pushing like organizations or companies as a whole over to whatever they decide they want to maintain. know, Amazon used to be really Java heavy and now they're pushing JavaScript really hard and rest, which I mean, rest is a good language for a lot of things, but it seems like they've picked what they want to invest in and kind of keep it going. So.

Justin Garrison (41:18.83)
And usually that involves some sort of vilification of the old, right? Where you're like, oh, you're doing Java still? That sucks, right? You should be right in rest now because it's safe typed and whatever, you know, like, like all the memory safety benefits and things that they can claim is like, you have to get to the new thing.

Autumn Nash (41:36.144)
Well, sometimes it's bullying through like documentation, which I don't think they're doing that. I think Amazon will always be a Java shop, but I think for the new infrastructure, all of the documentation, well, not all of it, but a large majority of it and a large majority of the examples are being done in JavaScript. So that's kind of the option. You know what I mean? Cause there's so many examples in it that it's almost pushing teams that don't even

normally use JavaScript to do it for infrastructure, just like for a long time they were using Ruby for infrastructure. That always confused me.

Justin Garrison (42:12.312)
That probably is.

Ingy (42:12.391)
What do you think is the biggest money making language in the world right now? I have a possible answer.

Autumn Nash (42:24.835)
I think languages make money in a weird way though. Like a lot of times it doesn't make money, it saves you money on compute and optimization.

Justin Garrison (42:24.92)
I-I-

Justin Garrison (42:31.756)
Well, and you mean which are you just talking about like generally like which apps are written the most that make the most money like

Ingy (42:36.133)
Which software in the world making the most money? What language? Yeah, I think it begins with a C. I, yes, I was going to, so I told you about the person I met at KubeCon who wrote the crystal binding for JavaScript, right? I mentioned that. so, yeah, I found that later.

Justin Garrison (42:40.076)
Yeah, I feel like that's gotta be C.

Justin Garrison (42:49.496)
Cobol. Yeah.

Justin Garrison (43:01.41)
Mm-hmm. Yeah.

Ingy (43:05.991)
that she's a rock star at Red Hat working on IBM mainframes and she pointed me at an article. I can link to this article. It's a quote from IBM and so you've got to wonder how they got the numbers. But if they're close, it's amazing. 68 % of production workloads are running on IBM mainframes and of the entire cost of all production workloads that they account for 6%.

So you're like, what the heck? How's that possible? Well, COBOL is the language of government, big pharma, medical, and banks, And insurance. So the biggest industries in the world that are automated are running these old systems that still work and they have to keep them working and they don't break and they don't have any exposure to the internet because they run on systems.

that were pre-internet so that they don't get attacked, that kind of thing. So it's really quite interesting that like a, I found this out while I was at a, so, you know, being around from 2001, I was really big in the Perl community. And to a degree, I, you know, I still, that's my family, right? So there's a core developers meeting and it's in Europe every year they have in the spring.

the Perl toolchain summit and I was over there and I was like, hey guys, know, Perl was made to run, I just counted today, 25 different architecture platforms. Like we don't even have that many platforms today, you know, but it was made in 87. So it was ported to almost everywhere. And I was like, do we still have access to, you know, IBM 360 architecture, which is now called 390? Do we have those machines left? Because we had test machines for all this stuff.

They're like, no, we lost them a few years ago. And I'm like, I think I know somebody who can get us access to those. But in the back of my mind, I'm like, that would be cool to test on those things again. what if Perl became the darling language of, know, because the new COBOL mainframes I'm talking about, they've now made them run Linux, Kubernetes, seriously, all these modern things, they're getting working on IBM mainframes. What if

Ingy (45:28.017)
But not a lot of languages, other languages, are targeting that. So what if Perl became the darling language of the COBOL mainframes again? I don't know. I thought it was quite an interesting possible fairy tale. So we'll see how goes. I actually met with that working group this morning for the first time to talk about how we get Perl working full on with IBM stuff again.

Justin Garrison (45:57.344)
I think the IBM testing goes through Oregon State University, which has mainframes. And I remember just seeing that they were at risk of being defunded. Did they get the funding? Okay. I know.

Ingy (46:04.613)
Mm.

Autumn Nash (46:08.815)
Yeah, they just got enough funding, I think, yesterday. Yeah.

Ingy (46:11.527)
Oh, wow. I was told that in Seattle here, there's a big mainframe center in South Seattle. then, you know, a guy on the call today, he said he has access to one of these old systems. I'm like, where is it? like, it's in Dallas somewhere. And then, you know, I applied to this Red Hat, you know, you can sign up for it to get access. And yeah, there's like different people running mainframes. And some of these are brand new, like mainframes. you know, people carrying, it's like a big laptop, you know.

Justin Garrison (46:37.933)
Yeah.

Ingy (46:41.733)
Mainframes used to be like big room size things, but now it's just like plugs in into a.

Autumn Nash (46:47.715)
Also lot of military and government run mainframes.

Ingy (46:50.21)
yeah, I left out military, my gosh. Yeah, yeah, of course. It's like.

Justin Garrison (46:53.71)
Yeah, there's some.

Autumn Nash (46:54.531)
I always wonder if that's like if Java will hold on the same way that Cobalt does or if Cobalt is just so big. Plus isn't tape getting really cheap also?

Ingy (47:04.593)
That's funny, tape. Did you say tape? Yeah, we used to ship out, and I used to do mainframe assembler in the 90s. We used to ship our releases on tape, and we used to ship our updates in a mailing, a paper mailing, and we'd send out, yeah, just if you want to fix this bug, just change these lines 46 through, you know, whatever. We'd give line numbers and lines of code of like, you know, just.

go change these files because we shipped the source because like it didn't really matter if you stole the source you'd never have the the machines to run it on right you know it's like it's such a different world anyway

Autumn Nash (47:43.94)
I was reading an article about somebody who used to work on mainframes, they were a TPM and just their kind of outlook on how like AI is changing everything, but how like everything changed from like mainframes and then, you know, like server servers and clouds and all that good stuff. Well, I mean, I guess they're the same thing, but you know what I mean? Like the kind of revolution of like how we use things. It was really interesting.

Justin Garrison (48:12.794)
You mentioned briefly about possibly helping people convert their YAML to YAML script. Is that something that you're looking into? Is that something that you think is going to be, we can take this giant 800 line Istio thousands of line Istio YAML Kubernetes file and convert it into YAML script.

Ingy (48:19.206)
Hmm

Ingy (48:34.471)
Yeah, mean, yes, I'm thinking about it, like, you know, in the last, like this, you know, in 2025, I'm like, already got my fingers into like, got into Wazom, said, to, you know, since KubeCon London into MCP, agentic AI stuff. So it's like, you know, if, I think it might be important to experiment with, can you have YAML script?

MC, MPC service sets that like, you know, some of this could be LL driven. It would be really interesting to see if that was a possibility. But yes, of course, if there was like, basically I work on a need basis right now, right? You know, it's like, if people would be like, yeah, I would use this, but, it's a problem converting that, you know, and go down that alley or like, you know, definitely try to find people that would want to work on that. there's, there's so much cool stuff to.

to do with Wyze. mean, it's just like, and with all these new technologies. Yeah, it's exciting. I made it. I'm like, I gotta write a list because I have scraps of paper everywhere down. I wrote a list of these are the kind of biggest projects I'm interested in. And I thought it would be maybe a dozen. It was like 26 as of this morning.

Like, the one cool thing about Yellowscript is I got so focused on it, I spent like 18 months, you 12 hours a day. just like, and I loved it every minute of it. Took all of last year off. Yeah, now currently.

Justin Garrison (50:12.142)
You've doing technology for a while now. How did you kind of stay interested in technologies from the 90s? I mean, it's been what, 30 years now? have you been doing the same thing of just finding something interesting and scratching an itch or are you...

Ingy (50:17.703)
a long while.

Ingy (50:35.399)
Every day, I mean, it's just like, well, I made two important decisions. like, don't get a big mortgage and don't. I broke one. I got married for just a little bit, but like, don't have kids. Don't have pets and well, Ashley, my partner, she's we have plants now, so but she keeps them alive, not me. So, yeah, you know, I mean, I like.

You know, like, what is that line if do stuff you love and you'll never work a day in your life? It's just, yeah, it's just like, like, you just take inputs and you're like, I don't know, it's still fun to me. I don't know why maybe I'm just kind of a simple person.

Justin Garrison (51:20.258)
Has there been any patterns you've seen that have been different for what's been fun?

Ingy (51:28.92)
yeah.

I see more patterns that keep it in similarities. It's like always, you're not going to be super excited about what you're doing five years ago. Or maybe it morphed into something, right? You're like, yeah. Because I feel like a lot of the ideas are based off of other ideas. it's probably all stuff I learned when I sat next to this guy who was super into

DRY, don't repeat yourself, programming. And it's just like, I got my mind and I'm like, okay, this isn't dry enough. How do we make it dry? It's just like that. And then you just like riff off into these wild frameworks and solutions. And yeah, I think I wrote the first on JavaScript templating language. It's called Jemplet back in 2006. There wasn't anything that, and the cool thing about it is it actually compiled to.

JavaScript so you could have these template files and then you compile them to JavaScript and JavaScript as pre node, right? It's just starting to catch on like doing clean JavaScript in the browser instead of just horrid stuff, but yeah. I don't know. And then somebody took that idea and ported it to like Lua and called it Lemplet or something like that. It's just like, yeah, I don't know. It's a...

It's kind of a wild ride, I do feel like when I saw wise, like, this is it. This encapsulates. That's why I said it's really hard to describe all the things. Here's some interesting things.

Ingy (53:12.751)
I just noticed one day I'm like, it'd be really easy to use the tool chain that compiles closure into a native binary since YAML script compiles the closure and then evaluates it. What if I just take any YAML script program that you haven't wrote and you just say, know, YS tech tech binary that file and it just creates a native binary for you, things like that. So, but also what if you could write

It's kind of that shared library. was like, know, YAML script is even higher level, I feel like, than Clojure. Clojure I kind of think of as my assembly language. Sorry, Clojure does, but that's how I see it. Because Lisp is a really normal type of way to generate code in, right? It's hard to mess up. Just keep your parentheses balanced, and you don't have to worry about much. So it's great that way. But with YAML script, I try to make it a...

I just program it in a lot. And if I don't like something, it doesn't last long. And I know that you've only seen a couple of examples. The Helmwise stuff are kind of focused in a certain way. But if I were to show you some other code, it's like, actually, I have a YAML script program that will take a

Okay, so there's a site called exorcism.org. Do know that one? It's a free language learning site. It's great. It's um, it's like exercise is um, so it's exorcism not exorcism. Um, and it's it's great. It's free. It's uh, volunteer driven. It's been around for a long time. They have 75 languages. One of them is YandleScript. So I took all of last summer. It's a lot of work to get a language learning track, YandleScript onto exorcism.org.

And this is where we cut because I was like.

Ingy (55:07.353)
all right. Sorry. I have to cut that out of it. But I think it's been going pretty good otherwise. Okay. So, yeah, so there's also something called Rosetta code. Are you familiar with Rosetta code? Okay. I actually like have met Mike. Well, something happened this morning. Rosetta code went down. It might be down right now if you check. And I reached out to Mike and I'm like, hey, your site's down. And he's like, yeah, this is what's going on. I'm like, I think I can help you when I get done with this.

Justin Garrison (55:21.038)
Yeah.

Ingy (55:37.105)
you know, for.

For can find out podcast I'm So that's what I'm going help him get that back up. If it's not up and running right now. it's a domain registrar thing anyway.

Yeah, so I wrote something in 2012 or something. I scraped all of Rosetta code. it was like, and I do it like every, whenever I think about it, you know, it's not a prompt or whatever, but I like, it's about 120,000 individual program files. It's like, I think they're coming up on a thousand languages, 950 plus languages against 1500 programming tests in a matrix in a media Wiki, really janky, but like also pretty cool. it's, um,

You know, there's a Rosetta code data project on GitHub where you can just clone the entire thing. And, so I took, I wanted to make sure that my exercise on solutions to, they have like 150 standard problems that you know, are exposed a different amount in different languages. Python has a ton and you had to have 20. I have 60 or YAML script has 60. So I wanted to take these programs and compare them to.

code written in other languages. And so I wrote a comparison program in YAML script that would, you know, just basically make a GitHub gist. And you could do a little collapsible sections in GitHub. it's with, you know, 74 other languages comparison, and then it shows the number of lines of code and like, how do I compare against Fortran or Go or Haskell or some really odd ones. anyway.

Ingy (57:24.583)
So that was a lot of fun. I just, I'm like, I don't have to be the shortest program. It's not golf language, but I just want to make sure that I'm in the right realm of, this a good working language? Is this how I would expect to program? And I think it's quite close to that. I used to write a new YAML script program and I would.

come up with 20 things I wanted to change. Let's just look little things and now I, know, every once in a while I'll find one or two. So.

Justin Garrison (57:55.118)
What do you think the next five years of YAML looks like? If we go ahead, it's 2030. Where do think we're gonna be?

Ingy (58:02.523)
No.

Ingy (58:07.975)
Yeah, with, I don't know, it's such a wild time, you know? Like I'll keep pushing, like I think YAML script is the future of YAML. And I'm just gonna quickly explain why. So, because here's the problem with YAML is it's a giant spec. It's very, very detailed and very easy to get wrong. And in fact, we have a YAML test suite and in 2021, not a single language passed the test suite and it wasn't even.

Justin Garrison (58:12.557)
Yeah.

Ingy (58:38.117)
It was just the start of a test suite. So it's like all of these implementations, they work good enough in their own language, but they just have all these little edge cases or minor discrepancies. So they don't really work good between each other. And that's what we originally signed up for. At the same time, we wanted to put out the next version of YAML 1.3. And we have a bunch of ideas of what we would do and even ways to do that without breaking the world.

The problem with that is you put out a new spec version and it's taken people like years to just make the ones that they had. Nobody's ever going to implement your next version of YAML. It's not something anybody wants to do. But what if there was one YAML loader that worked the same in every language, shipped to every major language that uses YAML. And the day that 1.3 or whatever the next YAML version spec version is, it was ready to go. And it was full featured, did comments like we were talking about, did

Justin Garrison (59:15.288)
Mm-hmm.

Ingy (59:36.985)
everything and if there's a bug in Python, it had the same bug in Ruby and that same bug fix made by a Haskell person would affect that same person's bug in Java, right? They'd all be the same. So...

Whereas I you know, maybe the spec wasn't the best way to make you know, maybe it's a spin

I don't know, implementation. don't know. I say both, right? So it's like, I'll make the spec, people can still implement it. And I don't think YAML script will be the only implementation to use, but it will be the one that will evolve and be the most correct with YAML for all languages. So I think that's really important. Even without the scripting, there's another, there's, can turn off all the scripting capabilities of YAML script. You know, obviously.

You don't want to expose some of the things that it can do, like make web calls, database calls, whatever, or access file systems or parts of file systems. Yeah, that's all configurable by either by both the user and by the consumers.

Justin Garrison (01:00:48.632)
Well, Engy, thank you so much for coming on and telling us all about the past, present, and future of YAML. I think it's been fascinating not even realizing that most of my career has been evolved around YAML in some way, because I was writing Ansible pretty early on. Even SALTs for config management was YAML based. And while there was always this Python or JSON sort of bits and...

Ingy (01:01:06.125)
Mm-hmm. Yep.

Justin Garrison (01:01:16.136)
other pieces it was all a subset of yaml in some way so that's really fascinating.

Autumn Nash (01:01:22.295)
It's really rad, I didn't know YAML powered so many things.

Ingy (01:01:26.213)
Yeah, I didn't either to be honest. mean, like, like when I went to KubeCon and just saw the amount of YAML in the world, just kind of messed with me a bit. It's a bit crazy.

Justin Garrison (01:01:42.066)
Where can people find you online? there a place that you want people to find you online?

Ingy (01:01:46.689)
Absolutely, I'm like always, I can use another friend. Yannelscript.org slash INGYDOTNET. We can put that down in the links. This is the page of all the ways to contact me. So, it doesn't have my address, but if you ask me, come over and we'll do a barbecue or something.

Justin Garrison (01:02:04.248)
Perfect.

Justin Garrison (01:02:09.998)
Perfect, we'll have it in the show notes. Thank you so much. Yeah.

Ingy (01:02:13.159)
All right. Thanks, Justin. And thanks, Autumn. It's been awesome. And you guys do a really good job of making a podcast flow really well. really enjoyed doing this with you guys.

Autumn Nash (01:02:26.789)
Thanks for coming on the show.

Justin Garrison (01:02:29.196)
Yeah, we're just nerds that are interested and so it's fun. It makes it really easy when there's an interesting topic.

Ingy (01:02:35.195)
When am I gonna, let's see, when am gonna see you again? Are you going to, you guys got all the coupons? Are North America's at least?

Justin Garrison (01:02:42.666)
Autumn only wishes. She doesn't tend to go to the cube cons.

Autumn Nash (01:02:45.421)
I wish so hard and then all my friends have fun without me and then Justin sends me pictures. It's so, it's, it's cruel.

Ingy (01:02:51.111)
That's so cruel. That's cruel, Justin.

Justin Garrison (01:02:52.174)
I will be at KubeCon North America in Atlanta. Yeah, that's in November. So I will be there. Sounds good. Thank you everyone for listening and we will talk to you again soon.

Ingy (01:02:56.793)
Atlanta.

think I'll be there too, so let's hang out. All right, take care, guys.

Ingy (01:03:12.264)
And.