go podcast()

This week I'm joined by Bill Kennedy. Bill makes me discover Encore which can handles service-to-service communication while programmers focus on their application. We talk about domain design in Go and how to architect an isolated system following the 3-tier layer design.

Links:

As always if you enjoy the show consider sharing it / talking about it. If you'd want to support the effort the best way is by purchasing my courses, Build SaaS apps in Go and Build a Google Analytics in Go. Those links have a 50% discount coupon applied to them for listeners of the show.

Creators & Guests

Host
Dominic St-Pierre
Go system builder - entrepreneur. I've been writing software systems since 2001. I love SaaS, building since 2008.
Guest
William (Bill) Kennedy
⌯Go: Walking the line between correctness and comprehension ⦁ bill@ardanlabs.com ⦁ Wife(@aleintech) ⦁ NPO(@golangbridge) ⦁ GMT-5(MIA)

What is go podcast()?

15 minutes news, tips, and tricks on the Go programming language.

Dominic:

Hey there. I am Dominic Sompiare and you're listening to Go Podcast. Today I am joined by Bill Kennedy and we talk about Go. Hello, gophers. So I have a special guest this week.

Dominic:

I'm receiving Bill Kennedy. So thank you very much for accepting this invitation, Bill.

Bill:

Oh, man. Thanks for inviting me, dude. I'm excited.

Dominic:

Great. You know what? What I will do to start is I will I will steal steal one of your first question that you are asking on your podcast actually because I find it very, very good. What are you doing, today, Bill?

Bill:

That, 2 minute elevator spin. I haven't found a really good way to say that. I I think of it as an elevator pitch, though. I'm not pitching anything. But I'm the managing director at, Arden Labs.

Bill:

One of the co founders and my time is primarily spent building material that we can use to help train software engineers. I've been working for the last month on, on a cool technology called Encore. I have a service repo that I teach, right? So I teach architecture and software design and I, I teach this stuff, and I enjoy teaching it. And, the Encore team reached out and asked me if I would look at some of their, their tech.

Bill:

And, I rebuilt the entire service class in Encore. I'm still working on it. But for the most part, it's just about done. And it's a very, very, really cool tech. And I actually brought some of those ideas back to the service repo.

Bill:

So I think it just, the more you learn and the more you see other people doing things and and you can take some of those ideas back with you, I think that's when software architecture and software design just get better for yourself. So it's been a really great sort of month for me to rethink some things and learn, and I'm excited to get back in the classroom to teach that kind of stuff to, to others.

Dominic:

Yeah. Nice. So let I'm I'm not familiar with Ankar, to be frank. But is is it is it not a is it it's it's built on JavaScript. Right?

Bill:

No. Actually, it's built in Go. And, what they've done is really interesting. I was I was really sus about it, when they first approached me, but, but the the team that's building it, Andre, Ericsson. I wanna make sure I say his name right.

Bill:

It's not like I don't talk to him every day. But, yeah, Andre Ericsson. He's I've seen the guy give some talks and he's so brilliant that my brain just said, you know, throw your bias away on these sort of frameworks and and dive into this. I give this an honest sort of try, and I'm really glad I did. So they've built essentially a runtime and an SDK that allows you to build, software and services primarily, in Go with the added benefit of, easy deployments because their their tooling does that static code analysis, integrate, and builds into their runtime into your software.

Bill:

You know, you know, Go has a runtime. Right? So, like, they took that same sort of approach, built their own runtime to to be able to do things behind the scenes related to protocols, HTTP frameworks, and things like that. And, really, I was sus in that they kept saying you're gonna get product developer productivity with this, and then we're gonna handle all the ops. And I'm like, yeah.

Bill:

Yeah. Yeah. But I'll be honest with you, man. I when I converted the service repo and my service architecture, which I got to keep, honestly, 90% of my architecture. I I didn't really lose the architecture.

Bill:

What they did is all of the HTTP stuff that I had to build, my own little mux, the little frameworks, the middleware, the how you're handling errors. Like, all of that stuff, about 6,000 lines of code of that stuff was able to be dropped because Encore was already handling it. And I didn't have to think about some of those things while not having to walk away from my from my, architecture, my software design, which to me was the biggest plus because a lot of these I don't like calling Encore frameworks. I think it's so much more than that now. But a lot of frameworks sort of box you in to their architecture, to their software design patterns.

Bill:

And I think what's been most impressive about Encore is that it hasn't boxed me in at all. Like, I'm not gonna say it hasn't put me in the in a corner every once in a while.

Dominic:

Yeah.

Bill:

But I have, it's a really it's a rounded corner. Let's just put it that way. Okay? So, I I I have not felt restricted at all. And like I said, everything that I teach in in my software design class, applies to my port, into Encore.

Bill:

And so I really do think there's a, a level of productivity developers can gain because there's a whole level of sort of, framework and infrastructure I don't have to think about anymore. And I I go back to, like, muxes and service to service communication and all that stuff is, like, taken care of. You can really focus on your app there. I haven't played with their deployment stuff yet, but, ideally, because they know so much about your application, again, with their runtime and SDKs and their static analysis. The idea is that you just use their CLI tool and you can deploy to Google Cloud or AWS, and you don't even have to think about those things.

Bill:

But if you're in a shop that already has a big handle on that, you're building a go binary that you can, at that point, put into a container and deploy it any way you want. Right? So, you don't need those aspects of encoring if if you wanna deploy things yourself. So, I'm still learning how to talk about this tech. I've only been I've been playing with it for about 4 weeks, but I have to say I'm super impressed with it.

Bill:

And if you're starting a project and, if you're starting a project, I think it's something you could consider sort of looking at. And I'm hoping now with this this repo that our labs slash Encore repo that I've been working on that people who wanna use Encore but still want software design, you know, knowledge and and and built into what they're building can can take that class. So I'm gonna be teaching Encore alongside with the, the other service class that I teach. I'm I'm really excited about it.

Dominic:

Yeah. This sound very interesting. To be frank, so I was totally wrong when I when I because I I I've seen a couple of your tweets and I was, I was intrigued because I I frankly did not heard about that. So when you say that it's a run time, so is it is it running the same binary or or they are recompiling the code?

Bill:

They recompile it. So so there's a few things there. Right? So they have their CLI tools called Encore, obviously. And, when you do like an Encore build, it's taking all your source code.

Bill:

It's doing a static analysis around it. So it's trying to identify not trying. It does. And this is where you kinda locked into having to do some things in a certain way, but it's not very restrictive. But they're they're gonna identify what sort of resources are you using.

Bill:

You're using a database? Are you using PubSub? Are you using this? Are you using that? Right?

Bill:

