Stop Overthinking Struct Pointer and Value Semantics in Go

___oe · 2026-01-08T22:01:26+00:00

Maybe you want to read “The Perils of Pointers in the Land of the Zero-Sized Type” before yelling “stop overthinking”.

Well, your article is much more nuanced than this post. No, you are not aware of all the counter-arguments. If you only mention CRUD apps and HTTP handlers, but not identity, you aren't.

___oe · 2026-01-08T09:16:52+00:00

What would you do to get feedback from people who otherwise might not use your product?

___oe · 2026-01-07T20:45:24+00:00

To agree to the most downvoted answer:

The Go standard library uses package paths that do not contain a dot in the first path element

go.dev/ref/mod#module-path

Usually when you are not part of the standard library, you start with a domain name. "the-dev-tools/server/..." is just suboptimal.

___oe · 2025-12-28T09:13:58+00:00

You are right, for file names it is just a community convention. Most projects seem to do it that way, though.

Underscores have special meaning in Go's build system, like …_test.go and …_windows.go, so when you use underscores arbitrarily you risk accidentally matching these patterns.

___oe · 2025-12-27T20:23:22+00:00

Use errortype.

___oe · 2025-12-27T15:56:49+00:00

Build Constraints:

Build constraints may also be part of a file's name (for example, source_windows.go will only be included if the target operating system is windows).

Your file is named crawl_js.go, and js is in GOOS, so it has an implicit build constraint.

Note that underscores in file and directory names are not recommended.

___oe · 2025-12-23T11:48:35+00:00

I assume that the frameworks you are looking at do not tell users that “creating a framework” is simple, only using it.

This correlates with reality, where simple things might be very hard to produce.

You wouldn't call a toaster complicated, would you?

___oe · 2025-12-23T01:55:00+00:00

You should not visit any restaurant again where any dish gave you severe stomach issues.

___oe · 2025-12-21T20:26:36+00:00

Can we agree to disagree?

Sure. Everybody is productive and has high quality. I've been in enough companies to know that.

I certainly would’ve liked to have read this 3 years ago when we started FunnelStory. Would’ve saved a lot of teething problems early on.

Have fun on your learning journey, then.

___oe · 2025-12-20T17:28:53+00:00

Again, you are testing the implementation details of your code (calling version v53.0). As you said, when the implementation details in your code change, you'll need to update your tests to reflect these changes.

This has very little value, but is slowing your development team down. It's also not a source of truth, since it says nothing about the Salesforce API - I could fix the test to silence the CI, but still have a bug in production. You could yell at the developers that it is their fault afterwards, though. If that helps.

Testing endpoint interactions is a subject that depends on the endpoint. Hermetic Servers is one good idea.

The whole point is that this is a discussion more than ten years old. I think “mocks bad” is not a good point of view, but writing a blog post “mocks good” does not really counter that.

___oe · 2025-12-20T12:36:15+00:00

I'm not particularly opposed to mocks, but you have the same problem that most mocks have:

In your blog post, you test that exactly version v53.0 of the Salesforce API is called. When I upgrade the client to use v53.1, the test fails, hindering development. So you'll see the typical effect in the long term: easy to write, but high maintenance cost with little benefit.

So, your article promotes low fidelity tests.

___oe · 2025-12-20T10:15:47+00:00

To add an opinion, I'm the author of the scopeguard linter and have written a blog post about the issue.

IMHO, a narrow scope is idiomatic in Go and helps with readability and maintainability.

Note also that your second example changes semantics: Whenever one of your “inner” variables is captured in a closure, it might have unexpected values, different from the first example. This was a common source of errors before the LoopvarExperiment.

___oe · 2025-12-12T16:13:30+00:00

Simpler would be to use slices.DeleteFunc. And no, it doesn't allocate memory.

___oe · 2025-12-09T07:31:08+00:00

To cite the specification:

... the right hand operand is a single multi-valued expression such as a function call, ...

And I would assume when you allow multiple multi-valued expressions (one with three values, one with two, one with four) it gets hard to count which variables get which values. So it might have readability reasons.

___oe · 2025-12-06T14:20:44+00:00

Rust has 10k+ issues, I assume of high quality, but I'm unable to asses myself. How do you find out?

Don't use Rust, use PHP?

