DEV Community: perez odiyo

Arrays vs Slices in Go: The Concept Every Beginner Struggles With (Until It Finally Clicks)

perez odiyo — Wed, 22 Jul 2026 07:20:41 +0000

There are a handful of concepts every Go beginner wrestles with.

Pointers.
Interfaces.
Goroutines.

And somewhere near the top of that list sits a deceptively simple pair:

Arrays and slices.

When I first started learning Go, I honestly thought they were the same thing.

Both stored multiple values.

Both used square brackets.

Both let me access elements by index.

So naturally, I asked myself:

Why does Go have two data structures that seem to do exactly the same thing?

Like many beginners, I searched for the answer.

Every explanation sounded something like this:

Arrays have a fixed size.
Slices are dynamic.

Technically...

That's correct.

But it wasn't helpful.

Knowing what they are isn't the same as understanding why they exist.

The real breakthrough came when I stopped thinking about arrays and slices as two competing data structures and started seeing their relationship.

Imagine a bookshelf.

The bookshelf holds the books.

It owns them.

Now imagine placing a transparent picture frame in front of just a few books.

The frame doesn't move the books.

It doesn't copy them.

It simply gives you a different view of what's already there.

That's exactly what a slice is.

Once that idea clicked, suddenly everything else made sense.

Why changing a slice sometimes changes an array.

Why append() sometimes behaves strangely.

Why Go developers almost always use slices instead of arrays.

And why arrays still exist in the language at all.

By the end of this article, you'll stop memorizing definitions and start thinking the way Go does.

Let's build that intuition together.

Arrays: The Bookshelf

Let's start with the bookshelf itself.

Imagine you've just built a wooden bookshelf with five shelves.

Not four.

Not six.

Exactly five.

Once it's built, changing the number of shelves isn't as simple as snapping another one on.

You'd have to build a completely new bookshelf.

That's exactly how an array works.

An array is a collection of values with a size that's decided the moment it's is created.

Here's an example.

package main

import "fmt"

func main() {
    languages := [5]string{
        "Go",
        "Rust",
        "JavaScript",
        "TypeScript",
        "Python",
    }

    fmt.Println(languages)
}

Output:

[Go Rust JavaScript TypeScript Python]

Nothing surprising yet.

But look closely at the declaration.

[5]string

Most beginners read that as:

"An array containing five strings."

Go reads it differently.

Go sees [5]string as the type itself.

That means these are completely different types.

[5]string

[6]string

Even though they both store strings.

The number isn't just information.

It's part of the type.

That tiny detail explains why arrays behave the way they do.

Go already knows exactly how much memory to reserve before your program even runs.

It's like buying a bookshelf with exactly five compartments.

The carpenter isn't expecting you to ask for a sixth shelf later.

The design is already finished.

Arrays Own Their Data

Here's another idea that confused me when I started learning Go.

Suppose you buy another identical bookshelf.

Then you copy every single book from the first shelf onto the second one.

Now you have two completely separate bookshelves.

Changing one won't affect the other.

Arrays work exactly like that.

Original

+------+------+------+------+------+
| Go | Rust | JS | TS | Py |
+------+------+------+------+------+

Copy

+------+------+------+------+------+
| Go | Rust | JS | TS | Py |
+------+------+------+------+------+

Let's see it in Go.

scores := [3]int{85, 92, 78}

copyScores := scores

copyScores[0] = 100

fmt.Println(scores)
fmt.Println(copyScores)

Output

[85 92 78]

[100 92 78]

Changing copyScores didn't affect scores.

Why?

Because Go copied the entire array.

Arrays own their data.

Whenever you assign an array to another variable or pass it into a function, Go creates a brand-new copy.

This is called value semantics, but don't worry about memorizing that phrase.

Just remember this:

Arrays own their bookshelf.

Every copy gets its own bookshelf.

No sharing.

No surprises.

And that's exactly where slices enter the story...

Golang Beginner Mistakes #4: Learning Interfaces Changed How I Write Go