And they identify what your resources are. And and then, they build your binary by including their runtime behind it. And then if you're leveraging their SDK, they can identify the resources you're using, and they can create a path to deployment. So, you basically do an encore build instead of a go build. They're using a lot of the go tooling behind it, especially for testing.

Bill:

If you do encore test, it's running go test after it builds in, adds its code. Right? It's back end code. Your it's runtime code into your product. So it's all seamless.

Bill:

And then at that point, you have a go binary with their runtime behind it and all of your application logic. And, you could deploy that pretty much anywhere. So, like, the thing I played with this week, which was actually I'm always sus. I'm, like, one of these person where I'm, like, sus first, like, and then I I get wrapped my head around. I'm like, okay.

Bill:

That was cool. So, one thing I played with this week, which was really cool. Right? So I have my sales service, and it and it handles a bunch of crud. But I wanted to add a second service to this thing.

Bill:

And, I I decided to pull all the authentication out. So made a little auth service, okay, that basically executes open policy agent stuff on behalf of any service that would be part of this project. And here's the cool part. Okay? So to talk to another service, you have to normally choose a protocol.

Bill:

Is it gonna be h t p? Is it gonna be gRPC? Right? You gotta think about that. And then, let's say we're just gonna keep it simple.

Bill:

We're gonna do HTTP. So now you have to make HTTP calls to the other service. Right? So you wrote your handlers in the other service. You gotta do raw HTTP to the other service.

Bill:

You got there's work there. Right? There's a thousand lines of code that you have to write there even if you package it. Well, with Encore, all I have to do is basically call an endpoint that I wrote in the other service. So it's one project with 2 services.

Bill:

And, Encore builds out a set of, endpoints, in Go code that basically, represents the, web API. And all I have to do is write, make a call to that go function. And when I encore build, it builds out all of the protocol communication behind it. Right? Mhmm.

Bill:

So they launch it as 2 services. In my Go code, I'm just making a function call. But when this thing's running, it's an actual HTTP call between these two services with all that marshaling and all that all that stuff that I would that I had to write manually, that that's where their runtime is coming in. Right? So they've got their own sort of networking gateway that's built into that.

Bill:

They they handle all that protocol and marshaling work that you'd have to do. And, all I have to do in my code is is make a function call essentially. And then during build, they convert that function call into all the protocol work. Like, amazing. Right?

Bill:

Yeah. Wow. Yeah.

Dominic:

That's that sounds a little bit crazy. Okay. Wait wait wait a minute. There there's so many thing. I'm sorry I'm sorry to stay on that topic, but I

Bill:

No. We could talk about this before this whole time because I I I think it's let me just say this. That alone now, I had I had service to service I had a deployment with multiple services. I had a service to service communication, and I had it all in in seconds, essentially. Right?

Bill:

So I had it all within the time it took me to just make the function call inside the COCO. I didn't have to do anything else. Right? So that's where you're getting that productivity sort of because look, dude. We've all written the protocol stuff before.

Bill:

We can all write HTTP handlers, and we can all call JSON dot on Marshall. Like, we can do all that, and I do that in the service project. Right? I teach you that. Right?

Bill:

I teach you how to package that. I teach you how to make that, more solid engineering. But, it's at this point, that stuff is so sort of redundant and and and rudimentary and, like, the it's just boring at this point. Right?

Dominic:

Yeah.

Bill:

They've basically, with their compile static analysis, compile run and runtime, they've just those are the things they've just taken off your plate. Right? Just think about data in terms of data structures. Think about data in terms of APIs, which we do. Right?

Bill:

But now think about it also between, say, a protocol community. I I I say protocol because I'm just saying it could be h t p. Right. They don't have strong support for gRPC yet, but it doesn't mean they couldn't add that. Right?

Bill:

But if you if you're willing to just do h t p communication between all your services, you basically don't have to think about the protocol level stuff. You're just making function calls in your code, and they take care of the rest.

Dominic:

But yeah. Wait wait a minute. I just want to understand this part. So when you say you just do a function call, so is it a function from the, you know, encore packages? You know, what what is that function?

Bill:

Yeah. So when you define an encore service, you define a set of, methods with annotations on top that tell encore, hey. This method here represents an HTTP route. It's going to be a post call. This is what the route looks like, and then it looks at what your function signature is to determine what the input is and what the output is.

Bill:

Okay? And then what happens is, Encore runs this this daemon that's always kinda running on your machine behind the scenes. So when you make any code changes, it goes behind the scenes and starts to re rebuild that software and let you know if there's any problems. But it writes, one code file out that is basically the, the interface of your web API in Go functions. So it it it basically produces a set of, functions that represent the web API.

Bill:

And all you have to do in your code is essentially import that file and execute one of those functions. And, those functions are shells, by the way. If you opened it up, you would just see comments like, hey. We're gonna fill this in, when we do the final build. That that's basically what the comment says for all these functions.

Bill:

Right? Like, you don't have to fill this in because we're gonna fill this in. And then all you do is you make a call to one of these I'm gonna call it fake functions because it from your perspective, they're fake until Encore does its build. And then when Encore does this static code analysis and it sees, hey. The Encore service in this folder is calling, an on calling a function from the Encore service in that folder.

Bill:

Oh, they want an HTTP protocol call there. Okay. We'll do that.

Dominic:

That is that that is crazy. I mean, I I, wow. Okay. I need I need to I need to you I need to check that out for sure.

Bill:

It's a lot of work to do what they've done. And I I think what's and I don't really know how long the project's been going on. It's definitely for several years. But I think what's super impressive is how stable that that stuff has gotten. You know, there's a lot of things that people want, and they've been also really good to prioritize.

Dominic:

Yeah.

Bill:

You know, there's a small team. So and testing is is is been really interesting too. I can we've we're able to do a lot of there's a lot of flexibility also with the ability to test and test against your postgres database. Right? That they're, they're they're starting for you too.

Bill:

So you don't even have to think about here's the other cool part is, you don't have to think about Docker. You don't have to I mean, you have to have Docker installed and all that, but you don't have to think about what am I what am I downloading? What am I doing? What are is there a new like, they take care of all that sort of stuff. So when I say encore up, it already knows I need a database, starts 1 in Docker.

Bill:

If I'm doing pubsub, it already knows I need, one of those services. It just it has its own, and it starts it up.

Dominic:

So you mean from a developer point of view? I I you know, there's a new developer joining a team. They just just need to do encore up, and that's it.

Bill:

Yeah. I I call it encore up because I have my make files, but it's basically, yeah, like an encore build and start. And they that's it. That's all they have to do. Nice.

Bill:

And then if you're gonna deploy this, let's say to, Google Cloud Run, they have some commands and they already provision everything that your app says it needs. They provision the database. They provision the pops up. They provision whatever that is, man.

Dominic:

Okay. And then I say that I suppose that they are also able to deploy the 2 services completely separated.

Bill:

The whole thing. They just do it. Right? Now not all shops want the deployment piece, which is fine. Yeah.

Bill:

But if you're a small shop, it's, like, we use Google Cloud Run and Build at Arden, and they have great support for that. Right? So for those kind of shops, like, I would say my shops, I for sure, that's like a home run. Mhmm. I I feel like their their kuber they still need some work on the Kubernetes sort of stuff.

Bill:

Again, from a Kubernetes perspective, you can containerize your your go apps here. Your I call it your Encore app, and then deploy it any way you want. But they've been working on on better and better sort of Kubernetes support as well.

Dominic:

So from the point of view, so so you you were mentioning that you started to modify an existing application that you had. So I would assume that if you if you kept the normal, you know, HTTP, response writer in the the HTTP request kind of function prototype, then you are all set and and it it should be kind of straightforward to, to use that?

Bill:

So I've been teaching for the last 5 years, a software design class where I teach right from the beginning. Right? Where pair programming, how to build what I call production level, web services in Go with a with a domain driven data oriented architecture. And I teach that stuff and I I love this project and I use it in when I decide to take a project on, you know, art and we take on projects. And I usually choose, like, one project a year that I'm gonna work on.

Bill:

Usually, you know, a 3 to 6 month project. And I use this code base. And my the people on my team or people already know this code base and we use it and I love it. So for me, going and saying I'm gonna try Encore was, can I take my service class and my software design, my architecture, and everything that I teach? And can I incorporate that using Encore without losing it, right, without being told that I can't write software and design software like this?

Bill:

That was my number one sort of, test for for the Encore. And, one, I was able to do that. But one thing that that came back at me when I started playing with Encore, which I never thought about before, was this I've added a new layer to the project, essentially. This idea of separating, I'm gonna call it the protocol from the app. So if you were to look at, earlier versions of service in my application layer, you would have seen all the raw HTTP handlers there.

Bill:

Mhmm. And you would have seen the code inside the handlers that did the unmarshalling. Let's say it's a post request. Right? So let's unmarshal the JSON into this and then call into the business layer and then send the response.

Bill:

That would have been inside the HTTP handler code, which for me was the app layer. And this one idea that I got from Encore was, you know, why don't we add a why don't we separate the protocol layer from the app layer? In other words, the app layer shouldn't know or think about HTTP. It should just think about data structures, which is what Encore wants you to think about. And so since Encore does all the protocol work underneath the the scenes, right, that protocol layer is hidden from you in Encore.

Bill:

So your app layer in Encore is a set of, handlers or we call them APIs, but they're they're data structure based. So one thing I did on service is I said, let's do this separation. So I added a an a I called it APIs because I wanted it to sit way on top. But I called it an APIs layer where we have those handlers, the HTTP handlers there. But all they do is the unmarshalling because you gotta do the unmarshalling there.

Bill:

And then they call into the app layer, which is your handlers in in data structure form. Now what's super cool about this, right, is that I don't know what percent. Let's just call it 90%. 90% of your app now, right, is sitting underneath the protocol layer, which now means, and something I've never really been able to do but I'm gonna try to do it next month, is I should be able to build a service now in my original project where it's not HTTP, which is the protocol, but gRPC. Mhmm.

Bill:

Because now I can build a service in gRPC where I just have to worry about those gRPC handlers that call into the app layer. So I just have to go from the protocol to the data structure and call it to the app layer, and I'm done. Everything works the same. Right? It's all about how you're marshaling data in and out of the system.

Bill:

So for me, the APIs layer, I call it my protocol layer now, is all about what protocol do you wanna talk in. You wanna talk HTTP? You wanna talk gRPC? You wanna talk something else? That's fine.

Bill:

You just do that because at that point, once you get the data off the wire and marshal it into the right data structure, you can flow that now into the rest of the app. And I would say this is what Encore has done, without you having to worry about the APIs layer. Right? They've done the protocol. Now I wish they had stronger support for gRPC.

Bill:

It's not a priority for them. Because then you could essentially do the same thing in Encore. Right? It's like build your app layer that calls into your business layer, that calls into your storage layer. Keep that.

Bill:

And then you can decide later on what protocol do you want to talk. Right? You want to talk HP or PC. And it would be beautiful if Encore could then build build that plumbing. Right?

Bill:

Where I have to do I have to write the plumbing in service, Encore is writing that plumbing.

Dominic:

Yeah. That's that's interesting. One one thing, that I'm thinking at this moment is that because I I I always need to do something like that. When when there's some kind of API at some point, there has to be 1 or 2, you know, background processes. Call call that what you want, but they will be CLI at the end of the day, which needs to call what you what you would call the business layer probably in in your, you know, in in your architecture.

Dominic:

And now they could they could directly call still call the application layer because now we we have removed the the protocol from from the function call.

Bill:

Your app layer is your is the API now. Right? Like, you don't go to the business layer directly. You go through the app layer, which isn't protocol driven anymore. It's data structure driven.

Bill:

So that's the big change in service. And now you add a layer on top, which is your protocol.

Dominic:

Very Just interesting.

Bill:

Yeah. Right? So and that idea came from Encore because Encore basically said to me, well, you're Applayer. Right? They don't they don't tie you into any sort of data model or data architecture.

Bill:

Okay? So I I'm still able to apply my what I call my domain driven data oriented architecture there. So whatever architecture you like and wanna use, Encore is not gonna stop you from using it. But the idea was that your app, your your handlers, or or your your entry point to the outside world is now data structure driven, not protocol driven. So to a point, and I was pushing back at first, and I saw the light within a few weeks.

Bill:

Right? You always push back, and then you at least I always push back and then I have to give myself a couple of days to like like chew on that. Right? So, you can't even access a a request object or anything. Right?

Bill:

Like, they've really done a good job of keeping it all away from you. So if you to to keep you safe from the protocol. Right? The only thing I would say even even if you want even if you're doing auth, which they have a great system for auth handlers and stuff, you're defining a data structure with things in it, and they're marshaling into that. So Yeah.

Bill:

The it was nice. It's nice.

Dominic:

That's what I was I was going to say because, you know, at always involves some kind of middleware and some kind of rejection at the at the HTTP level if if we are, you know, still still talking HTTP. So

Bill:

so they've handled all that plumbing, Don. They've handled all of the plumbing where I had to manually put the plumbing in. They've handled it. So I I would say right now, one one thing I one wall I kinda hit this week with the auth stuff is so they have an auth handler that you code, and there you can do your basic auth or j w t auth. Right?

