0:12

Welcome to Go Time, your source

0:14

for wide-ranging discussions from all around

0:16

the Go community. Find

0:18

us on the web at gotime.fm,

0:21

on the Fetaverse at Gotime, at

0:23

changelog.social, and on X at Gotime

0:25

FM. Thanks to our partners at

0:28

fly.io, the home of changelog.com. Launch

0:31

your app as close to your users

0:33

as possible. Find out how at fly.io.

0:36

Okay, here we go. What's

0:42

up friends? Do you remember when chat

0:44

GPT launched? I do. It

0:46

felt like the LLM was this magical

0:48

tool out of the box. However,

0:51

the more you use it, the more you

0:53

realize that's just not the case. The technology

0:55

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

0:57

prone to issues like hallucination on its own,

1:00

but there's hope. There is

1:02

still hope. Feed the LLM reliable

1:04

current data, ground it in the right

1:06

data and context, then and only

1:09

then can it make the right connections

1:11

and give the right answers. The

1:13

team at Neo4j has been exploring how

1:15

to get results by pairing LLMs with

1:17

Knowledge Graphs and Vector Search. Check out

1:19

their podcast episode about LLMs and Knowledge

1:22

Graphs throughout 2023 at Graph Stuff

1:25

dot FM. They share tips on

1:27

retrieval methods, prompt engineering, and so

1:29

much more. Don't miss it. Find

1:32

a link in our show notes. Yes,

1:34

check it out. Graph stuff dot FM

1:36

episode 23. Welcome

1:56

to Go Time. I'm your

1:58

host, my name is Chris. There

8:00

was this debugging argument that

8:03

he was making that I was following,

8:05

but I'm not really sure how that's going to

8:07

shake out in the actual implementation as far as

8:09

when you look at it. I don't think it's

8:12

going to look this weird when you look at

8:14

it, the iterators. Yeah,

8:16

I think that's also something that can be worked

8:19

out in the error messaging and the stack traces.

8:21

There's also an argument here that

8:24

it implicitly transforms, returns, continue, breaks,

8:26

defers, all of those. And I

8:29

understand that that does add complexity when you're thinking,

8:31

but as far as writing code, I think that

8:33

makes it a lot more simple. I don't have

8:35

to learn how to do

8:38

these things outside of the actual keywords,

8:40

right? Trying to continue inside a

8:42

not like a custom iterator

8:44

now is kind of a nightmare. Yeah. And there's

8:47

been so many times I'm like, I would like

8:49

to continue here, please. So I

8:52

honestly do think it's going to be simpler overall,

8:55

just being able to use your normal

8:57

semantics and keywords. Yeah. Because I was

9:00

using the goldmark package the other day

9:02

and has this AST walking

9:04

thing. And you have to return special

9:07

things to be like, oh, continue or exit

9:09

or whatever. And I was like, this is

9:11

kind of wonky. I don't know if I

9:13

like this as much. And then also, error

9:16

handling sucked a whole lot. And

9:18

I think it's kind of easier

9:21

to apply your own error handling

9:23

if you can just do a regular for loop

9:25

here or for range loop. Because

9:28

you can just have the captured error

9:31

variable that should still work

9:33

is I think it should work. Let's

9:35

see why it wouldn't work. I know there's

9:37

also the argument that this is one more way to iterate.

9:39

Right? But I think that argument kind

9:41

of falls flat, because it's not like

9:44

there were standard ways to iterate before. Right?

9:46

So we're not introducing a new standard. It's

9:48

just we're agreeing on a

9:50

pattern. Yeah, making

9:52

an attempt to consolidate or at least give

9:54

people a predefined path

9:57

to go on and not just like

9:59

what package have you been using and

10:01

deciding how you want to design your iterator based on

10:04

what packages you've seen, how you have an actual like,

10:06

well, this is how you can canonically do it

10:08

in the language. And you can still go

10:10

do it by under the way if you wish. But this

10:12

is how the way people are probably going to be most

10:14

familiar with. Yeah. So to

10:17

sum it up, I'm not

10:19

sure it's going in the wrong direction. Yeah,

10:22

it's kind of a, it's a very bold and

10:25

broad statement. They'll be like, it's

10:27

evolving in the wrong direction. I

10:29

think it's, I think

10:32

the only direction that languages can

10:34

evolve, especially if you want backwards

10:36

compatibility guarantees, is to become more

10:38

complex over time. Like I

10:40

think through that complexity too, you can gain simplicity,

10:44

right? So I think there's a weird argument in

10:46

here about like, yes, we have to keep

10:48

all of these old iterator styles,

10:51

but perhaps, you know, not forever. Like

10:53

we have ways of deprecating things even

10:55

in the standard library now. So

10:57

it's like, it gives us a path toward

11:00

all of the iterators eventually looking the same

11:02

or being able to like convert one iterator

11:04

to like this style of iterator in the

11:06

future with some like glue code or something.

11:08

So it seems like it feels like it

11:11

will have the eventual effect of making things

11:14

more simple in the same way that

11:16

generics had the effect of making things

11:18

more simple. For example, from the slices

11:20

package, right? Now you don't have to implement your own slices

11:22

package or implement all these functional all of

11:24

the time, or you don't have to, you know, write

11:26

those same lines of code that

11:28

are kind of confusing if you don't understand

11:30

that pattern already. I think most people, you

11:33

see the word slices.clone, you're like, I bet

11:35

this clone's a slice, right? It's very, it's

11:37

very straightforward what that means. So

11:39

I think like, yes, on the, I think on

11:41

a small scale, it might add

11:43

complexity language. But I think on a large

11:46

scale, it's making the language go in a

11:49

good direction, toward more of

11:51

the simplicity that we want. Because yeah,

11:53

if you don't want to have any

