Go Programming Fundamentals · Go Basics

Functions, Structs, and Packages

Q: Why do Go functions commonly return `(result, error)` instead of throwing an exception?

## Summary Go treats errors as ordinary return values so callers are forced to explicitly check them at the call site, rather than errors silently propagating up an exception stack. ## Longer Answer Go treats errors as ordinary return values so callers are forced to explicitly check them at the call site, rather than errors silently propagating up an exception stack. This is one of Go's most debated but deliberate design choices — explicit over implicit, even at the cost of some verbosity. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview. ## Key Points - Go treats errors as ordinary return values so callers are forced to explicitly check them at the call site, rather than errors silently propagating up an exception stack - This is one of Go's most debated but deliberate design choices — explicit over implicit, even at the cost of some verbosity - In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview - Use the answer to connect the concept back to a realistic production or interview scenario for 'Why do Go functions commonly return `(result, error)` instead of throwing an exception?' ## Comparison / Tradeoffs | Aspect | Notes | | --- | --- | | Core idea | Go treats errors as ordinary return values so callers are forced to explicitly check them at the call site, rather than errors silently propagating up an exception stack. | | Practical tradeoff | This is one of Go's most debated but deliberate design choices — explicit over implicit, even at the cost of some verbosity. |

Q: What makes a type satisfy a Go interface, and why is that different from languages like Java?

## Summary A type satisfies an interface automatically just by implementing its methods — there's no `implements` keyword or explicit declaration needed, unlike Java's nominal typing. ## Longer Answer A type satisfies an interface automatically just by implementing its methods — there's no `implements` keyword or explicit declaration needed, unlike Java's nominal typing. This is why interfaces like `io.Reader` are so pervasive in Go — any type, from any package, can satisfy them without that package needing to know the interface exists. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview. ## Key Points - A type satisfies an interface automatically just by implementing its methods — there's no `implements` keyword or explicit declaration needed, unlike Java's nominal typing - This is why interfaces like `io.Reader` are so pervasive in Go — any type, from any package, can satisfy them without that package needing to know the interface exists - In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview - Use the answer to connect the concept back to a realistic production or interview scenario for 'What makes a type satisfy a Go interface, and why is that different from languages like Java?' ## Comparison / Tradeoffs | Aspect | Notes | | --- | --- | | Core idea | A type satisfies an interface automatically just by implementing its methods — there's no `implements` keyword or explicit declaration needed, unlike Java's nominal typing. | | Practical tradeoff | This is why interfaces like `io.Reader` are so pervasive in Go — any type, from any package, can satisfy them without that package needing to know the interface exists. |

Q: How does capitalization affect what's accessible outside a Go package?

## Summary An identifier starting with an uppercase letter is exported and visible to other packages that import this one; lowercase means it's package-private and invisible outside it. ## Longer Answer An identifier starting with an uppercase letter is exported and visible to other packages that import this one; lowercase means it's package-private and invisible outside it. This is a simple, textual convention that replaces the access-modifier keywords found in most other languages. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview. ## Key Points - An identifier starting with an uppercase letter is exported and visible to other packages that import this one; lowercase means it's package-private and invisible outside it - This is a simple, textual convention that replaces the access-modifier keywords found in most other languages - In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview - Use the answer to connect the concept back to a realistic production or interview scenario for 'How does capitalization affect what's accessible outside a Go package?' ## Comparison / Tradeoffs | Aspect | Notes | | --- | --- | | Core idea | An identifier starting with an uppercase letter is exported and visible to other packages that import this one; lowercase means it's package-private and invisible outside it. | | Practical tradeoff | This is a simple, textual convention that replaces the access-modifier keywords found in most other languages. |

Organize behavior and data

Functions, Structs, and Packages

Functions can return multiple values, which Go idiomatically uses for returning a result alongside an error.

func divide(a, b float64) (float64, error) {
    if b == 0 {
        return 0, fmt.Errorf("division by zero")
    }
    return a / b, nil
}

Structs and Methods

A struct groups related fields together, and methods attach behavior to a type via a receiver argument.

type Rectangle struct {
    Width, Height float64
}

func (r Rectangle) Area() float64 {
    return r.Width * r.Height
}

Packages

Related files live together in a package, and exported identifiers (starting with an uppercase letter) become part of that package's public API for other packages to import.

Practice questions

Why do Go functions commonly return `(result, error)` instead of throwing an exception?

Answer

Summary

Go treats errors as ordinary return values so callers are forced to explicitly check them at the call site, rather than errors silently propagating up an exception stack.

Longer Answer

Go treats errors as ordinary return values so callers are forced to explicitly check them at the call site, rather than errors silently propagating up an exception stack. This is one of Go's most debated but deliberate design choices — explicit over implicit, even at the cost of some verbosity. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview.

Key Points

Go treats errors as ordinary return values so callers are forced to explicitly check them at the call site, rather than errors silently propagating up an exception stack
This is one of Go's most debated but deliberate design choices — explicit over implicit, even at the cost of some verbosity
In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview
Use the answer to connect the concept back to a realistic production or interview scenario for 'Why do Go functions commonly return (result, error) instead of throwing an exception?'

Comparison / Tradeoffs

Aspect	Notes
Core idea	Go treats errors as ordinary return values so callers are forced to explicitly check them at the call site, rather than errors silently propagating up an exception stack.
Practical tradeoff	This is one of Go's most debated but deliberate design choices — explicit over implicit, even at the cost of some verbosity.

