0:01

Let's do it. It's

0:11

go time. Welcome to go time. Your

0:14

source for wide ranging discussions from

0:16

all around the go community. Find

0:18

us on the web at go

0:21

time.fm on the Fediverse at go

0:23

time at changelog.social and on X

0:25

at go time.fm. Thanks to

0:27

our partners at fly.io, the home of

0:29

changelog.com. Launch your app as

0:31

close to your users as possible. Find

0:33

out how at fly.io. Okay,

0:36

here we go. What's

0:41

up friends? Do you remember when chat

0:43

GPT launched? I do. It

0:46

felt like the LLM was this magical tool

0:48

out of the box. However, the

0:50

more you use it, the more you realize

0:52

that's just not the case. The technology is

0:55

brilliant. Don't get me wrong, but it's prone

0:57

to issues like hallucination on its own, but

0:59

there's hope. There is

1:01

still hope. Feed the LLM reliable current

1:03

data, ground it in the right data

1:06

and context. Then and only then can

1:08

it make the right connections and give

1:10

the right answers. The team

1:12

at Neo4j has been exploring how to

1:15

get results by pairing LLMs with knowledge

1:17

graphs and vector search. Check out their

1:19

podcast episode about LLMs and knowledge graphs

1:21

throughout 2023 at graph stuff.

1:25

Dot FM. They share

1:27

tips on retrieval methods, prompt engineering, and so

1:29

much more. Don't miss it. Find

1:31

a link in our show notes. Yes. Check

1:34

it out. Graph stuff. Dot FM. Episode

1:36

23. My

1:52

name is Natalie Pistunovic and today's

1:55

episode is the first of several

1:57

on the topic of migrating to

1:59

graph. go. And we

2:01

start with migrating from PHP. And

2:04

our guests for today are Matt

2:06

Boyle and Chris Shephard. Hi

2:09

guys, how are you doing? Good, thank you. Great to

2:11

be here. Yeah, good thing. It's really great

2:13

that we get to record in the middle of

2:15

the day in Europe times, really, we do the

2:17

recording in the evening and it's a new

2:20

for me. So I'm really enjoying it. Hope

2:22

it works nicely with your day. Are you

2:24

more of morning or afternoon or evening people?

2:27

So I don't know about Matt, but I'm definitely

2:29

more of an evening person myself. But it's nice

2:32

to be doing this in the daytime. Yeah, I'm

2:34

the complete opposite. I get up really early, I

2:36

typically get up by six, and then I'm usually

2:38

in bed by like 9pm. And then usually I

2:40

wake up to a flurry of messages from Chris

2:42

who's been doing stuff till like 1 or 2am.

2:45

I used to be that person, but I'm really not

2:47

anymore. Same here, very much for the morning person. Cool.

2:52

So Chris sending you messages, you're

2:54

a good example of our colleagues, and you

2:56

work colleagues in your previous job. What do you

2:58

guys do and where? And what did you

3:00

do before that? Yeah, so I think we've

3:02

worked together now for roughly six years, maybe

3:04

both currently working at Cloudflare. And

3:07

then before that, we worked for a FinTech company

3:09

startup in London called Curve. I've been

3:11

at Cloudflare myself for about three years, I think that's

3:13

been there slightly longer than I have. Yeah,

3:15

I've been there for four years now, I think. But Chris

3:17

and I, we worked at Curve in the same team, and

3:19

then we weren't in the same team. And then we were

3:21

in the same team. And then

3:23

at Cloudflare, we were in the same team, then

3:26

we weren't again, then we were again for a

3:28

bit. And now we've just we've just parted ways

3:30

for another time. So I'm

3:33

the engineering manager for a team called

3:35

Developer Tools. We built internal

3:37

tooling, and Chris has just moved over into like

3:39

our data organization, which is pretty cool. They're the

3:41

ones who kind of deal with the large volume

3:43

of requests that make the way from Cloudflare's edge

3:45

to the core and do a bunch of processing and clever

3:48

things with it. So very cool team to be a part

3:50

of, I think. And you

3:52

are mostly using Go, but you used to

3:54

use PHP. Silence,

3:57

maybe, okay. I

4:00

was trying to figure out who didn't speak over each other. But

4:02

yeah, so Chris and I worked

4:05

together at Curve, as we said. Curve

4:07

was, when we joined, it

4:09

was predominantly PHP. Like the

4:11

first version of Curve was being built in PHP.

4:13

And actually, before that, I'd worked in PHP, another

4:15

company, too. And when we

4:18

joined, one of the reasons that Curve was

4:20

kind of increasing its size and developing its

4:22

engineering teams was obviously to go to market

4:24

faster. But some of the things that we

4:26

were trying to do, I don't

4:29

want to say we were hitting limitations of PHP

4:31

because I think it's been proven by multiple people

4:33

that you can take PHP surprisingly far. But

4:35

I think the way I think about

4:37

it more, I guess, is that we'd identify the

4:40

need to start maybe splitting out

4:43

the competencies of the monolith

4:46

so that we could move faster in different directions.

4:48

And we were no longer going to invest in PHP, right? We

4:50

were going to kind of strangle it out. And we were going

4:53

to build around the in-go, which

4:55

was a choice that was made at the time. And

4:58

Cloudflare actually did something very similar. Cloudflare was also,

5:01

people might not believe this, but Cloudflare started life

5:03

as a PHP monolith, too. And

5:05

similar sort of approach. So you're still PHP

5:07

in Cloudflare stack, very small amount. But we

5:09

basically, we don't really develop or invest in

5:11

it beyond what we have to anymore. And

5:13

we build most of our newer

5:16

systems and competencies. We build them

5:18

in in-go. And

5:20

at Cloudflare, more and more, we're seeing use of Rust

5:22

as well, which is interesting. I haven't run

5:24

into Rust yet. I don't know if you have, Chris. But it's becoming

5:26

more and more popular, I see. No,

5:28

no. Neither have I not really used much Rust,

5:30

to be honest. I think one thing that's common

5:33

between both Cloudflare and Curve is our

5:35

intention was never to completely rebuild

5:37

everything in-go. It was more new

5:41

things will be built in-go. And we'll

5:43

leave PHP as it is. But I

5:45

think over time, our mindset shifted a little

5:47

bit. And I think many, many more

5:49

things got migrated to Go as we were working

5:51

on it. And do you know what

5:53

brought this decision or what

5:55

introduced Go generally to the team? Yeah,

5:58

I think it was in London. I'm sure

6:00

you've seen this, Natalie, in Europe generally, but

6:02

quite a lot of the fintechs seem to

6:05

have picked Go. So I think

6:07

there was definitely a strategic hiring element

6:09

to it, right? I think this all started

6:11

with Monzo. That's my reading of the situation.

6:14

Monzo did a great job. Monzo is a large

6:16

UK-based digital bank. Yeah, sorry. I

6:19

just assume everyone knows what it is because it's so popular

6:21

here, maybe not in Europe. But yeah, Monzo is a huge

6:23

digital first bank. It was probably

6:25

one of the, I don't want to say the

6:27

first, but it's certainly one of the first modern

6:30

challenge events. But one thing

6:32

they did exceptionally well was they were

6:34

incredibly transparent about how they were building

6:36

and challenges they faced. And

6:38

they started life with Go microservices because a

6:40

lot of the team had come from another

6:43

company previously where they'd basically learned a bunch

6:45

of lessons that they felt they could hit

6:47

the ground running at Monzo and it would help them

6:49

as they scaled things out. And

6:52

one of my favourite Go conference speakers, or just

6:54

conference speakers in general, is Suhail Patel, who's still

6:56

at Monzo. He's a staff engineer there. And

6:59

he still talks about this to this day. And I think it's been

7:01

a really good decision for them. But one

7:04

advantage for companies on the periphery,

7:06

I guess, is there was a whole bunch

7:08

of people who really were excited about joining

7:10

Monzo, wanting to do what they

7:13

were doing. And there were people

7:15

looking to leave, maybe looking for different opportunities. And if

7:17

there was other syntax in the same space, you were

7:19

going to be using a similar tech stack. It

7:22

meant that we could be moving faster. We could leverage their expertise. So

7:24

that's one of the reasons I think perhaps we looked at

7:26

it. But there's also some more technical reasons. We

7:29

were certainly seeing performance issues with PHP. It

7:31

was pretty challenging. I think it

7:33