11:55

added complexity, then you just can't add

11:57

anything to the language. And that is

11:59

also. also a bad thing for the

12:01

language. Yeah, I like that

12:03

small scale versus big scale. Like

12:05

it's making the ecosystem simpler,

12:08

not the language simpler. Right. And

12:10

there is a kind of somewhat strange argument

12:12

at the end here too, where he talks

12:14

about like, oh, like we should

12:16

have more SIMD instructions and things like

12:19

that because Go is losing in the

12:21

performance space to Rust. And

12:23

I mean, we can talk about this with the

12:25

next article, but I don't really know if like

12:27

Go is that great

12:30

of a language for performance critical

12:32

things. It's not terrible for

12:34

performance critical things, but I

12:37

don't think that's like the target that Go

12:39

is usually going for most of the time.

12:41

It's not like the, when I think of Go,

12:43

I don't think of like, oh, I need

12:45

like low level, raw performance. I think like,

12:47

oh, I want a language that allows me

12:49

to maintain, you know, large code

12:51

bases that do, you know, a

12:53

whole bunch of different things. And I want to be able

12:55

to actually maintain it with the somewhat large team of people.

12:58

Yeah, I do think that's a good

13:00

transition to the next article. Yeah, so

13:02

this one isn't so much of an

13:04

article as it is a post on

13:06

Reddit and someone asking in

13:09

our Go lane, what software shouldn't you

13:11

write in Go? And

13:15

interestingly, I feel

13:18

like the people that commented like

13:20

some of the top comments, I'm just like, you're

13:22

all oddly wrong. Like most

13:25

of it is about like, oh, garbage

13:27

collection is a barrier. Like

13:30

one of the comments literally says garbage collection is a

13:32

barrier for some hard real time processes. And

13:36

there was an interesting other Reddit

13:38

thread I found. It was about

13:41

same sort of thing of like, well, why do we

13:43

keep saying that Go is bad

13:45

at real time? And

13:48

the argument and people basically said like,

13:51

what do you mean by real time?

13:54

Like what type of real

13:56

time constraints are you talking about? And

13:59

this is a very insightful. just like, you

14:01

know, real time doesn't necessarily have to mean like

14:03

as fast as possible. It could also just mean

14:05

like at a fixed interval. But

14:07

also like, you know, we're not in the go, certainly

14:09

not in the pre-go 1.5 era or in the even

14:11

1.5, 1.6 era where the garbage collection

14:15

pauses were, you know, 10 milliseconds

14:18

at every 50 milliseconds. Now

14:20

it's sub millisecond max

14:23

garbage collection pauses. I think it's like 100

14:26

microseconds is where they've gotten it down to

14:28

for the like the longest, like worst case

14:31

garbage collection pause, which for

14:33

most real time systems seems to like

14:36

that shouldn't that does not feel like it makes

14:39

a large difference for most

14:41

people as far as GC is concerned. So I

14:43

don't I don't really buy that whole argument of

14:46

it's bad at doing things

14:48

that need to be real time. But

14:51

what do you think? I mean, I get what they're

14:53

saying, right? Like I'm not going

14:55

to write some in best embedded like

14:58

firmware and go that needs to

15:00

recalculate something a hundred Hertz, right?

15:03

Like that just doesn't make sense anyways. But

15:06

yeah, I think I think people are

15:08

still kind of confused about the stop the world

15:10

GC stuff. Yeah, I think people like that also

15:12

goes to like my thing. I

15:15

always remember of like you don't have a garbage collection problem.

15:17

You have a garbage problem. Like if

15:20

the garbage collector is getting in your way,

15:23

it probably means that you have done something

15:25

pretty awful with your memory management,

15:27

you need to go fix up your memory

15:29

management. Like garbage collection does

15:31

not mean you don't do memory management. It

15:34

means you don't have to write as much

15:36

of the code to management as intricately be

15:38

self to do memory management. Yeah,

15:40

I also saw a lot of arguments on here. You

15:42

shouldn't write like gooey is with go. And

15:45

I think I would tend to agree with that. Like that's

15:47

just not what I would reach for. I

15:49

think there are some like decent libraries now, but

15:52

yeah, I don't know. Yeah, I think

15:54

gooey's is especially when

15:56

like the native platform like

15:59

language. macros

20:00

to make everything work. Yeah,

20:03

anything else on this list

20:05

of responses? Oh,

20:09

someone said they write everything in Go. Oh,

20:14

god. I'm actually trying to answer this. Is

20:17

there a class of software you should not write in

20:19

Go? I don't think there is. Yeah, I mean, I

20:22

don't think there is. I think

20:24

there's software that might be slightly better

20:27

to write in another language. This

20:30

is kind of like a thing I've been thinking about a lot

20:32

lately. It's probably like

20:34

another podcast idea or another

20:36

podcast episode idea. But we can also talk

20:38

about if we have time, where I've been

20:40

reading a bunch of Leslie

20:42

Lamport's work, mostly because I

20:44

haven't read the Paxos paper in a long time,

20:46

the part-time parliament. And I was like, I think,

20:49

looking for something else that he had

20:51

written. And I came across like, basically,

20:53

Leslie Lamport has this very

20:56

long list of all his written works. It's, I

20:58

think, currently 193 works long. So

21:00

he's written a lot of stuff over his

21:02

career. And in the

21:04

kind of blurb he writes about Paxos

21:06

in the part-time parliament, he's like, oh,

21:09

this is a simple algorithm. And

21:12

he doesn't really, he's like, I don't understand why

21:14

people don't understand this algorithm. So I

21:16

said to him, I read that paper. And then after reading that paper, I

21:18

was like, oh, this is kind of simple. And

21:21

so I went through and like got a whole bunch of other

21:23

