In Defense of the Hosted Language: Why Golang isn't the Catch-all, End-all
When I first heard about Golang, I sincerely thought the JVM was obsolete. Its day was past in my head. After all, when I wrote in Go, I felt like I was writing in Java or Python, because it was garbage collected. At the same time, since it was cross-compilable, it was as portable as Java, but I didn't need to install a run time first. As a DevOps engineer, I really saw the benefit. I still do. But as I have learned, it has its drawbacks. For example, say I want to write a GUI application. With the JVM, I can do all of it in pure Java. (Not that you would want to do this, but bear with me.) But I can't do it in Golang without using CGo. Why? Well, this is because you need to interact with native code to write a GUI because assembly is the language in which computer graphics speak (ish -- I know I'm glossing over details) and that is most easily interfaced with using a native language like C, C++ or Rust. With Java, I can bake that native code into the JVM, then call that