is possible to get more performance out of it, but it's a hell of

7:35

a lot easier in Go. Even bad

7:38

Go is incredibly performant. And

7:40

then I guess another thing that I've seen in more

7:42

recent years as well, especially more at Cloudflare, is

7:45

we've been really successful hiring people who don't

7:47

know Go and getting them productive

7:49

in literally like a week or two. We have

7:51

people putting things in productions like in a week

7:53

or two, which I've never really seen

7:55

for any other language. Oh, that's very fast. Yeah. I've

7:58

seen this before, like maybe the Node ecosystem. But

8:00

I've never really seen it in any of the other

8:02

ecosystems. Like PHP was quite hard. Our PHP curve especially

8:04

was quite hard to get on board with too. And

8:07

I've worked in places before where I've used

8:09

Java and getting people used to abstract being

8:11

entity factories was always challenging too, you know.

8:14

So, question to you both. When you

8:16

started using Go, how long did it take you? Did

8:18

you learn that? You did not learn that as a

8:21

first language, so you came with a background from some

8:23

other language. When you started working

8:25

in Go, how much experience did

8:27

you have from private projects? Did you learn on

8:29

the Go? How fast

8:31

did you throw the point of production? Yeah, so it's

8:34

actually funny that Matt mentioned Monzo before because

8:36

I think that's how I got into Go,

8:38

to be honest. I wanted to work in

8:40

FinTech originally and I think I

8:43

was reading the Monzo blogs and I heard about

8:45

Go through that. So I started

8:47

playing around with it in my spare time just building

8:49

things like nothing large, just like

8:51

very small applications. And then

8:54

I was looking for jobs in FinTech and Go at

8:56

the same time and that's how I came across Curve.

8:59

So when I joined Curve, I had very minimal experience. I

9:01

built a few things maybe for a couple of months

9:03

that I've been using Go. But

9:05

when I got to Curve, like Matt said, I think

9:08

within the first week or two, I was pushing things

9:10

to production. So it does

9:12

show how easy it is to get started

9:14

on Go and how quickly you can get onboarded like that.

9:17

Similar answer to me, I think. I think I started

9:19

out as a hobbyist. I don't think I particularly found

9:21

it because of Monzo, but the place I was working

9:23

at the time had a Go

9:25

affectionado who was writing small pieces for production

9:27

there and I was just asking him questions

9:30

and learning a little bit more about it.

9:34

And I kind of just really liked how simple it

9:36

was to get going. It was one of the first

9:38

languages where I watched a couple of tutorials and I

9:40

could build something useful. And I'd

9:42

never really experienced that before because previous to

9:45

that, I tried to learn Laravel, the PHP

9:47

framework. And it was very easy

9:49

to be productive in, but when things went wrong, I

9:51

didn't understand why they went wrong. Another message is it

9:53

makes sense to me. I mean, me

9:55

and Chris have joked about before. If you've used Java Spring Boot,

9:57

it's great while it works. But like, as soon as it's done,

9:59

it's gonna work. starts throwing errors at you and you

10:01

just copy and paste them into... We're probably showing

10:03

our age at this point, but putting them in

10:05

Stack Overflow and figuring out

10:07

what they mean is basically the only way

10:09

to proceed. I'm sure chatgbt can do a

10:12

much better job these days of helping you

10:14

figure those out. Whereas

10:16

I found Go quite intuitive. So similar thing. I actually

10:18

was actively looking for a job where I could use

10:21

Go at work rather than it being at home. So

10:24

I like to think I joined Curve

10:26

and was relatively productive relatively quickly. But

10:29

in my experience since then, we've hired tons

10:31

of people at Cloudflare and at Curve who

10:33

were predominantly from object oriented backgrounds like Java

10:35

and PHP were popular ones. And we found

10:38

people from those backgrounds especially really can be

10:40

productive in the one to two weeks that

10:42

Chris said there. Curve

10:44

of productivity, I guess, made it an easy

10:46

sell to whoever made the

10:48

decision to move from PHP to Go. Yeah.

10:50

And I think the really nice thing about... There's

10:54

lots of criticism of microservices and there's definitely

10:56

an argument that more folks

10:58

just start life as a monolithic

11:01

application in a single language and you break chunks

11:03

out. In this situation, I think

11:05

being able to write small chunks of code in

11:08

a microservice in Go in this instance is

11:10

kind of nice because it meant that we could kind of

11:12

safely try it and see if it works and see if

11:15

it has the profile and the performance index that we were

11:17

looking for before kind of going all in on it. And

11:19

if it's not the perfect

11:21

decision, you can then start to look

11:23

at other options and also you can use different options

11:25

for different languages. And this is kind of where Cloudflare

11:27

is at now. So I would say... I don't

11:30

think this is kind of official but Go is

11:32

our sensible default. If you are looking

11:34

to build something at Cloudflare in the

11:37

core which is Kubernetes, Go

11:39

is probably where you should start. We've got a bunch of libraries

11:41

in a good ecosystem around it. But

11:43

that's not to say that if you've got a specific task

11:45

where it makes sense to look at

11:47

Rust or to look at some of the other

11:49

languages out there, for example, the really obvious example is

11:52

if you're doing something in the machine learning ecosystem, Python

11:55

is probably the way to go. Like Go just does not have

11:57

that support yet for AI. I hope it comes but it's certainly

11:59

not that way. today. So trying

12:01

to square peg round hole is not the right thing

12:03

to do and just you may as well leverage the

12:06

great Python ecosystem that's out there. But

12:09

once we started to right go and to

12:11

this day I continue to see this, it's

12:13

really hard to come up with reasons not

12:15

to especially for typical HTTP

12:17

servers, GRPC servers, like

12:19

database interaction, CLIs, like those simple

12:21

use cases, typical use cases because

12:23

the performance is just phenomenal for

12:25

very little effort. You don't need

12:27

to be an expert to get

12:30

exceptional performance out of it. So it's certainly

12:32

because of my sensible default throughout my career

12:34

as well. So can you

12:36

share some of the challenges that you

12:38

had in migrating or like some stories

12:41

or generally talk about the migration process?

12:43

How did you start? How not

12:45

about building the new things, but actually the carrying

12:48

out from PHP to go for those who want

12:50

to do that or for those who consider doing

12:52

that. Any learning is very

12:54

interesting. Yeah, I think the

12:56

biggest challenge I saw at least when

12:58

we were moving from PHP to

13:01

go was probably

13:04

like the expectation that we were going

13:06

to move everything. I think originally we

13:09

didn't have that kind of opinion, but over time we

13:12

kind of thought that there would be a world

13:14

where we probably wouldn't have the PHP anymore and

13:16

we were kind of planning for that eventuality. But

13:19

in my experience like these things, I will

13:21

never fully get rid of the PHP and

13:23

we shouldn't... I mean, I

13:25

don't think it makes sense to

13:27

migrate everything to be honest in

13:29

most cases. But we're in this

13:31

situation where we're kind of building

13:33

things for life after PHP, but

13:35

potentially we're probably never going to get to that point.

13:38

So it brings challenges because we could

13:41

potentially have inconsistencies between the data

13:43

that we have in two places. And we're like,

13:45

yeah, ultimately we have to build around having these

13:48

two different systems that have

13:50

similar purposes, but yeah,

13:53

are completely separate. So

13:55

yeah, I think for me, yeah, I think it

13:57

just being pragmatic about what's

13:59

definitely going to be around forever and what's not

14:01

going to be around I think is the biggest learning I

14:03

took from it. Yeah, I think that's a

14:05

really good call out. I think the only thing

14:08

I would build on top of that with is

14:10

any challenges you're facing with your monolithic application, you're

14:12

going to experience 10 times more with a distributed

14:14

system. So you need to

14:16

go into that eyes open and be

14:18

aware that especially as you go through

14:20

this journey of starting to move, if you are going to

14:23

run this, there's two ways to do

14:25

this migration, right? You can down tools and literally

14:27

rewrite your whole application in Go and then ship

14:30

that and maybe there's a class of company that's small

14:32

enough where maybe that makes sense. I can't think of

14:34

any. I think I would get a bit of a

14:36

red flag if someone told me to do that or

14:38

asked me to do that. But generally

14:40

that is an approach that's valuable. To

14:42

Chris's point, I think most people are going to

14:44

adopt this sort of, we call it like a

14:46

strangle pattern, right? You either build new

14:48