papers. So I'm going to read all of these. And

21:26

there's one of his papers where he's

21:28

talking about teaching concurrency and

21:31

kind of like his suggestions for how we

21:33

should teach concurrency to students, specific

21:35

computer science students and computer engineering students.

21:38

And there's this really great line

21:40

in that paper. Actually, let me

21:42

like pull it up so I can read

21:45

it correctly. And he's talking about

21:47

like computation here. So he says, how

21:49

should we describe computations? Most computer scientists

21:51

would probably interpret this question to mean,

21:53

what language should we use? Which

21:55

I think is kind of the question we're asking

21:57

here of like, I don't know what.

22:00

things shouldn't you write in a go? What things shouldn't

22:02

you use this language for? And then

22:04

he says, imagine an art historian

22:06

answering, how would you describe Impressionist

22:08

painting by saying in French? Which

22:11

is just a hilarious line. And

22:13

just, it's one of those like deep

22:15

and subtle cuts at us as an

22:18

industry. Cause it's true. It's like

22:20

we talk about like, oh, you shouldn't use that

22:22

language to build that thing. It's like saying you

22:24

shouldn't write that novel in French cause it's not

22:26

a good, like you should write all novels in

22:28

English cause English is a good language for writing

22:30

novels. And it's like, we should

22:33

not be thinking about things in that way. And

22:36

kind of this point is like, we should be talking about

22:38

this stuff in form of concepts. And I

22:40

think that's true of this discussion as

22:42

well of like, I

22:44

don't think that there are things

22:46

that you, there certainly aren't things you can't

22:49

write in go if you can write them

22:51

in any language. Go is a turning complete

22:53

language, which means it's equivalent to all

22:55

of the other languages. There might be like missing APIs.

22:57

You might have to like go do some FFI stuff

23:00

and to see to like make it work or to

23:02

other weird assembly stuff. But there's not

23:04

like a fundamental thing that you can't do with, that

23:06

you can do with Go and can't do with another

23:08

language or you can do with another language and can't

23:10

do in Go. So I think

23:13

it's like more about the concepts that matter

23:15

and can you express those concepts well in

23:17

Go? But also there's like the

23:20

whole other, other argument as well of just like,

23:22

I don't know if you're doing a startup or

23:24

something like that or creating a project, is

23:27

Go your strongest language? That's probably the language you

23:29

should write that thing in, right? So

23:31

if you're like, for example, when you're talking about early

23:33

about Goobies, it's like, okay, if you need to build

23:35

a whole bunch of Goobies and Go is your strongest

23:38

language, perhaps it's just better to

23:40

make a slightly uglier Gooey and

23:42

learn something like fine. So you

23:44

can just implement a Gooey

23:46

with that and then have the application you want

23:49

and then move on instead of having to like

23:51

learn a whole new language just to build

23:54

a Gooey, right? It's like, oh, I

23:56

got to run Swift and C sharp and I guess

23:59

C++. for Linux. I don't

24:01

know what Linux goobies are made in, but yeah,

24:03

go learn three other languages to go

24:05

express this same concept. Seems kind of

24:08

silly. It's like, yes, go. Oh, you

24:10

want to like write this same

24:12

story, but you need to write it in like

24:14

four different languages now. Like that feels a little

24:16

weird. If you could just write it in the

24:18

one, it can still be accessible to everybody. We're

24:22

right back to the ask

24:24

a question in software engineering. And the answer is

24:26

it depends. Yeah, yeah. I

24:28

mean, I guess the answer to this is like,

24:30

what software should you write and go is mostly

24:32

just like, I don't know, just just

24:35

write and go like, if

24:37

you know, go goes to strong language, right? And go like,

24:39

and if that doesn't work for some reason or the reason,

24:41

I'm going to write in something else. But I

24:43

think it's yeah, I don't think there's

24:45

any broad answers that that work for

24:49

this kind of certainly, you know,

24:51

the broad answers that will fit into like a

24:53

Reddit response that is reasonable to read. Right. When

24:55

people say like, can't build real time systems in

24:57

it. It's like, no, like,

25:00

nuance is required there. Like, if I'm

25:02

writing, like, spark jobs, I'm

25:04

not going to write them and go

25:06

though, because it's Python or Scala, right?

25:08

Like, that's the supported languages.

25:10

Like, I think there's an argument for

25:12

tooling here, right? Like, don't shoehorn go

25:14

into things where there is no tooling,

25:17

just because you want to. I mean, it also

25:19

depends on your goal. Right? Because

25:21

it's like, if you have that argument,

25:23

then there will never be tooling for that thing

25:26

in that space. Right? If no one does it,

25:28

then there's never gonna, it's not, it's not going

25:30

to be in that space. Right? That creates like

25:32

those artificial barriers. And I

25:34

think like even, even thinking in this

25:36

way is indicative of, I

25:38

think of the problem that like Leslie Lamport

25:41

was bringing up in that conversation, which is

25:43

like, or in that paper, which is like,

25:45

if we think in the

25:47

framing of like certain languages are

25:49

good for certain things, then we're

25:51

not really thinking about the problem

25:53

itself. Right? We're thinking about

25:55

this other colored version of the problem of

25:57

like, okay, this problem in. And

26:00

then it's like, oh, well, now if we go to another language,

26:03

you have to solve that problem in a different way in that

26:05

language, which is, I

26:07

don't know, not, not, not the,

26:09

not the best of situations, but

26:11

that's a larger industry

26:13

level thing we got to solve

26:15

for. Yeah. I agree with you

26:18

there, but I think there's some leeway on both sides.

26:20

Like at the end of the day,

26:22

you got to make money. You got to get stuff done.

26:24

Yeah. You got to get stuff done. I

26:26

don't know. Yeah. Like once again,

26:29

