I've written all my three roguelikes in Go. Mostly because I was already familiar with Go and had enjoyed it for a non-roguelike project previously (a markup language). Certainly not because Go libraries for roguelikes were good at the time, they weren't!

For my first game, Boohu, due to the lack of any decent libraries for Go roguelikes at the time, I wrote from scratch most logic, using the termbox-go and then tcell terminal packages for UI, and later with alternate wasm and Tcl/Tk backends for tiles. The code ended up kind of messy in many places, being my first roguelike and all and having to roll my own stuff for everything, looking at roguelikedev and roguebasin articles, with no gamedev experience at all. That's in part why that game is basically just in maintenance mode now (but I made it work with Tcl/Tk 9 recently by forking and porting the unmaintained "gothic" Go bindings for Tcl/Tk 8.6).

After some early releases of Harmonist, I started working on Gruid, a Go roguelike framework, taking some ideas from the Elm Architecture and Go's bubbletea tui package, with extra pathfinding and mapgen packages (partly based on Harmonist and Boohu's code), and support for terminal, SDL (2 or 3), and wasm backends. And record/replay functionality that results in compact files and that works accross backends, as in "play in ascii in terminal, then watch in tiles in SDL": definitely one of the things I'm particularly happy with!

I then ported Harmonist's code with some effort to use Gruid, and even had Boohu use it for pathfinding (but not UI, as Boohu's UI code would sadly need a boring complete rewrite). Shamogu is the first game I wrote with Gruid from the beginning, and it felt very nice, so that's the one I'd currently suggest looking at for anyone wanting to write a roguelike in Go.

Also worth noting that earlier this year I rolled my own SDL2 minimal bindings, based on the veandco/go-sdl2 ones but cutting code size by an order of magnitude. That made it easy to port them to SDL3, too, and much faster to build than the full ones they're based on.

Which chains with another thing I'm pretty happy with Gruid, which is that there are few external dependencies outside of standard library: just the SDL 2 or 3 shared libraries for the native graphical build, tcell for the terminal build, and no dependencies at all for the wasm one.