pieces around the edge until the PHP becomes such

14:51

a small part of your ecosystem that

14:53

it's either really quick to rewrite because it's

14:55

become sort of irrelevant or it's become such a small part.

14:57

You just let it continue to do the things that it's

14:59

been doing well and you just continue

15:01

to build your new competencies in other languages. I

15:04

think that makes a lot more sense as an approach. The

15:07

huge downside is now you've got

15:09

this, all these systems or at least two systems,

15:11

your Go system and your PHP system talking to

15:13

each other and the network's going

15:16

to fail. It definitely will. You might not think

15:18

it will, but it will. So you've got to

15:20

make sure you've got things in place for this.

15:22

So just getting into the habit

15:24

of having retries built into your application or

15:27

deploying it in some way that you've got like a service mesh

15:29

that does some of these retries for you. Chris

15:31

touched on sort of like data synchronization issues. That

15:33

can be a problem if you are trying to

15:35

have two different views of

15:38

a, let's imagine you have

15:40

a customer and you have multiple different systems that have

15:42

a view of a customer. One of

15:44

them is a source of record. The others are going to have

15:46

to be somewhat out of sync. So you've got to kind of

15:48

think about this ahead of time and think about what does it

15:50

mean to have consistent data. If you've been

15:52

building a monolith before, all of this is probably new challenges

15:54

to you and you've got to be ready for them because

15:56

they're really, really hard. And so making sure

15:58

you invest in... infrastructure, your infrastructure

16:00

team, observability becomes really important. So these moves

16:03

do tend to be pretty expensive. And so

16:05

you've got to make sure it makes sense

16:07

for your business, you're going to get what

16:09

you want out of this, like this migration,

16:11

this refactor, this

16:13

rewrite, this commitment to a

16:15

new tech stack before you kind of go on

16:18

this journey. Because it sounds really fun. And it

16:20

is really fun. But when it goes wrong, it

16:22

can be incredibly painful. Can you share

16:24

some of the going wrong stories from either

16:27

of the immigration you had? Coast

16:30

contour recently, Chris, right? Do you want to share

16:32

that one? Yeah, actually, I do have

16:34

a good story I can tell. And so

16:38

one was actually a few weeks into my time

16:40

at Curve, I have not been there very

16:42

long. And it was my first time even

16:44

with any experience on microservices, like it only

16:46

worked kind of on one of the applications

16:48

before that. So to what Matt

16:50

said, like there is definitely a learning curve. And it's definitely a

16:53

lot of challenges that you don't

16:55

typically face with my list. I actually had

16:57

a very simple ticket to migrate

16:59

a data type that

17:01

we were to change a data type from

17:03

a string to a timestamp for and

17:06

basically some first

17:09

card state, it was one of the fields on the

17:11

card state, basically for cards

17:14

in the app. And I didn't

17:17

really think about I didn't I didn't have a lot

17:19

of experience at the time. So I didn't really think

17:21

about breaking changes and things like that. So

17:24

I made this change, it

17:26

passed our test, like our automation test framework,

17:28

it passed all the tests, every got approved,

17:30

everyone's happy with it. I

17:33

deployed it and didn't realize that

17:35

we had another service basically start

17:37

between this and the app. And that

17:40

service, because of the way it handled the new time,

17:42

like it because it because of the breaking change in

17:44

the way it handled the new data type, it

17:47

started marking everyone's card as deleted.

17:49

So I think we had

17:51

about a 20 minute period where every single user in

17:53

the app looked like their partner, their card had been

17:55

wiped. So it wasn't probably

17:58

my best moment, to be honest. Luckily

18:00

we did fix it and they did highlight a bunch of

18:02

other issues, but yeah, I learned a very valuable lesson from

18:04

that. Matthew,

18:06

you have a story to share. Yeah, I was just thinking. I

18:08

think there's been... So Chris's

18:10

example is a really good one of a

18:12

very clear issue, I think. I think we

18:15

saw very quickly that we'd broken the app

18:17

and we got lots of complaints

18:19

and we could see ourselves. But I

18:21

think some of the... Maybe a

18:23

more subtle one that's more interesting to share just

18:25

from a different angle is the

18:27

data consistency issues is a really interesting

18:29

one. So I'm trying to think of

18:31

a specific example where we've seen it,

18:33

but obviously if you're using

18:36

something like Postgres and you're replicating

18:39

the data and we call

18:41

it replication lag where it's taking a long time

18:43

to replicate, maybe it's taking three minutes, four minutes,

18:45

eight minutes, and you're using that database,

18:47

that secondary database as the source for

18:49

all your reads in your application and

18:52

you're sort of eight minutes behind, 10 minutes

18:54

behind, 15 minutes behind where you need to

18:56

be. I

18:59

can't actually think top of mind of a really concrete example

19:01

where it's been an issue. And one of the reasons for

19:03

that is it's actually really hard to figure out that that's

19:05

an issue. It doesn't show up on any of your dashboards

19:07

as customers are having errors or

19:09

seeing issues. The only symptom of it is

19:11

that replication lag. And so

19:13

just having that experience and that

19:16

observability up front is really

19:18

important. So that's actually a metric we

19:20

track really closely at Cloudflare. But

19:22

until I joined Cloudflare, I hadn't really ever thought about

19:24

tracking it as a metric. How

19:26

do you call that metric? It is called replication lag, yeah.

19:29

And it's measured in minutes? Ideally it's in seconds.

19:34

It's definitely shown up for us in minutes before.

19:36

It's basically the difference between, if you have a

19:38

primary database, like a primary Postgres database, let's say

19:40

it's running in 1 AWS

19:43

in London, and you have a secondary

19:45

in Ireland, what's the

19:47

difference between you writing to the Postgres database in

19:50

London and it's showing up in the Ireland database?

19:52

And that's the one you're actually using for your

19:54

reads. Like that's what we're measuring. And

19:56

it's a really common pattern I'm sure we've all used where

19:58

we write to the primary and we read. from the

20:00

secondaries to remove some load from the primary,

20:02

the writer. And if you're not

20:04

measuring that, then chances are you are seeing, you

20:06

could potentially be seeing this replication issue where your

20:08

customers are being served potentially stale data. And

20:11

depending on your use case, your business case, that

20:13

could be a big problem. But it's going to be really,

20:15

really hard for you to debug. And it's going to be

20:17

really, really hard. It's not going to show up on any

20:20

of your error dashboards or anything like that unless you're tracking

20:22

that specific metric. And I think

20:24

the more you dig into distributed systems, you'll

20:26

find, depending on what your stack looks like,

20:28

you'll find a bunch of different metrics

20:30

and things like that. They're like, oh, that

20:32

looks weird. Maybe we should be tracking that

20:34

one. It's having

20:36

customer impact, but we didn't necessarily know it was. So

20:39

these aren't go specific issues. Whatever migration you

20:41

go from, if you start to move into

20:43

a more distributed world, you're going to start

20:45

to see some of these things. And these

20:48

are super interesting problems. I love them. But

20:50

they are much harder than dealing with a

20:52

monolithic application with a single Postgres instance. That's

20:55

the ultimate place to be as a small team, in

20:58

my opinion. Yeah, and I think the

21:00

one worrying thing about that kind of issue as well

21:02

is if we're not tracking it, then we are relying

21:04

on a customer to raise it when they see that

21:06

error. And it's

21:08

a safe bet that if one customer's seen it

21:10

and raised it, you've got many, many other customers

21:12

who've seen it and just not raised it. It's

21:17

a challenging one, and it's definitely something to

21:19

bear in mind because customers 99% of

21:22

the time are probably not going to raise it unless

21:24

it's someone who really cares about the product.

21:26

Interesting learning, the replication lag. That's a good

21:29

recommendation, not even related to migrations.

21:32

Were there any interesting behaviors you noticed when

21:35

you migrated some

21:37

code base from PHP to Go? Maybe

21:40

you had to change the way that

21:42

it's written to do it more, the Go

21:44

way, and then it somehow affected the behavior?

21:47

Or any interesting things you stumbled upon?

21:49

There's a few things I would call out that

21:52

come to mind immediately. The

21:54

first one is, I think I mentioned it briefly

21:56

at the start, but the performance profile of Go

21:58

was noticeable. immediately.

22:01

We had systems that were struggling

22:03

along at 10 requests per second that

22:05

were using a bunch of CPU and

22:08

memory. And then all of a

22:10

