Language idioms across Python, Java, C++, Go

A candidate writes the obvious frequency counter in Python: Counter(s), one line, ships. They open Java to port it for an Amazon loop and write freq[c]++. The compiler refuses. Same shape in C++ just works; same shape in Go just works too. One algorithm, four surface forms, two of which lean on a language rule the other two don't have. The whole chapter is in that detail.

This page is the reference you come back to. Every later chapter on the site renders code tabs that follow these conventions; if a Java tab uses ArrayDeque for a queue or a Go tab clones a slice before passing it down, that's the page you're reading right now. The eight idiom rules below (DSH-01 through DSH-08) are enforced by CI; this chapter is the rationale and the table.

The same problem, four ways#

Count the frequency of each character in "abracadabra". The answer is {a: 5, b: 2, r: 2, c: 1, d: 1}. Here is the canonical Python, short because collections.Counter exists for exactly this.

from collections import Counter


def count_freqs(s: str) -> dict[str, int]:
    """Return a frequency map of characters in s using Counter."""
    return dict(Counter(s))

import java.util.HashMap;
import java.util.Map;

public class Sol {
    public static Map<Character, Integer> countFreqs(String s) {
        Map<Character, Integer> freq = new HashMap<>();
        for (int i = 0; i < s.length(); i++) {
            char c = s.charAt(i);
            freq.put(c, freq.getOrDefault(c, 0) + 1);
        }
        return freq;
    }
}

#include <string>
#include <unordered_map>

std::unordered_map<char, int> count_freqs(const std::string& s) {
    std::unordered_map<char, int> freq;
    for (char c : s) {
        ++freq[c];  // default-constructs to 0, then increments
    }
    return freq;
}

package main

func countFreqs(s string) map[byte]int {
	freq := make(map[byte]int)
	for i := 0; i < len(s); i++ {
		freq[s[i]]++ // map zero value for int is 0
	}
	return freq
}

Look at all four side by side. The shapes diverge in two important places. Python and Java make the missing-key check explicit: Counter hides it, getOrDefault(c, 0) + 1 exposes it. C++ and Go let the zero-value rule eliminate the check entirely. ++freq[c] and freq[s[i]]++ work because indexing a missing key value-initialises a fresh entry to zero in std::unordered_map^[1] and returns the zero value of the value type in map[byte]int.^[2]

That single observation generalises to most of what follows. Naming flips by convention in the same way: count_freqs for Python (snake_case per PEP 8)^[3] and the C++ STL, countFreqs for Java (camelCase) and Go (MixedCaps, where the leading lowercase makes the function package-private).

The reference table#

Twelve idioms across four languages.

The trap layer. The shape that bites between languages and is the leading source of "my code worked locally" anecdotes:

The DSH rules in the companion are this table compressed into a binding contract. DSH-01 forbids subtraction-based comparators (the comparator-overflow row). DSH-04 pins Python's recursion-limit policy. DSH-07 governs sort stability across the four languages. DSH-08 governs unordered_map behaviour on adversarial input.

What you actually need to remember#

Three reflexes are worth burning in. They cover the failure modes that account for most of the cross-language porting bugs.

Python and Java need explicit lookup-or-default; C++ and Go don't. When the algorithm is "increment a count for this key," Counter or getOrDefault in the explicit pair, ++freq[k] or freq[k]++ in the implicit pair. Pasting freq[c]++ into Java is a NullPointerException. Pasting getOrDefault into C++ compiles but reads as a translation, not a native idiom; use the bracket-and-increment form.

Half-open intervals [lo, hi) are universal. All four languages index from zero and treat ranges as half-open. Python slicing, Java subList, C++ iterator pairs, Go slicing: same convention. len = hi - lo works without +1, which kills off-by-one bugs that closed intervals invite. Skiena's Algorithm Design Manual makes the discipline explicit.^[9] The handbook always writes ranges as [lo, hi) and never as [lo, hi].

Boxing is a Java tax; UB is a C++ tax; aliasing is a Go tax. Each language carries one structural cost the other three avoid. Java's PriorityQueue<Integer> autoboxes on every offer and poll; on a Dijkstra hot path the GC pressure is measurable, and the canonical workaround is int[] paired with Comparator.comparingInt. C++ signed overflow is undefined under -O2 and the compiler is free to assume it does not happen; you defend by widening to int64_t before the multiply. Go slices share a backing array unless you slices.Clone, and the most common Go chapter-code bug is mutating one slice and accidentally mutating another that was passed in by value. Python pays none of these taxes and pays a different one, which is that arbitrary-precision arithmetic and reference semantics together cost a constant factor of three to ten on hot paths.

Where this leads#

Choosing your interview language is the next chapter and answers "given a target company, which one should I write in." The recommendation is mostly Python; the exceptions are Google (Java, C++, JavaScript, or Python only) and a candidate whose day-job language is already fluent.

Every chapter from Part 1 onward consumes this page's idiom rules. When Arrays: static, dynamic, multi-dimensional shows a Java tab using ArrayDeque for a stack, that's DSH-DSA from this page. When Hash maps shows a Go tab cloning a slice before passing it down, that's the aliasing rule. The four-language posture only works if the chapters and the reader share this conventions table; this page is where the table lives.

References#