Why

Summary

This is one of Go's most debated but deliberate design choices — explicit over implicit, even at the cost of some verbosity.

Longer Answer

This is one of Go's most debated but deliberate design choices — explicit over implicit, even at the cost of some verbosity. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview.

Key Points

This is one of Go's most debated but deliberate design choices — explicit over implicit, even at the cost of some verbosity
In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview
In an interview, relate 'Why do Go functions commonly return (result, error) instead of throwing an exception?' to implementation decisions, tradeoffs, and operational impact
Use the answer to connect the concept back to a realistic production or interview scenario for 'Why do Go functions commonly return (result, error) instead of throwing an exception?'

Comparison / Tradeoffs

Aspect	Notes
Core idea	This is one of Go's most debated but deliberate design choices — explicit over implicit, even at the cost of some verbosity.
Practical tradeoff	In an interview, relate 'Why do Go functions commonly return `(result, error)` instead of throwing an exception?' to implementation decisions, tradeoffs, and operational impact.

What makes a type satisfy a Go interface, and why is that different from languages like Java?

Answer

Summary

A type satisfies an interface automatically just by implementing its methods — there's no implements keyword or explicit declaration needed, unlike Java's nominal typing.

Longer Answer

A type satisfies an interface automatically just by implementing its methods — there's no implements keyword or explicit declaration needed, unlike Java's nominal typing. This is why interfaces like io.Reader are so pervasive in Go — any type, from any package, can satisfy them without that package needing to know the interface exists. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview.

Key Points

A type satisfies an interface automatically just by implementing its methods — there's no implements keyword or explicit declaration needed, unlike Java's nominal typing
This is why interfaces like io.Reader are so pervasive in Go — any type, from any package, can satisfy them without that package needing to know the interface exists
In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview
Use the answer to connect the concept back to a realistic production or interview scenario for 'What makes a type satisfy a Go interface, and why is that different from languages like Java?'

Comparison / Tradeoffs

Aspect	Notes
Core idea	A type satisfies an interface automatically just by implementing its methods — there's no `implements` keyword or explicit declaration needed, unlike Java's nominal typing.
Practical tradeoff	This is why interfaces like `io.Reader` are so pervasive in Go — any type, from any package, can satisfy them without that package needing to know the interface exists.

Why

Summary

This is why interfaces like io.Reader are so pervasive in Go — any type, from any package, can satisfy them without that package needing to know the interface exists.

Longer Answer

This is why interfaces like io.Reader are so pervasive in Go — any type, from any package, can satisfy them without that package needing to know the interface exists. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview.

Key Points

This is why interfaces like io.Reader are so pervasive in Go — any type, from any package, can satisfy them without that package needing to know the interface exists
In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview
In an interview, relate 'What makes a type satisfy a Go interface, and why is that different from languages like Java?' to implementation decisions, tradeoffs, and operational impact
Use the answer to connect the concept back to a realistic production or interview scenario for 'What makes a type satisfy a Go interface, and why is that different from languages like Java?'

Comparison / Tradeoffs

Aspect	Notes
Core idea	This is why interfaces like `io.Reader` are so pervasive in Go — any type, from any package, can satisfy them without that package needing to know the interface exists.
Practical tradeoff	In an interview, relate 'What makes a type satisfy a Go interface, and why is that different from languages like Java?' to implementation decisions, tradeoffs, and operational impact.

How does capitalization affect what's accessible outside a Go package?

Answer

Summary

An identifier starting with an uppercase letter is exported and visible to other packages that import this one; lowercase means it's package-private and invisible outside it.

Longer Answer

An identifier starting with an uppercase letter is exported and visible to other packages that import this one; lowercase means it's package-private and invisible outside it. This is a simple, textual convention that replaces the access-modifier keywords found in most other languages. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview.

Key Points

An identifier starting with an uppercase letter is exported and visible to other packages that import this one; lowercase means it's package-private and invisible outside it
This is a simple, textual convention that replaces the access-modifier keywords found in most other languages
In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview
Use the answer to connect the concept back to a realistic production or interview scenario for 'How does capitalization affect what's accessible outside a Go package?'

Comparison / Tradeoffs

Aspect	Notes
Core idea	An identifier starting with an uppercase letter is exported and visible to other packages that import this one; lowercase means it's package-private and invisible outside it.
Practical tradeoff	This is a simple, textual convention that replaces the access-modifier keywords found in most other languages.

Why

Summary

This is a simple, textual convention that replaces the access-modifier keywords found in most other languages.

Longer Answer

This is a simple, textual convention that replaces the access-modifier keywords found in most other languages. In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview.

Key Points

This is a simple, textual convention that replaces the access-modifier keywords found in most other languages
In practice, explain where this shows up in production code, what tradeoffs matter, and how you would justify the choice in an interview
In an interview, relate 'How does capitalization affect what's accessible outside a Go package?' to implementation decisions, tradeoffs, and operational impact
Use the answer to connect the concept back to a realistic production or interview scenario for 'How does capitalization affect what's accessible outside a Go package?'

Comparison / Tradeoffs

Aspect	Notes
Core idea	This is a simple, textual convention that replaces the access-modifier keywords found in most other languages.
Practical tradeoff	In an interview, relate 'How does capitalization affect what's accessible outside a Go package?' to implementation decisions, tradeoffs, and operational impact.

Open in the app to mark lessons complete, take notes and track your progress.