sudden they were using, they could do

22:12

thousands of requests a second and they were using

22:14

barely any CPU and memory. And we didn't do

22:16

anything clever, we just wrote and go what we

22:18

were about to write in PHP. That

22:22

was really eye opening to me. That was one

22:24

of the first things I remember being really

22:26

shocked about. The second was maybe slightly niche

22:28

and not for everybody but containerization

22:31

of a Go app

22:33

versus a PHP app. You literally

22:35

need a PhD to containerize a

22:38

PHP app. At least you did.

22:40

It was really complicated to figure out at least the way

22:42

we were doing it. It was really, really challenging. And

22:45

I think it seems to

22:47

remember our PHP container images were like a

22:49

couple of gig and then we moved

22:51

to this like distroless Go and they were

22:54

like 13 megabytes. It

22:56

was astoundingly different. And if

22:58

you're running these workloads somewhere where

23:00

you pay for nodes or

23:03

space or whatever, that can

23:05

be really significant to be able to have

23:07

such a small profile was amazing.

23:09

And then the third thing that really jumped

23:11

out to me was developer experience. So

23:14

PHP has this debugging path

23:17

called xdebug. I truthfully never

23:19

got it set up. I could never

23:21

figure it out. You had to kind of do some clever

23:23

stuff to get it working and I could

23:25

never get it working. I've tried a few times at various points

23:27

in my career. Like with Go, it

23:29

really was a case of like set a breakpoint,

23:32

hit debug and it worked. Recompiling the application was

23:34

super quick. So coming from like

23:36

Java and PHP to Go, like the developer experience

23:38

was like a huge one for me. And even

23:40

like silly things like running a unit test and

23:42

then running in a couple of seconds versus like

23:45

having to wait multiple minutes in some cases

23:47

in some of the old stacks was a

23:49

really nice. I'm very welcome change until

23:52

the replication language. Yeah,

23:54

exactly. Yeah, I

23:56

think just to pay back on kind of both

23:58

of the points that Matt made like For me, when

24:01

moving to Go, it was just shocking how quickly

24:03

you could deploy and run an application.

24:05

Like coming from a Java background where it takes

24:07

like seconds and seconds for an

24:09

application to actually start up. In Go, they

24:11

start up in milliseconds. And I

24:13

think just because it's designed for distributed systems,

24:16

it makes it so easy to build these

24:18

small applications and run them. And Kubernetes are

24:20

in Docker like Matt said. And

24:23

on the other point about productivity, it's the same

24:25

without like the tooling around Go is just so

24:27

great. Like it's so easy to go and run

24:29

tests. Like you can just run Go test on

24:31

any project. And for the most part, it will

24:33

just run the test. But honestly, like

24:35

trying to do that in Java, it's pretty challenging

24:37

to do it with a single command without having

24:39

like additional libraries and things like that. So

24:41

yeah, like I agree to both Matt's point, like

24:44

the developer experience is excellent as well. To

24:46

throw them some balance in this conversation. I know it's a

24:48

Go podcast, but there was some things I remember at the

24:50

time specifically that really sucks about Go as well. So

24:53

at the time, it was pre-Go modules that we were

24:55

doing this. I don't even remember

24:57

the Go path naturally where you had to put stuff

24:59

in specific places or it just didn't work. Like

25:02

figuring that out was really hard. And I remember I

25:04

was wasting like a bunch of time like trying to

25:06

help people figure out like Go path and getting everything

25:08

working and just thinking that way. That

25:11

was really, really challenging. So that was one

25:13

thing that I remember was kind of

25:15

sucky like PHP's dependency management ecosystem was

25:17

very mature. It worked and

25:19

Go's at this time was not. It was pretty

25:21

poor and Go modules like really saved our bacon

25:23

on that one. I was very glad when –

25:25

and a lot of people have got criticism of

25:27

Go modules, but considering where we came

25:30

from, it was substantially better. And then the other

25:32

one, I guess I'll call out, it's probably less

25:34

true today, but at the time, there

25:36

was so much documentation and learning resources

25:38

and stuff for PHP and there

25:41

wasn't very much for Go at all. So there

25:43

would be things you try and look up and there

25:45

wasn't really a good solution for it or you'd be

25:47

looking for libraries and they didn't really exist or they'd

25:49

be very immature. So you had to be willing to

25:51

kind of get stuck in and either make open source

25:53

contributions or roll your own thing. The lack

25:55

of libraries is a little bit like the Go

25:58

thing, right? You should use what you want. have

26:00

and don't use, don't like export libraries for

26:02

what you don't. Yeah. And I think that's

26:04

another learning, isn't it, that you kind of

26:06

have to pick up as you go with

26:08

Go is if you go and write JavaScript,

26:10

like, you know, the less pad incident is

26:12

famous where everyone was depending on

26:15

this really small module to do like something very

26:17

minor. And I think that comes

26:19

with people from a lot of other languages. Like

26:21

if you if you do come from PHP and

26:23

Java, like it's not unusual to pull in dependencies

26:25

and, you know, you get the, they

26:28

call POM files, I can't remember what

26:30

the Java things are called, they call POM

26:32

files, like that you could get huge ones

26:34

and the dependency management thing was like quite

26:36

well managed and there was enterprise solutions for

26:38

dependency management available to you. Whereas kind of

26:40

coming around to actually I should try

26:42

and implement this myself and go and I should,

26:44

you know, manage and own this myself, like, what's

26:47

the idiom, a little copying and pasting is better

26:49

than a little dependency, like coming around to that

26:51

way of thinking definitely took me some time

26:53

and it kind of takes everyone who jumps into

26:55

the, to the Go ecosystem a tiny bit of time

26:57

to get to grips with, I think. So

26:59

especially when we were doing this, this was unusual.

27:01

And so and also being able to like type

27:04

things into Google and not always finding an answer

27:06

was unusual too, especially if you

27:08

used to Java, whether it was

27:10

20 years of experience available on the internet for you. What's

27:21

up, go time Adam here in the

27:23

breaks talking to Segar Baju, co founder

27:26

and CEO of speak

27:28

easy speak easy is the complete

27:30

platform for great API developer experience,

27:32

generate SDKs in TypeScript, Python, go,

27:34

Java, C sharp and PHP. You

27:36

know what, Segar, imagine I have

27:38

some listeners who write go because,

27:41

you know, they're listening to go

27:43

time and they say, I maintain

27:45

our SDK and I don't mind

27:47

doing it, but I realized there

27:49

are ways to generate our

27:51

SDKs using the open API

27:53

specification. Now, give me an

27:56

exact workflow end to end

27:58

from curious to. leveraging

28:00

speak easy to generate and maintain SDKs

28:02

for an API written in Go. Let's

28:04

take the case of you're building an

28:06

API from scratch today. If you're building

28:08

an API in Go, you're probably going

28:10

to start with one of the common

28:12

frameworks to build a Go API. I

28:14

would highly encourage looking at frameworks like

28:17

Goa and Fuma, which actually give you

28:19

a lot of scaffolding out of the

28:21

box to just write your API, but

28:23

also to make sure that you get

28:25

an open API generated off of each

28:27

build of your API. That is like

28:29

a really great foundational building block to

28:31

invest in as a company, because that means all

28:33

of the future development of the API is guaranteed

28:36

to be described and documented out of the box.

28:39

Once you do that, it's, I think, a

28:41

good idea to have some basic concepts of

28:43

ownership built in. So if you have multiple

28:45

services and microservices, make sure your service is

28:47

annotated by teams that own it and then

28:49

also give your resources simple names that can

28:51

reflect an open API spec. Once you do

28:54

that, the spec is going to get created

28:56

every time you build your API. So

28:58

CI CD, your spec will get generated

29:00

every time you build and host the API. Make sure

29:03

that spec gets pushed to a change management solution. I

29:05

think that's what SPTC can come in. They actually push

29:07

the spec to us in every build and we'll create

29:09

a version snapshot of it. So you have it for,

29:11

we give you prominence over it, so you have it

29:14

for future builds and future work that you want to

29:16

do on it. Once that

29:18

happens, you can attempt to generate an

29:20

SDK and we'll hook directly to your

29:22

CI CD. And grab the latest

29:25

version of the spec. Every time that happens,

29:27

we'll compare the spec to a previous version,

29:29

tell them if there's any breaking changes and send

29:31

you a full request on any repo to generate that

29:33

new code. Once you get

