Maps vs Structs in Go: Making the Right Choice for Your Data

Margaret Apiyo — Thu, 25 Jun 2026 08:28:29 +0000

__
Choosing between maps and structs is one of the most common dilemmas Go developers face. This guide will help you make the right decision with confidence.

Introduction

Go's simplicity is one of its greatest strengths, but that simplicity sometimes presents developers with interesting choices. One such choice arises when you need to organize and work with structured data: should you use a map or a struct?

While both serve as containers for data, they have fundamentally different characteristics that make each better suited for specific scenarios. Understanding these differences is crucial for writing efficient, maintainable Go code.

In this article, we'll explore the technical differences, performance characteristics, and practical use cases for both data structures, helping you make informed decisions in your projects.

Understanding the Basics

What are Structs?

Structs are typed collections of fields. It groups multiple related variables (fields) of different data types together under a single name to organize data efficiently. They're compile-time constructs that define a fixed schema for your data. Each field has a name, a type, and can have tags for metadata like JSON serialization.

go
type User struct {
    ID        int       `json:"id"`
    Name      string    `json:"name"`
    Email     string    `json:"email"`
    CreatedAt time.Time `json:"created_at"`
}

When you create a struct instance, the memory layout is fixed and known at compile time. This predictability is a key feature that enables excellent performance and type safety.

What are Maps?

Maps are dynamic key-value stores where all keys and values must be of the same type (or satisfy an interface). They're runtime constructs whose structure can change as your program executes.

go
user := map[string]interface{}{
    "id":        123,
    "name":      "Alice",
    "email":     "alice@example.com",
    "createdAt": time.Now(),
}

Performance Comparison

Memory Allocation

Structs allocate memory contiguously in a single block:

go
type Point struct {
    X, Y, Z float64
}

// Single allocation: 24 bytes (3 * 8 bytes)
p := Point{X: 1.0, Y: 2.0, Z: 3.0}

Maps require multiple allocations:

go
// Multiple allocations: map header, buckets, keys, values
data := map[string]float64{
    "x": 1.0,
    "y": 2.0,
    "z": 3.0,
}

Access Speed

go
func BenchmarkStructAccess(b *testing.B) {
    user := User{ID: 1, Name: "John"}
    for i := 0; i < b.N; i++ {
        _ = user.Name
    }
}

func BenchmarkMapAccess(b *testing.B) {
    user := map[string]interface{}{"name": "John"}
    for i := 0; i < b.N; i++ {
        _ = user["name"]
    }
}

Results:

text
BenchmarkStructAccess-8    1000000000    0.28 ns/op    0 B/op    0 allocs/op
BenchmarkMapAccess-8       100000000    11.5 ns/op    0 B/op    0 allocs/op
Struct access is ~40x faster than map access!

Type Safety: The Compile-Time Guardian

Structs Catch Errors Early
With structs, the compiler catches mistakes before they reach production:

go
type Product struct {
    Name  string
    Price float64
}

func UpdatePrice(p *Product, newPrice float64) {
    p.Price = newPrice
}

// Compilation errors:
p := Product{Name: "Laptop", Price: 999.99}
p.Price = "invalid" // cannot use string as float64
p.Stock = 50 // unknown field

Maps Require Runtime Checks
Maps sacrifice type safety for flexibility:

go
data := map[string]interface{}{"price": 99.99}

// Runtime type assertion required
price, ok := data["price"].(float64)
if !ok {
    return errors.New("invalid price type")
}

// This compiles but panics at runtime
price := data["price"].(int) // panic: interface conversion

When to Use Structs

Domain Models Structs excel at representing real-world entities:

go
type Order struct {
    ID          int64     `json:"id"`
    CustomerID  int64     `json:"customer_id"`
    Total       float64   `json:"total"`
    Status      string    `json:"status"`
    CreatedAt   time.Time `json:"created_at"`
}

func (o *Order) Validate() error {
    if o.Total <= 0 {
        return errors.New("order total must be positive")
    }
    return nil
}

API Contracts Structs with JSON tags provide clean serialization:

go
type CreateUserRequest struct {
    Name     string `json:"name" validate:"required"`
    Email    string `json:"email" validate:"required,email"`
    Password string `json:"password" validate:"required,min=8"`
}

