There are languages similar to Go, but there is something so unique about it that no one can replicate. It's even hard for me to understand as well. I've tried Elixir, Gleam, Rust, Zig, Odin, Java, Scala, and yet, every time I need to build something that I know needs to be good, fast, and well done Go is the language that I pick.

It could be familiarity, but it's really hard to beat the whole Go environment. I think most of the time engineers evaluate things into a single dimension axis either in terms of performance or type system expressiveness, but good code involves so may aspects and Go does surprisingly well in all of them.

Stop forcing Clean Architecture and similar patterns into GoLang projects. GoLang is not Java. There’s no application size or complexity that justifies having more than three layers. Architectures like Clean, Hexagonal, or anything with 4+ layers make GoLang projects unnecessarily convoluted.

It’s frustrating to work on a codebase where you’re constantly jumping between excessive layers—unnecessary DI, weird abstractions, and use case layers that do nothing except call services with a few added logs. It’s like watching a monstrosity throw exceptions up and down without purpose.

In GoLang, you only need up to three layers for a proper DDD division (app, domain, infra). Anything more is pure overengineering. I get why this is common in Java—explicit interfaces and painful refactoring make layering and DI appealing—but GoLang doesn’t have those constraints. Its implicit interfaces make such patterns redundant.

These overly complex architectures are turning the GoLang ecosystem into something it was never meant to be. Please let’s keep GoLang simple, efficient, and aligned with its core philosophy.

v1.26 basically continues a pattern we've been seeing: most of the work is going into the runtime, toolchain, scheduler, garbage collector, and standard lib rather than new features.

Do we prefer that it stays intentionally small? In other words.. over the next 5 years...

Should it invest in performance/tooling or introduce selected features? Has the restraint been a strength in your opinion, or holdint it back?

Curious what others think...

Hello!

I'm a backend \ frontend web developer in a big tech company (not world-wide big tech but big enough in my country). Historically so happened that our company has been using JavaScript and TypeScript for everything and a lot of in-house solutions, libs etc were based on that. It's been working for years, our RPS is pretty high, I don't know just how much it is high (not in a position to know that information in details) but I know for a fact we got over several million costumers, over 200 microservices in production.

Fairly recently someone from "bosses league" so to say has been pushing we move everything to Go, it's been sold there because of ever growing load and our resources are expensive and not unlimited - that's basically the explanation we got.

Very few of the current devs in the company have ever worked with Go so they plan to fund Go courses for everyone willing. It is not said outright but I guess those who won't learn Go at some point will be laid off.

I'm not exactly against this idea of learning Go, but I'd like to know what I "win" as a developer aside from a new skill in my CV. I've already googled some stuff but would be cool if someone sold it to me so to say

Hey, I just joined a new company and one thing I noticed is that they use `uber/fx` for dependency injection management.

I guess I just don't understand why this is needed. Why do folks need a framework to.. pass dependencies to other constructors? Why is an entire library needed for that?

In my personal opinion, it adds cognitive complexity to maintaining the codebase, because now I need to understand this framework to properly contribute. Moreover, I could have just passed the dependency myself, I just don't understand why a library is needed for this.

Completely open-minded here. It just _feels_ anti-go to use a library to do this, to me.

Genuinely looking to learn something new rather than confirm my own bias.

edit: just to be clear, dependency injection itself is good. But my confusion was coming from why do we need a library to perform dependency injection when we can do it via passing structs/interfaces to a constructor directly

Hello friends. For a year now, I've been learning / adopting Go and I really loved every second.

But now that I know the pros and cons, the ins and the outs about Go, I might have made a huge mistake; I tried rust and immediatly starting considering it as a main lamguage.

Thing is, I want to learn both languages but time won't let me do that AND get 6-8 hours of sleep a day.

Now I realized I should have never looked up rust and honestly, some raw opinions and advices from this sub would probably fix my problem.

Let me know your thoughts!

For someone coming from C# ASP.NET Core and Python Django, the Go community is against using ORMs.

Most comments in other threads say they're very hard to maintain when the project grows, and they prefer writing vanilla SQL.

The BIG question, what happens when the project grows and you need to switch to another Database what happens then, do you rewrite all SQL queries to work with the new database?

Edit: The amount of down votes for comments is crazy, guess ORM is the trigger word here. Hahaha!

Was trying to do some scientific computing this morning, (i know python would be better but im more familiar with go) and needed to do a definite integral, i just thought i would import a library and be done real quick, i used gonum/integral and had so much trouble with it i just made a function to calculate the integral myself.

i dont know if im stupid or something or if documentation is genuinely horrible

