This is actually perfect for me.

Go is my most productive language, but it is the worst for some of the usecases I want to use it for due to goroutines and GC pauses and things like that.

I learned C and programming when I was a middle school math nerd and so my understanding of functions was colored by the algebraic definition of a single value function. This led to me writing my code in a more functional paradigm than an object oriented paradigm. I struggled to learn Java. I struggled in programming class when we made the switch from VB6 to vb.net because I didn’t really understand object oriented programming.

I find go’s procedural nature to be the best language for my understanding of programming with functions. The way the object oriented code is possible, but not required allows me to build types and objects that I can compose and use as I understand them, not the way that object oriented, inheritance, and polymorphism requires me to subclass.

I recently have had the idea for a project and I found the perfect ECS library that would allow me to compose my entities and components the way I do in Go, but it does not interface cleanly with Cgo either in runtime overhead or development overhead.

The official bindings for it are rust, c, c#, zig, lua, and clojure.

This would allow me to use it by writing Go code that calls it natively like C.

I’m not concerned about not getting to use Go libraries. I believe in Roll Your Own and always had to roll my own when I was learning C. Go’s stdlib is tight and lends itself to RYO really well.