It's been no secret that I I love Go,

okay? I have spent many an hour

programming on Go. I built an entire

whole like Doom where a thousand people

could play Doom all at the same time via

Go. I have been a big fan of Go for a

very very long time. It was one of my

go-to languages that I would reach for

whenever I'd want to build anything that

kind of interacts with the command line,

anything that needs to interact with the

system. Very quick, very simple, and

honestly, I just have a lot of warm

feelings about it. But I do know it's a

simple language. There's nothing about

it that was complex. There was nothing

about it that you could do or represent

in a complex way. And that's honestly

been a huge appeal for me is that I

could do so much because all I would

care about and all I would focus on is

writing about the problem as opposed to

solving the kind of ancillary problem.

And this has been the Go mantra for a

long, long time, which is like you go

into any Go project,

pretty quickly you can feel at home.

Everyone uses the same formatter. Every

function effectively looks like you

would write it to do. Everything is

pretty constrained in the exact same way

cuz there's really only one way to write

Go. But those days, they're changed. And

we're going to be doing a lot of yapping

here, so I hope that you're prepared

because this is one of those passionate

yaps where it's like I feel like my

childhood's being ripped away from me,

okay? Now, before we kick off this whole

Go apocalypse that I'm going to be

yapping about, I do want to kind of give

you my first introduction into Go. it

was right around 2015, 2016 I started

writing Go a little bit more seriously.

And of course, I became so kind of Go

pilled or Go brained that

there's certain phrases that I couldn't

understand about other languages if you

said it to me. Like I it wouldn't land

on me. A good example is I was at

Facebook interviewing. Yes, I

interviewed for the performance team.

And during that time, they asked me a

simple question, which was, "Hey, how do

you return multiple values in

JavaScript?" Now, me personally, I'm I'm

in Go land and I'm like, "Bro, you can't

do that, okay? Go has multiple return

values. JavaScript doesn't have multiple

What the hell you talking about? And of

course, then the person's they they

thought I was an idiot because they're

like, you return an object, you dummy,

or an array. And I'm like, but that's

one value.

>> [laughter]

>> And I just remember being so offended by

that and I was just so go-pilled I

couldn't hear what he was trying to say.

You get the idea. I failed the interview

so massively on such a stupid thing.

Anyhow, so my Go days have been long.

I've really enjoyed it. I've used it for

quite a few years. And I'd have to say,

it's been one of my favorites. Now,

before we begin, I'd like to say thank

you to the sponsor and a quick word.

HEY, DO YOU LIKE WAITING? YEAH. Neither

do I. With Blacksmith, you get speed, 2x

faster hardware, 4x faster cache

downloads, and 40x faster Docker builds.

So, stop waiting around. Use their

migration wizard to easily transition

your repos onto Blacksmith today. Thank

you, Blacksmith, for sponsoring this

video. And you, check out the links down

below.

Hi. All right, so welcome back. Uh it

turns out that now Go and Go 1.27,

you can do uh generics even on method

receivers. For those that don't know,

for a long time in Go, you could only do

it in functions. If you don't know what

a method receiver is, effectively, you

can create a struct and something that

looks like a function hanging off the

struct would be a method receiver. It'd

actually be a function that's associated

with some data, just like an object or a

class. And you could never do generics

on that. You could only just do it on

free-form functions, and that's it. But

now, in our new world that we live in,

you can now do it on everything. So, you

can actually see right here, here's a

result object, right? And it can have a

value V or an error error. And I have an

is okay function, like, "Hey, are you

okay if the error equals nil? Yes, you

are. Okay, awesome. You're okay." And

this is generic over the value V, which

means I can also do things like this. I

can return a result of type foo, which

means it has an error. And then I can go

in here and do all of this beautiful

code, where now I have a results object,

which means I can write code that looks

a bit more like this. I can convert a

read operation into a result. I can then

stringify it from bytes, and then I can

parse it, unwrap it, and print it right

here. If my file contains an error, it's

going to let me know, "Hey, there's an

error in whatever you're attempting to

parse." If I jump back over here, go in

here, jump this thing, and say turn it

into 69, nice, rerun this thing, you'll

see right here, "Hello, 69." Everything

parsed fine. So, I know at this point

people are looking at this and going,

"Hey, I kind of like that style of

code." This would be nice code for me to

work on with Go. And I do hear you. This

is generally nice code, but you have to

kind of take a step back and understand

Go from the very beginning. The very

mantra of Go is that there's one way to

do anything. Do you think that this is

going to lead to one way to do

something, or now you're going to have a

cornucopia of different ways in which

you're going to do stuff? You're going

to jump into code bases and have no idea

how they work. You're going to have to

go through layers of abstraction and

whole new ways in which to express

things, in which is just going to be

like every other language, just without

all the conveniences. A good example of

that is if you wanted to do a You can't

do like a generic convert function,

where I can convert any function with

any length of arguments into a result

type. So, instead you have like convert

one, convert zero, convert two, convert

three. I've tried many times to get some

version of this working, and I could not

seem to get this version of this thing

working right here. Whereas something

like this in TypeScript, very easy to

do, right? Like, okay, there you go. You

can convert any amount of arguments into

this. And so, it's like the actual

genericism that Go lang is providing is,

in fact, not that good. But then on top

of it, it's just going to make every

code base completely different. And this

