a common mistake when using Struct Literal And Fields
Fast recall
Quick revision
Core answer
Practical understanding of Struct Literal And Fields.
Repeating a definition without saying when to use it.
Give one trade-off and say how you would test it.
Interview-ready guide
Interview answer
The two absences and the design behind them:
No field defaults: a struct literal with missing fields gives those fields their ZERO values — not values you chose:
type Server struct {
Host string
Port int
TLS bool
}
s := Server{Host: "api.example.com"} // Port: 0, TLS: falsePort is 0 (the int zero) — not 8080 you might have wanted. There is no syntax anywhere for field defaults (no 'Port int = 8080' at the definition, no constructor magic filling it).
No constructors: no special method that runs at creation. What Go has instead is a three-layer convention:
- 1
Zero-value-usable design: for most types, the zero value works immediately (bytes.Buffer{}, sync.Mutex{}, strings.Builder{}). This is the preferred layer — the type is DESIGNED so zero is valid. When this is achievable, there's nothing to construct.
- 2
The New function: an ordinary exported function that returns a READY value:
func NewServer(host string) *Server {
return &Server{Host: host, Port: 8080, TLS: true}
}Convention, not language — NewX() is recognizable, greppable, and takes arguments like any function. It returns either the value (Server) or, for pointer-receiver types, the pointer (*Server).
- 3Validated construction (rare): when invariants must hold at creation, an unexported struct + New + methods — the caller can't build an invalid value.
The zero-value design pressure is the interesting part: it shapes types toward 'empty means empty-and-fine' (a Buffer's zero IS an empty buffer) rather than 'empty means broken' — and when a type genuinely can't have a valid zero (a Server with Port 0 might be invalid), THAT is the signal to reach for layer 2. Interviewers want the sequence: prefer zero-usable, else New, and the language gives you no third option — deliberately, so every type answers the question one of two ways, visibly.
a common mistake when using Struct Literal And Fields
Direct Answer
No defaults — zero values ARE the defaults (every field at its type's zero). No constructors either — Go's answer is the zero value usable, plus ordinary functions (NewX()) when setup is genuinely needed.
Deep Dive & Architecture
Why no constructors, mechanically: object construction in Go is just allocation + zeroing + (optionally) a literal's field writes — three things the language does directly. A constructor mechanism would add a hidden call at every literal/var creation — Go's cost model (every construct visible, no implicit execution) refuses it. The NewX convention keeps the call explicit: the reader SEES that a function runs and what its arguments are.
The zero-value-usability rule's deep rationale — from the language's own documentation: 'the zero value must be usable' is applied across the standard library as a design law, and its effect compounds: zero-value structs containing zero-value fields containing zero-value mutexes compose without any initialization chain. A global var x BigStruct with three embedded sync types is safe at program start — no init function, no order-of-initialization concerns. Constructors would reintroduce the initialization-order problem languages with static constructors fight.
The layer-2 nuance interviewers probe: NewX returning *Server versus Server. The rule follows the receiver convention: pointer-receiver methods on the type → the constructor returns the pointer (every use is *Server — uniform method set, see the interface batch). Value-receiver small types → return the value. The constructor choice is the FIRST place the receiver decision becomes visible to callers.
The anti-pattern to name: NewX that does real WORK (I/O, network) — a constructor that can fail should be (T, error), and one that does heavy work isn't a constructor, it's a function with a misleading name. Open/Load/Connect are honest names for that shape; New is for 'assembled a valid value' — the naming convention carries the failure semantics.
Common Mistakes & Pitfalls
Repeating a definition without saying when to use it.
Check your understanding
Answer these without looking back at the article.
- What is Struct Literal And Fields, and when would you use it?
- When would you use Struct Literal And Fields in a real project?
- How would you compare Struct Literal And Fields with an alternative?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.