Same as Go, where everybody just uses map[Key]struct{} as sets.

To be fair, this is because the language does not support a type safe set type. I would use one frequently if it did

map[T]struct{} is a type-safe set type. It's just not an ergonomic one.

FWIW, I'm usually using map[T]bool and only ever inserting `true` values. It uses a bit more space, but membership checks read like

  if set[key] {

instead of

  if _, ok := set[key]; ok {

Before Python grew a set type, it was common to implement them in a similar way, i.e. as a dict with some kind of default value (0, 1, None, etc).

Python sets are internally just a dict hash table for the keys with no associated values.

I think internally C++ STL set<T> is similarly just map<T, void>

> Interestingly enough some languages actually do the opposite.

Of course you can represent sets as dictionaries with empty values (ask anyone who programmed Perl). You're supporting my point that dicts logically subclass sets, because they can represent sets where the values can be other things as well.

You're also getting at what the behavior should be if you union a dictionary and a set. Hypothetical Python:

    >>> s = {'a','b','c'}
    >>> d = {'d': 'D'}
    >>> d | s
    >>> {'d': 'D', 'a': None, 'b': None, 'c': None}

I think he's flipping your point: sets are a subclass of dicts/maps, not vice-versa. Thinking of a maps as a set where it's value maps to something else sounds backwards because values in sets don't map to values arbitrarily (or at all in some cases); maps are maps.