like the big view versus the little view

26:31

from a individual person standpoint, uh,

26:34

or a small company standpoint. Yeah.

26:36

There's probably some things you shouldn't rate and go and you got

26:38

to make that trade off. But it's

26:40

also like a different type of question. Like is

26:43

the difference you post a question to

26:45

a company versus toward an individual. I

26:47

would say. So yeah,

26:49

you're right. It's a, you know, it, it

26:52

depends. It depends. It depends.

26:54

Uh, yeah. Yeah. That's

26:57

the Lord, the answer

26:59

to all the questions. It depends. Yeah.

27:02

You know, there's a whole, whole series over on

27:04

a unchanged log. I think it's

27:06

a change on that friend series. It depends. I

27:09

did an episode. It was fun. There's

27:11

many more episodes. I have not listened to that yet.

27:14

I'll have to check it out. So I'll go listen.

27:16

They're good episodes. They're fun. All right.

27:18

Do we have anything else to say on what software

27:20

shouldn't you write and go? So choose

27:22

your own adventure. I do think

27:24

that leads interestingly into the make files

27:27

written and go alternatives to make written and

27:29

go. Should you write

27:31

an alternative to make and go? I think

27:34

probably yes. Yeah. Yeah.

27:37

I mean, make also make is for a number

27:39

of reasons. Pretty awful. It's

27:41

like standard, which is nice, but

27:43

like that whole only

27:46

using like tabs thing and

27:48

so many other weird syntactical

27:50

things about make and

27:52

make files is just exhausting.

27:56

And like, I, you know, for well-established

27:59

projects or I think. I think ecosystems

28:01

like C and, yeah,

28:03

that have this more baked into them,

28:06

it makes sense. But for Go, it's

28:08

always like, Make files always feel so

28:10

awkward, weird in Go. So

28:13

I think I've always like reached for

28:15

some other alternative. Have you used any

28:18

of the alternatives mentioned in the article?

28:20

I think I've used Mage a few

28:22

times. I don't think I've ever used

28:24

Taskfile. Also, I hate YAML, so I

28:26

don't think I want to use Taskfile. Yeah,

28:29

we use Mage pretty extensively where I work.

28:31

And I think one of the great parts

28:33

about it is, I don't

28:36

have to learn all the weird extrinsicities.

28:38

How do you say that? Oh,

28:40

extrinsicities, yeah. Of the AWS

28:43

CLI for doing stuff. Like,

28:45

Go has a great AWS

28:47

SDK, right? So we can do all

28:49

of our automated AWS stuff

28:51

in a Mage file and it just works. It's

28:54

amazing. I would definitely recommend. That's nice.

28:56

And just being able to keep everything

28:58

in Go sounds nice. I

29:02

mean, having the full power of like, a

29:04

full actual turning complete language is nice not

29:06

having to do, kind of as the author

29:08

points out, all of this kind of bending

29:11

over backwards to make stuff work with the

29:13

shell and the weird version of the shell

29:16

that Make has. Yeah, being

29:18

able to do real for loops is real nice.

29:20

Yeah. Not that the shell can't do for loops, but

29:22

I mess it up every single

29:25

time I try. Real for loops and logging

29:28

and, execution

29:30

of parallel commands and a whole bunch of other

29:32

stuff. That's just like, this is like easier to

29:35

do in Go than it

29:37

is to do in other things. So

29:40

yeah, I mean, I'm fully on board with things like Mage.

29:42

Once again, I don't, when it comes to task

29:45

file, I don't really see, I

29:47

guess if you don't want to learn Make, like

29:51

the syntax of Make and you're

29:53

happy with YAML, then it's good. But

29:55

I just really do not like YAML. There's

29:58

just so many oddities. Like I was writing

30:00

YAML inside of Markdown the other day and

30:02

it was like, I was getting some weird

30:04

error from it because, oh, because I was

30:06

writing it and it was like converting my

30:08

tabs to spaces, just spaces to tabs on

30:10

a which, but the YAML parser didn't like

30:12

the fact that it was not using the

30:14

correct spacing type and it blew up with

30:16

some weird error. And I was like, this

30:19

is obnoxious, I don't like this. How

30:21

it likes white space important syntax

30:25

is not

30:27

what I enjoy in life. So I would

30:29

probably just sit down and use make or

30:31

really just use mage or something like that

30:33

instead of task file. But I'm

30:35

sure plenty of people like this. If

30:37

we wanna dist.toml or YAML some more,

30:39

I think one of my most frustrating

30:41

days ever was because YAML was not

30:44

considering something a string I thought was a string.

30:48

So you don't have to quote things, right? But every

30:50

once in a while, that'll bite you. Yeah,

30:52

yeah. It's

30:55

such a messy

30:57

markup language for sure. I

30:59

get why it was created, but

31:02

there's a lot of things we create that

31:04

sometimes are bad ideas. A

31:06

lot of things in this industry we create are

31:08

bad ideas. But yeah, no, I think like mage,

31:10

mage is cool. I think I've used it a

31:12

few times in the past. If you haven't checked

31:15

it out, you should definitely listen or go check

31:17

it out. Especially- I

31:19

would recommend. Yeah, especially like the fact that

31:22

it's like a directory of files. So

31:24

you can kind of like properly manage the structure of

31:26

it and have your own little like build system within

31:28

your code base. What I think is helpful.

31:31

Yeah, we've actually used mage inside of GitHub

31:33

Actions too to help manage

31:35

some of the like build and test

31:38

scripts. And it

31:40

works real well. Yeah, it's like you're

31:42

building your own little build system, which if you're

31:45

only ready to go, that's a nice little thing

31:47

to have. Yeah, I don't know.

31:49

Much else we want to say on good

31:51

old mage or good old, what

31:54