perez odiyo — Mon, 20 Jul 2026 07:32:43 +0000

For the longest time, I avoided interfaces.

Not because I thought they were useless.

But because every explanation I came across felt like a computer science lecture.

People kept saying things like:

"Program to interfaces."

"Accept interfaces, return structs."

I understood the words.

I just didn't understand why.

Why would I need an interface when my structs and functions were working just fine?

Then I ran into a problem that structs alone couldn't solve.

That's when interfaces stopped feeling like theory and started feeling like one of the most practical features in Go.

The Story: Dog, Cat, and a Better Way

I started with a dog.

type Dog struct {
    Name string
}

func (d Dog) MakeSound() string {
    return d.Name + " says Woof!"
}

Then came the cat.

type Cat struct {
    Name string
}

func (c Cat) MakeSound() string {
    return c.Name + " says Meow!"
}

Everything looked fine.

Until I wanted one function that could make any animal speak.

My first thought wasn't "interface."

It was...

"There has to be a better way than writing one function for every animal."

I almost started writing

PrintDogSound()
PrintCatSound()
PrintCowSound()
PrintBirdSound()

That didn't feel right.

There had to be a cleaner solution.

There was.

The Beginner Mistake

Many Go beginners postpone learning interfaces.

I certainly did.

The word sounds like something from a computer science lecture.

In reality, it's one of the simplest ideas in Go.

The trick is realizing that interfaces aren't about data.

They're about behavior.

What Is an Interface?

A struct answers one question.

What is this thing?

type Dog struct {
    Name string
}

A dog has a name.

That's data.

An interface answers a different question.

What can this thing do?

type Speaker interface {
    MakeSound() string
}

Notice something.

The interface doesn't mention dogs.

Or cats.

Or humans.

It only says:

"If you can make a sound, you're welcome here."

That's the magic.

No `implements` Keyword?

If you're coming from Java or C#, this part feels strange.

Normally you'd write something like

class Dog implements Speaker

Go doesn't do that.

Instead, it quietly checks:

"Does this type have the required method?"

If yes...

Congratulations.

It already satisfies the interface.

No keyword.

No inheritance.

No registration.

Just behavior.

The "Aha!" Moment

Let's add more types.

type Speaker interface {
    MakeSound() string
}

type Dog struct {
    Name string
}

func (d Dog) MakeSound() string {
    return d.Name + " says Woof!"
}

type Cat struct {
    Name string
}

func (c Cat) MakeSound() string {
    return c.Name + " says Meow!"
}

type Human struct {
    Name string
}

func (h Human) MakeSound() string {
    return h.Name + " says Hello!"
}

Now watch this.

func Announce(s Speaker) {
    fmt.Println(s.MakeSound())
}

func main() {
    Announce(Dog{Name: "Rex"})
    Announce(Cat{Name: "Milo"})
    Announce(Human{Name: "Perez"})
}

The beautiful part is that Announce never asks:

Are you a Dog?
Are you a Cat?
Are you a Human?

It only asks:

Can you make a sound?

If the answer is yes...

The function is happy.

That's the moment interfaces finally clicked for me.

⚠️ Beginner Mistake #1: Creating Interfaces Too Early

Once interfaces make sense, beginners often swing too far in the other direction.

Suddenly everything gets an interface.

Even when there's only one implementation.

type UserRepository interface {
    GetUser(id string) User
}

If you only have one repository...

You probably don't need the interface yet.

A popular Go saying is:

Accept interfaces. Return structs.

Another one you'll hear often is:

Define interfaces where they're used, not where they're implemented.

Start simple.

Add interfaces when they solve a real problem.

Not before.

⚠️ Beginner Mistake #2: Using `any` for Everything

Some beginners discover

any

and think they've found the ultimate shortcut.

func Print(v any) {
    fmt.Println(v)
}

Sure...

It accepts everything.

But it also throws away type safety.

Instead of saying

"I accept anything."

Ask yourself:

"What behavior do I actually need?"