29:35

to that first version of the SDK, that's where

29:37

you usually want to do some human-in-the-loop investment and

29:40

take a look at does the SDK suit your

29:42

needs? Is it ergonomic in the way you think

29:44

it should be? And then also make, is it

29:46

documented? Is it described well? If

29:49

there are gaps in that documentation, you can go

29:51

back and add that in your code base. But

29:54

if this is not a new API and this

29:56

is a legacy API, you can use tools like

29:58

Overlays to actually add in that. documentation

30:00

without altering the visual spec itself or

30:02

altering the source code. So you do

30:04

some investment there to make sure that

30:07

the SDK output is ergonomic while the

30:09

script is documented. And once that happens,

30:11

you're going to set us an autopilot

30:14

so every time your spec changes, speakers

30:16

will send you your pull requests. And

30:18

once you merge your pull requests, it

30:20

gets published and released on GitHub. Then

30:22

God go doesn't have a separate package

30:24

manager, it's all GitHub. So the moment

30:26

the Gitreapos update, you get a brand

30:28

new SDK version released to your customers. That's

30:31

the complete workflow all the way from your API,

30:33

so to your CI CD to actually add and

30:35

generate it at most of the SDK. So

30:38

take me in as close as you can. Give me an

30:40

Anse Eyes view. Why is this

30:42

beneficial for a team? I

30:44

think it's really beneficial when you start

30:46

thinking about growth and scaling the company.

30:49

The moment you have more than one

30:51

developer touching an API, let's say you

30:53

have two N-Pig developers touching and iterating

30:55

on an API, you want all those

30:57

changes to be captured and documented somewhere

31:00

so that someone else, not necessarily the

31:02

same developer, can decide whether that API

31:04

gets distributed to outside

31:06

the company. Doing that upfront

31:08

investment means every API change

31:10

is described, documented, and every

31:13

N plus one developer that comes

31:15

on the team is also going to onboard

31:17

that much faster. Because you're not going to

31:19

need to know how every service is constructed.

31:21

You're just going to be able to look

31:23

at the open API spec and say, we

31:25

have three APIs today, two of them are

31:28

generally available, one's in beta and then one's

31:30

of v1 and one's of v2. That's

31:33

at the most granular

31:35

level, that upfront documentation

31:37

means you're going to be able to move

31:39

a lot faster on other development going forward.

31:42

So I would say if I

31:44

had to say one huge benefit of

31:46

that is doing that for an investment

31:49

means every developer building an API going

31:51

forward is not going to have to

31:53

learn all the context of an API.

31:55

It's just going to be described in

31:57

a simple single document. Okay, go to

31:59

speaky.com. EasyAPI.dev. You get your

32:01

first SDK generator for free.

32:04

Once again, speak easy API.dev

32:06

and tell him go time

32:08

sent you. This

32:18

is something that I recently mentioned in some other podcast

32:20

for hours. I guess that this is the go way

32:23

of doing things. And then somebody wrote me

32:25

an email saying, I didn't find any documentation

32:27

for this. Can you, could you like

32:29

back your claim? And so I approached

32:32

the go team and Cameron, the

32:35

lead actually replies to me. I'm

32:38

looking for the exact quotes. The

32:40

go programming philosophy encourages using

32:42

trust worth the dependencies. While

32:45

I said something like the

32:47

go programming philosophy encourages using

32:49

the standard library as much as possible.

32:52

And when the standard library is not

32:55

solvent, generally prefer writing code over importing

32:57

third party. So just

32:59

for the very historic accuracy, in case

33:02

anybody follows up with a back

33:04

your claim, it is not written anywhere. But

33:07

here you have the philosophy, the go programming

33:09

philosophy encourages using trust worth a

33:12

dependencies, but it's still

33:14

somehow feels like almost like a

33:16

common knowledge, right? That you don't

33:18

import as much as you've right. Now

33:21

I'm very curious where does this come from? But

33:24

it's something that's kind of people know. Yeah,

33:27

I think so there's the, maybe

33:29

I can share a link in the show notes, but

33:32

there's, there's a video of the go idioms. I'm trying

33:34

to very quickly fill up when they were first spoken

33:36

about, but I seem to think Dave Cheney was responsible

33:38

in some way for, for these. So I'm going to

33:41

say around 2016 they were kind of shared as

33:43

like, Hey, well maybe we should think about things this

33:45

way. And I do know, like the go team have

33:47

kind of used those and repeat them too. So

33:49

I think at least since 2015, 2016, like

33:52

they've been kind of widely shared as do

33:54

You, I think you used a great word actually like philosophy. That

33:56

Seems like the right way to think about it. I think, doesn't

33:58

it? It's like this is the way to. Think about

34:00

writing Go. You don't have to believe it

34:02

is. It is how we think about as

34:05

the people altering the language and it seems

34:07

strange of first coming from other languages. but

34:09

the longer you spend especially if you work

34:11

in might be companies an enterprise like the

34:13

more this makes sense the more control you

34:16

have. All the anomaly says of your own

34:18

ecosystem of like your destiny effectively. Third, it's

34:20

also kind of. The content of your code

34:22

is yeah exactly. I get some. Mx

34:25

on the sun a breeze as codes. Thinking

34:28

of as an you mentioned that she

34:30

saw one big difference in the container

34:32

is a sin of peace as go

34:34

and tell that peach be ones were

34:36

a lot bigger. So when

34:39

you continue to talk about the service more

34:41

when you containerize, go accessing care. of

34:43

people know what and signs that the for those

34:45

who did not containerized goal is t v apps. Like.

34:48

with their. To. Take a crack of this

34:50

on Chris and he's been a bunch of time and poking

34:52

around in both. Go on his feet in Tennessee. My me,

34:54

that place francis nice and I am. To

34:57

be honest, I'm not exactly sure what is

34:59

involved in a pinch fi. Container.

35:01

And yeah I I think the difference

35:03

between the two is but with Go

35:05

you compile it to native binary so

35:07

you can fills the the binary as

35:09

part of your. File on,

35:12

then. He. Docker image essentially just

35:14

contains up on earth razzmatazz fetuses into

35:16

some language, sheep on a hostile up

35:18

in tips, a hostage copy and all

35:20

the posts on run all along with

35:22

inside to bundle on will be assets

35:24

as well. so adding but us. On

35:27

our the what makes. What? Makes sense.

35:29

Bottomless. Larger than. Two. Nights ago system

35:31

If is an A on the had the has appeared

35:33

to be has to have had a web server bill

35:36

into a pitch p like a patio as pm as

35:38

interim of is called he's have like a web server

35:40

news you have a bunch of like extensions the pitch

35:42

is all right to make it works and you need

35:45

to install composer and some other things to built her

35:47

a says interpreted rise all these things the to be

35:49

available to run it whereas with go a kind of

35:51

those build some sort of stuff away and and just

35:53

for the binder on the container which is was much

35:56

smaller. And they're wonderful Cross compilation

35:58

all the things that may go. for

36:00

their jobs people. So if somebody

36:02

were to migrate from PHP and I'm asking

36:04

this as a person based in Berlin that

36:06

Berlin used to be such a huge PHP

36:08

shop and more and more places more and

36:10

more companies migrated to go but there's still a

36:13

good amount of PHP on a list of

36:15

shops. How would you recommend

36:17

going about that? I think my

36:19

first piece of advice is like to figure

36:22

out why you're doing it and figure out what

36:24

success looks like for you. So here's some reasons why

36:26

I think it's a good idea and to think about

36:28

it is you

36:30

are running like a more performance critical

36:33

system and you think it'll be

36:35

easier to kind of get that

36:38

performance out of a Go

36:40

application or potentially another languages application. The

36:43

ecosystem is best suited for what you're trying to do

36:45

and that's not even migrating from PHP to Go but

36:48

like you know if you are really going to double

36:50

down an AI like maybe you know doing all your

36:52

AI stuff in PHP probably doesn't make sense. It probably doesn't

36:54

make sense to look at Python if you're going to build your

36:56

own models. One thing that should

36:58

not be underestimated is the ability to hire. Go

37:01

is certainly a much sexier language than

37:03

PHP and you know you will attract

37:05

in my opinion better talent like more

37:07

talented folks who want to learn Go

37:09

and potentially want to use it in

37:11

production and so you know there's

37:13

definitely reasons that you could look to the hiring market

37:15

as a good reason to be able to hire. I

