I’ve been intrigued by the Go language since I first encountered it about 6 months ago. There are some great online lectures that you can find here.
Go solves a number of problems that C++ and Java didn’t. Unlike C++, Go has a garbage collector which eliminates a large class of memory-leak issues. Go has a much cleaner syntax than either language, eliminating a great deal of programmer overhead when writing and reading code. Indeed, based on syntax alone I personally classify Go, along with Scala, as a next-generation language because they respect the needs of the programmer; they serve the programmer rather than telling what hoops must be jumped through.
But one of the biggest issues solved by Go is parallel programming. Go has built-in support for Communicating Sequential Processes (CSP). You can start any function f() as a separate process by saying go f(), and then communicate with that process using channels (which safely transport messages back and forth). It’s worth noting that Go was initially designed to create servers (not web servers per se, just general-purpose servers as we’ll explore in this article) and has expanded to a general-purpose systems language; it creates natively-compiled executables and tends to be more closely aligned to the hardware — thus “goroutines” tend to be tied to the processors/cores of a single machine. Scala, in contrast, seems to be aiming for distributed multiprocessing systems, especially when you look at the direction that Akka is going (the rumor is that Akka will eventually be folded into Scala).
My interest here is to make the case for hybrid programming. I distinguish hybrid from polyglot programming; the latter means that the programmer has learned and benefits from knowing multiple languages (this is essential, I believe, as it allows you to see solutions in multiple ways rather than being restricted to the lens of a single language). When I say hybrid programming, I mean that a single application is crafted using multiple languages.
In my experience, all languages do some things well but have blind spots. When you use those languages, you can move very quickly when utilizing their “power regions” but the project slows way down and becomes expensive when you encounter the problem areas. Why not use multiple languages and let each one work to its strength?
Coming from a background in C/C++, I find Go to be a real breath of fresh air. At this point, I think it would be a far better choice than C++ for doing systems programming because it will be much more productive and it solves problems that would be notably more difficult in C++. This is not to say that I think C++ was a mistake — on the contrary, I think it was inevitable. At the time, we were deeply mired in the C mindset, slightly above assembly language and convinced that any language construct that generated significant code or overhead was impractical. Things like garbage collection or language support for parallelism were downright ridiculous and no one took them seriously. C++ took the first baby steps necessary to drag us into this larger world, and Stroustrup made the right choices in making C++ comprehensible to the C programmer, and able to compile C. We needed that at the time.
We’ve had many lessons since then. Things like garbage collection and exception handling and virtual machines, which used to be crazy talk, are now accepted without question. The complexity of C++, and the resulting impact on productivity, is no longer justified. All the hoops that the C++ programmer had to jump through in order to use a C-compatible language make no sense anymore — they’re just a waste of time and effort. Now, Go makes much more sense for the class of problems that C++ was originally intended to solve.
Sandwiched between these sections is example codes with explanations as to making a hybrid program of python and Go, which, more programming oriented among you might enjoy!