Operators and Expressions

A billing job computes a prorated refund: refund := charge * daysLeft / daysTotal, all integers. The numbers come back suspicious. The cause is a rule most engineers absorb from C and then forget applies here too — integer arithmetic in Go is exact and unforgiving.

7 / 2        // 3  — division truncates toward zero, never rounds
-7 / 2       // -3 — truncation, not floor: -3.5 rounds toward zero
-7 % 2       // -1 — remainder takes the sign of the dividend
7 % -2       // 1

The remainder follows from the spec's identity x = q*y + r with q truncated toward zero, which forces r to share x's sign. If your code assumed Python's floor division and positive remainders (-7 % 2 == 1 there), every negative input shifts by one. Money, timestamps, and pagination are where that shows up.

Division by zero has two different endings. With constants the compiler catches it:

const bad = 10 / 0      // compile error: division by zero

With variables it is a runtime panic that kills the program, so validating a divisor is a real precondition, not paranoia.

Overflow is the quiet one. Constants are checked at compile time because the compiler evaluates them with arbitrary precision:

const over uint8 = 300        // compile error: 300 overflows uint8

Variables are not: they hold sized storage, and arithmetic wraps silently through two's complement.

var x uint8 = 255
x = x + 1                     // 0 — no warning, no error
fmt.Println(x + 1)            // 1

Counters that must never wrap need explicit bounds checks before the arithmetic, not after. And a related trap: operands of a binary operator must already have the same type — var i int; var f float64; i + f does not compile, even though both are numbers. Untyped constants slide past this (i + 1 works because the constant 1 adopts int, while i + 1.5 fails because 1.5 cannot), which is exactly the boundary Variables and Constants drew. Getting from i + f to working code means writing float64(i) + f — the conversion story is the next topic, Explicit Type Conversions.

Go's entire binary operator precedence fits on one card:

Unary operators bind tighter than all of these, and ++/-- are not operators at all — they are statements, which is why x++ cannot appear inside an expression and if x++ == 1 {} does not compile.

The level-5 versus level-3 split settles a bug that ships in C code to this day. In C, & binds looser than ==, so flags & Read != 0 parses as flags & (Read != 0) — comparing first, then AND-ing a boolean against an integer. Go puts & at level 5 and == at level 3, so the same line parses as (flags & Read) != 0, which is what every reader assumed. The lesson inverts the usual advice: here the unparenthesized form is correct, and your C-trained instincts are what need adjusting.

The same table explains Effective Go's example x<<8 + y<<16: shifts sit with multiplication, addition sits below them, so the expression means (x<<8) + (y<<16) — what the spacing implies. When in doubt, parentheses are always legal and gofmt preserves them; reach for them when the code must be unambiguous to someone who has not memorized the table, not to satisfy the compiler.

The rest of the expression toolkit is small on purpose:

total += price        // compound assignment: += -= *= /= %= &= |= ^= <<= >>= &^=
n := -score           // unary negate
ok := !failed         // logical not

There is no ternary ?: — max := a; if b > a { max = b } is the idiom, and you will meet it properly in Conditionals with if and else. There is no comma operator, no implicit conversions in mixed expressions, and no ** exponent (use math.Pow). Every omission pushes the same design: one obvious way to write each thing, readable by someone who learned the language last week.

Comparison splits into two capabilities, and the type system decides which one your value gets.

Equality (==, !=) is broadly available: booleans, all numeric types, strings, pointers, channels, and interfaces support it, along with arrays and structs whose elements all do. Ordering (<, <=, >, >=) is restricted to numbers and strings — you cannot ask whether one struct is less than another, and there is no automatic lexicographic fallback for structs.

"apple" < "banana"        // true — byte-wise lexicographic
"Z" < "a"                 // true — uppercase sorts before lowercase!
[2]int{1, 2} == [2]int{1, 2}   // true — element-wise

String comparison is raw byte order, which means it is not natural-language collation: uppercase letters all sort before lowercase, and accented characters follow UTF-8 byte values rather than dictionary order. For user-facing sorting you need explicit locale-aware logic; for keys and IDs, byte order is exactly what you want.

The refusals are worth memorizing because they are compile errors, not surprises:

m1 := map[string]int{"a": 1}
m2 := map[string]int{"a": 1}
m1 == m2            // compile error: maps are not comparable
s1 := []int{1}
s2 := []int{1}
s1 == s2            // compile error: slices are not comparable

Maps, slices, and functions can only be compared against nil — a test of presence, not of content. Structs are comparable only if every field is, so a struct containing a slice cannot use == at all; comparing content there means writing an Equal method or using reflect. Elements matter too: struct { ids []string } inherits the slice's incomparability.

Two runtime behaviors complete the picture. Interface values compare by dynamic type and value — fmt.Stringer(x) == fmt.Stringer(x) is true only if both hold the same underlying value — and comparing interfaces that hold values of the same uncomparable type (two slices, for instance) panics rather than compiling to false. And IEEE floats carry a trap: every comparison against NaN is false, including NaN == NaN, so range checks (x > low && x < high) are the reliable idiom instead of equality on floats.

Equality is the silent half of control flow: every if, switch, and loop condition you write next is built from these operators, so knowing which comparisons are legal — and which are lies — decides how readable that code can be.

The logical operators &&, ||, and ! are ordinary, but Go's && and || short-circuit: the right operand is evaluated only when the left does not decide the result. That is not a micro-optimization — it is a safety mechanism.

if s != nil && s.Len > 0 {
	// s.Len runs only when s is non-nil
}

if user == nil || !user.Active {
	return ErrInactive
}

Without short-circuiting, s != nil && s.Len > 0 would panic on nil dereference for every nil s — the guard would be decorative. The pattern is load-bearing in nearly every condition you will write, including the err != nil checks from error handling: write the potentially unsafe access on the right, the check that makes it safe on the left, and never reorder them casually. || mirrors it: the right side runs only when the left is false, so user == nil || user.Name == "" is a complete emptiness check with one side-effect-free first test.

Bitwise operators live at a different altitude: they operate on the bits of integers, which makes them the encoding layer under everything from file permissions to network flags.

const (
	Read  = 1 << iota // 001
	Write             // 010
	Exec              // 100
)

var perm = Read | Write    // combine: 011
hasRead := perm&Read != 0  // test one bit
perm = perm &^ Exec        // clear: Go's AND NOT — keep bits where Exec is 0
perm = perm | Exec         // set

The operator table for integers: & keeps bits set in both, | keeps bits set in either, ^ toggles, <</>> shift (with a non-negative count — a negative shift count panics at runtime), and &^ — uniquely Go's spelling — clears the right operand's bits from the left. x &^ (1 << n) reads as "turn off bit n," which is the operation everyone else writes as x & ~(1 << n) and half of them get wrong at the boundaries. The flag-building half of this pattern, 1 << iota, is developed in Variables and Constants.

Watch the contrast that confuses newcomers: && requires booleans and short-circuits, while & requires integers and always evaluates both sides. Using & where you meant && — with non-boolean operands it will not even compile — is caught early; using && on bits is a type error in the other direction. Between the two families, every condition and every flag in the codebase has exactly one idiomatic spelling.