All Segments
HARD truths before switching to Go
19 segments available
Twitch https://twitch.tv/ThePrimeagen Discord https://discord.gg/ThePrimeagen Become Backend Dev: https://boot.dev/prime (plus i make courses for them) This is also the best way to support me is to support yourself becoming a better backend engineer. ### LINKS https://www.youtube.com/watch?v=UEU4SzBjqrc By: https://www.youtube.com/@awesome-coding Great News? Want me to research and create video????: https://www.reddit.com/r/ThePrimeagen Kinesis Advantage 360: https://bit.ly/Prime-Kinesis
Segments Timeline
The Good and Bad of Go
In this segment, the speaker introduces the Go programming language, highlighting its popularity among developers and its backing by major tech companies. They discuss the positive aspects of Go, including its high rankings in developer surveys and successful projects like the TypeScript team's decision to port their compiler to Go for better performance. However, they also hint at the potential downsides, setting the stage for a deeper exploration of Go's complexities.
"I vibed so hard and got so far, but in the end, I still can't merge the [ __ ] PR. Thanks, Randall. But we're going to look at Go. Okay. Go has a How much do you want to bet that I'm going to disagree..."
Simplicity vs. Complexity in Go
The speaker reflects on the initial appeal of Go's simplicity, noting that while it appears easy to learn, this simplicity can lead to a lack of expressiveness. They share their personal experience transitioning to Go, emphasizing that the language's design choices can sometimes complicate coding practices, particularly for developers accustomed to other languages.
"the tech community. On top of that, it enjoys some of the best publicity thanks to the large companies. One to one. If go is bad, does that mean that come is good? I got to turn I got to turn off TTS...."
The Pitfalls of Channels
In this segment, the speaker warns about the overuse of channels in Go, which can lead to unnecessary complexity. They advise developers to use channels sparingly and share their insights on the nuances of Go's design, emphasizing the importance of understanding both its strengths and weaknesses before fully committing to the language.
"to improve its tooling and the resulting performance is magnitudes better than before, you know Go's doing something right. Can I also just interject for a second? the fact that it's 2025 and the Type..."
Realities of Go Development
The speaker discusses the realities of developing in Go, acknowledging that despite its advantages, there are significant challenges that arise when building non-trivial applications. They emphasize the need for developers to be aware of these challenges and to approach Go with a balanced perspective, recognizing both its capabilities and its limitations.
"who plans to learn or use Go in their next project should be aware of this caveat. You know the worst part about Go is that channels feel really nice to use and then you overuse them. There's like alm..."
Design Decisions and Developer Frustrations
This segment delves into specific design decisions in Go that can frustrate developers, such as the handling of loop variables and the lack of certain keywords. The speaker shares their personal frustrations and highlights how these decisions can impact coding practices, particularly for those transitioning from more feature-rich languages.
"decision. I do love that there was recently this like up in arms everybody's super angry at Go because they finally decided after what 12 years to fix the fact that a for loop was referencing or was k..."
Public vs. Private in Go
The speaker critiques Go's approach to visibility modifiers, where capitalization determines public and private access. They express their disdain for this method, arguing that it can lead to confusion and potential errors during refactoring. This segment highlights the speaker's strong opinions on Go's design choices and their implications for developers.
"Go. It was surprising to find out that based on some Google searches apparently I'm not the only one noticing these things. One of Go's biggest selling points is its simplicity. To be fair, it really ..."
Refactoring Challenges in Go
In this concluding segment, the speaker discusses the challenges of refactoring in Go, particularly the risks associated with changing the case of function names. They emphasize the potential for breaking APIs without compiler warnings, underscoring the importance of understanding Go's unique design principles and the implications for long-term code maintenance.
"to nag you after a while. For instance even though Go has a while loop, it does not have a while keyword. You just write a for loop and skip the condition. This forced syntax reuse just for the sake o..."
Enums in Go: A Clever Hack?
This segment critiques Go's implementation of enums, comparing them to C-style enums and labeling them as a workaround rather than a robust feature. The speaker argues that this simplistic approach lacks the complexity needed for modern programming, leading to potential issues in type safety.
"don't care how private it is. Especially when refactoring. Change the case of a function name and you've potentially broken your entire API without any compiler warnings. And let's be honest. Wait, wh..."
The Limitations of Multiple Return Values
The speaker examines Go's ability to return multiple values from functions, praising its initial elegance but criticizing its limitations. They explain how these return values cannot be treated as first-class citizens, leading to verbosity and boilerplate code that complicates larger codebases.
"the problem. You guys are the problem. Also, the word enum and Russ's use of the word enum is a crime against humanity. Uh it's they're they're union types. Okay? They're tagged union types if we're g..."
Error Handling in Go: A Double-Edged Sword
In this segment, the speaker addresses the verbosity of error handling in Go, acknowledging that while explicit error management can be beneficial, it often leads to repetitive code. They contrast this with Rust's approach, expressing a preference for Go's clarity despite the redundancy.
"complexity instead of eliminating it. I I just in my head, what I think is that people who were really excellent at C made a language that's easier to use than C. One of Go's more distinctive features..."
The Case for Explicit Error Handling
The speaker concludes by defending Go's explicit error handling style, arguing that it promotes clarity and reduces ambiguity in code. They share their personal preference for this approach over Rust's more convenient but less explicit error management, emphasizing the importance of understanding error states.
"your codebase. Let's consider the common scenario. I I could see why it'd be nice to be able I I do wish there was like an easy way to do channels with just like here's my list of values, right? Like ..."
Inheritance vs. Composition in Go
In this segment, the speaker contrasts Go's approach to inheritance with traditional object-oriented programming languages. They explain how Go favors composition to avoid the pitfalls of inheritance, which can lead to tangled codebases. This discussion sheds light on Go's philosophy and its implications for developers familiar with OOP.
"the only reason why I don't like it about Rust isn't because it it's not it's not that I dislike convenience. It's that I just hate the fact that you'll see something that looks like a method and then..."
Generics: A Long-Awaited Feature
The introduction of generics in Go is discussed in this segment, highlighting the limitations and challenges that have accompanied this feature. The speaker reflects on the mixed reception of generics and how they align with Go's philosophy of simplicity. This segment provides insights into the evolution of Go and the community's expectations.
"another await. Like if anyone has ever worked with some of those things and it's just like man there are so many things going on in this statement. It's such a turse statement and so many so much of t..."
The Trade-offs of Explicit Code
The speaker elaborates on Go's rigid type system and the absence of operator overloading, emphasizing the benefits of clarity and readability. They discuss how this approach can lead to more verbose code, especially in larger systems, and the implications for maintainability and onboarding new developers.
"feels like it's just lazily handled and just tossed up, right? And I just find that there's a lot there's there's a lot of behavior mixed in these lines. So when I glaze over something, I don't like t..."
Expectations in Go Programming
In this concluding segment, the speaker reflects on the expectations developers have when working with Go. They discuss the balance between sophisticated abstractions and the cognitive load they impose, ultimately reinforcing the idea that Go's design choices are rooted in a philosophy of simplicity and predictability.
"having to deal with errors explicitly. Did he just say good software is predictable. I could predict these errors are coming out, right? Forces you to acknowledge when something can go wrong and handl..."
The Generics Debate in Go
This segment discusses the introduction of generics in Go, which was a long-awaited feature that finally arrived in 2022. The speaker highlights the limitations of generics in Go, including the inability to use them on method receivers and the lack of operator overloading. The conversation emphasizes Go's philosophy of prioritizing clarity and simplicity over expressiveness, which can lead to more verbose code in complex systems.
"and simplicity. Go was initially designed without generics and that decision did limit the language for over a decade. Generics were finally introduced in 2022, but with a design that maintains Go's p..."
Understanding Go's Trade-offs
The speaker elaborates on the trade-offs of using Go, particularly its straightforwardness versus the complexity of more sophisticated abstractions. They explain how Go's design allows developers to easily read and understand code, which is beneficial for maintainability and onboarding. However, this simplicity can sometimes result in verbose code, especially in larger systems where more advanced abstractions could reduce redundancy.
"expectations. Yeah. I mean, but the the more sophisticated your abstractions are, the more like time you have to spend thinking about them. That's I mean I think that's the whole trade-off is that you..."
The Realities of Using Channels
In this segment, the speaker shares their frustrations with Go's channel implementation, emphasizing the need for context when using channels to avoid common pitfalls. They discuss the challenges of managing errors and the complexity introduced by the panic and recover mechanism in Go, contrasting it with the desire for a simpler programming experience. The speaker reflects on the balance between error handling and maintaining a reliable web server.
"Yeah,, I, I I, really, The, only, thing, I honestly didn't like about is the if the I think there's just like everything else it was fine. It was fine. The I I do agree with the channels and multiple ..."
Considering Alternatives: Elixir
The speaker expresses their interest in exploring Elixir as a potential alternative to Go for server development. They mention the positive feedback they've received about Elixir, particularly from a peer who advocates for its capabilities. This segment highlights the speaker's ongoing journey in programming and their openness to learning new languages while still appreciating Go.
"there's things that can go wrong and if you were to write like a proper web server you probably want to wrap all of your handlers in a pan like a panic recover because you want to make sure that if fo..."