That's usually an interface.

Real Examples You'll See Every Day

Once interfaces click, you'll notice they're everywhere.

io.Reader
io.Writer
http.Handler
Database repositories
Payment gateways
Logging libraries

They all follow the same idea.

Describe behavior.

Not implementation.

Struct vs Interface

Whenever I'm unsure, I ask myself one question:

Am I describing data... or behavior?

If it's data...

Use a struct.

If it's behavior...

Use an interface.

Simple.

Situation	Interface?
Multiple types share behavior	✅
Only one implementation	❌
Modeling data	❌
Want loose coupling	✅
Future implementations expected	✅

The Mental Model That Finally Stuck

Forget complicated definitions.

Just remember this.

Struct = What is it?

Interface = What can it do?

Structs describe things.

Interfaces describe capabilities.

That distinction is what makes Go code so flexible without becoming complicated.

Final Thoughts

One thing I love about Go is that it encourages simple designs.

You don't start with giant inheritance trees.

You don't spend hours designing interfaces "just in case."

You build concrete types.

Then, when multiple types share behavior...

You introduce an interface.

Go doesn't care what something is.

It cares what something can do.

That tiny mindset shift completely changed how I write Go.

Over to You

What Go concept took you the longest to understand?

Interfaces?
Pointers?
Slices?
Goroutines?

I'd love to hear your story in the comments.

If you enjoyed this article, consider following the Golang Beginner Mistakes series, where we break down the kinds of mistakes almost every new Go developer makes—and how to avoid them.

Golang Beginner Mistakes: If You Know Every Field, You Probably Don't Need a Map

perez odiyo — Mon, 20 Jul 2026 07:03:12 +0000

When I first started learning Go, I discovered structs before I discovered maps.

So naturally...

Everything became a struct.

Need a user?

type User struct {
    Name  string
    Email string
}

Easy.

Need application settings?

type Settings struct {
    Theme         string
    Notifications bool
}

Still easy.

Need categories users can create themselves?

...

I still made a struct.

type Categories struct {
    Fitness string
    Reading string
    Coding  string
}

It looked fine until someone wanted to add "Meditation."

Then another user wanted "Gaming."

Then another wanted "Cooking."

That's when it hit me.

Structs aren't meant to grow while your program is running.

I was using the wrong tool.

What a struct actually is

A beginner usually hears:

"A struct groups related data."

That's true.

But it misses the important part.

A better definition is:

A struct describes something whose shape is already known.

For example, every user in your application has the same fields.

type User struct {
    Name  string
    Email string
    Age   int
}

You already know those fields before writing the program.

That's why a struct exists.

Think of it as a blueprint.

Every house built from the same blueprint has the same rooms.

What a map actually is

A map is completely different.

A map doesn't care what keys you'll use tomorrow.

prices := map[string]float64{
    "apple": 0.50,
}

Later...

prices["banana"] = 0.30
prices["mango"] = 1.20
prices["orange"] = 0.75

No problem.

Maps are designed for data whose keys are discovered at runtime.

The question that changed how I write Go

Nowadays, before writing any type, I ask myself one question.

Do I already know every field this data will have?

If the answer is yes, I create a struct.

If the answer is:

"Well...the user decides."

"It depends on the API."

"It depends on the environment."

I immediately reach for a map.

That one question has saved me countless rewrites.

⚠️ Beginner Mistake #1: Treating dynamic data like fixed data

Imagine you're storing HTTP headers.

A beginner might write this.

type Headers struct {
    ContentType  string
    Authorization string
    UserAgent    string
}

Looks reasonable...

Until a request contains:

X-Request-ID
X-Forwarded-For
Or some completely custom header.

Now your program needs another field.

And another.

Instead, use a map.

headers := map[string]string{
    "Content-Type": "application/json",
}

Now any header can exist without changing your code.

That's exactly what maps were made for.

⚠️ Beginner Mistake #2: Using maps because they feel flexible

Then comes the opposite mistake.

You discover maps.

They're cool.

