For some it's stupidity. For others it's brilliance.

It's one of many examples of 80/20 design in Go: 80% of functionality with 20% of complexity and cost.

Struct tags address an important scenario in an easy to use way.

But they don't try to address other scenarios, like annotations do. They are not function tags. They're not variable tags. They are not general purpose annotations. They are annotations for struct fields and struct fields only.

Are they are as powerful as annotations or macros? Of course not, not even close.

Are they as complex to implement, understand, use? Also not.

80/20 design. 80% of functionality at 20% of cost.

▲

Philpax a day ago | parent | next [-]

Go's simplifications often introduce complexities elsewhere, however, as this article demonstrates with the complexities of correctness of a stringly-typed DSL.

There's no free lunch here, and the compromises Go makes to achieve its outcomes have shown themselves to be error-prone in ways that were entirely predictable at design time.

▲

Kamq a day ago | parent | next [-]

> Go's simplifications often introduce complexities elsewhere

It does occasionally, although I'll push back on the "often". Go's simplifications allow most of the codebase to be... well... simple.

This does come at the cost of some complexity on the edge cases. That's a trade off I'm perfectly willing to make. The weird parts being complex is something I'm willing to accept in exchange for the normal parts being simple, as opposed to constantly dealing with a higher amount of complexity to make the edge cases easier.

> There's no free lunch here

This I'll agree with as well. The lunch is not free, but it's very reasonably priced (like one of those hole in the wall restaurants that serves food way too good for what you pay for it).

> the compromises Go makes to achieve its outcomes have shown themselves to be error-prone in ways that were entirely predictable at design time.

I also agree here, although I see this as a benefit. The things that are error prone are clear enough that they can be seen at design time. There's no free lunch here either, something has to be error prone, and I like the trade offs that go has made on which parts are error prone. Adding significant complexity to reduce those error prone places has, in my experience, just increased the surface area of the error prone sections of other languages.

Could you make the case that some other spot in design space is a better trade-off? Absolutely, especially for a particular problem. But this spot seems to work really well for ~95% of things.

▲

valenterry a day ago | parent | prev [-]

> Go's simplifications often introduce complexities elsewhere

Exactly this.

Basically: have a complex compression algorithm? Yes, it's complex, but the resulting filesize (= program complexity) will be low.

If you use a very basic compression algorithm, it's easier the understand the algorithm, but the filesize will be much bigger.

It's a trade-off. However, as professionals, I think we should really strive to put time to properly learn the good complex compression algorithm once and then benefit for all the programs we write.

▲

maleldil a day ago | parent [-]

> I think we should really strive to put time to properly learn

[insert Pike's Google young programmers quote here]

That's just not the philosophy of the language. The convention in Go is to be as obvious as possible, at the cost of more efficient designs. Some people like it, others don't. It bothers me, so I stopped using Go.

	▲	valenterry 10 hours ago \| parent [-]
		Exactly. Look how we are getting downvoted for the truth.

▲

timeon 21 hours ago | parent | prev [-]

Starting to get feeling that 80/20 design is not good thing. Many things seems to be driven by worse is better but, looking at things like Climate Change... was it worth it?