🌳 Roots & Trees: OpenRoot, and Cedar to the rescue for access control
This show is supported by you. Stick around till after the news to hear more about that and our new Patreon members and one time donation. This is Cup of Go for November 1, 2024. Keep up to date with the important happenings in the Go community in about 15 minutes per week. I'm Jonathan Hall.
Shay Nehmad:And I'm Shay Nehmad.
Jonathan Hall:Happy Halloween.
Shay Nehmad:Did you have a good week of, playing Factorio Space Age and trying to lie to your bosses that you're actually working like the rest of the engineers in the world. Not me, of course.
Jonathan Hall:Hey, look. I barely saw that. That would never happen.
Shay Nehmad:No. I I worked my ass off. But if you are one of these people, oh my god, isn't the expansion great? Sorry. I'm nerding out about Factorio.
Shay Nehmad:This is not a gaming show.
Jonathan Hall:It's not. It's not. But it yeah. Because we use Go, and you can't write games in Go as everybody knows. Right?
Shay Nehmad:Starting with the flame bait right at the top. We
Jonathan Hall:got corrected about that when we said that before.
Shay Nehmad:Hello, everyone. Welcome to our, weekly Go news show where we do some news, then we do an ad break, then we do an interview. This week, we have a super interesting interview with, Justin McCarthy from, strong dm about Cedar. You're into, like, authorization or cyber security or anything like that, language design, you should definitely definitely stick around. But let's start with the news.
Shay Nehmad:Right? Meetups. Let's do meetups.
Jonathan Hall:Let's do it.
Shay Nehmad:So usually we do a a round of like, hey, there's a meetup here, there's a meetup there, that date, that date. If you're really really into meetups, you're like going or maybe you're even an organizer or you thought about it, the Go remote meetup, needs someone to step up as their meetup organizer. Peter Leonce pointed it out to us in a different Slack group called brands, and I don't know how I think about that. The Go remote meetup group as a general is not one I interfaced with. I don't know if you ever went to one of their meetups.
Shay Nehmad:Well, went. No. Quote unquote went.
Jonathan Hall:I didn't even know it was a thing. I I wouldn't be surprised if this sprung up during, COVID or something like that. And, so, yeah, I don't know how active it's been, but I I could imagine it being really valuable, especially for folks who are in more rural places where there's not a in person go meetup. I could be see it being really valuable. So I just wanted to bring it on the show and see if somebody wants to step up and, you know, organize that.
Shay Nehmad:Yeah. Just just to clarify what that means is you need to host events, online as often as you want. You need to encourage members to participate. It's not easy to get people to come, but it's very hard to get, people to do talks, and it's really hard to find good talks. Like, it's not easy being a meetup organizer as well.
Shay Nehmad:You're have you have a lot more experience in that than I do, Jonathan. Right? Yeah. I've been Amsterdam thing.
Jonathan Hall:I've been the, co organizer no. I guess I'm co organizer Emeritus of the Amsterdam, meetup. But I I think it's worth pointing out that this, group is a member of the Go developer network. We had, Wilkin Rivera on the show back last September, a year ago. I was talking about that.
Jonathan Hall:So they already have the support of the Go Developer Network, which can help you with a lot of these things, finding speakers and so on and so forth. So it's not that you're doing this you're not flying solo if you take this on. You do have some
Shay Nehmad:support. Do you remember that, scrub sting? I can do this all on my own. No. I know.
Shay Nehmad:I'm no Superman. Well, anyways, if you wanna organize the gory mode meet up, you can step up. I think it's an interesting opportunity. Like, it feels, if you're an engineer, it feels like these sort of step up opportunities. Something I would recommend to one of my employees if I wanted to, like, make them a Go senior developer.
Jonathan Hall:And it'll definitely look good on your CV.
Shay Nehmad:For sure. Also, it's a lot of fun. Yeah. Really a lot of fun. Every time I had to step in to do something small at a meet up, like, oh, can you grab the pizzas?
Shay Nehmad:Or, oh, we have a missing talk. Can you find someone to fill in? There's a lot of excitement there. You're sort of both of organizing and you you wanna please the people and you feel, like, very, oh, I'm in charge of something important, like, educational and community and things like that. Anyway, a cool opportunity.
Shay Nehmad:We really hope they find someone good.
Jonathan Hall:Yep. Let's talk about some proposals.
Shay Nehmad:Yeah. We have interesting ones.
Jonathan Hall:Yeah. We have a couple, old news ones updates. First one is the s log dot discard handler proposal has been accepted. I'm excited about this, because it's gonna save me writing a longer one line. I can now do it in a shorter one line.
Shay Nehmad:What is the s log discard handler? We already talked about this, but
Jonathan Hall:We talked about this, yeah, a few episodes ago. We'll hold a link in the show notes if you wanna hear the full description. But, if you're using the structured logger and the Go Center library and you just wanna discard your logs, typically for testing, it's easier to do that. It will it will become easier to do that now. You just call s log dot discard handler and your logs just go into the bin rather than trying to pipe them to dev dot null or devnull or something like that.
Shay Nehmad:Just to clarify, they're not going into the bin directory. No. They're going into the trash.
Jonathan Hall:The trash bin. Yes. Yes. Yes.
Shay Nehmad:We have another update. Right?
Jonathan Hall:Yeah. Another one that's been accepted. We just talked about this one last week, is the Go Cash prog making that, an official non experimental feature. If you didn't hear the episode last week where we talked about that in detail, link in the show notes. But that's been accepted, so I'm not gonna go into that one again.
Shay Nehmad:It is cool to see that, you know, they put it in the final comment period. Seems like a lot of people tested it in in Golegsea Island and things like that, and nobody reported any bugs. No change in consensus. Accepted. Really cool.
Shay Nehmad:Stuff works.
Jonathan Hall:That's awesome.
Shay Nehmad:Yeah. So these are, accepted ones, so you should now you can just sit around and, look forward to them. We wanna talk about ones that are still open. The first one is safer file open functions. And if your memory is tingling, it's because we talked about this 20 episodes ago, the episode with Ashley Jeffs.
Jonathan Hall:This is Cup of Go for June 7, 2024. Keep up to date with the important to have things in the Go community at about the end of the week. I'm John Paul.
Shay Nehmad:There's a proposal here from Neil, Damien Neil, to add some safer file open functions to OS. You know, there's a big class of vulnerabilities around files. I think the most common one is, you wanna serve files from your HTTP server. Anyway, it's been moved to the final comment period. They likely accept as well, and I really, really like the API.
Shay Nehmad:Root represents a directory and there's implementation for Windows and JS and Plan 9 and like, definitely seems like a lot of thought that went into it. Then you can open a directory that's called root and then you can do things on that like create, open, close, make dir, make dir all, remove all, chown, chmod, like everything you'd expect and it's all safe. So you can't jump through relative, path names and attacks and things like that. So you define the root of where you want people to operate right now if you're opening a file server. Right?
Shay Nehmad:This is the root of the current operation right now. It sort of reminds me of like, dockering or or containerizing a thing. If your application doesn't wanna run-in a containerized environment, you just want to prevent these sorts of attacks, a really really good way to do it. And I wouldn't be surprised if Golang c I lint is not is gonna start reporting on unsafe usage of file dot open use, you know, the root directory instead.
Jonathan Hall:Oh, it already does and it drives me nuts.
Shay Nehmad:It drives you nuts and it's right.
Jonathan Hall:It's right. But it it there's not a clean way to fix the half of the half of the reports. Like, if you're using GoSec, it tells you what you may be opening an unsafe file, but there's not a a good way to solve it. There finally will be. So I'm excited about this too.
Jonathan Hall:And I also love that they like if you if you start reading at the top, the API they suggest is kind of cumbersome and clunky and weird. But if you jump straight at the bottom, like you said, I like the new API. It's very different from the original proposed API and much better I think.
Shay Nehmad:Funnily enough, very unlike Go, I think the first design is very much, Go ish, where it's just functions, not like object oriented things. But file systems are where object oriented, like, very lean object oriented design usually shines in my opinion. And this is a really good case. They define the struct called root and then they defined all these methods on root and there's like new root. It's called open root, but whatever.
Shay Nehmad:Really really good design. I like it a lot. I also think it would be fun to implement because I assume all the security researchers in the world are gonna try to find a hole in all these, implementations. Like what happens when you do make d roll in, and then schmod and then dot dot and then make d roll again and then dot dot. Does that count as a root escape or not?
Shay Nehmad:Like, you know what I mean? Mhmm. Very very cool proposal. It's still likely accept. So if you have a comment about the API or if you wanna comment and, propose some ways to try to fight this, from a security perspective or or you think there's some possible vulnerabilities or you wanna give example of prior art in other languages that you may know, etcetera, etcetera, etcetera, I would definitely recommend jumping on this conversation.
Shay Nehmad:One thing that that tingles my spider sense is that there are a lot of file systems in Go. Like, you can embed a directory using Go embed, right, and then treat it as a file system. I was at a lecture once where someone, spoke about you they wrote a Go file system that represents git. So you do git operations via FS, the FS, interface where commits are like, branches and then commits and then files are parts of, the path. Moving these to using the open safe, like, the these not real, file systems that are file systems but are not classic file systems might not gel super well with this.
Shay Nehmad:But I don't know, maybe they maybe they do.
Jonathan Hall:No.
Shay Nehmad:I I I haven't implemented the file system yet.
Jonathan Hall:Yeah. I I haven't either. That's It's
Shay Nehmad:a very cool proposal. Final comment period. Final comment period. Put in your, thoughts now. And there's one active one that you read about.
Shay Nehmad:I'm really excited about it. I haven't read about it. Teach me about it.
Jonathan Hall:Yeah. Yeah. So the proposal is to cache link output binaries in the build cache. Probably just requires a little bit of explanation. So we probably all are familiar with the go build cache, which is one of the reasons compiling is usually so fast, especially if you use cgo.
Jonathan Hall:You may have noticed that the first time you build something that has a cgo dependency, it takes a while because it's building all this c stuff and that's not so fast. And you may notice if you look at your PS app, but you see c the c compiler or c plus plus compiler running in the background. But on subsequent runs, it's much faster. Well, this proposal is about caching the final linked binary as well. You're wondering why would that be beneficial, aren't we already caching the intermediate steps until the final link is pretty quick.
Jonathan Hall:The primary use case of this would be for go run. So if you're running go run either maybe in a go generate statement or as maybe your Docker, or maybe your
Shay Nehmad:CI jobs sometimes do their own.
Jonathan Hall:CI jobs or whatever. You you use Go Run. Maybe you have a tool that you're, that that you execute through Go Run. This would help, cash that final output step. So your Go runs would be faster.
Jonathan Hall:So that that's a proposal. There's been a lot of discussion on here about when would it actually be useful, when would not be useful. Should it apply to Go test as well? Because you're doing essentially the same thing? It seems like this is still in common period.
Jonathan Hall:So there's a lot of opportunity to get in here and weigh in if you have an opinion on this. So the way the conversation seems to be going, is toward the idea of doing it just for go run, not for go test, not for go build or go install, which is probably where the most benefit would come from without overhead of adding these very large, objects to your cache. So, yeah, it's an interesting discussion about how long should things live in cache, which things should be cached, which things should not. If you have an opinion, go weigh in on the conversation.
Shay Nehmad:So today we already cache, packages, but not the final binary. Right? Like the link stuff. Right. But the final binary might be super big.
Jonathan Hall:Exactly.
Shay Nehmad:What if I embed a lot of stuff into it or I don't know. It's just big. Uses a big library. Won't the cache just take up a lot of space?
Jonathan Hall:That that's absolutely one of the concerns brought up here and why they would not do it for, things like go build, or go test.
Shay Nehmad:But I guess if you're doing go run, you're writing the, binary to disk anyway. So Yeah. While it is well, that's interesting. Like any cache, feature, I'm immediately, like, wait, but where are the bugs? Yeah.
Shay Nehmad:Do you see any obvious like pitfalls that this might, cause?
Jonathan Hall:I think the the caching algorithm itself is pretty solid. So it's not really a question of bugs per se, it's more a question of weighing trade offs. The speed that you get from caching versus the size of your cache and and potentially caching things that are only ever used once and therefore wasted space.
Shay Nehmad:Cool. We really have a lot of things to go through and we wanna mention all of them, so we'll go to the lighting round. Lightning round. First up on the lightning round, I wanna highlight a really great blog post. I wanted to talk about it forever since it came out.
Shay Nehmad:Kind of said it's relegated to the lightning round. We might talk about it at length once I try it out at work, but Go test parallelism. So it this blog post in a nutshell by Robert Lasek visualizes how Go tests run. So it puts it on like a time graph and you can just look at when your tests are running. Ideally, all of them begin at the start, right?
Shay Nehmad:And then your test suite is just as long as your longest tests are. But in reality, Robert ran it over at 3 dots labs and he saw like a a long waterfall where you see like really unoptimized web pages that have these long waterfall network connections, grab a JavaScript, then grab react react, react grabs Astro, Astro grabs view, only then you can view your page, this sort of thing. So if your tests are slow or if you wanna make them faster, check out this blog post. It's the thing I'm passionate about, developer experience, things like that, looks really really cool and is relatively detailed. I I just haven't gotten around to trying it yet.
Shay Nehmad:I will update when I do though.
Jonathan Hall:I have a lightning mention that's a little bit different than we've ever done before. It's not really technical, but it's go related. So I hope I say her name right. Alcione Ribeiro, I don't know. She lives in Germany apparently, but it looks like it might be a Portuguese name.
Jonathan Hall:I don't know. But anyway, she has created a crochet pattern for a gopher using a Japanese technique called amigurumi. I don't know what that means, but I I would call this plushies as code. Because
Shay Nehmad:a few feces a few feces in, in California just woke up and are like, something else is code. Here's $15,000,000 in funding.
Jonathan Hall:She has a GitHub repo with the crochet pattern and photos of her pink, crocheted gopher. I I am going to crochet a gopher. I'm not sure when I have to move to my new house in first, but I'm gonna crochet a gopher, and I'll put pictures of it on the channel when I do. I love this. So thanks, Alcione.
Jonathan Hall:I hope I said your name right. Thanks for sharing this to the community.
Shay Nehmad:I'm I'm really interested in the syntax. You have, like, 1234569sc below 3sconeincopenparens3xclosed params.
Jonathan Hall:Hey, it makes sense to me. I know crochet, but,
Shay Nehmad:Oh, do you?
Jonathan Hall:I do. Yeah. I've crocheted before.
Shay Nehmad:Cool cool cool. But what is the syntax of exclamation mark exclamation mark exclamation mark remember to fill the polyester fiber before finishing the gopher mean?
Jonathan Hall:If you can't figure that one out, Shai, you're helpless.
Shay Nehmad:I might let my wife, do that one for me. Oh, listen. The I I just scrolled down and her crocheted, gopher with the 3 d printed Wonder Woman assets, like, the shield and the tiara. Mhmm. Dude, this is really cool.
Shay Nehmad:Well, if you're the creative sort, you're into crocheting. It's for you. That does it for our, news segment this part. Stick around for a short ad break and a super interesting interview with Justin McCarthy of StrongDM. Welcome to our ad break.
Shay Nehmad:Brief, recess here between the news and the, super interesting interview coming up. Thanks for listening to our show. This week we've gotten a lot of support from our community. We have 2 new Patreon members, Stephen Clark and Kamal Akayoun. I hope I'm saying that right.
Shay Nehmad:Thanks for, becoming members of the, Capo Go Gophers over at Patreon and supporting us financially. This is a hobby. We do it for ourselves. We're not making money off of this but it's a rather expensive one. We pay for hosting, pay for our time obviously and editing.
Shay Nehmad:So this is just the best way to support what we do here. Head over to patreon.com. Oh, I don't know what the slash thing is. You know what? Head over to cupago, dotdev and you can find all the links there.
Shay Nehmad:Also, a huge thanks to, Remi Zentwykaj, I hope I'm saying that right, I'm probably not, for your, like, one time support donation. I really don't know what to say. Thanks a lot. We'll we'll put that towards the show for sure. Just thanks a lot.
Shay Nehmad:We really really appreciate it. People liking the show, not like liking in a social media sense, but telling us they enjoy the show, willing to support us is a really, surprising and, fun turn of events for us, and it keeps us motivated in doing this show. Anyway, thanks a lot to all our new patrons and, also Remi. Dude, you rock. You can reach us at capago.dev.
Shay Nehmad:You can find links to everything you need there, our, Slack channel, hashtag capago, kebabcase with hyphens over the gopher, Slack workspace, or you can just email us at news atcapago.dev. That is news atcapago.dev. Other than buying stuff on the swag store or joining the Patreon or otherwise spending money, it really helps us out if you also spread the word about the show. More listeners, more audience, more people, more fun. So you can leave a review on your whatever thing you're listening on, Spotify or Apple Podcasts or just wherever you listen to your podcast, or you can share the show in your work Slack with a friend, a colleague, a co student, just someone who you know who's, in to go or wanting to get in to go.
Shay Nehmad:That's all for this ad break. Stick around for an interview with Justin McCarthy about authorization and cedar.
Jonathan Hall:Hey, Shai.
Shay Nehmad:Yo. I'm looking around here.
Jonathan Hall:I'm sitting here in Guatemala, sitting looking around all the trees. I see some cottonwood. I see some palms. I see all sorts of stuff. You know what I don't see?
Shay Nehmad:Wait. What do you see there?
Jonathan Hall:I don't see any cedar trees.
Shay Nehmad:You don't see cedar? Any cedar trees?
Jonathan Hall:Ah, fadump gee. But if we had I I wish we could get somebody on the show who knew something about cedar.
Shay Nehmad:I believe it's called, like, horologist or something like that. People who know about trees. But I don't know anything about that.
Jonathan Hall:Hey, Justin. Do you know anything about cedar?
Justin McCarthy:I did, while you were doing the bit, I did look up, the extent to which cedar's trees are indigenous to Guatemala.
Jonathan Hall:Okay.
Justin McCarthy:And it turns out they are.
Jonathan Hall:Okay. They're just not right in this particular area. Awesome. Right.
Justin McCarthy:Yes. I guess we'll have to
Shay Nehmad:talk about other types of cedar then.
Justin McCarthy:I'm looking at the Latin name here and everything. So, yep, it's there. They're there.
Jonathan Hall:Very cool. Very cool. I'll I'll look harder, when I when I get out of town or get out of the the house. So, Justin, welcome to the show.
Justin McCarthy:Thanks for having me, folks.
Jonathan Hall:Yeah. We have Justin McCarthy here, to talk about Cedar. Before we do that, why don't you tell us who you are, and then we'll talk about what Cedar is.
Justin McCarthy:Sure sure thing. So, so my name is Justin McCarthy. I am, I'm I'm up let's see. You're you're down there in Guatemala. I'm up here in California.
Justin McCarthy:I spend my my days, as the co founder and CTO at StrongDM. So our company does you'll you'll hear more about it over the course of this talk. But, we do we do a lot of cybersecurity topics, specifically access related topics and authorization related topics. So because of all that security focus, yeah, that's what that's what brings me here speaking about the CDR authorization language today.
Jonathan Hall:Awesome. So let's let's do it. So, sounds like we're talking about security quite a bit today. Where does CDR fit in? Cedar is a Go library.
Jonathan Hall:There's also a Rust implementation I see and maybe others on the way. I'm not sure. Tell us what Cedar does. Yeah. Let's start there.
Justin McCarthy:Sure. So so the first thing I'll note is that in some ways, it may be surprising if you haven't really focused on this problem before. But Cedar is a language.
Jonathan Hall:And
Justin McCarthy:it's a language that was not at all developed, by by me or our team at StrongPM. This is actually years of intellectual investment, that the, team over at Amazon has been making. Okay. Really, sort of boiling and distilling all of the decades of large scale IAM lessons that they've learned. Okay?
Justin McCarthy:So for anyone that's worked in any kind of Cloud configuration, specifically in AWS, you're gonna remember, all of the IAM stuff. Okay? So if you think about, if you're sitting on top of those, all of that, data, all of those user experiences, eventually you're gonna think, Gosh, maybe we could do better than this. Right? And so you put a couple professors on it and a couple smart folks, ask them to think really hard about it, and out pops, Cedar, which has a few interesting properties.
Jonathan Hall:So hearing your description there, the first thing that popped to my mind is, like, is this Terraform for IAM? How close am I? Am I way off the mark or is that kind of kind of close to this?
Justin McCarthy:Okay. So I wouldn't compare it to Terraform, but in terms of any of the language properties, but the ambition, yes. So the ambition of I want something I can test, I want something with predictable behavior. I want something repeatable. That's exact all of those ambitions.
Justin McCarthy:Implementation is quite different, as we'll as we'll get into. And the reasons why the the shapes have to be quite different. But yeah, the same the same sort of folks who find repeatable anything, appealing will find a language like this appealing.
Shay Nehmad:Cool. Looking at, again, the motivation, it's like, I wanna make sure that all the problems you mentioned, right, someone wants to write an I'm policy. It's difficult, right, and you need to worry both about what for me, like, about 4 things, right? The resource you're working on, actor or entities that get the value, the context and is it allow or deny and I think there's something else maybe labels or tags or something like that. It's a lot.
Shay Nehmad:Even as someone who works at a cloud security startup, I wouldn't trust myself to write a policy. Like, I would like to test it. The way I know how to do it today is I take the JSON of the policy, probably some AI spewed for me at this point, and I put it in the I'm policy checker in the UI and I wouldn't do it every time, for sure. So is sitior, like, more expressive? Is it more testable?
Shay Nehmad:Is it easier to learn? Is it hard to learn? Like, what's let's say, I am writing, I'm policies. I assume, by the way, not just for AWS, but let's just focus on that. Also, biggest market share.
Shay Nehmad:What benefit would that give me?
Justin McCarthy:Sure. So, you asked if it was more expressive, if it was easier to learn, if it you know, and I think, obviously when you get a chance to sort of sum up all of the prior art, think it through and, you know, design, for a modern era, then you do get, you know, some benefit. So personally, when I reflect on all of the other ways of expressing an authorization decision like this in any kind of, declarative or procedural language, my eye is drawn to the Cedar syntax. I find it easy to read as a human, which is actually interesting because that was certainly a design goal of the language as far as I understand. Again, I'm not the language designer.
Justin McCarthy:But actually, a simultaneous goal that has persisted throughout the development of SEDAR is actually one of machine analyzability. So the ability to do, automated reasoning and essentially proofs over the language, has also been a really key part of the design and the implementation. So even though it's very readable for a human, it's even more readable for a machine. And so, so that's actually pretty exciting too. When you think about running those test cases, when you think about running those simulations, it's been designed to facilitate all of that at high throughput and very, very high certainty of correctness.
Shay Nehmad:I'm a big, like, logical policy language nerd, and I've been playing a lot with, Regal, where which is the open policy agent where you define, sort of policies. And, obviously, when you say prior art, I'm not I assume you mean I am prior art, but there's also prior art in the, like, logic programming space. Right? The Rego has its roots in I'm blanking. Someone help me.
Shay Nehmad:Prolog. Prolog. Yeah. Thanks. And, you know, it's been developed in a few different directions, but it certainly, as languages, some languages have gone, has gotten better with more capabilities, more things like that.
Shay Nehmad:And also, I assume more approachability, like, I'm looking up Cedar today. I'm, like, I have a a playground and a tutorial, whatever. I assume if I search for a prologue, it's gonna you sure? Did you mean something else? Or is that what you're looking for?
Shay Nehmad:But where does your involvement fit in? Let's say you convince someone. Cool, Logic ish programming, I define a policy related to I'm sounds relevant. Where does your involvement come in? Because you say I'm not a language designer and you haven't designed the language.
Justin McCarthy:Sure thing. So this became a really important part of some product ambitions that we had within the Strong VM product. So a big part of what we do is we we connect people that essentially have access to very sensitive systems. So they might have access to a virtual machine, or a Kubernetes cluster, or a database. So we actually have protocol and identity aware proxies that sit between the users and those workloads.
Justin McCarthy:So when you look inside those workloads and you ask, you know, is it okay for Justin to perform this action at this moment? That's actually essentially an I'm layer that we wanted to add as an overlay to all of these protocols. So if you can imagine, how do you specify the universe of what's possible in an Oracle database or a Kubernetes cluster? You need actually a very powerful language to sit over that. And then we also needed a language that we could embed into those proxies that we're going to run at wire speeds.
Justin McCarthy:So we had performance characteristics and expressiveness characteristics that we needed out of the language. And that's what that's what brought our attention to Cedar about at this point, about a year and a half ago.
Shay Nehmad:And Cedar had a Go implementation, or did, like, you and StrongDM started?
Justin McCarthy:So, yeah. All of our initial prototyping using CR was based on the the the original implementation, which was all in Rust. Okay? So obviously, through bindings, it was very easy to call. And so we were able to validate our, essentially, our product ambitions.
Justin McCarthy:What features did we want out of this thing, with the original Rust implementation? Once we moved out of the dating phase and we got into the marriage phase, with the language, we realized that we just needed for our proxies, which are implemented in Go, we needed something that was directly in the same runtime, had the same idioms, the same memory boundaries of predictable characteristics, and was in a language that we felt like we could contribute at high velocity to the implementation to sort of expanding the capabilities, of of the language itself and the implementation.
Jonathan Hall:I have a question, but there's a loud church bell behind me right now. So I'm gonna wait just a second till it's down and then I'll ask you.
Shay Nehmad:I can turn on, like, the I I can tell the imams here to also do their evening prayer at the same time, and we can, get all the we have some Buddhist monks behind it. We can get all religions. So Buddhist monks tend to be relatively quiet, I think. Well, I have one if you want me to I wanted to pass the reins to you because I'm doing the thing where I always do.
Jonathan Hall:Yeah. I have questions relevant to what we just said, but I I really
Shay Nehmad:wanna do
Jonathan Hall:some So
Shay Nehmad:I'll wait. Oh, wait. I'll I'll do something irrelevant. Justin, I'm I'm just, done with 13 years of beard.
Jonathan Hall:It is an awesome beard.
Shay Nehmad:Do you think that helps your CDO status? People are looking that, oh, that guy knows security. He looks grizzled.
Justin McCarthy:This this is actually just a a a video filter. It's like a Tic Tac filter. I'm I'm completely clean shaven.
Jonathan Hall:It's pretty good. So I think you should go into business making filters.
Justin McCarthy:Yeah. Yeah. Well, it's all pure go.
Jonathan Hall:Yeah. Okay. Awesome. The filters are all
Justin McCarthy:in go.
Shay Nehmad:Right. Right.
Jonathan Hall:So you mentioned the dating phase of Cedar. I'm curious what other alternatives you looked at and how they weigh to get you know, how did they measure up to to Cedar that you finally chose? What were the pros and cons?
Justin McCarthy:Sure. You know, so like I said, there's a lot of prior art on this topic. The the the idea of fine grain authorization, you if you type fine grain authorization into your favorite search engine, you're gonna find a lot of folks that have tried this before, actually decades ago. They've tried this before recently. So this has been an ambition.
Justin McCarthy:If you think about back to the beginning of time when authentication was actually completely disparate, every system had its own password. Right? And then we all got together as an industry and said, you know what? Maybe we can do some single sign on standards. That was a successful way of transitioning authentication into a unified approach.
Justin McCarthy:Right? Well, same thing for authorization, which is what happens after you've authenticated. Folks have said, gosh, why can't we externalize this? Why can't we be more intentional about this? Why do we have to write it every time?
Justin McCarthy:Okay? And so there are options to choose from. I think we just basically had the advantage of needing a very powerful deep authorization answer at a moment when the Amazon team had just baked all of their thinking. So it's thinking that essentially reflects the sum of everything that came before it. And so, so one note I'll add in contrast to some of the other options though.
Justin McCarthy:There's actually a little bit of an art of expressiveness. Okay? Expressiveness, when we typically say it, sounds like an unalloyed good. It sounds like you can never have too much expressiveness. Right?
Justin McCarthy:But if you ask a Go developer and then you show them some Ruby or whatever, like, baby, you can have too much expressiveness. Yeah. Yeah. Right? So there's an an aspect of that in a lot of the other expression languages where, there's essentially too much power.
Justin McCarthy:It's it's inching too close to turn completeness. Okay? And so, so the Cedar language was very, very fixed. There's you know, you're you're not going to get into any kind of recursion. There's not going to be any unexpected looping that's gonna happen as a byproduct of some policy statement.
Justin McCarthy:And so the language itself is concise in that way. And then the other real innovation that, really no other language has is this notion of proofs and the ability, to apply machine reasoning so that you can get essentially decidable expressions and decidable policy statements. I know that sounds like a sort of a nerdy language feature, but result of that is you can run essentially large scale simulations in essentially set arithmetic space, and, figure out what would happen if we refactored the policies from this set of statements to this set of statements. And refactoring and reorganizing policy is a very, very real use case, especially the more complex your organization is. So having confidence through change is enormously enabled by the machine reasoning properties of the language.
Jonathan Hall:Pretty cool.
Shay Nehmad:I do wanna dig on that even though Amazon did a lot of thinking. Rigo, you said performance as one thing. So any sort of policy language that's, not, in a that doesn't have any implementations or can't have any implementations that are, compiled and like fast, like JSONata or these sorts of, you know, JSON manipulation languages. All of these are the window. Right?
Shay Nehmad:Because this is someone sending a request to a Kubernetes cluster, they need to, while that request is in flight, get a response from your policy engine. A quick peruse on your home page shows up a really cool use case of like, wait, is this Justin's normal working hours or is someone like, not doing it from, like, he doesn't usually work Saturdays at 2 AM. Why is he sending a request to the Kubernetes cluster? I assume this is expressed in a, like, context based filter in a cedar policy. Right?
Shay Nehmad:Context dot time equals outside of working hours, blah blah blah, something like that.
Justin McCarthy:Yeah. Yeah. That's a that's a great example. And we we have a lot of examples that are sort of accessible and intuitive. And then if you imagine stacking all of those, policies simultaneously, the other, really interesting things I mentioned a minute ago, the set arithmetic properties of the system, part of how it is performant, is related to that.
Justin McCarthy:So, depending on which variables you're binding, depending on which entities are in consideration at any given moment, the, essentially, you can think of it as the amount of paths that we don't need to fully explore in the evaluation is, like, sort of optimally optimally calculable very, very fast. Okay? And so that means, really, every use case we've thrown at it, we we use the expression wire speed often. But the idea is, it's not gonna pro it's not gonna induce any sort of latency, in any sort of gesture, any sort of action that any user or machine is needs to perform.
Shay Nehmad:So what I'm saying is all policy languages that are not can't run from, like, go or don't are are maybe Turing complete and therefore don't have these, sort of, of, option of mapping out into a search tree and and doing the thing you mentioned are out the window. So that's a pretty large number of the policy languages already that are outside the window. What I know like, I'm not an expert in this topic, but I'm familiar with rego. I think it is like a competitor. Right?
Shay Nehmad:So if someone is evaluating Rego right now, what you're saying is take a look at SEDAR as well.
Justin McCarthy:Sure. Yeah. I I think, you know, there's also a little bit of culture of what what types of applications tend to adopt, what types of approaches. I would say, we've obviously seen Rego have pretty good deployment, in, for example, the Kubernetes universe. So there are lots of examples of applications there.
Justin McCarthy:I will note actually that, actually just yesterday, there's a new blog post live, on the Cedar blog. So if you look over there on the blog, you'll see that there's an implementation of essentially Cedar for Kubernetes that is based on the Go implementation. Okay? And the and the ambition there, this is from the SEDAR team and a principal engineer over at AWS named MICA. The ambition there is to unify the essentially admission control and RBAC side of the decision to do to allow or deny inside of Kubernetes, which has typically been a fractured story.
Justin McCarthy:By having it go, by having it based on SEDAR, there's at least the possibility of bringing those worlds together. So, yeah. Anything that feels like that, anything where you realize you actually have to sit down and have a design discussion about your authorization system, I would definitely put SEDAR up on the whiteboard. One other note, just in contrast, to some of the prior approaches, really how explicit it is about actions, how explicit it is about hierarchies of entities that are principles, and hierarchies of entities that are potentially resources that you could editing. It really lends itself to, maybe more application authorization.
Justin McCarthy:Like, can can I share this photo with if Jonathan shared it with me, can I share it with Shai? Those sort of decisions, which I'll note, those should be very familiar for anyone that has ever read the Zanzibar paper from Google. That's how, essentially all of the permissions inside of the Google verse are modeled. That's generally referred to as relation based access control opposed to role based or attribute based. And I'll just note that SEDAR really has an ambition of being sort of star back.
Justin McCarthy:So so role, relation, and attribute based. You can express all of those sort of authorization models within SEDAR.
Jonathan Hall:Justin, I'm really curious who you think, is the target audience for for this sort of thing. I mean, I can imagine a lot of our listeners are like, I just wanna write code. I don't care about policies. If they wanna stop listening, that's fine. But who should listen?
Jonathan Hall:Who who who maybe in particular, who who should be thinking about this for whom it's not obvious that they should be thinking about it?
Justin McCarthy:Okay. I I haven't fielded that question before. So let me let me let me see how I do, coming up with an answer. So so actually, one you know, at one layer, in addition to having a very high throughput, identity aware, protocol aware, sort of like data layer within the strong VM product, we also have a control plane, right, with standard administrative functions. Right?
Justin McCarthy:Where, you know, is Justin what what level of permissions does he have? Is he allowed to invite other users? Those kind of questions. Okay? So one note is that we have, essentially, recursively embedded SEDAR, really around every one of those decisions, throughout our product.
Justin McCarthy:So we kind of, you know, maybe it's like everything looks like a nail once you have a golden hammer.
Jonathan Hall:But
Justin McCarthy:I would say it's really the ergonomics of saying, Well, it's not an editable policy. It's not a configurable policy. But we're still running it same through running through the same authorization, essentially, stack. Right? For really, for everything.
Justin McCarthy:I'll note one dimension of flexibility that that has created as a byproduct is, it has given us a path to say, Well, especially when working with complex enterprises, especially, you know, they have multiple jurisdictions, they have multiple continents and countries. There are times where for compliance reasons, you want to say, Jonathan on this continent can't approve something, from China on another continent. Right? And it's a weird it's a weird business rule. Right?
Justin McCarthy:And it's a weird business rule that if you're a product manager on some SaaS application, you're never going to put that button in the interface. Right? Someone's gonna ask for it, and it's gonna sit in the product management queue forever. Right? This gives you a pathway at least, right, to say, Oh, okay.
Justin McCarthy:You you at least can say this statement. And furthermore, you can evaluate what impact that might have over your actual traffic. Okay? So so I would say, again, back to you know, I said this earlier, but, like, if you've got beyond the most basic, authorization question in your system and you realize you have to design something, don't design something without looking at SEDAR first.
Shay Nehmad:So the common, like, no thinking approach, I think, or like the the most it depends but this is the first advice I'll give you approach is if you're designing anything beyond basic authorization, my first thing would be, oh, look at Cedar to implement it. It would be, oh, go buy it from someone. If you wanna externalize it, externalize it completely and like just get it from other named brands. I don't wanna name a list because maybe one of them is your competitors and they won't like it. But, if if I'm building a product and I need a login, I'm not, like, building my own authentication at this point.
Shay Nehmad:Right? I'm slapping in a sign in with Google page button and many people don't have that for the authorization part. They start building the authorization, the RBAC, like, inside maybe because they use a framework and the framework has, like, quote unquote RBAC capabilities until you found that you're not buying a to do app and it's not actually as simple, as as you always say. But again, the the common knowledge is, oh, just buy it. I assume also for people who are looking at build versus buy, you might be saying, hey, people at Amazon already did a lot of the thinking for you.
Shay Nehmad:You might be able to implement this mechanism with all the heavy lifting being done by cedar, and you're just, like, sending the request, writing a tiny bit of code to wrap cedar dot run my policies, then sit for a while and write these policies down. Right?
Justin McCarthy:Yeah. So so I would say on the build versus buy, maybe maybe another way to think about this is, the architecture could provide for, like, lingering a little bit longer on the build and then sort of hybridizing it with the build versus buy because there's actually a couple more components. We've been talking about the language itself. And that's the thing that decides, is allowed or is denied at a really fine grain. That's the evaluation part of authorization.
Justin McCarthy:There are other parts. What possible properties can we pass in? That's the notion of schema. Right? So you have schema just like you would in a database, but for defining what is the surface of authorization for my application.
Justin McCarthy:Then you have the notion of, revising and versioning these policies. And then, and then, sort of unioning them and combining them. That's the policy store. So each of these components actually need to live somewhere. There is an off the shelf version you can rent from AWS.
Justin McCarthy:But then there are other products out there as well. So if you think of, Hey, I like the cedar shape. You can begin experimenting. Just write your own tests, have your own local, you know, flat file storage of the Cedar policies. And then over time, you can say, Hey, there is a subcomponent here where I really want a SaaS to take care of it.
Justin McCarthy:And so you can sort of outsource, you know, just the policy store or, just the schema definition and schema editing or just the testing. You can sort of push that out to other systems as they come online.
Jonathan Hall:What resources can you recommend to somebody who who hears us talking and they're like, that sounds intriguing. I don't know where to start. I want to look at SEDAR, but, you know, what should I start? I could I could go through the Go repo and there's examples there, but, you know, what's the best place to, you know, start getting your feet wet with this?
Justin McCarthy:Alright. So, so there's a great, there's a a great playground available, you know, from, the Cedar team itself. So you're gonna find that at cedarpolicy.com. Although, since this is a Go focused podcast, I will say, starting with the Go, that's one wonderful thing about the language we all love. Starting with the Go is actually a a totally great way to get introduced to it.
Justin McCarthy:So start with the test, start with the examples that you can see in the repo there, and then go read the implementation. Right? Because that's, something that, you know, it's very legible. And it gives you a sense of really the magnitude of the kinds of topics that are involved. And and, actually, if you're making a build versus buy versus DIY, decision, it might even help fortify your argument, that you need to at least upgrade to something that you can get off the shelf for GitHub there, in the form of Cedar Go.
Justin McCarthy:Because, there's a lot of ideas in there that you may see how they apply to your application. And, yeah, the cost of experimentation is very, very low. It's just a pure Go dependency like anything else, and you can just run it and see how you like it.
Jonathan Hall:I wanna flip that question around a little bit. One question I like to ask when we're talking about, products the audience may not be familiar with is, who should not use this product? Because we we talked about all the great things, but, you know, there's all there's always someone who it's not for. Who who would you say should should just run away from this? It shouldn't be relevant to them.
Justin McCarthy:Oh, gosh. Okay. Well, this this one I I do struggle with because just because the cost of adopting this is so low, because you're not taking a dependency that introduces latency or anything like that. And because of the expressiveness, and you can really model anything. So let me just try and say, who should not use this?
Justin McCarthy:Let's go with crypto. How about that? Okay. So and and and I mean and I mean the coins. So like if you're doing something with a blockchain, and everything's public and all of the security model is essentially delegated to that way of thinking, then, yeah, then maybe maybe you don't have another RBAC model on top of that.
Justin McCarthy:If you, if you're doing something that is just gosh. I just really struggle to think of of cases that don't have some level of permission built in.
Shay Nehmad:I would tell you what. What I think what I think is people are excited and nerd out about the stuff such as yourself might write start writing their side project, which is a super simple site, sign in with Google, only one type of resource, only one type of principle, and then you'd be like, of course, I need SEDAR here because I need SEDAR because I have authorization, but it's a bit early. You know what I mean?
Justin McCarthy:Yeah. Yeah. But I like I like ridiculous side projects. So I I I so I so turn I love turning to side projects up to 11. So, so you won't get me to endorse that view.
Shay Nehmad:Yeah. I had Jonathan. I last episode just, talked about me trying to side project the perfect documentation repository for, like, 30 minutes just talking about whether my product approach is correct. I I get what you mean. The side project is where we're allowed to turn it to 11.
Shay Nehmad:Right? Exactly. Exactly. We have to worry about that product manager and his product team.
Justin McCarthy:Exactly. Exactly.
Shay Nehmad:Cool. So it's safe to assume that at strong dm, Cedar is very much adopted. Right? Who is writing? My my question is, like, there's as a developer, I would spend some time, you know, introducing the learning the the playground and then, you you know, adding the the dependency, trying to play around with it a little bit, integrating it somewhere in my product, like some HTTP middleware somewhere or in your case even, like, more advanced, the component itself.
Shay Nehmad:All it does is, well, I assume it does more stuff. But one of the things you've, outlined it it does is this authorization for the first policy, for the second policy. But I assume at some point you want, like, writing policies to become easier than once you pay that, like, first cost, right, of implementing it and integrating it. Are the people who are writing policies now at your organization still developers or can, like, product people or even customers, like, hop in and be like, hey, I wrote this policy. Can can you slap it into the to the product?
Justin McCarthy:Okay. Yeah. Great. That's a great question. I would say that's that's another advantage of having sort of a common language because we actually have examples of all of that.
Justin McCarthy:So because our product itself is a policy store, right, we have policies that are essentially, you know, frozen or embedded into the binary. Right? And then we have policies that are editable at runtime. Okay? And then we have policies that reflect back on what's possible to edit at runtime.
Justin McCarthy:Right? So, so essentially, all of the above. Customers have their fields that they're editing that have policy statements that, where we have our own fields that we're editing, and then we have, you know, the product itself, which has essentially embedded policies. In terms of the learning curve and what I would refer to as, like, the design space, that's what I notice, is sort of the the the the most sort of virtuous activity that I note happening is is it's the same thing as naming in any other, design, session that you're in. Like, what should we call this particular resource?
Justin McCarthy:What at where should we put the attribute on the photo or the folder that the photo is contained in? Right? So it's it's that level of design that it it sort of forces you to have that conversation instead of just one person unilaterally throwing a name on there. Right? And so, as I noticed the different application teams adopting SEDAR and applying them, they're going through those design conversations, and, you know, how how to model, permission how to model a superset of permissions in Kubernetes versus how to model a superset of permissions in, in, you know, Microsoft SQL Server.
Justin McCarthy:Right? Those kinds of topics come up. And the modeling environment and the schema environment of SEDAR gives a a way to host those conversations.
Shay Nehmad:So what you're saying is people who, let's say, I wanna model well, I'm I'm coming from a cybersecurity company in the cloud security space. So that's the example I'm gonna give. Please forgive me that it's boring. Access to cloud resources by, people. Right?
Shay Nehmad:Like, can, Justin access this s three bucket? Which is where all this thing originated. Right? I am. We were going getting back to the beginning of the conversation.
Shay Nehmad:I don't have to be a Go expert to talk about that this policy because I can do it in cedar. Sounds like what you're saying is the learning curve is pretty steep like I'll get on pretty quickly. I'll I'll understand stuff pretty like quite fast and I'll be able to like reason about the things I want to model in cedar without a long, like, okay. Now I'm learning Cedar for a month before I can jump on it.
Justin McCarthy:Yeah. I I would say, like, it it's actually again, sorry. I'm I'm just gonna refer back to Go. A a very a very common thing that I share with folks that are that are curious about Go is like, I just ask, are you a programmer? Yes.
Justin McCarthy:You pretty much already know Go. What you don't know yet is the culture. What you don't know yet are the idioms and how to name things. But you pretty much know Go. I would say the same thing about the Cedar language.
Justin McCarthy:Like, if if you have seen any kind of expression language, if you've seen any kind of organization and and mix of, expressions of data in any format, you'll instantly parse it. Okay? So you'll you you won't need it explained to you. So in some ways, you already know it. Right?
Justin McCarthy:And it's really about what is the culture of designing the names of the attributes? How do we organize them into hierarchies? How do you, instead of arithmetic, if you're allowing things and then denying things, or permitting and forbid to use the parlance of SEDAR, how do you how do you actually join those together, with negative conditions in a way that both achieves the policy result and maintains readability?
Jonathan Hall:I think I'm gonna use SEDAR. I'm I'm gonna look at using SEDAR for a project I'm working on right now. So it sounds like it might solve some problems I have. And keep me from reinventing the wheel.
Shay Nehmad:You have converted one person and people, who are just listening via audio and maybe skipped to the interview don't know, but Justin carries a magnificent beard. And the first thing that popped to my mind when, you converted, Jonathan was like, hey, he's like that guy from, Age of Empires 2 that does, like, and you you know what I'm talking about? Anybody here on the call play Age of Empires?
Justin McCarthy:I don't. But it is here in the US, it is Halloween at the moment. So I'm gonna very quickly go, buy that game, play it through, figure out the purse personality of that character, and then embody it before sundown tonight.
Shay Nehmad:It's you're playing like blue, someone else is playing red. You can buy these sort of monks and they're called because that's the sound bite they do. They go and go and and then they turn, like, red, red, units from your opponent into blue. Okay. You just cedar, Jonathan like that.
Justin McCarthy:I'll be I'll be dashing through the neighborhood doing that tonight then. Cool.
Shay Nehmad:Cool. Cool.
Jonathan Hall:Well, Justin, I wanna ask if there's anything that we should have asked about that we didn't. What what are the important things that do you wanna talk about that we we haven't touched on yet?
Justin McCarthy:I, you know, I think we've covered a lot. I I will just note that, you know, all of this work, all the smarts, really, the Amazon team spent a ton of time. You you can you can go watch plenty of videos on the subject. They've just been thinking about it so deeply for many years. And I'll just note at strong DM, we we just fell in love with the language.
Justin McCarthy:And so we're sort of, we're doing our part to make a Go native idiomatic version, in the Sierd Go project. Okay? So if you find elements, I would just encourage all these Go listeners out there, give it a try. We want all that feedback about things that were surprising or unexpected that are in the API design. As you know, that's, like, always for an early project, that's always the kind of feedback you're thirsty for.
Justin McCarthy:And so please, send that feedback in all the usual ways. You're just gonna be able to find the repo out there. We're paying attention to the issues. And as you can see, the commits are coming, like, pretty fast and furious right now. So the language, and the implementation is a a work in progress right now.
Justin McCarthy:It's being very actively developed. So encourage all all your requests to come in, yeah, as you have them.
Shay Nehmad:So you you're not doing it, so I will. Also, looking at the strong DM website, looks like there's open positions in the engineering, department.
Justin McCarthy:So Well, I mean, there are always open positions in the engineering department. But I I do wanna say, I'm just gonna anti sell here. It's only for people who really love hard problems and solving them in Go. So it's so I don't know. So, you know, may not be for you.
Shay Nehmad:No. Our listeners are just like easy problems. They just they ride the same, like, HTTP server over and over again.
Justin McCarthy:Oh, okay. Oh, yeah. But that's not the That's
Jonathan Hall:not the
Shay Nehmad:That's the Disney News, 99%, and Josh Bleecker Snyder is writing the compiler. And that's pretty much
Jonathan Hall:I I have one spicy question I wanna ask before we, move to the the closing of the interview. There's been a lot of news in the last couple years, I I would say, about open source projects going semi closed source. What are the chances of Cedar Go switching from Apache to the Winamp license?
Justin McCarthy:Oh my gosh. I don't know. I'm fine making predictions. 0. How about 0?
Justin McCarthy:This isn't like, I mean, you can just compute the financial motivations of everyone involved. Like, this is this is something where more adoption is better. And this is in terms of the layering of your stack. This is so fundamental that you wanna know everything about it. Okay?
Justin McCarthy:And so I would say, no, this is definitely We benefit from these very large organizations, these hyper scalar companies that are able to invest really high quality thoughts and sweat over years to create this stuff. Mhmm. And I I don't know. I don't I don't think they jealously guard, components that are as fundamental as this. Sure.
Shay Nehmad:Not not Justin, in our podcast 2 years from now. Alright. So we're announcing open seeder coming from Fortnite. Alright. No.
Shay Nehmad:I'm just kidding. Actually, it does make sense. Like, when you think about these things that, Amazon, did in the open source space in relation to licensing, not just Amazon, but they are, definitely a highlight player there. It's like full products. It's not like your query language, it's your elastic server.
Shay Nehmad:It's not your, JSON storage, facility, it's your MongoDB. Like it's a full a thing you can sell and there's just no way they can sell cedar as a language. I do believe that they might do offerings and it's totally fine that they do closed source offerings that they pay, including the I'm policy center and other things maybe within, Amazon that might even compete with strongDM, But I definitely believe that they would benefit from keeping Cedar open. That does
Justin McCarthy:make sense. And and you'll find that today, Amazon verified permissions, if you're interested in the how can I pay Amazon for this? Amazon verified permissions is your is is is the way, to to pay Amazon.
Shay Nehmad:Yeah. We built a very complicated, access system, so now you can pay us to verify it.
Jonathan Hall:I'm always looking for ways to pay Amazon, so I'm glad that that's there.
Shay Nehmad:Cool. We usually, ask towards the end of the interview, stumper questions. Last year it was, what would you take, and what would you from another language into Go and what would you remove from Go. But we basically cover the entire feature list. So this year it's when did you start learning Go?
Shay Nehmad:Like when did you get into Go, Justin? And what sort of was challenging or surprising to you? You mentioned the language is pretty lean, but there's like idioms or maybe culture that could be surprising.
Justin McCarthy:Sure. Okay. So, so I I will note, as much as I I I like personal projects to be experiments and turn them up to 11, but but I also can can't be curmudgeonly about languages at some point. So at some point, I I felt like I didn't need Go. Okay?
Justin McCarthy:And I sort of turned my nose up at it, and I felt like I had all of the I had everything I needed in in my sort of portfolio of languages that my my fingers were fluent in. Actually came down to actually, right at the beginning of strong VM, I did a bake off between a number of languages. At the moment, I realized that we were going to have this very, very high throughput, data plane use case. So we needed to handle packets very quickly, needed to disassemble them, needed to reassemble them, needed to, you know, do all that at Wirespeed. And so I had a bake off, between Go and then a few other languages you would know.
Justin McCarthy:And actually, the surprising thing to me from the beginning is that there was just no contest in terms of the developer experience. I just kept saying like, Wow, it's working already? I'm done? And and so that and that was with like literally, you know, the GoBook open on my desk. And and just like and just typing away by myself.
Justin McCarthy:And and I I was just done. And and there were other languages where I was still installing. Right? And so, so that was a profound revelation. The asterisk on that was always, well, you know, I haven't fully explored the GC.
Justin McCarthy:Maybe there's gonna be, you know, certain kinds of surprises that are come gonna come later. I'll circle back to that later and make it you know, remake this language decision or push some push some stuff down to see if needed. Nope. Never needed to come back. Go is caught up in terms of performance, for everything you've thrown at it.
Justin McCarthy:Okay? So that was my introduction to Go. In terms of biggest surprise, one of the sort of like taste judgments that unfortunately we all have to make, about a language is related to dependencies and the dependency ecosystem. So the experience of installing. Obviously, we all went through a bunch of different models in Go at the beginning.
Justin McCarthy:And so I would just say the surprising thing was how slow, getting to consensus on dependencies and, defining what, and then installing them. But the because of the Go tools, because of Go install, Go get, having that as sort of the primitive in there meant that regardless of which modularization scheme we were sort of experimenting with at the time, they all were kind of fast and had, like, a unified caching and download model underneath. So the I guess the surprising thing is how long it took to get to consensus. But then how I don't know. Maybe people still have opinions on this.
Justin McCarthy:But I've just always felt that all of the schemes worked better than a lot of the other languages out there. So dependencies, thumbs up. I love Ghost model.
Shay Nehmad:Awesome. Cool, cool, cool.
Jonathan Hall:I like that answer. Well, before we wrap it up, Justin, how can people get in touch with you? I suppose if they have questions for you specifically, we'll have a bunch of links that we've talked about already in the show notes for people who wanna look at Cedar and all these other things. But if they wanna reach out to you, how can they do that?
Justin McCarthy:Sure. Alright. So, so if you're ever in Redwood City, California, you can just walk up and down the street, and eventually you'll bump into me. If you wanna do a more digital option, I prefer email. Email is great.
Justin McCarthy:So justjustin@strongdm.com. So, yeah. Send me send me an email. I'd be happy to hear from you.
Shay Nehmad:Awesome. That founder email, no last name.
Justin McCarthy:Yeah. Definitely no last name.
Shay Nehmad:That's that's so swaggish. And when we started my when I started my previous company, like, of course, no. No last name. And I was, like, no. Everybody does their email with the last name because everything has to be formatted.
Shay Nehmad:And the founders went ahead and did a first name basis only. Anyway, well, I hope, there there are no other Justins in the company.
Justin McCarthy:Well, yeah. Unfortunately, there are you know, I think it's inevitable when you have a reasonably common name that there but, you know, but there's yeah. There's only there's only one first name account available. So Yeah. I can hand it out.
Justin McCarthy:Sorry.
Shay Nehmad:Cool. So justin@strongdm.com if people wanna follow-up.
Jonathan Hall:Well, Justin, this has been fun and educational. I'm I'm happy to learn about SEDAR and, give give it a try here on one of these projects I'm working on. So thanks for for educating me.
Shay Nehmad:Thanks a lot.
Justin McCarthy:Yeah. Sure thing. Alright, folks.
Jonathan Hall:Until next time.
Shay Nehmad:Thanks again to Justin for coming on our show and thank you all for listening. You can find the links to all the things we mentioned, down at the show notes. And again, this was super fun. Thanks a lot Justin for coming. He's not on the air right now, but it was really a super interesting interview, and you don't know this, but I was 15 minutes late and, both Justin and John were super gracious about it.
Shay Nehmad:That's a lot of fun and now we'll see you all next week. Program Ex is it. Goodbye.
Creators and Guests
