> pointers make such a mess, but are neccessary

ikr! I've shot myself with pointers and nil interfaces countless times. I try to write in a more pure functional style to be more aware of pointers and mutability but Go is really designed with interfaces in mind. So it's always easier to put state inside a struct and attach methods to it. Makes extending and refactoring very easy, but it also leads to more pointer receivers and heap allocs. Oh yeah the heap! Wish it was easier to deduce if a var will escape to the heap. Just read a good article about it, but it's never straight forward:

https://medium.com/eureka-engineering/understanding-allocations-in-go-stack-heap-memory-9a2631b5035d

The modules are very powerful if you're the downstream and upstream follows strict SemVer. I understand the need. The things I have headaches around is the change in behavior  from v0 to v1 and the change in import path with every major version bump.

But I have very few grumps about Go as a whole and continue to love using it day to day.

> odin looks interesting but i'm too committed to Go tbh

That's why it caught my eye. I've been programming in Go almost exclusively for almost a decade. Odin has taken a lot of the good ideas and lessons of Go and has some really nice ergonomics like the explicit context, or_return operator and really the best error handling I've seen so far. Even the package names they use are sometimes the same as in go's stdlib, so it's very easy for a gopher to read odin once you know the small syntax changes. Look at the hello world:

```odin
package main

import "core:fmt"

main :: proc() {
    fmt.println("Hellope!")
}
```