37:18

know in Berlin as you mentioned there's a bunch of

37:20

like there's a really hot startup ecosystem and I know

37:22

a bunch of them are using Go so you get

37:24

to leverage that ecosystem and those people who've been potentially

37:26

taught how to write Go in production and they can

37:28

come along and help you out. So

37:31

I think just figuring out success is

37:33

my tip number one like what do you hope to get out

37:35

of this and does it really make sense to move

37:38

from a monolithic application to a distributed system?

37:41

If you decide that's yes my advice would be

37:43

to do the smallest possible thing

37:45

you can first. So I would always recommend

37:47

instead of having one monolith and

37:49

then a bunch of microservices maybe consider having

37:52

two smaller monoliths like you have

37:54

the PHP one you keep that around and then you

37:56

start to build up a Go monolith

37:58

if you will rather than going from a

38:00

PHP model list to hundreds of Go

38:02

microservices, which is kind of what we did. And

38:05

it worked out okay for us, but I think

38:07

we introduced more challenges to ourselves along the way

38:09

than if we'd gone to moving to

38:11

a simpler, just one other system that

38:13

was Go. Because it's all the distributed

38:15

system considerations you're introducing. Exactly.

38:18

And every – if you just think of it,

38:20

the simplest way I think about it is every

38:22

network hop introduced a point of failure. So the

38:25

fewer network hops you can have, in very

38:27

simplistic terms, the better. There's a lot more to

38:29

think about than that, I guess. But especially if

38:31

you're a smaller team, you are just kind

38:33

of starting out and figuring this out. I think that's

38:35

a fairly reasonable rule to think about

38:37

and to follow. And so I would

38:40

do a little – a smaller migration first and

38:42

just kind of start building up new things and

38:44

then follow that strangle pattern, which is start to

38:46

write your new stuff in Go where it makes

38:48

sense. But don't be afraid to hop into the

38:50

PHP to make small bug fixes or

38:52

to don't – remember ultimately our goal

38:54

is – our job is always to deliver

38:56

business values. So if there's a piece of

38:58

work, a Jira ticket or whatever that could

39:00

be completed in five minutes in PHP,

39:02

but you could rewrite it in two weeks and put

39:04

it in Go, do the

39:06

five minute fix and leave the Go stuff

39:09

for the bigger features. And you'll have much

39:11

more sustainable

39:13

buy-in, not just even like – not

39:16

even achievement, but like buy-in. Remember, the whole time you're doing

39:18

this, you've got to keep the business engaged. It's the whole

39:20

thing going. It's a good technical decision. So

39:22

if they ask for a tax change and you say it's

39:25

going to take three weeks because you need to rewrite from

39:27

PHP to Go, you're

39:29

probably going to struggle to keep that buy-in for a long

39:31

time. Is there anything you'd add to that, Chris? Yeah.

39:33

I think the other thing is just be prepared,

39:35

but it will be a learning experience, especially if

39:38

a few companies are not writing Go at

39:40

the moment. And if there's not many people

39:43

maybe with experience writing Go, I

39:45

think it's a learning experience and it's

39:47

worth taking time just to look

39:49

at how to write Go and how to structure

39:51

projects and things like that. Because

39:54

I know from experience, when

39:56

starting out with Go, the

39:59

quality of our services varied massively

40:01

compared to the ones we may be writing

40:03

a couple of years into that journey. I

40:07

wouldn't recommend writing Go like you were writing

40:09

PHP just because they're just totally different languages

40:11

and different paradigms, but there definitely is a

40:14

learning experience there and there definitely is a

40:16

learning curve. So I think that's the biggest

40:18

thing. Be prepared that it might take longer

40:20

than you expect to actually start

40:23

getting services out at the start. You

40:25

touched on something really interesting there as well. I

40:27

think there's this illusion that the PHP is tech

40:29

debt and the Go is going to be beautiful

40:31

and it's going to be perfect and tech debt

40:33

isn't allowed there, it doesn't exist. I

40:36

think the reality is your first

40:38

pass at writing any Go, especially if it's going to

40:40

be a new service since your first time doing it,

40:42

you've got to accept and expect that there's going to

40:44

be technical debt there too. You're not going to figure

40:46

out exactly how you want to structure things. You're going

40:48

to run into a few issues with how Go does

40:51

things a little bit differently to how you're used to.

40:53

So making space for that learning experience that Chris shared

40:56

is really important and just having that expectation in your

40:58

head that we're going to get a bunch of

41:00

things wrong as we try and go down this path

41:02

and we can't assume that this Go is

41:04

going to be perfect. It's not going to be. How

41:08

would AI change all this? The duration of

41:10

the migration, the number of mistakes, the

41:13

mis-perspective, any bets? We're

41:15

not speaking from experience. We have not been migrating

41:18

things with AI. There's no tools under

41:20

this automatic field. But with whatever experience you

41:22

do have with writing code with AI, what

41:25

are your bets? I think it could

41:27

definitely help. I think it can

41:29

definitely give advice on how to... things like

41:31

structuring a project and things about writing

41:34

Go in a more Go-like fashion.

41:36

I think it can definitely help. But

41:39

I think there's still something to be said for

41:41

actually doing it yourself and getting your

41:43

hands dirty and actually learning what

41:45

looks correct and what works and what doesn't.

41:47

So I think it could help the progress.

41:50

But I wouldn't rely on it. Yeah,

41:53

so it's a really great question. I actually wonder

41:55

if in the short term it will make it

41:57

worse, but in the long term it could be

41:59

better. So the reason I say that

42:01

is, so I do use coding assistance, especially

42:03

at home all the time. I find them

42:05

incredibly helpful. But I find them the

42:07

most helpful when I already know what I'm trying to

42:10

do. So I'll start a function signature, and I can

42:12

just tab it to completion. But I already knew what

42:14

I was trying to achieve, and it's just helping me

42:16

do it faster. But I found

42:18

a few times when I asked it to write some code

42:20

to do a specific thing maybe I didn't know too much

42:22

about. And it's actually

42:24

not got it quite right, or this was a

42:26

couple of GPC versions ago, but it actually gave

42:29

me an SQL query that wasn't escaped. And

42:31

so it actually gave me an SQL vulnerability in

42:33

the response. And thankfully, I knew

42:35

what that looked like, so I checked it. But if

42:37

I didn't, I would have just thought, oh, that's how

42:39

you do SQL queries and go, let's put that in

42:41

production. That sounds great. So short term,

42:43

I think it could be

42:45

helpful as long as you take the time to kind of think

42:49

about why it suggested what it did,

42:51

and you go and do that. But I worry most people

42:53

won't. I think long term,

42:55

there's a very great use case here

42:58

for a long time now. We've been using

43:00

tools like Sonocube and things like that to

43:03

kind of give you code quality scores and

43:05

look for basic defects and rules and

43:07

things like that. You can see AI taking that to the

43:09

next level and being able to give you a pretty

43:12

reasonable code review. If

43:14

you've got standards, like Go

43:16

standards at your work, and you've got

43:18

a set of good quality code that you really like

43:20

and a style that you like, being

43:22

able to have a bot do the first

43:24

pass of that review and just spot all the

43:27

really easy, obvious things that your colleague is going

43:29

to call out straight away who's got a bit

43:31

more experience. That could be really powerful. And

43:33

then it comes down more to the people

43:35

just to kind of give the opinion of,

43:38

this doesn't actually quite match the acceptance criteria

43:40

for this, that, and whatever reason. But purely

43:42

like code and stylistic and technical issues, you

43:44

can see AI being able to do probably

43:46

a better job than humans can at spotting

43:48

those. There's a joke isn't there that if you

43:50

give someone a 10,000 line

43:53

PR, you'll get a thumbs up. Looks good to me. But

43:55

if you give them a 10 line PR, you'll

43:58

get 10 pieces of feedback. Whereas. a

44:00

bot is probably more likely to actually spot all the issues in the 10,000 line

44:02

PR because it will take the time to

44:04

figure them out, whereas humans kind of, their eyes start to

44:06

glaze over. It's true humans do

44:09

rely more on the test automation at

44:11

this scale, but for now,

44:13

if they say, I still have context

44:16

memory issues. So both different

44:19

ways of unreliable, but as you say, in the long term,

44:21

this will be improved and this will be better. I know

44:23

you spend a lot more time in this space than we

44:25

do. Have you seen any really interesting sort of use cases

