asdfghj

Basic suggestions

Line 211 in fba6a09

for i, c := range board {

for i, c := range board {
    if i > 0 && i < SIZE-1 {
//becomes
for i := 1; i<SIZE-1;i++ {
    c := board[i]
    // same suggestion for inner loops

gocellular/main.go

Line 117 in fba6a09

if Neighbour == 1 {

if Neighbour == 1 {
// extract contents of `if` to a function countNeighborsMoore?

OOP-ish suggestions

Encapsulate board logic in a type

type game struct {
    board tensor3 // tensor3 type with contiguous allocation, stride mem access if you want to needlessly optimize, if not already existing [][][]uint8 is good enough
    rules int // Moore==1, neumann==0 
}

//suggestion for tensor3
type tensor3 struct {
   data []uint8
   r, c, d int //row, column, depth
   // dynamic stride completely useless if no resizing going on
   //stride1 int 
   //stride2 int
}

// set assigns v to element at position (i,j,k) of 3D tensor
func (t tensor3) set(i, j, k int, v uint8) {
    // row major, depth minor. not sure if this is correct though
    t.data[k + j*t.d + i*t.d*t.c] = v // 🤷
}

and add logic as methods to game

Good suggestions!
Whats the gain of extracting contents of if to a function countNeighborsMoore?
Changing the data structure might be a good idea but hinders readability, will be considered when optimization is needed

Whats the gain of extracting contents of if to a function countNeighborsMoore?

Readability of code exclusively. It would serve as a way of "indexing" the Neumann, Moore, etc rules of the game inside a file since it is likely one wants to make changes/view the code of one of the rules at a time.

Changing the data structure might be a good idea but hinders readability, will be considered when optimization is needed

Agreed, these methods would add quite some cognitive load. On the bright side you can reach the same optimization by making a somewhat large change

boardNow [][][]uint8
boardOptimized [SIZE][SIZE][SIZE]uint8

The net effect of the above implementation would be equal or even better than using the proposed tensor3 implementation. SIZE is already a const so there would not be much breakage I imagine. Of course, if one wishes to let the user choose the size during runtime this would not be a desired change to have.

Implemented