It’s been a few years for me since I coded for my dinner money, personal automation projects aside, so I would not consider myself a professional coder. I have played with a few languages over the years: Assembler, C, Basic, Java, PHP, and Python, to name some. Recently I have been playing with GO and I became aware of a Network Operating System (NOS) written in RUST (Flock Networks). There is at least one successful NOS that combines C/C++, GO, and Python, and more than one NOS that uses Python for the CLI. I first felt the need for C to be replaced in NOSs over a decade ago, I probably became aware that I was not the only one who felt that way about 4-5 years ago. The search for a C replacement is well and truly on, in and outside of networking.
There are a couple of dimensions to the search. One is scaling developer productivity beyond what the C approach provided, which is where languages like Java and Python have landed. What languages programmers become proficient in during their education also plays a role here. The other is to provide a high-performance, yet less-error prone, systems programming language, which is where GO and RUST fit. Some would argue GO is not a systems programming language, especially as it has garbage collection and does not have the level of control in memory allocation / deallocation that C & RUST do. Without getting tangled up in that debate, I would just say that if a successful modern NOS can combine C/C++, GO, and Python, then there is obviously a hierarchy of needs in an embedded environment, and not everything needs to be written in C.
The IT universe wants to find a replacement for C, yet languages like GO and RUST look very C-like, visually. I guess some things are hard to abandon, even as a language makes forward progress. As GO has more visibility than RUST, I will focus on RUST. Does GO solve all of C’s problems? As an amateur programmer, I would say not, I would also say Java and Python are somewhat more productive languages for individuals, and I have experienced some runtime errors I thought GO may have eliminated (though as I become more familiar with the GO-way, these will diminish). Putting amateurs like me aside, it is at the team / large project level that GO seeks to enhance productivity, through the enforcement of specific idioms that leads to developers doing things the same way, across a large project, and thus making it easier to maintain code. The combined ideas of trying to evolve GO with a minimalist mindset, and enforcing commonality through enforced idioms, are two of the ideas that lead to GO standing out from the pack. You know the old saying, something is not finished when you can put everything possible in, but when you have taken everything possible out! That is what GO is endeavoring to be, the “simple” language for a complex time. It is in many ways, a philosophy that resonates with the times we live in, regardless of what the initial motivations may have been. We will have to see how it stands up to years of pressure to put more stuff in.
GO has good and easy to use support for concurrency (both GO routines and easy to use MUTEXs). The order in which GO routines actually execute can surprise sometimes, but that’s OK, I think. GO has well integrated support for HTTP, whether it is easy to use is debatable from my perspective, especially when going beyond demos and developing REST interfaces. Of course, just as REST was becoming the defacto industry standard it is coming under attack as not being so easy to support in general, and perhaps too verbose and inefficient. Enter gRPC. Amazing, does not matter how much bandwidth we have, engineers tend to keep pulling the industry back from verbose formats like plain text and XML That’s not necessarily a bad thing, just observing, throwing bandwidth at it is still not the answer for many developers. The modern world is about writing services, and in GO, that is not really what I would call native. To recreate the ease of development under AWS, you have to use a GO framework like GO MICRO. That is not necessarily a bad thing, but it does tend to highlight that sometimes a language is only as good as the supporting libraries and frameworks that you have access to. I would observe there may still be a gap in the world of languages when it comes to (micro) services. I am not saying it cannot be done with any number of languages, I am just saying, I am not sure any language has focused on making it a centerpiece of the language, with the entire environment you need to support it (for example what is found in GO MICRO). I think about gaps only because I think about where the next disruption might come from, not a big part of how I assess GO.
I do like Python. I will admit I flipped out a little bit the first few times my programs did not run because I screwed up my tabs and/or spaces where in the wrong place. It is great to get rid of the semicolons, but to add this annoyance to the language is unfortunate. It was good to see that GO also got rid of the semicolons without adding some weird idiosyncrasy like that. You go GO! But yeah, Python rocks in its own way, and pretty much rules the data science / machine learning landscape at this point. I’m starting to play with some stats in GO, and GO has ambitions in that area of stats and ML, but Python certainly has both mindshare and running code.
Languages are like any thing else that exist in a competitive market. Disruption is driven by the languages that address the new problems an industry is facing, both natively, and through the ecosystem that surround it. There are clearly two new rock stars on the scene, GO and Python. One of them looks a great deal like C, even if it has different capabilities, and the other is a bastion of productivity both through the language itself and the supporting libraries. C is dead. Long live C, the language that other languages want to be, in style. substance, and/or popularity.
Oh, you want to know why a nice boy like me is screwing around with programming languages. Well there are two answers. Firstly, screwing around with code is one of only a few things I have ever truly found joy in. Secondly, and more importantly, I think someone else said it better than me: