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?