Configuration Management Configuration is typically well-defined:

go
type Config struct {
    Host     string        `yaml:"host"`
    Port     int           `yaml:"port"`
    Timeout  time.Duration `yaml:"timeout"`
    Database DatabaseConfig `yaml:"database"`
}

Database Models Structs work perfectly with ORMs:

go
type User struct {
    ID        int64     `db:"id"`
    Username  string    `db:"username"`
    Email     string    `db:"email"`
    CreatedAt time.Time `db:"created_at"`
}

When You Need Methods

go
type Calculator struct {
    Precision int
}

func (c *Calculator) Add(a, b float64) float64 {
    return math.Round((a+b)*float64(c.Precision)) / float64(c.Precision)
}

When to Use Maps

Dynamic Data When the data structure is unknown at compile time:

go
func ProcessWebhook(payload map[string]interface{}) error {
    eventType, ok := payload["type"].(string)
    if !ok {
        return errors.New("missing event type")
    }

    switch eventType {
    case "user.created":
        return processUserCreated(payload)
    case "order.completed":
        return processOrderCompleted(payload)
    default:
        return fmt.Errorf("unknown event type: %s", eventType)
    }
}

Dynamic Keys When keys come from external sources:

go
func BuildQueryParams(params map[string]string) string {
    var queryParts []string
    for key, value := range params {
        queryParts = append(queryParts, fmt.Sprintf("%s=%s", key, value))
    }
    return strings.Join(queryParts, "&")
}

HTTP Headers HTTP headers are inherently dynamic:

go
func SetHeaders(headers map[string]string) {
    for key, value := range headers {
        w.Header().Set(key, value)
    }
}

Caching Maps are excellent for simple caches:

go
type Cache struct {
    store map[string]interface{}
    mu    sync.RWMutex
}

func (c *Cache) Get(key string) (interface{}, bool) {
    c.mu.RLock()
    defer c.mu.RUnlock()
    value, ok := c.store[key]
    return value, ok
}

Counting or Set Operations

go
// Using map as a set
activeUsers := make(map[string]bool)
activeUsers["alice@example.com"] = true

// Counting occurrences
wordCount := make(map[string]int)
for _, word := range words {
    wordCount[word]++
}

The Hybrid Approach

You don't have to choose just one. Combine both where appropriate:

go
type User struct {
    ID         int
    Name       string
    Attributes map[string]interface{} // Dynamic attributes
}

func (u *User) GetAttribute(key string) interface{} {
    return u.Attributes[key]
}

This gives you the best of both worlds: fixed fields for core data and dynamic fields for extensibility.

Decision Framework

Use this flowchart to guide your decision:

text
Is the data structure fixed at compile time?
│
├── Yes ──> Does performance matter?
│ │
│ ├── Yes ──> Use STRUCT
│ │
│ └── No ───> Use STRUCT (still better!)
│
└── No ────> Are keys dynamic or from user input?
│
├── Yes ──> Use MAP
│
└── No ───> Consider STRUCT or MAP based on other needs

Quick Decision Rules

Use Structs When:

You know the data shape at compile time
Performance is critical
Type safety is important
You need methods or interfaces
The data represents a business entity
You want self-documenting code
You're working with JSON/XML serialization

Use Maps When:

The data structure is truly dynamic
Keys come from user input or external sources
You need to iterate over all fields generically
You're working with HTTP headers or query params
You need a set or counting structure
You're caching arbitrary data

Common Pitfalls to Avoid

Using Maps for Everything

go
// Hard to maintain and error-prone
func ProcessUser(data map[string]interface{}) {
    name, _ := data["name"].(string) // Potential panic
    age, _ := data["age"].(int)      // Might be float64 from JSON
}

Using Structs for Highly Dynamic Data

go
// Adding fields requires code changes
type DynamicData struct {
    Field1 string
    Field2 string
    // Field3 needed? Must modify struct
}

Mixing Types Without Clear Semantics

go
// Avoid this pattern
data := map[string]interface{}{
    "id": 123,
    "name": "Alice",
    "tags": []string{"admin", "user"},
    "settings": map[string]interface{}{
        "notifications": true,
    },
}

Best Practices

