[farslan]

Sometimes you don't use the field everywhere. Instead you add a new field to extend a functionality, with a proper new method/function. So if you use tag literals your existing code will still compile safely, and the tests will pass too (assuming you didn't change the functions where the struct were used).

In a very large code base, not using tagged literals will just break anything. Not sure you want it (for the case of extending). Removing will already break it so no problems there.

(Disclaimer: I wrote the blog post)

[modulus1]

This is one of the trouble spots I have with Go.

Say I have 3 members that must be set, and 5 optional members. Go's solution is to make the 3 critical members private so that someone using this struct will probably figure out they should use a construction function. And doing this means replacing all code that creates my struct with calls to a 'New' function. With all this friction, people aren't likely to do the right thing.

At least in C++ with public members I can initialize appropriately in the constructor. Of course littering my code-base with public members would be bad practice in the first place.

[NateDad]

I used to worry about that, too, but in practice it rarely causes problems. The constructor function will be grouped with the type it returns in Godoc, and auto-complete generally will show both type Foo and func NewFoo when you start typing "Foo". And generally you place the constructor function next to the type it creates in the code as well.... it all contributes to it not really being a problem.