Go for BURNED OUT Rust Developers

All right, Rustaceans. It's time to broaden our horizons a little bit. In this video, we're going to look at Golang. Partially because it might offer things that resonate with you. And partially because, well, there might be something between these just begging to emerge. Go is a language where the

borrow checker is just a mythical creature of the past. It's a place where developers are trusted to avoid referencing unallocated memory. Data lifetimes are for the garbage collector to figure out, not you. What

even is that thing? And where locks on shared data are optional. I didn't necessarily say any of this resonates with me. This is more about you. But more on that toward the end. So, set those lifetimes aside. Here we go. Okay, this is a big one. To make a collection of an abstract type in Rust, you need to box a trait object. In Go, you can just refer directly to the abstract type, which in this case is called an interface. So much easier. In Go, you no longer need to deal with an option type. Things like pointers and interfaces are implicitly optional by default. You can set them to nil. In Rust, you'd have to use option. But then everywhere you read the value, the compiler forces you to handle the sum and none cases. That can make things really verbose. Get this. In Golang, after you pass a variable to a function, you can still reference it later after that function call. The way programming languages have always been. In Rust, in most cases, if you want to refer to a variable again after passing it to a function, you have to pass something called a shared reference to the function. Things can get really confusing with all those ampersands flying around. So, if you have to use Rust, pro tip, just clone that Tanta knows what I'm talking about. In Rust, if you have a recursive type like this employee with its manager field, you can't just make it a pointer. You have to choose from one of a thousand wrapper types depending on what you're trying to do. In Go, you can just make it a pointer and bam, you're done.

Let's talk about loops. Rust has several loop keywords: for, while, and loop for when you want an infinite loop. It also has iterators and combinators. There isn't really one idiomatic way to do things. Go only has the for keyword. But in Go, it encompasses the functionality of all three Rust loop types. It did get iterators in 2024, but imperative for loops are still the gold standard. Okay, this is a good one. Sick of separate impl blocks for every trait a struct implements? Golang struct methods stand on their own. If a struct has method signatures described by an interface, it automatically becomes an implementation of that interface. Now, buckle up cuz we're about to talk about the big one, async. But speaking

of interfaces, I'm very happy to say that this video is sponsored by JetBrains. It's been almost 20 years since I started using their products. Yep, I was rocking good old IntelliJ back in 2007 thinking it was the greatest thing ever. Well, now we have Juni. And my 2007 self would be shocked. It's a coding agent that isn't like the rest. It has some tricks up its sleeve like live prompting. You can send a new prompt before you get the result from your previous prompt. I have been wanting this for so, so long. Most agents use LSP to guide their actions, but Juni leverages tools from the IntelliJ platform to give it a better handle on your code base. That should yield higher quality code. You can use it on the command line in Zed, IntelliJ, or any IDE that supports the ACP protocol. Definitely check out Juni when you get a chance. Link below in the description. Thank you again to

JetBrains for sponsoring this video. Async Rust can get a little crazy. I mean, you basically have to add a third-party dependency just to be able to execute async functions. On top of that, they won't automatically run in parallel. For that, you need to use Tokio spawn or something similar. In Go, you just use goroutines. One keyword, no async await, no send and sync traits. Oh, and you can reference global state directly in any goroutine. Locks or atomics? Completely up to you whether you want to use them. But the Golang way to share data between threads is to use channels, and channels are actually built into the language. They have a dedicated keyword, chan. The Rust equivalent just feels Okay, you can do the same thing in Rust. Channels aren't built into the language, but they are in the standard library. Okay, not so terrible, I guess. Now, let's talk JSON. In Rust, you need to add the serde crate and add this serialize macro to the struct that you want to serialize. Then to actually serialize it to JSON specifically, you need to pull in the serde_json crate, too. Things are simpler in Go. JSON serialization is in the standard library. It uses something called reflection to automatically understand fields and convert the struct to JSON. So, no need to add these weird derive macros to your struct. Okay, guys, let's

have a little chat. This was a little satirical and tongue-in-cheek. I personally prefer Rust for most things, but the views here probably represent the views of many folks out there. And I do think it's helpful to empathize with them even if we might not agree. The reality is that Rust and Go are both great languages. In the end, it's all about trade-offs. Which things are non-negotiables and which are you willing to make concessions on? Even if you love Rust, let me know in the comments which of these perspectives hit closest to home for you. In any case, I hope this video has given you more perspective on the whole Rust vs. Go conversation. If you like this video, definitely check out one of these other ones. Thanks for watching, and we'll see you in the next one.