Bill:

Mhmm. And then I use middleware for the the next level of authorization. And I use OPA, open policy agent. I love that stuff. The one thing that I've I find interesting is you can have a project with multiple services in it, but they have a restriction where you can only have a single auth handler for the entire project.

Bill:

Now that was like mind blowing to me because I would I thought I could have this auth handler be unique for every service. Right? But it's kind of like global. So one of the things I had to do, that I don't do in the other project is I had to add a an auth service, which took so this is interesting. Okay?

Bill:

Actually, this is like this is where I spent my entire day on yesterday. In the service project, the idea is that you have middleware that gets executed to do auth, and I use OPA. So so those middlewares call into the OPA APIs and auth is done, and I make my middleware reusable. So if there's multiple services that need to do auth, they can just include this middleware. And inside the middleware, let's say you're making your calls to OPA, whether that's in proc or external.

Bill:

And I think of OPA as my auth service. Right? I don't need to build another service for that. And that would just be an extra level of indirection. But because Encore only has the concept of a single auth handler, So I had to put that somewhere centralized.

Bill:

So I added an auth service in Encore, which I don't have in in in the other project. And here's the interesting part. Okay? This is like when your mind starts to get sort of blown out. This this is a a go function.

Bill:

It's a handler. Right? That has to get called. And it has to belong to one of your services. So I add an auth service, and I say that the auth service is the sole owner of the auth handler because I have to do that.

Bill:

Now, here's the cool part. Okay? When one of the other services get called and the auth handler has to get executed, when this is deployed, because Encore does all the plumbing, that call to the off handler ends up being a protocol call. Right? An HTP call to the auth service.

Bill:

I don't I don't have to do that. You see what I'm saying? You get that auto magically. Yeah. And so when you step back and see that and you say, why did Encore do that?

Bill:

Because Encore always felt that you were gonna have it off a separate off service at a microservice architecture. So everybody just needed to attach themselves to that auth handler, and we'll figure out who owns it, and we'll do the plumbing to execute it. You you see where it comes from? Yeah. So it's interesting.

Bill:

Right? Like, took a different approach in service, and I said, well, I'm using a third party auth service, so I need all my services to talk to that. Encore said, well, you're gonna have your own auth service. So let's put that handler in your auth service, and I'll make sure the plumbing goes there. So interesting stuff.

Bill:

Right? Interesting. But because they do the plumbing for you, it's not this big ordeal. It's not this drag. It's not this.

Bill:

Oh, man. I'm gonna lose the next 3 hours because now I gotta worry about how do I start this second service and how do I make that call across and I gotta build a package to do that. Like, nope. You just just define the function and you're done.

Dominic:

Yeah.

Bill:

Game on.

Dominic:

Oh, totally. I mean, it's it seems it seems interesting because like you said, I mean, those those kind of things, kind of are repetitive at the at the end of the day when I've I've been doing Go since 2,014 actually. So 10 years now. So yes. If I can, if I can skip the the JSON on Marshall and and things like that, it seems, but but but the intercommunication between between your services seems to be just crazy removing everything.

Dominic:

So yeah.

Bill:

Yeah. As long as you're right now okay with HTTP communication, which I always have been. Like, I I I've seen too many projects choose gRPC, which adds such a level of complexity. And I'm always like, was that really necessary? Like, all your services are in Go.

Bill:

Don't give me the performance sort of answer because, you know, what are you doing? And, I'm, like, 8 out of 10 times, the the the person finally just admits they could have used HTP and everything would have been fine. I'm not saying there aren't projects out there where the answer is gRPC. Right? You're in a polyglot environment or for whatever reason, performance on the wire is critically important.

Bill:

And it's obvious that it's critically important then, yeah, you should add the complexity. Because for me, you know, there's this balance there's this constant balance between complexity and performance. I feel like every time you say this has to be more performant, you have to add more complexity to a situation. Yeah. And so there's this balance that you have to find where I've the performance is good enough for the complexity for the complexity that I'm at.

Bill:

Right? And I'm not saying there aren't projects where you have to your performance is so critical. Edge stuff maybe things like that where you have to live with that high level of complexity but that's not every project. Right? And I just wish more developers and engineers were more honest about this complexity performance sort of ratio.

Bill:

I think there's a lot of projects using gRPC that don't need to be using gRPC. So the fact that Encore is doing this inter, service communication with htp obviously doesn't bother me at all, especially for most of the projects. In fact, let me just say this. I've never worked on a project where we need a gRPC for any sort of interservice communication. It just I I I've never turned around and said we absolutely need gRPC here.

Bill:

If anything, I've ripped it out of more projects than I've than I used to.

Dominic:

I I'm I'm with you on that. I I think I think gRPC though is is like it's performance. Yes. But I think the contract that you are establishing between your services is what you what those teams might be chasing, you know, kind of similar to what, you know, SOAP services was back back in the old days. But I I think that's another reason why gRPC could be I don't know.

Bill:

Yeah. If you're a Google and you've got a thousand or Uber and your whole company velocity is based on on services, then you need that and versioning and all the other stuff that comes with it. I'm not saying there isn't value in it. I just wanna question so many small projects

Dominic:

Oh, yeah. Oh, no. I'm with you.

Bill:

That are using it without doing this sort of complexity performance evaluation is, you know, is what I'm saying.

Dominic:

I was, I was wondering

Bill:

is in a a fun project I'm working on with my wife called, Liar's Dice. So in between projects, I I go back to this, pride. It's under our lives called liar's dice. It's a it's, a mix of Go and Ethereum Oh. Where we're building a Liar's Dice game.

Bill:

But it's web 3. So you you connect your wallet to the game. You throw some money into the in into the smart contract bank, and then you can bet games. So you can play a game of liar's dice with somebody for, like, a $5 ante. Right?

Bill:

And you play and then, I don't think this will ever get on mainnet. Hopefully, testnet one day. And I've gone through some iterations of this, and we've had some UIs. But I wanted my wife to build a new UI in Phaser Phaser IO. And I was working on a lot of JavaScript to to be able to have the browser communicate with the MetaMask wallet at least to start and, all the stuff that has to go on between the wallet, the browser, and the and the game engine.

Bill:

So that's where the JavaScript stuff was coming from. And, actually, I I I didn't even know about JavaScript modules, and I've learned that. And, dude, it's been like a month since I looked at that code now since I've been working on Encore. But once I'm done with the Encore stuff, I'll go back to that. And that's just my fun game to keep my programming up because look, man.

Bill:

I mean, my my the priority of the majority of my time is teaching. Right? It's teaching Go, teaching software design, teaching architecture. And there are these lulls in time where excuse me. You know, I I don't have anything new I wanna add to the project or there isn't a client project that's come across my desk that I find super interesting to dedicate time to.