They're flexible.

So suddenly everything becomes

map[string]interface{}

Even users.

user := map[string]interface{}{
    "name": "Perez",
    "age":  22,
}

This works.

But you've thrown away one of Go's biggest strengths.

Type safety.

This typo compiles.

fmt.Println(user["nmae"])

Notice the spelling?

The compiler doesn't.

It happily runs your program.

Now compare that with

type User struct {
    Name string
}

fmt.Println(user.Nmae)

Go immediately says:

"Nope."

Compilation fails.

That's exactly what you want.

Let the compiler catch mistakes before your users do.

Structs and Maps Are Teammates, Not Enemies

One thing took me embarrassingly long to realize.

Structs and maps aren't competing.

They're usually used together.

A very common pattern is

type Product struct {
    Name  string
    Price float64
}

inventory := map[string]Product{}

Notice what's happening.

The Product has a known shape.

The inventory doesn't know how many products exist.

One models an object.

The other stores a growing collection of those objects.

You'll see this pattern everywhere.

User sessions
Product inventories
Cache systems
Feature flags
Configuration
Backend services

Once you notice it, you can't unsee it.

Struct vs Map: A Quick Decision Guide

Situation	Struct	Map
Known fields	✅
Unknown keys		✅
Type safety	✅
Dynamic user input		✅
Real-world objects	✅
Fast lookups by key		✅

My Rule of Thumb

Whenever I'm unsure, I ask myself:

Can I confidently write every field name before running the program?

If yes...

➡️ Use a struct.

If no...

➡️ Use a map.

Simple.

Final Thoughts

One of my favorite things about Go is that it gives you only a handful of data structures.

That means learning when to use them matters more than memorizing how to use them.

I spent weeks treating every problem like a struct.

Then I spent weeks treating every problem like a map.

The sweet spot was realizing they solve completely different problems.

A struct answers:

"What is this thing?"

A map answers:

"How do I find this thing?"

Once that clicked, my Go code became much simpler.

Over to You

What beginner Go mistake took you the longest to understand?

I'd love to hear it in the comments. Chances are, someone else is struggling with the exact same thing.

If you enjoyed this article, consider following the Golang Beginner Mistakes series, where we break down the kinds of mistakes almost every new Go developer makes—and how to avoid them.

Go Beginner Mistake #2: Why `time.Now().Format("YYYY-MM-DD")` Doesn't Work in Go

perez odiyo — Sat, 06 Jun 2026 16:24:40 +0000

Dearest learner

I hope this post finds you well.

If you're here because time.Now().Format("YYYY-MM-DD") isn't doing what you expected, pull up a chair. I spent an embarrassing amount of time staring at that exact problem, and today I'd like to save you the trouble.

First, Some Embarrassing Context

If you read my last post, you already know I was building a Net-Cat project in Go and got burned by log.Println() silently adding its own timestamp to my output. Fun times.

Well — I hadn't even gotten to that bug yet. Before I ran into the log problem, I was still fighting a more basic battle: just getting a timestamp to print correctly in the first place.

This is that story.

What I Expected

I come from a JavaScript background. In JS, formatting a date looks something like this:

// JavaScript
const now = new Date();
console.log(now.toISOString()); // 2025-01-15T14:32:05.000Z

And in Python, it's something like:

# Python
from datetime import datetime
print(datetime.now().strftime("%Y-%m-%d"))  # 2025-01-15

Notice the pattern? Both use placeholder tokens. YYYY means "put the 4-digit year here." MM means "put the month here." %d means "put the day here." They're basically fill-in-the-blank templates where each token represents a concept.

So when I opened a Go file and typed this, it felt completely natural:

// What I tried first (very wrong)
fmt.Println(time.Now().Format("YYYY-MM-DD"))

I hit run.

The output was: YYYY-MM-DD

Just... the string. Printed back at me, unchanged. No date. No numbers. Nothing.