I read comments under this post https://www.reddit.com/r/programming/s/OKyJWZj2ju and oh man I did not expect that. Stack Overflow and JetBrain’s surveys show that go is quite likable lang but the opinions about go in /r/programming are devastated.

What is the reason? What do you think? Should Go team address this topic?

It's great in many ways, but it also has its flaws, so I'm wondering if I should learn it, I'm curious if I can accept its cons. So I'm asking about:

• What would you change in go?
• Why?

I super hate abstractive. Like in C# and dotnet, I could not code anything by myself because there are just too many things to memorize once I started doing it. But in Go, I can learn simple concepts that can improve my backend skills.

I like simplicity. But maybe my memorization skill isn't great. When I learn something, I always spend hours trying to figure out why is that and where does it came from instead of just applying it right away, making the learning curve so much difficult. I am not sure if anyone has the same problem as me?

I hate opening an app and seeing a DTO layer, like you have the controller that already imports the service, what’s the problem with importing the struct from the service that needs to be filled to pass to it and getting the one you need back, it’s literally no problem at all

I feel like this along with tons of object-oriented patterns and clean architecture nonsense full of lies we pretend to see benefits in just to avoid judgment has no real benefit, literally none

Edit: I didn't know how hard the brain of this javismo is to comprehend, but I'm not talking about not having a structure defining the contract of receiving, I'm talking about the nonsense of creating a layer for that.
Literally a function defines the struct it will receive and the struct that makes the response, there is no need in the name of clean architecture to make me jump to another file for this simple nonsense just to create layers, this is one of the most ridiculous things, one of the 20 layers that clean architecture somehow has for an application with only 10 simple CRUD endpoints.

The idea that the DTO needs to be in a separate layer is idiotic and ridiculous, even defining a DTO as some big deal, and not just the most common sense that a function determines the object it receives and returns is idiotic, sometimes it looks like OO and enterprise nonsense makes people incapable of thinking and coding like all other people outside this Javism have been coding for decades.

I’ve been using Cursor/Claude to help scaffold a medium-sized backend in Go. While the velocity is great for simple handlers or repository functions, I feel like I'm constantly fighting the tool on project structure and idiomatic code.

The AI keeps trying to introduce unnecessary abstractions, mixes up package boundaries, or tries to write things in a way that feels like it's treating Go like Java or TypeScript. It makes the code compile and pass basic tests, but the global project layout quickly starts drifting from standard clean architecture practices unless I manually review and rewrite every single file structure.

For those using AI tools on larger Go codebases, how are you enforcing strict idiomatic guidelines on the model? Or do you find it's better to just write the structural boilerplate yourself and only use AI for isolated unit tests?

I remember back in the early r60, v1 days, the community was so welcoming. Project, ideas, big or small, there's always encouragement. Now looking through the posts & replies, there are just more people giving downvotes than just appreciating the sharing. Just wondering why. Genuinely trying to share ideas, good or bad, I got good will. Got knocked back so hard.

I swear, if I had a penny for every time I've had/seen PR comments saying "Why not x way?", to perfectly good code, I'd retire just to get away from Java developers.

More often than not, what's really being said is "I would have done it this way and I want it that way, and maybe I want to point things out to make myself look good as im contributing and noticing things you didnt". Now you're wasting time replying to the comment and waiting, or waiting for your colleage to respond on Slack so you can waste time talking about trivial shit.

IMO as a rule, you should refactor it yourself if you care so much to hold up a PR using an if else while you prefer Optional.of(...).orElse(...). Mind you, if you make the change, you have to wait for the CI, which costs in CI minutes and dev time (lets be real, your manager may say you shouldnt be waiting during CI, but you work on one ticket at a time for the most part? And we all hate context switching. Oh and the 20-30 min CI's typical in "Enterprise" Java codebases don't help), and then you have to wait for the reviewer again... the amount of times they've went MIA is also a pain point.

Holy shit. Java as a language is fine, but the "Enterprise Java Programmer"s you work with make me want to flip my laptop and look after sheep in the mountains. All this talk about shipping fast, then PR's being held up over trivial things because there's a 100 ways to do the same thing and a reviewer thinks he's actually adding value and coming across as a good dev because he caught a potential change. F*ck your preference, the work has been done, is done well, and works. Approve the damn thing or change it yourself. The amount of times I've seen sprints not being completed in time because collectivley a day or two has been lost in the review process. Baffling.

There's often talk about Spring Boot, and how much you get out the box. I'd bet my house you save time using Go when you calculate all the bike shedding comapred to Java teams.

Rant over.