are these alternatives to make files? That's

31:57

all I got. Ha ha ha. I

32:01

do recommend checking out. If it

32:03

works for you, it works really well. Yeah.

32:07

What's up friends? I'm here

32:09

with two new friends of

32:11

mine from SpeakEasy. Sengar Batchu,

32:13

co-founder and CEO and George

32:15

Hadar, founding engineer. So for

32:18

the uninitiated, SpeakEasy takes care

32:20

of the entire SDK workflow

32:22

to save you and your

32:24

team significant time, delivering enterprise

32:26

grade SDKs to your customers

32:28

in minutes. You can generate

32:30

best in class SDKs in

32:32

TypeScript, Python, Go, Java, C-sharp

32:34

and even PHP. So

32:37

Sengar, what's your excitement level

32:39

for APIs and this API

32:41

world we're living in? I'm

32:43

super excited about APIs. I

32:45

think we went through Gen

32:47

Zero of the API first

32:49

revolution. And I think we're actually going to

32:52

a second one now with the tailwinds of

32:54

the AI ecosystem kind of causing that to

32:56

be invigorated. So yeah, super, super psyched to

32:58

be working in this space right now. I

33:00

think it's, everyone's at a point now where

33:02

everyone knows about REST APIs and GraphQL APIs

33:05

and GeoPC APIs. And now I think we're

33:07

actually getting into the second phase of

33:09

that, which is how do people ship

33:11

great developer experience in addition to the

33:13

APIs? And how do we build

33:15

like truly best in class APIs that

33:18

turn into laying along the infrastructure, right?

33:20

And this is kind of the vision,

33:22

I think, that Stripe helped manifest for

33:24

everyone in the FinTech space, which is

33:26

an API that really sets the bar

33:29

for developer experience, but also like it's

33:31

something you can truly rely on. It's

33:33

a true fuming Stripe dependency of your

33:36

company. You can feel confident doing that.

33:38

And I think that's the part of API development

33:40

that really excites me. I agree,

33:42

that is exciting. So George teams who

33:44

leverage SpeakEasy are those who have leaned

33:46

all the way in on

33:49

documenting a solid open API spec

33:51

and mostly want to be hands

33:53

off of their SDKs. Is that

33:55

right? Precisely. So you're coming to

33:57

us because you want to be

33:59

hands off. from that process. You

34:01

want to put all of your effort

34:03

into documenting your API and then you're

34:05

trusting and relying on great quality tooling

34:07

to turn that into code and documentation,

34:09

which is what we're doing for you.

34:11

You're not meant to change or edit

34:13

the code because it will be regenerated

34:15

the next time you change your open

34:17

API. So you ultimately put it in

34:19

our hands. Once you've committed the changes

34:21

to your open API, it's off to

34:23

the races and you get a new

34:25

release of your SDK. You'll get a

34:27

pull request to review. You will have

34:29

the opportunity to look at the contents

34:31

of the code, but quite often you

34:33

can let it hum along creating SDKs

34:35

for you or new releases of your

34:37

SDK every time you change your API.

34:39

Very cool. Well, the thing that got

34:41

me with speakeasy that really helped me

34:44

understand it was that as George said,

34:46

it is hands off. You can just

34:48

focus on documenting your API via the

34:50

open API spec and you still have

34:52

pull requests. You still have visibility. And

34:54

in fact, they will even hop into

34:56

pull requests with you to triage any

34:58

sort of anomalies or issues that come

35:00

from the SDK generation and improve

35:03

the backend of speakeasy to make

35:05

future releases better for you. I

35:07

think this is so cool for

35:09

teams who want to just be

35:11

hands off of their SDKs and

35:14

focus on their product, focus on

35:16

the core documentation around the open

35:18

API spec, but still have all

35:20

that awesome visibility. Okay. So the

35:22

next step is to go to

35:25

speakeasyapi.dev. You can start off with

35:27

one free SDK. That's so cool

35:29

because you can go there right

35:31

now and try it out completely

35:33

free. One free SDK. Let them

35:36

know the changelog sent you, let

35:38

them know JS party sent you.

35:40

Once again, speakeasyapi.dev. So

35:50

the next article we have is titled

35:52

the long overdue problem coming for some

35:54

people in Go123. This

35:56

is kind of like an in the world. Weeds

36:01

article. This is talking about a specific

36:04

compiler directive called

36:06

Go Link Name that the Go team

36:08

is starting to really lock down. Should

36:10

we explain what it does? Yeah, yeah.

36:12

So it's about to explain what it

36:15

does. So Go Link

36:17

Name effectively allows you

36:19

to reference an object

36:21

or a symbol or something like

36:23

that that you would usually not

36:25

be allowed to access. So for

36:28

example, you can use it to

36:30

access a unexported variable

36:33

or function in another

36:36

package. So you have some package that has

36:38

some type or some function foo that would

36:40

only usually be able to be called from

36:43

within that package. And you have another package.

36:45

You can use this Go Link Name directive

36:47

to be like, actually, I

36:49

want to be able to call foo from inside my

36:51

package, which obviously, it's necessary

36:54

for the Go team and for

36:56

Go to have this for a

36:58

number of reasons. But it also

37:01

is kind of

37:03

not great because it means that

37:05

now all of your things

37:07

you meant to be private are not really private

37:09

anymore. You just kind of reach in and grab

37:12

them and take them out and use

37:14

them. Yeah, a couple of notes on that. You do

37:16

have to import unsafe to use this. So

37:19

you are the Go team is telling you, hey,

37:22

this is going to break. So

37:24

the changes that they're making is that

37:26

you can no longer just go in

37:28

and grab something out of any package.

37:31

And the next version of Go in 123, only

37:34

things that are explicitly marked as

37:36

you being allowed to do this will allow

