What TypeScript & Elixir Can Learn from each Other (Advent of Code 2024)

[utterances-bot]

What TypeScript & Elixir Can Learn from each Other (Advent of Code 2024)

Effective TypeScript: What TypeScript & Elixir Can Learn from each Other (Advent of Code 2024)

https://effectivetypescript.com/2025/11/24/advent2024-elixir/

[jaman]

I noticed a number of things with this article, but I'll address one of them:

def read_tuple_from_map() do
  grid = %{{1, 2} => true}
  Map.get(grid, 1, 2)  # bad!
  Map.get(grid, {1, 2})  # ok
end

The bad example does not produce a type error, at least not with Elixir 1.19.

It would not produce a type error for at least two separate reasons.

The first: "Maps do not impose any restriction on the key type: anything can be a key in a map." By design, they're meant to accept anything as a key. This is in the Map moduledoc, and is a feature, not a bug, nor is it something lacking in the type system.

Second, the 'bad' call you're making is explicitly calling the 3 arity Map.get, which sets 2 as the default return when the key is not found. That call can't fail — it returns 2. Flagging it would be a false positive.

The thing to know is that in Elixir, the function head is where you put constraints:

def read_tuple_from_map(map, {_, _} = key) when is_map(map) do
  Map.get(map, key)
end

read_tuple_from_map(grid, 1) now has nowhere to land. And you can go further:

def read_tuple_from_map(map, {x, y})
    when is_integer(x) and is_integer(y) and x >= 0 and y >= 0 do

TypeScript would catch the shape with [number, number], but not the non-negative part — that needs branded types, and a brand is just a cast someone can write past. The guard runs on every call.

The other direction is worth a mention too: TS Map compares tuple keys by reference, so grid.get([1, 2]) returns undefined even after grid.set([1, 2], true), and it typechecks clean. Elixir compares tuples structurally, so your grid actually works. That's the harder guarantee, and you already have it.

You're doing this already without calling it that — in read_grid_from_lines, for {x, _y} <- Map.keys(grid), do: x won't match a non-pair key. Same idea.

Which is why I'd say the 1.20 inference you describe is the answer to your complaint rather than a separate topic. Write the head as {x, y} and Elixir works out the domain from the body, no annotation. You quote Hejlsberg on why TypeScript won't do that — the implementation leaking into the signature — but here the leak is the point. Map.get/3 can't help you, because its key type is any() and always will be. A function that only makes sense for pairs gets a pairs-only domain for free.