I know this is kind of far out of an idea. But I have been working with Golang recently. And I can’t help but think how awesome it would be if we could write cold fusion and it gets compiled to golang as 1 binary.
I know this would be pretty hard to do but just putting the concept out there to see what other people think about it.
If you want it to run natively in golang, you’re asking for a transpiler. This maybe straightforward for basic CFML functions, but nearly impossible to support everything CFML does. You’re more likely to find a way to run CFML via a scripting engine interface like JSR-223 from golang, but that would still require the lucee.jar and dependencies be present for execution.
I’d be more interested in hearing what you like about golang and what we can do to make it native to Lucee so you don’t need to touch Golang at all 
My favorite part of golang is the incredibly small runtime (about 8megs) and the fact it doesn’t require an external VM (like the JVM). Lucee lite is around 17 megs, but the JVM is still a hard requirement and doesn’t get much below 40 Megs (Azul)
I certainly understand Java is the work horse of the industry.
I think the attraction to go is just getting rid of the jvm itself. It seems like there is so much effort keeping lucee up to date with jvm versions. Reducing the size, load time. Having it down to 1 binary, there is something compelling about that. No dependencies or libraries required at the device. Using it on embedded devices.
I love that CF is easy and fast to get work done. And I want to see it live on for many years. If CF ran on go it would attract a lot of people to it. Even if it was feature limited.
I guess what I want is to code in CF and get a single small highly-portable performant binary with no dependencies.
I have no idea if it would work, but maybe you want to try out GraalVM with the native-image support.
With GraalVM you can compile Java bytecode into a platform-specific, self-contained, native executable - a native image - to achieve faster startup and a smaller footprint for your application. The Native Image functionality is not available by default, but can be easily installed with the GraalVM Updater tool:
Seems to work with tomcat, with some caveats.
My gut feeling with no facts is that OSGI is going to make this 100x more complicated.
Ultimately, if you’re packaging your app properly, using containers, using proper dependency management, this should be a non-issue. I highly doubt you’ll attain any significant performance improvements.
One could argue that garbage collection causes so many issues in Java, it’d be more efficient if we didn’t have garbage collection and things were allocated more like other languages… but then it wouldn’t be Java anymore 
Code written to work in the language would be expecting things to exist that don’t. For instance, what good is it to transpile the entire JDBC layer so we can access databases? Golang can do that natively in a different way - but there’s no way something non-lucee is going to know “This is datasource management and could just use golang DBs under the hood”. So what you’re really asking is if someone wants to write Lucee in golang - in such a way that Lucee runs in golang natively, either with a golang web server/container/J2EE emulation layer w/ native implementation or providing its own, and compiling CFML directly to golang instead of java.
Performance wise, with transpiling, you need to provide a poly-fill for that sort of functionality when generating .go (or any other) language code, so it’s not like you’re going to see major improvement. Just look at babel as an example - babel transpiles so programmers can use newer javascript language constructs and have compatibility with interpreters that can’t do that natively. It’s not about performance, it’s about maintainability and readability and the new features of the language.
Computers are fast. (even embedded systems - Pi’s are quad core now, as are intel sticks) Maintaining code, dealing with technical debt, maintaining information and standards across teams - these are hard problems. I don’t think the effort makes sense in what you’re suggesting. (This is merely a similar discussion to the earlier discussion of “why can’t all this stuff just run in java without lucee”)
My $.02
I played a bit with GraalVM after I attended a session on it the last time I was at Devnexus. While it worked, the download size was huge and it was slower than a standard JDK. Also, most of the tools for removing unused classes from the JVM don’t work at all with a CF engine that classloads stuff at runtime.