Default to Structs
In 80% of cases, structs are the better choice. Start with structs and only switch to maps when you have a specific reason.
Use Typed Maps When Possible

go
// Better than map[string]interface{}
type Attributes map[string]string

Validate Map Data Early

go
func validateUser(data map[string]interface{}) error {
    required := []string{"name", "email"}
    for _, field := range required {
        if _, ok := data[field]; !ok {
            return fmt.Errorf("missing required field: %s", field)
        }
    }
    return nil
}

Document Map Expectations

go
// UserData must contain:
// - "name": string (required)
// - "email": string (required)
// - "age": int (optional)
func ProcessUserData(data map[string]interface{}) error {
    // Implementation...
}

Consider Conversions It's easier to convert a struct to a map than the reverse:

go
// Convert struct to map
func ToMap(v interface{}) map[string]interface{} {
    result := make(map[string]interface{})
    data, _ := json.Marshal(v)
    json.Unmarshal(data, &result)
    return result
}

Conclusion

Choosing between maps and structs in Go comes down to understanding your data's nature and your application's requirements.

Structs are the default choice for most applications. They provide:

Compile-time type safety
Superior performance (40x faster access)
Self-documenting code
Better memory efficiency
Method support
Interface implementation

Maps shine in specific scenarios:

Dynamic data structures
Unknown or user-defined schemas
Generic iteration over fields
HTTP headers and query parameters
Caching and counting operations

Remember: You can always refactor from structs to maps if needed, but the reverse is much harder and more error-prone.

What's your experience with maps vs structs in Go? Share your thoughts in the comments below!

Enjoyed this article? Follow me for more Go insights and best practices.

Why Port 8080 and Not 80? A Beginner’s Tale in Go

Margaret Apiyo — Fri, 15 May 2026 07:40:58 +0000

****I

recently started my coding journey with Go. If you’re a beginner looking for a language that is simple yet incredibly powerful, I can’t recommend Go enough.

While building my first Go HTTP web server, I hit a point of curiosity. I learned that a server must "listen" on a specific port number, but I kept seeing 8080 in every tutorial instead of the standard 80.

I did some digging, and here is what I found.

What exactly is a Port?

Think of an IP address as the building address and a Port as the specific door (entry point). The port number decides which software gets the request. When a server "listens" on a port, it means the software is standing behind that door, waiting for someone to knock.

The "Conflict" Rule

On your local machine, only one process can bind to a specific port at a time.
If you have Apache, Nginx, or another system service already listening on Port 80, your Go application will crash on startup. The OS will essentially tell you: "That door is already taken!" By using 8080, you avoid crashing into the main web services already running on your machine.

The "Root" Problem (Privileged Ports)

There is a second reason beginners use 8080 that is even more important: Permissions.
In Unix-like operating systems (Linux and macOS), ports numbered 1 to 1023 are considered "Privileged Ports."
Port 80 requires administrative (root) privileges to run.
Port 8080 is an unprivileged port.

Think of it like this:
Door 80: Imagine this door has a "Security Clearance Required" sign. Only the "System Admin" (Root/Sudo) has the key.
Door 8080: This is an open side entrance. Any developer (standard user) can walk through it and set up shop.

As a developer, you don't want to run your Go binary with sudo every time you test a change. Using 8080 allows you to run your code as a normal user, making your development workflow much smoother and safer.

Why the number 8080?

You might wonder: “Why not 1234 or 9999?”
Technically, you could! However, 8080 became the industry standard because it literally looks like "two 80s." It’s the universal signal to other developers saying: "This is a web server, but it's for development/alternative use."

A Quick Example in Go
In case you’re wondering how this looks in code, here is how we "listen" on 8080 in Go:

package main

import (
    "fmt"
    "net/http"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "Hello! You've reached the Go server on port 8080.")
    })

    fmt.Println("Server starting on :8080...")
    // We use :8080 to avoid permission issues and port conflicts
    http.ListenAndServe(":8080", nil)
}

Summary

Port 80: The default for HTTP. Requires "Root" permissions.

Port 8080: The "Alternative" to 80. Easy to use for development without special permissions.

Understanding these small "why" questions makes the coding journey so much more rewarding. If you're just starting with Go like me, keep questioning the default`

DEV Community: Margaret Apiyo