I'm writing a simple functional language with automatic memory management. Go's simplicity seems it could be a good target for transpilation: garbage collection, decent concurrency paradigm, generally simple/flexible, errors as values. I already know Go quite well, but I have no idea about IR formats (LLVM, etc)

To be clear, using Go as a compiler backend would be a hidden implementation detail and there would be no user-level interop features. I'd like to bundle the Go compiler in my own compiler to save end-user headaches, but not sure how feasible this is. Once my language is stable enough for self-hosting, I'd roll my own backend (likely using Cranelift)

Pros

• Can focus on my language, and defer learning about compiler backends
• In particular, I wouldn't have to figure out automatic memory management
• Could easily wrap Go's decent standard library, saving me from a lot of implementation grunt work
• Would likely borrow a lot of the concurrency paradigm for my own language
• Go's compiler is pretty speedy

Cons

• Seems like an unconventional approach
• Perception issues (thinking of Elm and it's kernel code controversy)
• Reduce runtime performance tuneability (not to concerned about this TBH)
• Runtime panics would leak the Go backend
• Potential headaches from bundling the Go compiler (both technical and legal)
• Not idea how tricky it would be to re-implement the concurreny stuff in my own backend

So, am I crazy for considering Go as compiler backend while I get my language off the ground?