Bill:

But I can't not be programming because I can't be in a classroom where I haven't programmed in 3 months and Yeah. Expect anybody to listen to me. So, I find these little projects like this liar's dice game that allows me to keep my skills up. It's fairly technical. And, again, you're learning.

Bill:

Every time you learn something, you can bring that back into the material that you're teaching.

Dominic:

Yeah. Totally. I I do the same with, with software as a service. I've been building software as a service since 2008. And, yes.

Dominic:

This this to me because at the end of the day, sometimes and I I know that it's not it's not similar to to what you are doing with your teaching and being there in a class and whatnot, but sometimes, you know, your day job might not bring everything that you need, especially if you are if you are extremely curious. So I always I always need a a project myself as well. So, something that I really like.

Bill:

So Yeah. So it's it's it's been a fun project.

Dominic:

Nice. What, what brought you to, to go, Bill? Actually, I'm I'm curious to to understand, you know, what, you know, what what what were you doing before and and what, what happened for you to to choose choose go or try go at some point?

Bill:

Wow. Excuse me. So I I've I was from my first paid job is in 19, I guess, 92, as a c developer. Then about a few years after that, I moved to Miami and started coding. I continue to code in c and c plus plus.

Bill:

And then in 2,002, I started coding in c sharp. So I've always been programming on the Microsoft sort of OS Microsoft platforms. And in 2,000 and, 10, essentially 2,000, actually, no. In 2011, my business partner Ed Gonzalez and I, that's when we started Arden Labs. So we, we left our company and we started this consulting business.

Bill:

We we had our first client in 2011. And again, we were coding in c sharp and and and and building solutions out on that platform. And then in about 2013, the city of Miami Beach had a big project, big, big project, and we wanted to bid on it. And so it was the first time we were bidding on anything and we went through the whole process and we realized at the end of that, that Microsoft was gonna make more money than we were in licensing fees. And we realized that we weren't gonna have a company very long if all of our bids were gonna be twice as much as the Linux teams.

Bill:

So we went, oh shit. I mean, we've got 25 years of experience on this platform and we have to walk away from it. So Ed had already been looking at Ruby and was already playing with Ruby at the time. But he basically said, Bill, you need to start programming on Linux and learn Linux, which was really depressing because I could tell you the internals of the Windows operating system inside and out. Right?

Bill:

I now have to learn a new operating system and a new programming language. It was like starting over. But long story short, I looked at a bunch of programming languages. Didn't like any of them. Thought I was gonna have to continue to stay on c sharp for a while.

Bill:

And then Ed told me to go look at Go, which was in 1.2 at the time. And over a period of, a few hours on the weekend, I fell in love with the language. And I said, Ed, okay. Yeah. I can transition now to, to Linux.

Bill:

So 2013, we did it kind of out of necessity to keep the company sort of, viable. And, look where we are now. So it's it's been a good ride.

Dominic:

Sounds great. Yeah. Similar to to how I I jumped on on Go. I I was working at this this startup. I was building everything in in in JavaScript actually, so front end and back end.

Dominic:

And at some point I woke up and I said, screw that. I'm rewriting everything. And I was I was looking at Go for a couple of weeks now, and I was like, you know what? This is exactly what I want, you know, me to work on every day and and be, be a little bit more safe with with what I'm building. So, I I also have a a dot net background.

Dominic:

So it's interesting. I did not knew that you were coming from c sharp. And now I I might start to understand where the the demand the demand line, comes in a little bit.

Bill:

Well, the domain stuff is new for me just over the last Oh. Few years, thinking about how you create firewalls between the different parts of your program. Right? I mean, for me, software design and architecture is all about where are you placing those firewalls and how are you able to sort of maintain those firewalls properly? Packaging gives you a set of firewalls, you know, horizontal layering gives you a set of firewalls.

Bill:

I think domain allows you to start having what I call these sort of vertical firewalls, in your architecture. And too many people, I think, gravitate to microservices for these vertical firewalls. And I've tried to figure out how do you add these sort of vertical firewalls inside the scope of a single project, before you need to get to microservices. Right? So, again, just to reduce complexity.

Bill:

And and that's kind of the stuff I've been really thinking about studying. And I think I have a good sort of solution right now to that. It works, but it does require developer discipline. But, I mean, at some level, what doesn't require

Dominic:

Right.

Bill:

Developer discipline. Right? So, so that's kinda just the last few years. If you had looked at my c sharp, man, you would have seen so many static classes and static methods Because I hated the idea when I moved from c to c plus plus and then c sharp where everything had to be a class. I hated the idea that everything had to be state and behavior.

Bill:

Like, not all behavior requires state. And so the keyword static became my sort of go to. Right? I was just using classes as a namespace to define a set of functions. So I've always been a minimalist in terms of what a language or a framework provides.

Bill:

And, it was just nice when I got back to go because I got my functions back. I think that was one of the first things I said out loud. I got my functions back.

Dominic:

Do do you think that the lack of project structure though is a little bit distracting? And and I I've said it a lot in this podcast. And to be frank, I don't understand why. But it seems like because people are coming from all over languages and and different things where, you know, they they are they are used to have some kind of project structure. It's it's done for them.

Dominic:

They don't need to, you know, it's it's one less thing to think about. In my opinion, I I don't see a problem, but it seems like, I don't know. It's it seems like, it might be. I don't know. What what are your thoughts on that?

Bill:

Your goal as a software engineer has to be as a priority to reduce complexity, every opportunity that you have. It has to be about wrangling and reducing complexity and allowing the average developer on that project to be able to maintain a mental model of the code that they're working on. Because if you don't wrangle the complexity and the project will become unmaintainable at some point, and if you can't maintain a mental model of the project, then the you're just adding bugs with every release. You're not reducing them. So for me, an architecture and a project structure is designed to help you in these 2 sort of right?

Bill:

In these 2 ways. It's there to help you make sure that you're not adding but, reducing complexity in terms of worth and mental models. Right? It's allowing you to maintain a mental model of the project. Where are these things that do whatever they do?

Bill:

Where's the flow? Right? It sets up rules for what code can be where, how, and why. And then all of that helps you to start thinking about the complexity that you're adding and and and help if you can't reduce it, at least not add to it. Right?

Bill:

One of my favorite quotes is that you can't take a complex problem and make it simpler, but you can surely make it more complex. Right. And so I I think architecture and design, when done right, allows you to have those mental models, allows anybody to come on the project and fairly quickly develop a mental model for it, which means that project is now maintainable. And, allows you to make the the best decision that you can at that moment in time to help at least if not reduce, not increase, levels of complexity, which will happen when when it's chaos. If there's no rules and there's no guidelines, then anybody can do what they want.

