Go’s Big Mistake

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.