I know there exists more generic typing tools. One idea I had was to make a "guts" to convert Golang -> Generic Typing -> All languages.

The reason to keep Golang as the source of truth is these types originate from the backend. So when you are writing the backend, it is just the easiest place to write and maintain things. No obstacles.

Golang types are also very simple. I imagine almost all Go types can be converted because of that.

Using Golang as the source is easier for a Golang backend team. Native types are always going to be the most convenient.

The theory when we came out with guts was that Golang's typing system is very simple (this was before generics when it was made). So how hard could it be to write a simple converter?

The first iteration of guts was written in an afternoon. Eventually I moved it to its own repo, mainly for personal use.

So honestly it really comes down to making it as easy as possible to write backend code. Using another spec that autogen's the Golang would be an extra step we did not feel we needed.

> Using another spec that autogen's the Golang would be an extra step we did not feel we needed.

No need to. You can start with Go Lang server and generate the spec from it as well.

Thrilled to see you got value out of it!

I totally agree a proto first approach to your types can pay back in dividends if you need to serialize over different wires.

This project admittedly was developed to solve a specific need in an existing codebase with a lot existing types.

The codebase is also mostly maintain by the backend Golang engineers. Letting them use their native type system increases adoption and buy in.

Totally - The other really nice thing about Golang "type-system" ecosystem is their native ast in the stdlib. You can do so many amazing things from there. Infact if you pledge your life to Go (which I think I have atleast for now) starting from Go and generating everything outwards is not necessarily a bad strategy.