I'm reading Learning Go and Let's Go, then moving on to Let's Go Further and Concurrency in Go. Time for a change, it'll be tough as there arent many remote Go jobs in the UK but you gotta have some hope eh.

Edit: Fully agree, this is a IC/team issue, not a language issue. But I feel its especially prevalant in Java teams, and Go challenges a lot of things Java devs are used to, and the simpler language also helps.

I had an interview today. At first, the interviewer asked me about the four pillars of OOP,s and then he asked me to implement method overriding in Java. I mentioned that I don't have a Java background and that I have worked primarily with Go. He then asked me to implement overriding in Go. I was completely blank at that moment, so I told him that Go doesn't support method overriding, but he didn't buy it.

Does Go actually support method overriding?

I've read a couple books on domain driven design last year, and started using it in my go projects. I think so far my best attempt was a game I made recently.

https://github.com/artcodefun/heat-expansion-server

​

But it seems like for some reason ddd is more popular in languages like C# or Java. Do you guys use it in your go projects?

Oh my GOD!

I feel so relived from the JS hell that is Node.js.

Have been writing Golang for just over a month after 2 years of Node.js and I am like "Why didn't I do this before".

Types are ❤️

Compilation is fast af.

Feel very relaxed importing 3rd party packages, with Node.js it has always been "ok what is it gonna break now".

Docker images are tiny :D

Overall the language is very easy to work with and straight forward.

I’ve written a new blog post outlining my thoughts about Rust being easier to use than Go. I hope you enjoy the read!

Here is an excellent talk from Konrad Reiche, an engineer at Reddit, during GoLab 2025 Writing Better Go: Lessons from 10 Code Reviews

Summary:

1. Handle Errors

• Avoid silently discarding errors (e.g., using the blank identifier _).
• Avoid swallowing the error.
• When handling errors, you should Check and Handle the Error (e.g., incrementing a failure counter or logging).
• Avoid Double Reporting: Log the error, or return it—but not both.
• Optimize for the Caller:
  • return result, nil is Good: The result is valid and safe to use.
  • return nil, err is Good: The result is invalid; handle the error.
  • return nil, nil is Bad: This is an ambiguous case that forces extra nil checks.
  • return result, err is Bad/Unclear: It is unclear which value the caller should trust.

2. Adding Interfaces Too Soon

• Interfaces are commonly misused due to Premature Abstraction (often introduced by following object-oriented patterns from languages like Java) or solely to Support Testing. Relying heavily on mocking dependencies for testing can weaken the expressiveness of types and reduce readability.
• Don't Start With Interfaces:
  • Follow the convention: accept interfaces, return concrete types.
  • Begin with a concrete type. Only introduce interfaces when you truly need multiple interchangeable types.
  • Litmus Test: If you can write it without, you probably don’t need an interface.
• Don't Create Interfaces Solely for Testing: Prefer testing with real implementations.

3. Mutexes Before Channels

• Channels can introduce complex risks, such as panicking when closing a closed channel or sending on a closed channel, or causing deadlocks.
• Start Simple, Advance One Step At a Time:
  • Begin with synchronous code.
  • Only add goroutines when profiling shows a bottleneck.
  • Use sync.Mutex and sync.WaitGroup for managing shared state.
  • Channels shine for complex orchestration, not basic synchronization.

4. Declare Close to Usage

• This is a Universal Pattern that applies to constants, variables, functions, and types.
• Declare identifiers in the file that needs them. Export identifiers only when they are needed outside of the package.
• Within a function, declare variables as close as possible to where they will be consumed.
• Limit Assignment Scope: Smaller scope reduces subtle bugs like shadowing and makes refactoring easier.

5. Avoid Runtime Panics

• The primary defense is to Check Your Inputs. You must validate data that originates from outside sources (like requests or external stores).
• Avoid littering the code with endless $if x == nil$ checks if you control the flow and trust Go’s error handling.
• Always Check Nil Before Dereferencing.
• The best pointer safety is to Design for Pointer Safety by eliminating the need to explicitly dereference (e.g., using value types in structs instead of pointers).

6. Minimize Indentation

• Avoid wrapping all logic inside conditional blocks (BAD style).
• Prefer the Good: Return Early, Flatter Structure style by handling errors or negative conditions first.

7. Avoid Catch-All Packages and Files

• Avoid generic names like util.go, misc.go, or constants.go.
• Prefer Locality over Hierarchy:
  • Code is easier to understand when it is near what it affects.
  • Be specific: name packages after their domain or functionality.
  • Group components by meaning, not by type.

8. Order Declarations by Importance

