Be careful with Go struct embedding • Hacker News Board

Re: Be careful with Go struct embedding

#31

Post by eru » Mon, Sep 22, 2025, 2:10 AM UTC

echelon wrote: post #8

jrockway wrote: post #3

Earlier quoted context omitted.

Because type Foo struct { sync.Mutex whatever string } var foo Foo foo.Lock() foo.whatever = 42 foo.Unlock() is convenient.

It's dangerous. This is awful. Any coding construct that can cause defects is an antipattern. Your language should discourage defects by design. Especially if the faults crop up at runtime. This struct field dereferencing is like NULLs and "goto". Language design that is anti-defect yet ergonomic include the modern Option and Result as seen in languages such as Swift and Rust, with first class destructuring that does…

I mostly agree.

> Language design that is anti-defect yet ergonomic include the modern Option and Result as seen in languages such as Swift and Rust, with first class destructuring that doesn't make it painful to use.

Funny enough, this is only 'modern' in imperative languages. It's been a staple in the ML family since approximately forever. (But hey, I do appreciate progress when we get it!)

Re: Be careful with Go struct embedding

#32

Post by eru » Mon, Sep 22, 2025, 2:11 AM UTC

linhan_dot_dev wrote: post #9

I like the Go language because it's straightforward and clear, even if it looks a bit plain. I hope the feature mentioned in the article will cause a compiler error. However, I wouldn't use this approach when writing my own code.

> I hope the feature mentioned in the article will cause a compiler error.

Read the article. It won't.

At best you can perhaps find a linter that'll report it?

> However, I wouldn't use this approach when writing my own code.

You might use it by accident.

Re: Be careful with Go struct embedding

#33

Post by _2d30 » Mon, Sep 22, 2025, 2:12 AM UTC

noisy_boy wrote: post #26

Am I the only one who found the described behavior to be intuitively correct? I did expect it to print "abc.com".

I don’t write Go at all but given the first example, also expected this.

I was very surprised that either example compiled, though.

Re: Be careful with Go struct embedding

#34

Post by preommr » Mon, Sep 22, 2025, 2:22 AM UTC

My personal conspiracy is that Golang is an epic prank.

Make a language that's really good in some ways and just horrible in other ways for no reason whatsoever.

So that when it's critics point out contradictory features like embedding, it's defenders can be the ultimate troll and say things like "but, actually, it's a simple language because it doesn't have while loops".

It's the best explanation I have for some of the cognitive dissonance surrounding the language design.

Re: Be careful with Go struct embedding

#35

Post by oefrha » Mon, Sep 22, 2025, 2:31 AM UTC

nemo1618 wrote: post #21

Over the course of ~10 years of writing Go, my ratio of "embedding a struct" to "regretting embedding a struct" is nearly 1:1. I do not embed structs anymore. It is almost always a mistake. I would confidently place it in the "you should be required to import 'unsafe' to use this feature" bin.

Using struct embedding for pure data to implement discriminated unions is fine, better than MarshalJSON() that is lost on a type definition. Using it to save typing, or going crazy with it (I consider embedding two things going crazy) is bad.

Re: Be careful with Go struct embedding

#36

Post by MH15 » Mon, Sep 22, 2025, 2:33 AM UTC

Hello from another Matt Hall! Interesting post, although I don't do much Golang.

Re: Be careful with Go struct embedding

#37

Post by shadowgovt » Mon, Sep 22, 2025, 2:44 AM UTC

preommr wrote: post #34

My personal conspiracy is that Golang is an epic prank. Make a language that's really good in some ways and just horrible in other ways for no reason whatsoever. So that when it's critics point out contradictory features like embedding, it's defenders can be the ultimate troll and say things like "but, actually, it's a simple language because it doesn't have while loops". It's the best explanation I have for some of…

As with most small-team languages, it was built mostly to solve the problems that its initial author had in front of them.

Re: Be careful with Go struct embedding

#38

Post by adastra22 » Mon, Sep 22, 2025, 2:44 AM UTC

noisy_boy wrote: post #26

Am I the only one who found the described behavior to be intuitively correct? I did expect it to print "abc.com".

What is the intuition for that?

Re: Be careful with Go struct embedding

#39

Post by alpb » Mon, Sep 22, 2025, 2:49 AM UTC

It's my common code review comment to the beginners to not embed structs. There's rarely anything to be gained by doing so. The only use case I found to be useful is to embed something like:

    type MockHandlers struct {
        UnimplementedHandlers
    }

    func (m MockServer) LoginHandler{ /* ... */ }

where I get to override only a part of a bigger interface at a time and have the embedding take care of the rest by saying panic("unimplemented") to satisfy the interface.

Re: Be careful with Go struct embedding

#40

Post by Fire-Dragon-DoL » Mon, Sep 22, 2025, 2:51 AM UTC

Maybe I see it differently, but it made sense: embeding works only at 0 depth, it's like a macro to access rapidly the fields of the embedded struct, it doesn't go beyond that,there is no inheritance.

When embedding BarService, the field being embedded is BarConnectionOptions