By GoGopher_99
I used to be a C++ diehard, but after using Go for a year, I’m never going back. The simplicity of the language, the built-in concurrency with goroutines, and the single binary deployment make it a dream for infrastructure tools.
No more header files, no more complex build systems, and no more memory leaks (mostly). Anyone else made the switch recently?
@GoGopher_99 "No more memory leaks"? Sure, if you don't mind a garbage collector stopping the world every few milliseconds. If you want real systems programming with safety and performance, Rust is the only way to go. Go is just Python with types.
@Rustacean_In_The_Dark Rust is too complex. Go is fine for what it is. I still stick to C for my kernels, but for a fast CLI tool or a web service? Go is unbeatable in dev speed. I don't need 100 features, I need to get things done.
@Rustacean_In_The_Dark The GC in Go has improved so much that latency is barely an issue for 99% of use cases. And calling it "Python with types" is just disrespectful lol. Have you even tried channels yet? 🚀
@GoGopher_99 Spot on about the deployment. I don't miss the days of ensuring the right glibc version is on the server just to run a hello world. CGO_ENABLED=0 go build and a scratch image. That's the dream.
@OldSchool_C "C is fine"? Tell that to the CVE list from last week. Memory safety isn't just a "feature," it's a requirement in 2026. Go gives you a decent middle ground, but I'm still tilted by how easy it is to have a nil pointer dereference.
@Memory_Safe_Sam If you're dereferencing nil, you don't know your state. Simple as. We survived for 50 years without a compiler screaming at us about every single byte. The problem isn't the language, it's the quality of the developers. Go is just a padded cell for people who can't manage a heap.
@OldSchool_C Spoken like a true greybeard who hasn't seen the light. It's not about being "able" to manage a heap, it's about the cognitive load. Why spend 4 hours debugging a segfault when the compiler can tell you you're a moron in 4 seconds?
And @GoGopher_99, Go's GC is predictable? Tell that to any low-latency trading firm. If you have a 100GB heap, you're going to feel it eventually.
@Rustacean_In_The_Dark Actually, Discord moved some of their services away from Rust back to Go because the developer velocity was higher and the GC pauses were negligible with their current architecture. It’s about tail latency, not just raw throughput.
@GoGopher_99 I made the same call at my firm. We tried a Rust pilot and it took three months to get a simple CRUD service into production because the junior devs kept fighting the borrow checker. We rewrote it in Go in two weeks. Pragmatism over purity.
Has anyone seen the proposal for Go 1.25's new iterator syntax? It feels like we're slowly adding everything people complained was missing. Is Go becoming the "bloatware" it was supposed to replace?
@Byte_Me I hope not. The day Go adds the ? operator or complex macros is the day I switch to Zig. The whole point is that any dev can read any Go codebase and understand it in an hour. Keep it boring.
@Standard_Library_Stan "Boring" is another word for "boilerplate." Half of any Go project is just if err != nil { return nil, err }. It's like writing in Morse code.
@Rustacean_In_The_Dark At least I can search for error handling points with a simple grep. Show me a Rust macro stack trace and tell me that's "simple."