I sat there for a second. Then I tried "yyyy-mm-dd". Same thing. Then "%Y-%m-%d" like Python. Same thing. Go was just printing whatever I typed, completely unbothered.

The Thing Nobody Warned Me About

Here's what Go actually does, and I wish someone had just said this to me directly on day one:

Go doesn't use placeholder tokens. It uses a real, specific reference date.

That reference date is:

Mon Jan 2 15:04:05 MST 2006

Or written out in numbers:

01/02 03:04:05PM '06 -0700

You use that exact date — in whatever arrangement you want — as your format string. Go looks at your string, recognises the pieces of that reference date inside it, and replaces them with today's values.

So instead of "YYYY-MM-DD", you write:

fmt.Println(time.Now().Format("2006-01-02"))
// Output: 2025-01-15

That 2006 is the year. That 01 is the month. That 02 is the day. Not because those are magic tokens — but because January 2nd, 2006 is the reference date Go was built around.

The first time I read that, I genuinely thought the documentation was trolling me.

And Then I Used the Wrong Date

Even after I understood the concept — "use a real reference date" — I still got burned. Because I thought: okay, any date will do. I need year-month-day, so I'll just write a date in that order.

I typed "2020-02-12" and felt confident.

fmt.Println(time.Now().Format("2020-02-12"))
// I expected: 2025-01-15
// I got:      10100-10-1110

The output looked like a date the way binary looks like a number — technically valid, completely unreadable.

Chaos. The numbers were all shuffled wrong.

Here's why: Go didn't see a random date. It looked at 2020 and tried to find pieces of the reference date (Mon Jan 2 15:04:05 MST 2006) inside it. It found 20 — that's the timezone offset token. It found 02 — that's the day. 12 — that's the 12-hour clock hour. None of it meant what I wanted.

The format string isn't a template where any date works. It has to be that specific date — January 2nd, 2006. That's the one Go knows. Any other date is just a string full of ambiguous numbers it'll try to interpret as tokens, with confusing results.

// This is the only date Go understands as a format
fmt.Println(time.Now().Format("2006-01-02"))  // ✓

Tattoo it somewhere. 2006-01-02. Year, month, day — from the one reference date. Not your birthday. Not today's date. Not a date that "looks right." The reference date.

The "Wait, Why?!" Moment

Okay but why that specific date? Why not just use YYYY like a normal language?

This is the part that actually made me laugh once I understood it.

That reference date — 01/02 03:04:05PM '06 -0700 — is special because each component is a unique number:

Month: 01
Day: 02
Hour: 03
Minute: 04
Second: 05
Year: 06
Timezone offset: 07

They count up: 1, 2, 3, 4, 5, 6, 7. Go uses this sequence so it can unambiguously look at any format string and know exactly what each piece represents — no token dictionary needed. If it sees 06 in your format string, it knows you want the two-digit year. If it sees 2006, it knows you want the four-digit year. If it sees 15, it knows you want 24-hour time (because the reference hour in 24h format is 15:04).

It's genuinely clever once it clicks. But until it clicks, it feels completely unhinged.

The Aha Moment, In Practice

Once I got it, formatting timestamps became almost fun. Here's what correct usage looks like:

package main

import (
    "fmt"
    "time"
)

func main() {
    now := time.Now()

    // Date only
    fmt.Println(now.Format("2006-01-02"))
    // → 2025-01-15

    // Date and time
    fmt.Println(now.Format("2006-01-02 15:04:05"))
    // → 2025-01-15 14:32:05

    // More readable
    fmt.Println(now.Format("Mon, 02 Jan 2006"))
    // → Wed, 15 Jan 2025

    // For my Net-Cat project
    fmt.Println(now.Format("[2006-01-02 15:04:05]"))
    // → [2025-01-15 14:32:05]
}

The reference date is always the same: Mon Jan 2 15:04:05 MST 2006. You just rearrange and decorate it however you want your output to look.

I'd actually recommend keeping that reference date somewhere visible while you're learning Go — a sticky note, a comment at the top of your file, whatever works. You'll need to glance at it more than once.