37:39

you to do it, which I

37:41

just find to be kind of a funny thing

37:43

because then this is just another way of exporting

37:45

things. Because it's like, yeah, it is

37:47

a little bit weird. Yeah, it's like I get why

37:49

we're doing this kind of gymnastics to

37:51

make this happen. But it's just kind

37:54

of hilarious. You see it

37:56

a lot in the standard library. and

38:00

stuff from the runtime, right? Like

38:03

if they're gonna lock this down, I wonder why

38:05

there isn't just a runtime package that

38:07

is used to pull those things in. Like

38:09

there's probably a good reason, but I don't know

38:11

why. Yeah, and I think this

38:14

directive also was probably intended to be used for

38:16

something else and people found they could use it

38:18

for this thing and are like, oh, we'll just

38:20

use it for this other thing. It's

38:23

also interesting like the particular

38:25

situation of why the author

38:28

kind of stumbled upon this was because of

38:30

the quick go package that needed

38:32

to get the default Cypher suites for

38:34

TLS 1.3. And

38:37

in go, there was explicit choice

38:39

made that those Cypher suites are

38:41

not configurable, but also because

38:43

of, you know, does your

38:45

hardware support AES? Does your client want

38:48

to use AES and a whole bunch of

38:50

other things? It's not like

38:52

the default Cypher suites might not even

38:55

be like an actual like stable thing

38:57

that you can reference, which

39:00

is like an interesting little quirk of

39:02

this quirk is that, you know, the

39:04

reason why it's not an exposed variable

39:06

is because it's an extremely complex thing

39:08

that like can't really be determined until

39:10

runtime and still might shift at runtime.

39:13

So it winds up being like this kind of odd

39:16

space and that's why it's not an exported

39:18

thing. But yeah, just a little bit of

39:20

a weirdness. This whole

39:22

situation is just weird overall. But

39:25

yeah, it's like a little thing that's gonna start breaking

39:28

random things. I'm sure there's tons

39:30

of just people that have used this as some sort of

39:32

pack to get around something. And now stuff

39:34

is just gonna start breaking and people have to figure out how

39:36

to fix that. Yeah, and the

39:38

proposal to do this, I think is

39:40

really interesting because in it, Rustcox literally

39:42

says, hey, this is gonna break stuff,

39:45

but it puts us on a

39:47

good path forward. So it's worth breaking those things,

39:49

which I think I agree with. Yeah, I mean,

39:52

once again, you probably shouldn't be able to just

39:54

reach into other packages and

39:56

tinker with their unexplored things like

39:58

that. saying

1:02:00

like, Oh, we need to get

1:02:02

rid of these harmful, quote unquote harmful words on

1:02:04

our code bases. So master and master and slave

1:02:06

and blacklist and whitelist and all of these things.

1:02:08

And there's a huge hubbub

1:02:10

and people filed a bunch of PRs and we

1:02:13

eliminated a bunch of these words. And like, you

1:02:15

know, get we we changed it, it's no longer

1:02:17

master is default. It's main, right? We went through

1:02:19

all of this effort to change all of these

1:02:21

things. And this in this idea that

1:02:24

like, oh, these words using these words are harmful

1:02:26

to, you know, people of color, especially black people

1:02:28

and they shouldn't have to see them every day

1:02:30

and all of this. And I

1:02:33

push back a lot. And that at the time, I was like, this is

1:02:35

not this is not where we need to be spending our time. And people

1:02:37

said, well, we got to do something, we should be doing some things. And

1:02:39

like, we can do this, and we can do those other things. And

1:02:42

then you look at the same

1:02:44

industry as the same people. And we're

1:02:46

just like, you know, full on embracing

1:02:48

AI right now. And if

1:02:51

you go look at the underpinnings of how

1:02:53

all this data is cleaned, how these things

1:02:55

get trained, there's a lot

1:02:57

of like subjugation of like, especially people

1:02:59

of color going on a lot of

1:03:02

destroying of people's mental health and oppression.

1:03:04

And like, where is that

1:03:06

energy from our industry to push back on those

1:03:08

things, right? We said, well, we'll get rid of

1:03:10

these things. This is the first step toward fixing

1:03:12

larger problem. But then the

1:03:14

follow through isn't there. I think that's the same thing

1:03:16

that sort of happens in obviously different contexts

1:03:19

for these other things. We're like, oh, we got to

1:03:21

make software better. So the way we make software better

1:03:23

is by fixing the languages. But

1:03:25

the languages aren't the problem. It's the concepts

1:03:27

and understanding that's the problem. And

1:03:29

that's where the Rust isn't helping. But it's not

1:03:31

just Rust. It's like any of these languages that

1:03:33

are like, we will by making

1:03:35

this language better, we will make it so you

1:03:37

can write better software. And like, that's addressing

1:03:40

the wrong problem. So I guess at the

1:03:42

end of the day, you're saying it's not

1:03:44

the languages. That's the problem. It's us. That's

1:03:46

the problem. Yeah. The engineers.

1:03:49

Once again, I think Rust is

1:03:51

a cool language. I think people

1:03:53

should use Rust. I think we

1:03:55

should have memory safety. And I think the

1:03:57

baro checker is a really cool thing. And I think we

1:03:59

should have type safety. which of all these tools that help

1:04:01

us write software better, but we

1:04:03

shouldn't forget that the primary problem with

1:04:06

software today is not that we don't

1:04:08

have memory safety. Like we've been able

1:04:10

to write many a systems with really

1:04:12

good, without having memory safety. We've been

1:04:14

able to write many a systems without

1:04:16

having type safety, right? And

1:04:18

the end of the day, your computer also like, assembly

1:04:20

doesn't have any of these things. That's what's running everything,

1:04:23

with the instructions at the end if they don't have