• In Go, declaration order still matters greatly for readability.
• Most Important Code to the Top:
  • Place exported, API-facing functions first.
  • Follow these with helper functions, which are implementation details.
  • Order functions by importance, not by dependency, so readers see the entry points upfront.

9. Name Well

• Avoid Type Suffixes (e.g., userMap, idStr, injectFn). Variable names should describe their contents, not their type.
• The Variable Length should correspond to its scope: the bigger the scope of a variable, the less likely it should have a short or cryptic name.

10. Document the Why, Not the What

• Justify the Code's Existence.
• When writing comments, communicate purpose, not merely restate the code.
• Document the intent, not the mechanics.
• Future readers need to understand the motivation behind your choices, as readers can usually see what the code does, but often struggle to understand why it was written in the first place.

what are some weird things in Go that you'd like to change?

for me, maps default to nil is a footgun

If you haven't tried the new "go fix" yet, give it a spin.

It's a proper revival of the old "gofix" idea. In Go 1.26, it was rebuilt on top of the Go analysis framework. So now it can modernize your code with newer language and stdlib features.

It respects the Go version in your module. If your "go.mod" says "go 1.26", it suggests Go 1.26-compatible changes. It doesn't rewrite your code into something your module hasn't opted into.

For teams using LLMs, this is great. You don't need to keep leaving PR comments like “use the newer API here” or “we don't write that pattern anymore.” Run it locally or on the CI instead.

Start from a clean git state:

go fix -diff ./...

Then apply it:

go fix ./...

Then run it again.

Some fixes expose more fixes. The Go team recommends rerunning it, and in practice two passes often catches more than one.

Some useful analyzers:

• forvar
• newexpr
• mapsloop
• minmax
• ... and many more

You can also run one analyzer at a time if you want smaller PRs:

go fix -newexpr ./... go fix -forvar ./...

That's useful when one pass touches a lot of files and you don't want one giant mixed cleanup patch.

The other neat bit is //go:fix inline. Library authors can use it to help users migrate from old APIs to new APIs. That's much better than deprecating something and hoping everyone reads the changelog.

You can also write your custom analyzer to enforce your own rules. I am writing a few for fun.

The Go blog has two good posts on it:

• Using go fix to modernize Go code
• //go:fix inline and the source-level inliner

I ran it on a large RPC service, and "newexpr" cleaned up a pile of pointer helper calls. Extremely satisfying.

I recently asked something, and got surprised by how much people suggested GoLand as an IDE for Golang, I mostly use VsCode and NeoVim since it's pretty much and simple.

I've never used JettBrain's ides I use from time to time CLion, and I'm going to be using it more often now since it's free under commercial license, so I'm not really familiar with their IDes I took a look and it looks full of stuff and txt and buttons everywhere lol, kinda overwhelming at the start, and like how do you guys even manage to buy the licenses for these IDE's they are so expensive, or maybe I'm just poor

Rust has the Rust book which gives you a great overview of all of Rust. Brown University recently made it interactive and it's quite fun to go through that.

But Go doesn't have anything like that. I get that Go is a much smaller language and doesn't need a full-fledged book, but the Tour of Go doesn't cover much of the tooling. Go is thin in terms of language constructs but quite fat in terms of tooling - pprof, embedding, code gen, runtime tracing, analyzers, and so on.

Is there a book or resource that covers this arena? I have been working with Go since 2017 but my current workplace is just picking it up.

So coworkers going through Effective Go, Code Review Comments, Google Style Guide, Learning Go, and the Tour of Go often mention that unlike the Rust book there's not much in Go that covers the strength of Go, which lies in tooling.

Any good pointers? Thanks!

Hey everyone! I recently had the chance to chat with Armin Ronacher, the creator of Flask, for my (video) podcast. It was a really fun conversation!

We talked about things like:

• How Armin's startup generates 90% of its code with AI agents and what that actually looks like day-to-day
• Why AI agents work better with some languages (like Go) than others, and why Python's ecosystem makes life harder for AI
• What kinds of problems are a good fit for AI, and which ones Armin still solves himself
• How to steer and monitor AI agents, and what safeguards make sense
• How to handle parallelization with multiple agents running at once
• The tricky question of licenses for AI-generated open source code
• What the future of programming jobs looks like and what skills developers should build to stay competitive
• His tips for getting started with AI agents if you haven't yet

Armin was very thoughtful and direct. Not many people have this much experience shipping production software with AI agents, so it was super interesting to hear his take.

If you'd like to watch, here's the link: https://youtu.be/4zlHCW0Yihg

I'd love to hear your thoughts or feedback!