DEV Community

Cover image for Capital Letters Made My Workmate Quit Go—But Should You?
jjpinto
jjpinto

Posted on

Capital Letters Made My Workmate Quit Go—But Should You?

One of Go’s simplest rules—capitalization for visibility—turned my colleague off the language entirely. But is it really that bad? In this article, I explore why this rule exists, why it feels weird, and why it might actually be one of Go’s smartest design choices.

The Moment My Workmate Walked Away

A few weeks ago, I told a workmate I was learning Go. His response?
"Congrats—but I could never deal with a language where capital letters decide everything."

At first, I laughed. Then I realized he wasn’t joking. For him, the idea that a function’s visibility depends on whether it starts with a capital letter was enough to walk away from the language entirely.

It got me thinking: Is this rule really that strange—or are we just not used to simplicity when we see it?

Why Go Uses Capitalization for Visibility

In Go, capitalization isn’t just a style choice—it’s a visibility rule.

  • If a function, variable, or type starts with a capital letter, it’s exported (public).
  • If it starts with a lowercase letter, it’s unexported (private to the package).

There’s no public, private, or protected keyword. This minimalist approach aligns with Go’s philosophy: fewer keywords, more clarity. But for developers coming from Java, C#, or Python, this can feel unintuitive—even frustrating—at first glance.

Simplicity Can Feel Complicated

“Simplicity is complicated.” — Rob Pike, Go Proverbs Talk

For many developers—especially those from object-oriented backgrounds—this rule feels like a step backward. We’re used to explicit visibility modifiers: public, private, protected.

But Go takes a radically transparent approach. The rule is simple, consistent, and enforced by the compiler. Once you get used to it, it becomes second nature—and you start to appreciate how much boilerplate it eliminates.

Example: Capitalization and Visibility in Go

package mypackage

// Exported (public)
func SayHello() string {
    return "Hello from SayHello!"
}

// Unexported (private)
func sayGoodbye() string {
    return "Goodbye from sayGoodbye!"
}
Enter fullscreen mode Exit fullscreen mode

In this example:

  • SayHello is exported (public) because it starts with a capital letter. It can be accessed from other packages.

  • sayGoodbye is unexported (private) because it starts with a lowercase letter. It can only be used within the same package.

Should One Rule Make You Quit Go?

I don’t think so. Every language has its quirks—Java has checked exceptions, Python has strict indentation, and C# has LINQ syntax. Go’s capitalization rule might seem odd at first, but it’s a small price to pay for a language that offers fast compilation, powerful concurrency, and a clean, consistent developer experience.

If you’re curious about Go, don’t let a capital letter stop you. Dive in—you might just find it’s exactly what you’ve been looking for.

 
Have you ever struggled with Go's capitalization rule? Does it make the language harder or simpler for you? Let me know in the comments!

 
 
 

This post was reviewed with AI assistance to refine clarity and structure

Top comments (2)

Collapse
 
vladimir_cezar_ed99049607 profile image
Vladimir Cezar

Haha, great story. Go’s strictness can be frustrating, but it really does force clarity. Loved the perspective!

Collapse
 
jjpinto profile image
jjpinto

Go’s quirks can be frustrating, but they do push us toward cleaner code. Glad the post resonated!