Currently we create a new HashMap on every loop iteration.
There are a few ways to improve upon this:

• Mutate the HashMap (might be bad for parallelism?)
• Ditch the HashMap based implementation and perform the whole thing inline
  This method saves a the resources required for the HashMap but is less DRY, requiring an automaton implementer to duplicate the neighborhood code (check every direction, if there can be a cell there then grab that cell, use the neighborhood to calculate the next state of the current cell).

Both methods are less flexible (what if an automaton requires more than one type of neighborhood for its algorithm?). A possible solution for the issues with the solutions I proposed can look like this:

• Create a Neighborhood struct that acts as wrappers for the HashMap with handy methods for mutating its values. The HashMap can have as a key every key we use currently for the 3 neighborhood types, which is 12 in total. Maybe the user of the Neighborhood can decide how many keys they want to allocate in the neighborhood's constructor.
• Replace the *_neighborhood_of functions with Neighborhood::* (perhaps new_*?) functions that take the same parameters as the current versions and return a Self with the right values in the HashMap (note that this is less data-oriented [a-la-Clojure] but the performance might be worth it)
• Add a get_neighborhood_instance function¹ to Automaton that returns a reference to the specified neighborhood type of the specified type which is stored as a member variable in the automaton implementer struct. The implementer is responsible for populating it with the right values, taking care of Nones and avoiding panics.
  This might be too robust, maybe I'll simplify it to remove some of the overhead (at least 4 to 8 extra hash values) my proposed solution requires.

The implementer can then implement their automaton's logic like this:

fn next_state_of(&self, idx: (usize, usize)) -> Self::State {
    // Unsure about the notation.
    // Naming will probably be different in the actual code.
    let &mut neighborhood = self.get_neighborhood_mut();
    neighborhood.modify_according_to(idx, NeighborhoodKind::VonNeumann);
    // If the neighborhood has the right keys for the VN kind:
    if let Some([n, e, s, w]) = neighborhood.as(NeighborhoodKind::VonNeumann) {
        // Do something with n, e, s and w.
    }
}

This might count as less functional since there's mutation involved, but I'm not sure there even is a fast immutable way to solve this (unless the current naive implementation isn't actually that slow).
What would a Haskell programmer do? Is it doable in Rust?

1: Naming is subject to change.