Types, structs & the basics

Go is statically typed and compiled, like TypeScript — but the types are the language, not a layer on top that erases at build time. There's no any escape hatch you'll reach for daily, and a Go binary carries no runtime type checker because the compiler already proved everything.

A Go struct is the workhorse for "a bag of named fields." It's closest to a TS interface describing an object shape, except in Go the struct is the concrete type.

type User struct {
    Name string
    Age  int
}

// A method is declared outside the struct, with a receiver.
func (u User) Greet() string {
    return "Hi, " + u.Name
}

u := User{Name: "Ada", Age: 36}
fmt.Println(u.Greet())

In TypeScript you'd write the shape and the behavior together, or as a class:

interface User {
  name: string;
  age: number;
}

function greet(u: User): string {
  return "Hi, " + u.name;
}

Methods live next to the type, not inside it

Notice func (u User) Greet(). The (u User) part is the receiver — it's what this is in a JS method, but named explicitly. Go has no classes; you attach methods to any type you define. Capitalization matters too: Name (capital) is exported (public), name (lowercase) is package-private. Visibility is a naming convention, not a keyword.

Value vs pointer, briefly

When you pass u User by value, Go copies the struct. To mutate the original, you take a pointer receiver (u *User) — similar to how objects in JS are passed by reference, except in Go you decide per function whether you want a copy or a shared reference.

The challenge below is a JS model of a Go struct plus a method — the runner executes JavaScript, not Go, so we mimic the shape and receiver in plain JS.

Next: how Go handles failure without try/catch.