The Takeaway

Go's time formatting is one of those things that feels bizarre at first and obvious in hindsight. Most languages teach you a set of format codes to memorise (%Y, %m, YYYY, etc.) and trust that you'll look them up when you forget them. Go took a different approach: instead of a codebook, it gave you a single example to reference.

Once you know the reference date, you don't need to memorise anything. You just ask yourself: "How would I write January 2nd, 2006 in the format I want?" — and that's your format string.

For beginners, here's the mental shift:

Don't think "what token represents the year?" — think "what does the year 2006 look like in this format?"

It's a small shift, but it changes everything.

I really wish someone had framed it that way for me on day one instead of letting me spend twenty minutes typing "YYYY" into a terminal like a confused golden retriever.

Learn from my suffering. Use the reference date. Format your timestamps.

And if your output still looks weird — check whether you're using log.Println(). Trust me on that one.

Next up: the actual Net-Cat project, and all the new ways it found to humble me. 🐹

Go Beginner Mistake #1: When `log.Println()` Made Me Question `time.Now().Format()`

perez odiyo — Fri, 05 Jun 2026 16:52:20 +0000

A small bug that taught me to read my tools before blaming my code.

The Plan

I was building a Net-Cat project in Go — a simplified version of the classic nc (netcat) Unix tool. One of the features I wanted was a clean timestamp displayed whenever a client connected or sent a message. Something like this:

[2025-01-15 14:32:05] Alice has joined the chat

Simple enough, right? I reached for time.Now().Format() and felt good about it.

timestamp := time.Now().Format("2006-01-02 15:04:05")
log.Println("[" + timestamp + "] Alice has joined the chat")

I ran it, looked at the output, and... something was off.

The Confusing Output

Instead of the clean line I expected, my terminal was showing this:

2025/01/15 14:32:05 [2025-01-15 14:32:05] Alice has joined the chat

Two timestamps. Right next to each other.

My first thought? My format string must be broken. I started Googling time.Now().Format syntax. I tried different layouts. I rewrote the format string three times. Nothing changed. The double timestamp was still there, mocking me.

I even briefly wondered if Go had some weird timezone bug. (It did not.)

The Culprit: `log.Println()` vs `fmt.Println()`

Here's what I didn't know at the time:

log.Println() and fmt.Println() are NOT the same thing.

fmt.Println() is simple. It prints exactly what you give it, adds a newline, and calls it a day.

fmt.Println("Hello, world!")
// Output: Hello, world!

log.Println() is different. It's part of Go's log package, which is designed for application logging — the kind where you always want to know when something happened. So by default, log automatically prepends every message with the current date and time.

log.Println("Hello, world!")
// Output: 2025/01/15 14:32:05 Hello, world!

See that prefix? You didn't ask for it. It's just... there. Always. That's the log package doing its job.

So when I wrote:

timestamp := time.Now().Format("2006-01-02 15:04:05")
log.Println("[" + timestamp + "] Alice has joined the chat")

The log package saw my message, slapped its own timestamp at the front, and printed both. My code was working perfectly — I just didn't understand the tool I was using.

Why Does `log` Do This?

The log package in Go is built for one specific purpose: structured application logging. When you're debugging a server that's been running for days, or tracing a crash in production, the absolute first thing you need to know is when something happened.

So the designers of the log package made that the default. Every log entry gets a timestamp. You don't have to ask for it.

You can actually control this behaviour with log.SetFlags():

// Remove the automatic timestamp entirely
log.SetFlags(0)
log.Println("No timestamp here!")
// Output: No timestamp here!

// Or keep just the time, not the date
log.SetFlags(log.Ltime)
log.Println("Just the time")
// Output: 14:32:05 Just the time

The default flag value is log.LstdFlags, which equals log.Ldate | log.Ltime — both date and time. That's the source of my double timestamp.

How I Finally Figured It Out

After enough head-scratching, I stopped trying to fix my time.Now().Format() code and started asking a different question: "Where is this first timestamp actually coming from?"

