Go Is Not Good – A list of articles complaining that go isn't good enough

The fact that I have to wrap them in an interface is also a performance concern, because an interface devolves to a pointer if it can't fit the contents into a single machine word. So in effect, every single struct becomes a pointer, which in my case seems unnecessary.

There are some concerns that cut across all uses of the data that could be methods, but even things like mapping over (transforming) the data shouldn't really need to be built into the data structures via interfaces. Not least because it's horrible to write. For example, consider this:

    type Expression interface{}
    type And struct {
      LHS, RHS Expression
    }

    newExpr := Map(expr, func(e Expression) Expression {
      if and, ok := e.(And); ok {
        if and.LHS == True {
          return and.RHS
        }
        if and.RHS == True {
          return and.LHS
        }
      }
      return e
    })

    type Expression interface {
      Map(fn func(e Expression) Expression) Expression
    }

    func (e And) Map(fn func(e Expression) Expression) Expression {
      e.LHS = fn(e.LHS)
      e.RHS = fn(e.RHS)
      return fn(e)
    }

    type Expression interface {
      GetChildren() []Expression
      SetChildren(...Expression) Expression
    }

    func (e And) GetChildren() {
      return []interface{e.LHS, e.RHS}
    }

    func (e And) SetChildren(children ...Expression) Expression {
      e.LHS = children[0]
      e.RHS = children[1]
      return e
    }

    func Map(e Expression, fn func(e Expression) Expression) Expression {
      children := e.GetChildren()
      newChildren := make([]interface{}, len(children))
      for i, child := range children {
        newChildren[i] = fn(child)
      }
      return e.SetChildren(newChildren...)
    }

Less expensive idea: Since all my expressions are nonary, unary or binary, I could have a Nonary/Unary/Binary to avoid GetChildren() and SetChildren() operating on slices, and then Map() could simply do a switch.

Or you could simply skip all of that and build a switch statement:

    func Map(expr Expression, fn func(e Expression) Expression) Expression {
      switch e := expr.(type) {
        case And:
          e.LHS = fn(e.LHS)
          e.RHS = fn(e.RHS)
        // ...
      }
      return fn(expr)
    }

(There's a lot of boilerplate: Map() is not the only function I need. I also need a top-to-bottom version (the above is depth-first) and a Find(), and multiple other things that need to recursively determine something about an expression, without knowing all the types involved.)

Probably compared to what they were shown in university/bootcamp/whatever.

'no programming experience' could esily mean 'no professional programming experience' which is very close to 'no programming experience'.

I am enrolled in a computer engineering course, and I can tell you the amount of code we get to write is ridiculously low.

Some package management systems can decouple what packages are called inside the code from what they're called outside.