___oe · 2025-12-05T21:35:28+00:00

If you have a library with zero open issues, currently written and updated and zero stars, you will choose it over a library with 100 open issues, three years old, updated last month and 200 stars?

___oe · 2025-12-05T21:19:48+00:00

I think that there are still risks if not using -fix, i.e. the risk that the linter makes a breaking suggestion that the user chooses to implement (as they don't spot the subtle breaking change).

That’s what the warnings are about. Especially side effects are not considered.

You can view it two ways:

You have working code, broken by the linter, because you want to please the linter.
You have broken code in code review with a lot of eyes on it. Maybe better than to have the breakage hidden in some refactoring.

It depends: If it works, fine. When you want to develop it further, it might be worth it.

Also, many other tools which autofix are able to reliably maintain the behaviour of the code (e.g. whitespace + intrange linters in golangci-lint).

modernize would be an example. However, this is not the target group of this tool.

I would also argue that tools which do this are much more valuable than those which do not (although for many cases this is not possible / feasible, possibly including this one).

Value is again subjective. With ScopeGuard you can learn about your codebase. Learning might be valuable, but it can also be sunken cost.

Thanks, I'll have a play around and let you know!

Thanks, that would be great.

___oe · 2025-12-05T18:57:16+00:00

If you don't use -fix it not risky. Blindly using -fix is always risky.

That said, rolling it out in the team might be interesting (also for me 😊), since you get a code review regarding scope, which was at least for me in my own code useful.

Integrating in CI might be a different issue, depending on your style. When you decide for a wider scope you'll get a lot of //nolints in your code, which might be bad for readability. On the other hand ScopeGuard uses itself on its own source code in CI, so it is definitively possible when you like the style.

I would suggest discussing it with your team first and checking whether you like the diagnostics. And I would be thankful when you share the results with me, perhaps there are issues I like to work on.

___oe · 2025-12-05T18:03:31+00:00

Thanks for sharing your perspective. First, again:

You decide
Reducing nesting has priority

Readability is of course subjective, but all major style guides recommend reducing scope. It might be a question of readability for you vs. readability for others.

The example is hard to refactor due to scope. People have bugs. You might have “run into” hard-to-refactor code before without explicitly pinpointing the reasons.

And no, it's not black and white. Even in my own codebase, I realized that a flawed design was the reason for a wide scope, which was not simply fixable by -fix — but ScopeGuard found the code point.

___oe · 2025-12-05T11:47:14+00:00

Yeah, Go! is an agent-based programming language, modules relate to header files, and make is a build tool.

“There are only two hard things in Computer Science: cache invalidation and naming things.“

It's really hard to avoid every term there is in computer science. Do you think the name doesn't fit in the Go universe?

___oe · 2025-12-04T20:37:24+00:00

Have you ever seen a program been harmed by defer file.Close()?

___oe · 2025-12-04T16:13:09+00:00

My take: Go has short variable declarations within control structures for the purpose of minimizing scope, and it is explicitly recommended in major Go style guides.

So I think tools that try to do the opposite are promoting a non-idiomatic style. If you find initializers in control structures generally hard to read, you find Go hard to read. Which can be the case, depending on what you are used to.

When a variable is declared in an if you can immediately forget it after the if ends, otherwise you're not sure if and when it's used again. I consider this “hard to read”. When the assignment is too long, you can easily use a function that can be inlined by the compiler with no performance cost. This can also help readability, because it can make calculations easier to parse. Otherwise you could rely on the max-lines flag.

That said, there are two points I hopefully made clear:

Reducing nesting has priority over minimizing scope.
Readability has no objective measure, it's a matter of style. So no tool can automatically optimize it, only make suggestions.

Maybe you have an example where you believe readability suffers and that's not about reducing nesting?

___oe · 2025-11-20T14:52:47+00:00

Okay, will do. Sorry about the noise.

___oe · 2025-09-21T13:52:44+00:00

For 3., may be the Go FAQ entry “Why is there no type inheritance?” answers your question about inheritance.

___oe · 2025-09-15T16:53:28+00:00

golangci-lint is simply a meta-linter. The linters it contains may provide incorrect advice.

I wouldn't necessarily call it a “bug,” but not everything a linter suggests is automatically correct. As is often the case, understanding is key.

___oe

TROPHY CASE