I removed my custom timestamp entirely and just logged a plain string:

log.Println("Alice has joined the chat")
// Output: 2025/01/15 14:32:05 Alice has joined the chat

There it was. The timestamp wasn't coming from my code at all. I opened the Go docs for the log package for the first time, and the very first line told me everything:

"Package log implements a simple logging package. Each logging operation makes a single call to the Writer's Write method. A Logger can be used simultaneously from multiple goroutines; it guarantees serialized access to the Writer. The default logger writes to standard error and prints the date and time of each logged message."

Date and time of each logged message. Right there in the first paragraph. I just hadn't read it.

The Fix

For my Net-Cat project, I had two clean options:

Option 1: Switch to fmt.Println() and keep full control of formatting.

timestamp := time.Now().Format("2006-01-02 15:04:05")
fmt.Println("[" + timestamp + "] Alice has joined the chat")
// Output: [2025-01-15 14:32:05] Alice has joined the chat

Option 2: Keep log.Println() but disable its automatic prefix.

log.SetFlags(0) // Call this once at the start of your program
timestamp := time.Now().Format("2006-01-02 15:04:05")
log.Println("[" + timestamp + "] Alice has joined the chat")
// Output: [2025-01-15 14:32:05] Alice has joined the chat

I went with Option 1. fmt was the right tool for user-facing chat messages; log is better suited for actual application diagnostics.

The Real Lesson

The bug was never in my time.Now().Format() code. It was in my assumption that log.Println() behaved like fmt.Println(). They share a similar name and do similar things on the surface, but they're built for completely different jobs.

The takeaway for new Go developers:

When something isn't working, before you rewrite your logic — make sure you understand every tool you're using. A quick trip to the official Go docs (pkg.go.dev) can save you an hour of chasing the wrong bug.

Use fmt when you're talking to the user.
Use log when you're talking to yourself (or your future debugging self).

And when output looks weird? Don't assume your code is wrong. Ask where every part of that output is coming from.

Happy coding — and may your timestamps never double up again. 🕐

DEV Community: perez odiyo

Arrays vs Slices in Go: The Concept Every Beginner Struggles With (Until It Finally Clicks)

Arrays: The Bookshelf

Arrays Own Their Data

Golang Beginner Mistakes #4: Learning Interfaces Changed How I Write Go

The Story: Dog, Cat, and a Better Way

The Beginner Mistake

What Is an Interface?

No implements Keyword?

The "Aha!" Moment

⚠️ Beginner Mistake #1: Creating Interfaces Too Early

⚠️ Beginner Mistake #2: Using any for Everything

Real Examples You'll See Every Day

Struct vs Interface

The Mental Model That Finally Stuck

Final Thoughts

Over to You

Golang Beginner Mistakes: If You Know Every Field, You Probably Don't Need a Map

What a struct actually is

What a map actually is

The question that changed how I write Go

⚠️ Beginner Mistake #1: Treating dynamic data like fixed data

⚠️ Beginner Mistake #2: Using maps because they feel flexible

Structs and Maps Are Teammates, Not Enemies

Struct vs Map: A Quick Decision Guide

My Rule of Thumb

Final Thoughts

Over to You

Go Beginner Mistake #2: Why `time.Now().Format("YYYY-MM-DD")` Doesn't Work in Go

First, Some Embarrassing Context

What I Expected

The Thing Nobody Warned Me About

And Then I Used the Wrong Date

The "Wait, Why?!" Moment

The Aha Moment, In Practice

The Takeaway

Go Beginner Mistake #1: When `log.Println()` Made Me Question `time.Now().Format()`

The Plan

The Confusing Output

The Culprit: log.Println() vs fmt.Println()

Why Does log Do This?

How I Finally Figured It Out

The Fix

The Real Lesson

No `implements` Keyword?

⚠️ Beginner Mistake #2: Using `any` for Everything

The Culprit: `log.Println()` vs `fmt.Println()`

Why Does `log` Do This?