44:28

or tools where you think it

44:30

could help here? Nothing

44:32

reliable yet, but the trend is there,

44:34

the trajectory is there. It's the

44:36

same challenge that I did

44:39

not personally witness, but know

44:41

of that the memory used to be enough

44:43

efficient, but now we have enough memory and

44:46

this is no longer a limitation. Interesting.

44:49

So I think we will be there. What

44:52

did you think of the GPT 4.0 announcement?

44:56

Did it impress you? The Omni. Yeah.

44:58

Yes, actually we started this podcast where

45:01

I had to refresh my computer 15 times because

45:03

I had to close tools one by one, apps

45:05

one by one, and I bet the

45:07

chat GPT desktop app was one

45:09

of the ones, but yeah, I've

45:11

been using it not so for screenshots and so

45:13

on. I really enjoyed that it helps me navigate

45:15

through code, but

45:18

also things that are not code that

45:20

I have to deal with like SAP

45:22

Ariba, a

45:24

tool that the companies, large companies

45:27

like using for processing

45:29

invoices and as a

45:31

technical person, I have no idea what's going on there and this

45:33

is really helping me. But I think when

45:36

you were talking about the replication

45:38

lag, I immediately thought

45:40

of the question like, if

45:43

you give it screenshots of like,

45:45

this is my dashboard and

45:48

this is what the app does, what am

45:50

I missing? Give me some more metrics and

45:52

kind of have the

45:54

visual feedback. So I'd be super

45:56

curious for something like this. If you do end up trying, please

45:58

come back and share. Yeah, that's a really interesting

46:01

use case actually. We

46:03

did this thing at Cloudflow where we review

46:05

all the team's dashboards. So we

46:07

started doing it recently where Chris will

46:10

show up and say, hey, here's

46:12

my dashboard for this service. This

46:14

is what we're measuring. This is why. This is what you

46:17

can see. This is why we measure that. And

46:19

you get critique. That's a great practice. It

46:21

is. And it's useful. You get critique and

46:23

feedback from other people in the company like, well,

46:25

why aren't you measuring this? Could

46:28

this signal have been useful in that incident? Would

46:30

it have helped you spot it faster? Stuff like

46:32

that. And yeah, what you just said is really

46:34

interesting to me. Could we take a screenshot of that

46:36

dashboard and just throw it into an AI tool and

46:38

see? If we gave it enough

46:40

context, would it give good enough feedback? I'm

46:43

going to have to try that. I will definitely come back to you.

46:46

Because I think that's, even if it doesn't

46:48

get everything perfect, if it can

46:50

give some of the high level things of, you

46:52

probably should be measuring these things, I think they'd be helpful to

46:54

you. And it gives someone a jumping off point to go and

46:57

explore. That could be powerful. If

46:59

you have some more capacity for this, I even

47:01

have an improvement idea that will take a little

47:03

bit longer than a five minute conversation. So

47:05

some postmortems that you have, things that

47:07

you did not understand why something went

47:10

wrong and you investigated and you realized

47:13

two unrelated things plus the metric and

47:15

so on. And give these

47:17

several summaries that you have. And

47:20

say, these are kind of solved

47:23

problems we had. Find more problems. That's

47:25

a really cool idea. With the dashboards. I

47:27

think one of the challenges that we see, and I think a

47:30

lot of big companies will see, is we want to kind of

47:32

own this data. We want to keep it internal, some of it,

47:34

right? We have public facing postmortems, but

47:36

we have some internal things that we don't share

47:39

externally too. And so kind of taking this

47:41

stuff and giving it to open AI or

47:43

whatever other AI is

47:46

potentially a security risk. And I think we actually have

47:48

to do this for some of our compliance. So

47:51

I think there's one really interesting use case

47:53

that I'm still looking for. I haven't seen

47:55

great offerings here as being able to deploy

47:57

some of this stuff on-prem, right? You can

47:59

with Azure. and so on, you can have

48:01

even the German health companies, which is like

48:04

my peak GDPR example, they

48:06

use the German based data center

48:08

instance and that's like meeting all

48:10

the requirements worth looking into. Definitely has

48:12

to take a look. Like we obviously don't, we

48:14

run our own cloud, right? We don't use any

48:16

of the other cloud providers. So it might just

48:19

be, we haven't yet kind of invested the effort

48:21

to figure out how to deploy

48:23

this ourselves, but like I'd be super interested to be able

48:25

to, because I know there's tons of great open source models

48:27

now, so I'd love to go and explore that a little

48:29

bit further. So thanks for the idea. I'm going to add

48:31

it to my to-do list right now. So

48:34

we talked about PHP to go. What are some

48:36

things you did like about PHP and maybe you're

48:39

missing? I'll

48:42

have to think on that one for you to be

48:45

honest. Other than the mascot, they're really cute. Eliscent is

48:47

cute. I think one thing I, at

48:49

the time again, especially was the ecosystem.

48:52

Like there was every, every library or use case

48:54

or question you could have. Like there was

48:56

very clear answers to it. And

48:58

one thing that, this

49:00

isn't something I personally have a strong preference for,

49:03

but one reason that a lot of people still

49:05

love PHP and it actually seems to be growing

49:07

is Laravel specifically is

49:09

like in a very opinionated

49:12

framework about how you should write PHP apps. And if

49:14

you follow their rules, you will be able to put

49:16

something in production very, very quickly. So a bit like

49:18

describing Go. Yeah. The opinionated group

49:21

of doing things. Yeah, but it takes

49:23

things a lot further. In Laravel you

49:25

can be like, generate me

49:27

a service and a database

49:29

and like a cache and it'll just, it's one

49:31

command and it'll do all for you. And it

49:33

spins you up Redis and Postgres and it gives

49:36

you an R M and you have

49:38

to write code in a certain way, like you can write comments

49:40

above classes and it will generate stuff for you when

49:42

you run it and stuff like that. It's like

49:45

a very hyper opinionated framework for

49:47

how to build PHP applications. And it's very popular

49:49

because it's very productive. And I

49:51

think Encore is probably the closest thing in the

49:53

space in the Go ecosystem. And

49:56

I think they're doing a great job. I think

49:58

Encore is a phenomenal tool. think

50:00

they are having to constantly battle

50:02

a lot more against this

50:04

isn't, you know, the Go philosophy, this isn't the Go way

50:06

to do things. Like we like to write things ourselves. Whereas

50:09

I think in other languages, like you've got Ruby

50:11

on the Rails, you've got like Laravel, Spring Boot,

50:13

the people are more open to this idea. And

50:16

so I do wonder if we'll ever get there,

50:18

we'll ever land there with Go. But for now,

50:20

the it's very much being pushed

50:22

back against, I feel. Chris, is there something you

50:24

like about PHP? You liked and miss? Yeah,

50:27

I mean, I think the point I was gonna

50:29

make was exactly the same one, as Matt said,

50:31

I think with things like Laravel, you can basically

50:34

run a single command, it will generate a full

50:36

project that's production ready. And like, like I said,

50:38

you can specify, I want

50:40

this database, I want Redis, I

50:42

want even maybe even Kafka, things like that,

50:44

you can specify that and it generates all the code for

50:47

you. And it's ready to go out of the box. Like

50:49

all you have to do is implement your business logic. Yeah,

50:52

I think there are things like on core that give you

50:54

that and go. Yeah, it's, I think

50:57

they're much less adopted than they are

50:59

in PHP. And I think, yeah,

51:02

it removes a lot of the learning curve

51:04

for PHP, like you can, you

51:06

can just write business logic and run it very quickly.

51:08

Whereas with Go, you do kind of have to learn

51:11

how to write Go and how to structure projects and things like

51:13

that at the time. Well, one

51:15

more unpopular question. What

51:35

are your unpopular opinions? Who'd

51:37

like to start? I can go first. I know

51:39

for my unpopular opinion, I know at least one

51:41

person here will disagree with me straight away. But

51:45

I think that between three and four o'clock is

51:47

the best time to eat lunch. Wow.

51:51

Second lunch. Yeah,

51:55

I mean, I mean dinner at that time,

51:57

typically like that's way too late. I know.

52:00

I'm actually surprised Natalie disagrees with you. I thought it

52:02

was like 3 or 4 p.m. I thought it was

52:04

like a very European time to be to be having

52:06

dinner having lunch. No, I can

52:08

speak for myself that I have Multiple meals