Bill:

Then that project's going to, at some point, begin to fail. And fail means that you're adding more bugs than you're fixing. Fail means that nobody can maintain it anymore. Fails. Fail means that it's just it's just causing more problems than good.

Dominic:

Yeah. That that's interesting. Were were you always thinking like that? Or or you would say that since you adopt Go, the complexity now is is difficult to accept, I would say?

Bill:

I alright. I'm not how do I say this without I was a c student in high school, dude. K? I barely got into college. My brain does not function at the level of most of the people that I've been fortunate enough to meet.

Bill:

Okay? Yeah. So there are things that people just look at. They see code, they do this, and it's like an instant sort of I understand how that works. I struggle.

Bill:

It takes me hours. Sometimes it takes somebody minutes. It takes me hours. So just as a maybe defense mechanism, I've had to always find ways to reduce the complexity of anything I'm working on. Just because my that's for what my brain can basically handle.

Bill:

Okay? And I think it's has served me well. I think it helps me also from a teaching perspective because I have to learn things at at at a such a certain level that then I'm able to sort of communicate that to to others. Right. So I I think it's because my brain doesn't function as high as like people coming out of it.

Bill:

Am I just, I'm not trashing myself here. I just it's just the reality. Right? So but look. I'm also not clueless.

Bill:

Right? I I know that I'm still smarter than 50% of the people on this planet even though there's 50% more people smarter than me. Right? I'm just the average the average sort of developer here. And so I gotta find ways to keep the complexity at a level that I can handle because I'm responsible for for managing sort of that code.

Bill:

And if things start to get too complex and I can't figure it out and somebody can't teach it to me, I just can't have it. I just I just can't have it. So I think that's kinda where this comes from, and it wasn't just Go. Go has allowed me to keep things simpler. And I like I said, I always use the bare minimum of everything.

Bill:

I use the bare minimum set of c sharp and c plus plus and frameworks and SDKs. I use the bare minimum of everything just so I could keep my brain wrapped around what I was doing in the mental models and stuff. So I would argue that it's more of a defense mechanism than it is, a choice. I'm sure. I'd love, dude, I'd love to have a brain that could comprehend how somebody developed enough math to know that in, like, 2044, we're gonna have the next solar eclipse over Montana.

Bill:

Right? Like, there are ridiculously brilliant people with brains that can do ridiculously amazing. My my daughter-in-law, Madonna, my stepdaughter who's, 16. Okay. She's got, like, a 14/20 on the SAT.

Bill:

I look at her sometimes, and I say, I wish I had your brain for just 3 days. If I had your brain for 3 days, what I could do. Right? What I could do with your brain. And it's okay.

Bill:

I'm not mad or upset about it. It is what it is. And I think I've done a lot with what my brain can sort of handle and process. So I'm proud of myself there. But it that's where it comes from.

Dominic:

Yeah. It's funny. I I I post something last week on Twitter, you know, with with without rehearsing everything that you just said. But, I I was curious to see where I was, and I I I tried to to do a an interview at Amazon just for fun. I mean, I've I've been I've been running my own company since 2008, to be frank, so doing consulting.

Dominic:

So I I have never been an employee. The last time was in October 2007. So I did not really add much interview in the last, I don't know, whatever, 13 years, what and, I completely failed. Completely failed. And I I've been programming, professionally for, like, more than than 23, 24 years now.

Dominic:

I so I found that important to say that on Twitter, you know. Maybe for younger programmer, you know, just be careful. It's not,

Bill:

It also depends on what they're they're interviewing at. Right? Because if you if I get into an interview and you wanna talk about architecture and design and those things, I think I would do pretty well.

Dominic:

Yeah. That was not true.

Bill:

If you wanna talk about data structures, I think I would do pretty well.

Dominic:

It was delete code. You know, things like, I don't I don't even know. They they give you they give you a a small problem, and you need to but it it has nothing to do you you will never do that in real life. So I'm I'm I'm proud of myself because I'm I'm fixing business problem. So I've I've entirely built a a credit bureau in your area in Canada that got acquired by Equifax.

Dominic:

So I mean, at at some point, I I I know that I'm able to build things that that stand the test of time and that has some real value for bigger organization. But, I was surprised at how, how those things are handled as well. That Well,

Bill:

you know, there are academic level computer science problems that I am not the right person to be working on. Mhmm. I know that. Well, like Damien Griskey, who god, god. I haven't talked to Damien in so long.

Bill:

That guy that guy is amazing. Right? Like, I want Damien working on those academic computer science problems. And we have a bunch of them, and they need to be solved. I am not the person for that.

Bill:

Yeah. But it just like like you're saying, if you've got a sort of business domain problem, then I'm like the perfect person for that. And look, I would almost argue that the people working on these academic problems, you probably don't want working on the business problems. Right?

Dominic:

Yeah. Yeah.

Bill:

Even I've heard Russ and I'll paraphrase here. I've even heard Russ Cox say, you know, like I I work on compilers. Right? I don't build Yeah. I don't build web APIs.

Bill:

So and it's not to say that he couldn't do it, but I don't know. I I think he recognizes that he's not gonna build the best web application that somebody else could build because that's not what he focuses on. Right? That's not where his where his passion lies. So there are problems for everybody and all sorts of brains and all sorts of interests.

Bill:

And, hopefully you're working in, in that area that you want to work in. So I'm not working on academic problems. And if you give me an academic interview, yeah. I'm gonna fail miserably, dude. That's not where that's not where my experience in my computing or my brain can go.

Dominic:

Hey. Yeah. Yeah. Interview interviews is such a a topic in itself. I think I think, we are not doing very good.

Dominic:

But let's not focus on that. I want to you said something. I heard you said something. I was looking at a couple of, YouTube video video view before interviewing. You said something that caught my attention very, you know, strongly, I would say.

Dominic:

You said something like, I'm paraphrasing. Sorry about that. But, we do introduce complexity in

Bill:

our systems because to,

Dominic:

you know, be because we need systems because to you know, be because we need to handle the fact that there will be people problem. And I found it interesting. And I understand what you're trying to say and what but as an industry, you know, I don't I don't I don't believe that the onboarding of of new of new engineer, is is that great. I think we could do better because you you were saying something like, well, we we might need to introduce, you know, some complexity to a system because there will be people going in and getting and getting out and things like that. So and I understand that, but is it the bet the best that we can do?

Bill:

It becomes, I think too many engineers are forgetting that they're hired and being paid to solve problems. And those problems have to result in either increased revenue, so I can pay your salary Mhmm. Or decreasing cost, so I can pay your salary. Yeah. But you exist at company x to help solve a business problem, to allow that company to exist, grow, and unless you're working for a nonprofit, generate profits.

Bill:

Alright. So you start there. And so now you have this project in front of you that the company has decided it's going to invest time and resources in. There's probably some form of time constraint that if we don't get this done within a certain amount of time, it either we either don't maximize our benefit or we end up no longer needing it. Okay?

Bill:

And so now you've got to identify how many people do we need to get this project done within that timeframe in order for us to be successful. K? Now, there are people problems all around that. Right? How many people?

Bill:

If we only need 1 person, well, then the code base can be simplified down to the fact that only one human being is going to be working on it at any given time. That person can't trip themselves up because they're basically as, a singularity. Right? Mhmm. But if it's decided that we really need 3 people on this project, even still small, well, what what parts are they gonna be working on so they're not stepping on each other's toes all the time?

Bill:

So they're working at the highest level of velocity possible. Right? And how are you gonna build the firewalls between them? And when they do have to come together, how are we gonna make that productive? And for what I'm teaching right?

Bill:

I'm teaching really around how you can get, I would say, 3 to 5 people on a project. And that's just not one service. It could be multiple services and tools, but 3 to 5 people in a single repo, single project working together at a high velocity and the ability to throw maybe one more person in there when you need it. That's what I'm teaching. Domain driven data oriented design for me is all about, don't go to microservices just yet.

Bill:

Let me show you how to how to be that level of production. Let me show you how to build the firewalls around those people. Now, at some point, you have so much more work that you need to get done that you really need more people. How do you stop them from stepping on each other? This is for me where you start getting into the Ubers of the world.

Bill:

Right? Mhmm. Now what you're doing is you're building mini teams of 3 to 5 people. They all have to work on their own service. My ideas around domain driven data aren't oriented.

Bill:

I still work. Right? They work at these team levels. But now what you're doing is you got the microservice architecture. We've added complexity because these architectures have to talk.

Bill:

These services have talked to each other. But you did this because one team wasn't gonna finish all the software that had to be written in time to get us to this place. Right? And so you've decided that if we're gonna have 3 teams, they can't be stepping on everybody. They have to stay in their silo, in their firewall, and we have to meet somewhere.

Bill:

So this is what I was trying to say. Right? There's that when you start adding complexity to architecture, we're we should be doing it because we have a people say velocity problem. We shouldn't be doing it because we wanna play with microservices. No.

Bill:

If you just have one team of 3 to 5 people, you probably don't need it. Right? But once there's so much functionality that has to be done at the same time, has to be done in parallel. How do you do that and maintain developer productivity? That's that's the question there.

Bill:

And microservices has has been a solution to that. Right? And I think companies like Uber and Google have proven that it can work when you're at that scale. And there's other talks and things you can hear about about how those teams run. But even those teams need an architecture.

Bill:

And I think that's what I'm teaching in in sort of service. Right? That how do you get that team of 3 to 5 people to be as productive as possible, in that project? And again, it's all about these firewall. Where are you putting your firewalls?

Bill:

How are they helping these team members sort of execute in isolation and only have to kinda come together, in these small moments and to keep things keep things going. So that's kinda what I was talking about in terms of, architecture complexity and and, velocity there.

Dominic:

That makes sense. That makes sense. Yeah. So maybe maybe I have one last question about, about Demand Driven a little bit. So I'm I'm curious to hear your thought about you seems to push the idea of having, you know, multiple class inside your your level.

Dominic:

So let's let's say if a good old 3 tiers application, application layer, the business logic, business rules, and the storage, or the database. Well, let's say storage. I think it's a good word that you're you that you're using. So you seems to to redefine those type. Let's say, a user.

Dominic:

So I I think you are using, this this example a lot. So I could not I could not stop to to see, you know, and you might notice this guy. So, you know, Scott and Solman saying, well, you you are doing a lot of right left programming. So you're basically filling, you know, fields from a struct from one side to the other mode, you know, when you are jumping to the next level. Is it, you know, it could could it not be just one type?

Bill:

It absolutely can't be one type. You really need every layer, that horizontal layer to have its own type system because it's it's it's providing 2 things that it's just too critical to architecture. The first thing that it's providing is it's protecting the APIs at every layer. So the last thing you want is someone in the business layer to change a struct and suddenly your web API changes with it. So you can't have that.

Bill:

You can't have that. That's leaking a change. Right? The app layer models are what are being defined for data to come in and out of the system externally, and the business layer models are defined to allow data coming in and out of that layer. And and that data also is going to look different.

Bill:

It is You might see the same field names, but that data is gonna be shaped differently. And that's the other critical part. You cannot be writing you need we have this old saying. Right? Bad data in, bad data out.

Dominic:

Mhmm.

Bill:

Data has to be validated. But you cannot be doing data validation with if statements at every layer. And layers have to be able to trust the layers above them to have done the data validation that needs to be done. What's beautiful about every layer having its own data models is every layer has its own sort of type system for those fields. And what that does is it forces, and I would say at a compiler level, data validation to happen before you transition to the next layer.

Bill:

So data coming into a web app is probably all, scalar types, strings, ints, and bools. Mhmm. I don't use types beyond that at the app layer because I wanna do some data validation there, and I don't want the unmarshalling to fail. Unless I was supposed to get a string and you gave me an int. Right?

Bill:

Right. I don't want that. So when you're using types like string, what you're saying is the data can be anything. Right? Like the data can be anything because I haven't built a type around it to shape that data just yet.

Bill:

A string isn't really a a data shape beyond the fact that it isn't in it. But in the business layer, okay, a lot of those strings need to turn into a UUID. They need to turn into, a time dot time. They they need to take shape. And for you to move that data from the app layer to the business layer requires you to do a data conversion from string to time, or string to UUID or string to roll.

Bill:

And that conversion that's happening at the app layer is your data validation. And it's forced upon the app layer to do it because it can't move the data until it's shaped. Right? And so now you don't need an if statement to validate the data because in that call to parsing the data from from string to UUID or string to time or string to whatever, if that fails, then the data validation has failed. And so you want these data models in these different this is why I I say you don't want more than 5 layers ever.

Bill:

3 is great. And by forcing the data to be reshaped as it moves down and back up the stack, you are forcing the data validation and therefore you're enforcing data integrity, and you're enforcing it at compile time because the code won't compile unless that data is shaped into its proper types And those parse functions are, making sure at runtime that the data flowing in and out of this system in each layer is what it's supposed to be.

Dominic:

And those, so so I I, I imagine that if you have some parse function, you you will need to have the reverse. So let's say you are fetching a list of users from the database. It means that when you are traversing up to the layer, you need to convert those into