1:04:25

these protections on them. So it's like

1:04:28

not having these things doesn't preclude us from

1:04:30

writing good software. So we should

1:04:32

focus on what are the things that will help us write

1:04:34

good software, which I think that this

1:04:36

could be a part of it once we actually teach people

1:04:38

how to think about code and how to think about their

1:04:41

programs. So I think if you

1:04:43

actually do sit down and you spend time, a lot

1:04:45

of time thinking, you wind up with massively simpler solutions

1:04:47

to problems. And if you

1:04:49

kind of aggregate those things together, you wind

1:04:51

up with massively simpler, larger code bases at

1:04:53

the end of the day. Because if

1:04:55

you don't, the problem just snowballs. Like once you're already in

1:04:57

a mess, it's so much harder to get out of that

1:04:59

mess. Yeah. So

1:05:02

we'll see how unpopular that is. I mean, they're probably

1:05:04

pretty popular with Go people. So just said, you know,

1:05:06

Go is the ideal language for writing

1:05:08

good software. Well, not ideal. It's one of the good

1:05:10

ones. I would say like Wisp is probably one of

1:05:13

the more, you know, ideal

1:05:15

languages for the translation, at least

1:05:17

from the view of computation, if you

1:05:19

want to do it rigorously into actual

1:05:21

code you can run. I

1:05:23

think I do have an unpopular opinion. Okay, go for it.

1:05:26

And this is something I want to do an episode on. I

1:05:29

guess the premise is learning Go isn't

1:05:31

easy. I know we say that

1:05:34

a lot. Like, oh, Go is easy. You can

1:05:36

get it down in an afternoon. And

1:05:38

I would go on to expand that learning any

1:05:40

new language isn't easy. And it's

1:05:42

not, when we say learning a language, I think a lot

1:05:44

of people think learning the syntax

1:05:46

of a language, right? Like how to do a

1:05:49

for loop, how to assign a variable. And

1:05:51

I think that's the, not even the tip of

1:05:54

the iceberg, it's just the pointy part on top

1:05:56

and nothing else, right? Learning a language is learning

1:05:58

its paradigms, learning. like how

1:06:00

it's normal libraries where it gets learning

1:06:03

how to write idiomatic code in that

1:06:05

language. And that's not like

1:06:07

you're never going to get that overnight. Like

1:06:09

that's all going to come with experience. So

1:06:11

pretending that any language is easy

1:06:13

to learn, I think does the whole

1:06:15

community a disservice,

1:06:18

right? Acting like you can jump into a language and

1:06:20

immediately write good code is, is I

1:06:23

don't say realistic, at least it's not realistic

1:06:25

for me. You just don't know enough to

1:06:27

know if you're writing good code when you first

1:06:29

jump in. So learning any programming language is not

1:06:31

easy. Learning the syntax is easy. The

1:06:34

rest is hard. Yeah, I think I

1:06:36

agree with that. Because I think like the

1:06:38

way I was just kind of translating that in

1:06:40

my mind was like, if you think about it in

1:06:42

terms of like language as a whole, it's like, yeah,

1:06:45

you can learn like the syntax and the grammar of

1:06:47

like a particular natural language.

1:06:50

But also deeply embedded into language is

1:06:52

the culture of the

1:06:54

community that developed that language. And

1:06:58

it takes a lot of effort to learn that

1:07:00

culture and to understand that culture, especially if that's

1:07:02

a culture that is somewhat at

1:07:04

odds or juxtaposed with your own words,

1:07:06

like, okay, like, I think

1:07:08

this is like the thing between like, I have some friends

1:07:10

who are like Eastern Europeans and the way that they express

1:07:13

things in the way that Americans tend to express things is

1:07:15

like vastly different, especially when it comes

1:07:17

to levels of excitement. I think that same sort of

1:07:19

thing exists within programming languages where it's like, yeah, I

1:07:21

know the way that you express something in, I mean,

1:07:23

Go and Rust are good examples. The way you do

1:07:25

something in Go and the way you do something in

1:07:27

Rust are going to be

1:07:29

very different because the cultures of those communities are

1:07:32

very different. So you might be able to learn

1:07:34

in syntax, but actually understanding

1:07:36

all of that cultural stuff is

1:07:38

real tough. I think that's

1:07:40

the perfect analogy for it. Yeah, yeah, I

1:07:42

know. So I think, yeah, it's, I

1:07:46

think our unpopular opinions are like somewhat,

1:07:48

somewhat tangentially related because it's like the

1:07:51

tough part of, of all of

1:07:53

this is like figuring out like, how do you express

1:07:55

what you want to express in

1:07:57

the language, in the way it should be expressed in the

1:07:59

language? And I think that's how

1:08:01

you wind up with these languages

1:08:03

that get, or these concepts that

1:08:05

get siloed into our particular language

1:08:08

is because we like, oh, well, that language is easy

1:08:10

enough to learn. Like I think Python and data science

1:08:12

is a good example of just like, oh, Python is

1:08:14

easy enough to learn. So you can

1:08:17

do data science and data engineering in it. And

1:08:19

that whole world just kind of gets everything built

1:08:21

for it. But it's like, do

1:08:23

the people doing those things understand conceptually

1:08:25

what it is that they're doing and

1:08:27

they're simply mapping those concepts into that

1:08:30

language? Or can they only express those

1:08:32

ideas in that language itself and they

1:08:34

can't pull it out to another language?

1:08:37

I think that's a, that's an actual more concise way of saying

1:08:39

my own unpopular opinion is like, no, we need to need

1:08:42

to focus more on having the

1:08:44

conceptual understanding and mapping it into

1:08:46

the language as opposed to having

1:08:48

the language be our only vehicle

1:08:50

for expressing that conceptual thing. Yeah.