was the entire argument, by the way, as

to why they were not going to do error

handling. Error handling has

historically always been the butt of a

joke for when it comes to go, because if

you wanted to do something like this,

print some, you'd have to take the two

strings coming in, convert the first

string into a number, which could result

in an error, cuz that makes sense,

right? If I try to convert hello into a

number, well, it's not a number. It's an

error, actually. And so, there we go. We

have an error. Yeah, I convert B, that's

into an error. Then I can finally print

then I can finally return. So, that

means this is error handling code, error

handling code, error handling code. That

means there are 1 2 3 lines of actual

code, whereas there's 1 4 7 lines of

code dedicated to error handling. And

this has always been the big problem.

Now, I personally have enjoyed this kind

of error handling, cuz that means every

single time I do something that could

error, I know it, and I have to

explicitly handle it. Now, granted,

there could be some more ergonomics

around it, but nonetheless, I've

actually really appreciated that about

Go. And the reason why they said, "No,

hey, we're not doing fancy error

handling, okay? We're not going to be

throwing in tries. We're not going to be

throwing in some sort of extra error

capture up here. No, we're not going to

be throwing in little question marks

like we're Rust, okay? We're not doing

any of that brother. Okay, we're

going to keep Go Go, the end." And

honestly, you may not like that, but to

me, that is okay, because that is one

thing I have appreciated about it. Every

code base is the same. Now, we have a

whole new set of problems. We now have

iterators. So, now you're hiding what's

actually happening. Again, another thing

I loved about Go. Everything you did,

you understood the cost. When you need

to iterate over a list, you could

understand what's happening. Now, all

sorts of stuff could be hidden from you

due to iterators. We now also have

generics. And in fact, this has led to a

very good article called Go's evolving

in the wrong direction, because here's

the deal.

If you want a fancy type system, don't

use Go. So, now that they're adding all

these features, you still get all the

crappy type system of Go that was good

because of the way it was, an unabashed

procedural language, right? It's purely

imperative. Nothing about it was fancy.

But instead, it's like you get Rust

light. You get kind of like the worst

version of Rust or the worst version of

TypeScript. Brother, if I wanted those,

I should just go and use those other

languages. They have significantly

better items to offer if this is what I

was going for. I use Go for what it was,

not so that it could look like every

other language just with a new set of

syntax. This is the thing that really

bothers me about Go. Go knew what it

was, and that's one thing that was very

special about Go. A strong standard

library, a very simple language. Now,

yes, could they have made error handling

better? Absolutely. Could they have made

enums of any kind? Absolutely, and I

think that would have dramatically made

people's life better. But they didn't.

They have chosen to actually add to the

language ways in which make it so that

every code base is going to be so

bespoke now and so much different. It's

going to be so much more frustrating

than it used to be. Go is no longer the

language I like. I don't want to use Go

anymore. In fact, I kind of found its

spiritual successor. So, Odin right

here, the language that you see right

behind me, this thing I've actually

really enjoyed because it reminds me so

much of Go. It has package level or

directory level packages. So, everything

inside a directory now shares all the

types. I really prefer that over file

level modules. I like package level

modules or package level directories.

Oh, so much better. It also has explicit

overloading. I really, really liked it.

It does do some polymorphism, parametric

polymorphism, and all that. But

honestly, I rarely even feel like I need

that. I just program the problem and it

works. The language looks good. It gives

you complete control over allocations

and how memory works, and it's just so

straightforward, absolutely lovely to

work with. And that's because Odin knows

what it wants to be. It's an unabashed,

simple, C-like

programming language designed and geared

towards games and graphics and that kind

of nature. Go used to be the same thing.

It was a simple kind of system-level,

server-level language that was designed

to sit in this intersection instead of

being like complicated Java land, you'd

have something super simple. The build

tool, the formatting tool, the how you

run it, all into one. It was a

self-contained, self-packaged language

with a very minimal package management

system built into it such that you

didn't actually overrun your project.

Like it knew what it was. But now, for

the first time, I feel like Go is having

its spiritual crisis. It doesn't know

what it wants to be. Now, apparently, it

wants to be Rust. It wants to like Okay,

I guess we have C++ light now.

Fantastic. That's all I've ever wanted

in life, right? I just wanted another

thing in which I can have massive

abstractions and find myself tight

masturbating all day instead of actually

solving the problem at hand. Thanks, Go.

Anyways, I say all this because I'm just

getting all fired up because it's like

one of the languages that I found very

appealing due to how different it was

from everything else. Like I knew that

when I used it, I was solving a specific

problem, and it was like the best tool

for the job. Like it had this very nice

kind of one-to-one reach. And now, like

Odin, it feels like that, too. It's a

very It has this very defined purpose,

and I feel like I can just reach for it

when I need to solve a certain problem.

I don't feel that anymore with Go. And

it just makes me feel a little bit

funny. I don't know. I don't know. Well,

hey, you know, I'm supposed to do this

as a YouTuber. Yo, hey bro, hey. What's

your opinion on this? Honestly, I'll

read them. Lay me Lay me down some

opinions. Maybe smash that like button

and the subscribe or something like

that. I I asked for this in a long time,

okay? I haven't asked for this in over

130,000 subs. So, why don't you just do

it? For old times' sake, okay? Me and

you, we're going to feel good better

together. The name

is the Primagen.