Bill:

That's right. But the app layer would get the business layer's in the middle. So the app layer has to convert its data models to business layers and get the business layer models back and convert it. Same thing with the storage layer. Right?

Bill:

Mhmm. So the business model is the is essentially the the data structures for the project. It it is what the data is, what the data is that comes in and comes out. The app layer now, you know, your app layer could be a CLI tool, couldn't it? Yeah.

Bill:

Where data's coming in as, you know, as input and things like that. So, the business layer says, this is what our data model actually looks like. The storage layer says, okay, I can take your data model and and shape it in a way that I can actually persist and retrieve. And the app layer says, okay, I could take your data model and shape that so I can get data in and out of the system. And that's what its job is.

Bill:

And you get the data integrity from that. And look, you might say, well, Billy, you're spending a lot of time doing all this data marshaling. Well, you know, integrity costs performance. I'm sorry. And if you're a Go developer, you already know this because Go, unapologetically, uses 0 value for everything.

Bill:

Doesn't it?

Dominic:

Yeah.

Bill:

Anytime you do every time you construct a value in Go, it's going to be initialized to its zero value state. You have to run electrons through the machine to make that happen, and you cannot prevent it from happening. There there are CPU cycles behind that, but I promise you this. Okay? Those CPU cycles for zeroing out a value, and these CPU cycles for shaping data as it flows between these layers will never show up in a profile.

Bill:

Your program isn't as fast as it otherwise could be because of that. It's going to be something else. Yeah. Oh, yeah. So so we take the data integrity all the time.

Bill:

We take integrity a 100% all the time. And so what these data models are doing between these three layers is giving you the data integrity that you can't live without and getting it to you at a compiler level.

Dominic:

And are those layer different packages? So let let's let's have a

Bill:

a Absolutely. Okay. Absolutely. Every layer has its own set of packages. And some of these packages become the API for the, for the layer above.

Bill:

But now we start getting into package oriented design. And how do you build firewalls between, right? There's 3 sets of firewalls, essentially. There's package level firewalls. There's the horizontal layering of firewalls app business storage, and then you have the vertical ones, which get down to domains, user, products, sales, whatever that domain of data is.

Bill:

And so, you know, we can have an entire, I do teach an entire sort of hour on package oriented design.

Dominic:

Yeah.

Bill:

What is a package? What is an API? What is a type system related to that package? How does that work? How do we define purpose?

Bill:

Where does that package live? Is it an app layer package? Is it business labor? Is it a foundational like, dude, that's a whole Yeah. Yeah.

Bill:

Part of the class. Right? And and you've gotta have those conversations along with the layering. So I I like using the idea of a firewall, and there's 3 sets of them. And for me, the domain level firewalls, a lot of people do that with microservices.

Bill:

Right? Mhmm. Instead of kind of building that into your project, we take those domains and we move them into their separate services. But I go back to what I said before. If you're a small team, why are you doing that?

Bill:

You're just adding more complexity right now than you need. Those domains could exist in the same project, in the same service, and you could still gain the benefits of of having a firewall there if you architect things. Right? And you maintain a set of guidelines and rules.

Dominic:

Very interesting. So Bill, if if any listener would would be interested, so how how does your class work? Do do do you have batches? Where where can they go?

Bill:

Yeah. Just reach out. And we do we do corporate classes all the time where, a company brings a a team of people together. We can do that physically which is my my favorite. We did that with, Amex recently.

Bill:

I could do it virtually or we'll do 4:4:5 hours a day over Zoom. Whatever it is. Right? We'll do that. I'm always teaching 8 hours of something at the conferences.

Bill:

Yeah. So I'm I'm always available for that kind of stuff.

Dominic:

I'm I'm curious to, how many how many developers? So when when you when you when you go to a a business, a company, how many developers do you do you get at the same time?

Bill:

Oh, man. It it's been as small as 10 to 15 and as big as 50. Oh. And and at the conferences tend to get, you know, 80 plus people might show up in a workshop, and, it's a lot of fun.

Dominic:

Very, very interesting. Alright. So, I think it's time to wrap up. I don't want to, to keep you forever. I I I'd like to, you know, I I have a closing question.

Dominic:

And, I I'm not even sure I will continue to ask because so far, I mean, I'm getting, mixed mixed result. But are you are you missing something in Go? Is there anything? And and let me let me maybe suggest something to use because I haven't I have see a couple of your example with, with a type alias for a role for a user. So are you are you missing a union type for example in Go?

Bill:

I'm not missing anything because I've never hit a wall where I said I can't do something that I really wanna do and do it in a, in a reasonable way. So I can't say I'm missing, anything. I would tell you that if I could get rid of anything from the language, if I had one choice to get rid of something, it would be naked returns. I want to see that removed. You should never have a return, without anything in front of it.

Bill:

When you've basically declared variables for the return arguments. Like that to me was the if I had to say there was one big mistake, it was supporting. I under I don't have a problem with naming the return arguments because defer functions need that, especially with errors, right? Where the defer is now being called and you want to return an error back to the calling function, either defer. So I get the idea of naming the return arguments.

Bill:

And, I would almost wanna linter to say that if you've named a return argument and it's not being used in a deferred, you don't link properly. But the the the naked return should have,

Dominic:

Because you you don't find it clear or, you know, what

Bill:

absolutely not clear. It Okay. Everybody finds it, realizes it, that also, and you're looking at a return, and you have no idea what's being sent back. Mhmm. That's why, you know, the rule is you zero value on the return for the things that really aren't being returned and then that variable.

Bill:

Right?

Dominic:

Yeah.

Bill:

And you're declaring those variables as close to where they're being used as possible. And so the moment you're looking at a return and you're like, I have no idea what's what's I don't even know if this is a good if it's a successful return.

Dominic:

Right.

Bill:

Or a or an error return. Right? Like you lose all readability information at that point. So I for me that that's the one thing I would've I would get rid of almost instantly.

Dominic:

Interesting. Alright. Bill Kennedy, thank you very much for your time, and it was, it was very, very interesting to be. I I will I will certainly go check Encore for for sure in the next week.

Bill:

Yes. And check out the ardenlive/encore project. It's still still working on it. I'm still, you know, enhancing it, but it give you a general idea also of, how to have multiple services and do stuff.

Dominic:

Sure. We will have that on the show notes for for sure as well. Alright. Thank you very much.

Bill:

Thanks for having me.

Dominic:

Alright. That's it for this week. I would really appreciate if you can talk or share about this podcast. It's it's always helpful. Also, another way to support this show is by purchasing my course.

Dominic:

There's always a link in the show notes. So on that, see you next week.