52:10

and I definitely have my second lunch around

52:12

3, but I do have my main lunch

52:14

around 12 It's

52:16

I partially agree. I don't know. I Guess

52:20

in Spain, it's more common to eat

52:22

later. Yeah, I guess because it's been the

52:24

house yes, but um, I don't

52:26

know Yeah, I don't know what the science is behind it

52:28

There is any science but I swear when I have lunch

52:30

later in the day like that I don't get any kind

52:32

of dips in the afternoon So I feel

52:34

like I'm more productive in the afternoon when I eat lunch

52:37

later I don't know. I feel like you have

52:39

about six cups of coffee a day as well. So I think

52:41

claiming no because of late lunch is There's

52:44

more to the story I mean that probably helps yeah,

52:47

no, I've always been I

52:49

have a terrible habit where I have I don't eat

52:51

breakfast at all, which I think is part of my

52:53

problem So I usually just have coffee

52:56

for breakfast. I just find it hard to eat in

52:58

the morning. Oh that intermediate fasting Yeah,

53:00

I can call it that but I'd

53:03

like to claim I did it on purpose. But um, yeah,

53:05

I'm I'm type 1 diabetic. So I have to be Like

53:08

religious I think about how when I when how

53:10

I eat so I always found having carbs in

53:12

the morning for some reason There

53:14

are there are people sort of health gurus that claim this is

53:16

true, but I've certainly seen it in myself Carbs

53:19

in the morning seem to make my blood sugar go up

53:21

way way higher than they do later in the day So

53:23

I found that sort of fasting in

53:26

the morning and only having black coffee keeps my blood

53:28

sugar much flatter I have way more control when I

53:30

when I don't but that also means that I'm hungry

53:32

much earlier So whenever Chris and I are in the

53:34

office, I'm always at like 12 like come on Let's

53:36

go get lunch from starving and you know, Chris has

53:38

barely finished his breakfast at that point Do

53:41

you have another unpopular opinion other

53:43

than eating time? So

53:45

I have one which I am Actually,

53:48

I wonder if there's an unpopular or not. I think It

53:51

certainly would have been unpopular at one point, but

53:53

I'm not sure if it's still the case But

53:55

I think smart home stuff is like really stupid.

53:58

I completely went all in on the smart home

54:00

stuff a few years ago. I bought all the

54:02

bulbs and I wanted to get

54:04

the sockets and blinds that

54:06

open and close themselves. I

54:09

moved to house recently and I was about

54:12

three months before we moved. I was still pretty insistent this

54:14

was going to be the smartest house I ever lived in.

54:17

Then we had a power cut and

54:19

I couldn't open my blinds. I was like,

54:21

this is ridiculous. Imagine a world where you

54:24

can't open your blinds because the internet's not

54:26

working. I know there's sort of clever things

54:28

you can do to avoid that but it

54:30

really put me off and I've gone the complete opposite

54:32

way now. I've got really dumb stuff in our house

54:34

now and I have no intention to really invest in

54:36

smart things again. I had like five Alexa's in our

54:38

old house and I don't have one in this house.

54:40

It could potentially be sold

54:42

on another AI assistant if it

54:45

was actually smarter than Alexa was but I

54:48

haven't seen anything in that space yet. Surprisingly, it feels

54:50

like a really natural use case for open

54:52

AI stuff so I'm just waiting for them to sell

54:55

an Alexa-style thing and I'll probably get one. If

54:58

to summarize your opinion to one

55:00

sentence that we can then tweet

55:02

and have a poll and actually

55:05

evaluate. Smart homes should

55:07

not be a thing or how would you

55:09

phrase that? Yeah, I don't think smart homes

55:11

should be a thing. I think everybody is

55:13

better off with a dumb

55:15

house. Interesting.

55:18

I don't have a feeling where will this go but

55:20

I'm curious. What do you think Chris? So,

55:23

funnily enough, I actually have a few light

55:25

bulbs but I think we changed

55:27

the light plugs or something

55:29

a couple of years ago and they

55:31

stopped working so now I just use

55:33

the light bulbs as regular light bulbs.

55:36

I think I somewhat agree with

55:38

some things it's just easier just to

55:40

have them done but now

55:43

I definitely do think there are some

55:45

advantages to having smart homes. The

55:48

light bulbs are something I

55:50

enjoy. It's convenient that when

55:52

I go into the bathroom there is a sensor

55:54

and I don't have to with dirty hands touch

55:56

the light screech. I specifically like that one thing.

56:00

And if the internet goes out, I can

56:02

always still click on the button.

56:04

But that's where it kind of is for me. It's

56:06

true. It's frustrating how assistants

56:09

are useless. Yeah. It

56:11

also is, um, it just shows where Amazon really

56:13

fumbled as well. Right. They had such a lead

56:16

with Alexa. Like it actually bothers me that they're

56:18

not the ones like presenting like all this stuff

56:20

to open AI and Google too. Like it felt

56:22

like theirs to win, you know, I don't

56:25

really know how we got here. So massive

56:27

props to open AI for, you know, being

56:29

massively behind, at least on paper, having this,

56:31

like, you know, they went up against, you

56:33

know, Google and Amazon and Microsoft

56:36

and they're the clear, clearly

56:38

leading the pack when if I had to bet five years

56:40

ago, it was going to be like it would have a

56:42

hundred percent been Amazon Alexa is going to be the one to

56:44

take this. My unpopular

56:46

opinion is around which best

56:50

strawberry ice cream flavor is

56:52

the best. And I had a poll

56:54

so I can confirm this is unpopular, but

56:56

I think that definitely the best flavor, the best

56:58

thing you can do with ice cream with strawberry

57:00

ice cream is make it mint strawberry.

57:02

Interesting. I don't know if I've

57:05

ever had. Not basil strawberry, not

57:07

creamy strawberry, and also not sorbet

57:09

strawberry. Plain mint strawberry. I

57:11

don't know if I've ever had mint strawberry ice cream. I'm going to

57:13

have to go and try it, but I will say there's a strawberry

57:16

ice cream from Hagen-Dazs. I

57:19

think it's Germans. I'm really sorry if I've just

57:21

butchered the name of it. Hagen-Dazs is not German.

57:23

Americans made up a name that

57:25

sounds European, but it's like not in any European

57:27

language. So that was even more offensive than saying

57:29

it wrong. But

57:33

they do a strawberry cheesecake ice

57:35

cream and it's phenomenal. Like it's probably one

57:38

of my favorite ice creams. So I will

57:40

try strawberry mint, but I'm going to, I'm

57:42

going to say my default is that strawberry cheesecake

57:44

is probably one of the best ice creams that

57:46

has ever been created. And I'm probably going to

57:48

give an even more unpopular opinion now by saying

57:50

I'm not actually a massive fan of ice cream.

57:52

So yeah, I've never tried strawberry mint, but yeah, generally

57:54

I'm not a huge fan of ice cream. So I don't

57:57

really eat it a lot. Try to live somewhere where it's

57:59

funny. I think we deserve that for me

58:01

saying Hargen-Darls was a good moment. We

58:08

have a few months of pleasant weather a year. It just

58:10

starts now, so I guess we'll celebrate. Well,

58:13

this has been an interesting conversation. Thank

58:15

you for sharing your experience moving from PHP

58:17

to Go. We mentioned some cold

58:19

stuff. We will include them in the show notes and

58:21

we will tweet all the unpopular opinions to see which

58:24

one is the most unpopular. Thank you, Matt.

58:26

Thank you, Chris. Thanks for having us. Thanks

58:28

a lot, man. I'm

58:32

Trading Change Log Sticker Packs

58:34

for thoughtful 5-star reviews on

58:37

Apple Podcasts and Spotify or

58:39

blog posts recommending GoTime. Simply

58:42

send evidence of your review

58:44

or blog post to Gotime

58:46

at changelog.com alongside a mailing

58:49

address and I'll send you

58:51

free stickers right to your mailbox.

58:53

Once again, that's Gotime at changelog.com.

58:56

Go ahead, get your sticker on. Thanks

58:59

once again to our partners at fly.io,

59:01

to our Bfreakin' residents, Breakmaster Cylinder, and

59:03

to our friends at Sentry. Use

59:06

code CHANGELOG when you sign up and save

59:08

100 bucks on their team plan. Why not,

59:10

right? That's all for now, but we'll talk

59:12

to you again next time on GoTime.