1:08:53

It's almost like we're learning things the wrong in the

1:08:55

wrong direction, like inside out. Yeah.

1:08:58

Instead of outside in. We're hyper focused on language, which again,

1:09:01

was, is Leslie Lamport's point. Like I

1:09:03

haven't finished reading the computation and state

1:09:05

machines paper, but in

1:09:07

that paper, he basically talks about

1:09:09

his interesting thing in the beginning

1:09:12

of it where he talks about

1:09:14

like, oh, imagine

1:09:16

if we didn't use equations

1:09:18

in say physics. So

1:09:20

you have two different parts of physics that

1:09:22

had their own special notation that it might

1:09:25

not be obvious that like E equals MC

1:09:27

squared is like the same thing in these

1:09:29

two to, in two different parts of physics,

1:09:31

right? Or now for, for

1:09:33

anything, right? If you don't, if you use

1:09:35

dissimilar syntax, then it's not going

1:09:38

to be easy to recognize similarities and

1:09:40

patterns between two different places or that

1:09:42

you have the exact same thing in

1:09:44

two different places. And

1:09:46

so his kind of point there was like, oh,

1:09:48

well you might, you have equations and just because

1:09:50

like you have two equations that say

1:09:53

the same thing, doesn't mean they do the

1:09:55

same thing inside of the branch of physics

1:09:57

that you're operating within in the same way.

1:09:59

like you can, you know, if

1:10:02

you put this into natural language, you can

1:10:04

say the same English phrase to

1:10:06

two different communities of people, and it

1:10:08

could mean two vastly different things, even

1:10:11

though the words are still equivalent. But you have

1:10:13

the ability to kind of like understand and translate

1:10:15

those things because you have the similar base

1:10:18

of words that you're using and all of that. Yeah,

1:10:20

I have that issue talking to non-software people, like a

1:10:24

regular software term will slip into everyday language

1:10:26

and they're like, what are you talking about?

1:10:28

Yeah, that's like, that's the, you know, the

1:10:30

beginner to master. Like, you know, you've mastered

1:10:32

something when you can explain it to someone

1:10:34

that doesn't have any context for what it

1:10:36

is because like you understand what the concept

1:10:38

of the thing is so you can better

1:10:41

bring that over to what people want to understand.

1:10:43

So yeah, I think these

1:10:46

would be two good episodes. I

1:10:48

had to get some people that will probably disagree with me and

1:10:50

get Johnny on, get some,

1:10:52

who else would disagree with me? Oh, maybe I can

1:10:54

get Sam to come back. I

1:10:58

don't disagree with what I'm saying. And another, you know,

1:11:00

gotta, gotta, gotta, if I'm gonna have this as an

1:11:02

episode of like, yeah, meh, on Rust for all these

1:11:04

reasons, gotta have people that are gonna disagree with me.

1:11:06

This is assuming that they're gonna disagree with me. They

1:11:09

might agree with me and then it wouldn't be as

1:11:11

fun or it might be like, you know,

1:11:13

Sam stands on Rust. I don't, I

1:11:15

think he's, nah, I won't speak

1:11:17

for that. I think he's fine with it, but now

1:11:19

I don't know. That'll be a good thing to learn,

1:11:21

right? Yeah. Yeah. I'm interested to know. I'm

1:11:24

still undecided on Rust. So again,

1:11:26

I don't, I'm probably going to

1:11:28

learn Rust. Like I, like me

1:11:31

being Matt on Rust has little to do with

1:11:33

like the language or its usefulness or utility. Like

1:11:35

I understand in the current context it is. It's

1:11:37

a more macro thing, right? Learn

1:11:40

concepts, people learn how to think. That's the big

1:11:42

thing. We all need to learn how to think.

1:11:44

And I hope, I

1:11:46

hope people don't think it's an insult. I'm not

1:11:48

insulting us as an industry by saying that we

1:11:50

don't think about things. Like thinking is very

1:11:53

difficult to do and it's a very difficult thing to

1:11:55

learn how to do, to think critically

1:11:57

and intensively about things. Like. So

1:12:00

it's not an insult to anybody to say

1:12:03

like, we're not thinking, it's just

1:12:05

a thing that we should fix if we want to

1:12:07

build better software. It's like, yeah, you gotta think, it's

1:12:09

hard. It's hard work. We get paid a lot of

1:12:11

money. We can do the hard work. But

1:12:14

yeah, that feels like a good place to wrap

1:12:16

it up. Any last

1:12:19

words, Ian? I

1:12:22

think we've said it all. I think so. Thanks

1:12:24

for joining me and thank you listeners for

1:12:26

listening to this kind of all over the

1:12:29

place episode. I hope you enjoyed it as

1:12:31

much as the last one we did. That

1:12:36

is Go Time for this week. Thanks

1:12:38

for listening along. Subscribe

1:12:40

now if you haven't already head

1:12:42

to gotetime.fm for all the ways

1:12:45

or simply search for Go Time. Wherever

1:12:47

you get your podcasts, you'll find us.

1:12:50

Hey, do you receive our change

1:12:52

log newsletter each Monday? If not,

1:12:54

let's fix that bug. One reader

1:12:57

calls it so good, he considers

1:12:59

it a competitive advantage. Sign

1:13:01

up for $0

1:13:04

at changelog.com/news. Thanks

1:13:06

once again to our partners at fly.io, to

1:13:09

our mysterious beat freak, Breakmaster Cylinder, and

1:13:11

to our friends at Sentry. We love

1:13:13

Sentry. You might too. Use

1:13:16

code changelog when you're signing up for a team

1:13:18

plan and save $100. Why

1:13:20

not, right? That is all for

1:13:22

now, but we'll talk to you again next time

1:13:25

on Go Time.