Abusive Relationships with Programming Languages

This morning browsing GitHub, a simple thesis came to me to potentially explain the nature of the issues I had with Go, and it came while sifting through a newly-starred Rust repository that someone I follow put onto my feed. In its README I noticed a very telling personal signal that put into context a lot of the weird behaviours and strange decisions that have been making patterns in such programming communities lately.

I’m not going to name them, or even get into what specifically it was. The detail was a kind of profile picture they displayed showing a political affiliation with, let’s just say, a fringe ideology. A lot has been said as to what draws people into such circles, and it seems to draw a lot from a misanthropic perception of benign things of the outside world as malicious and destructive. People who hold extreme views tend to feel persecuted and forced into a way of life that makes it impossible for them to live, and this turns out to be a very well-fitting frame for why evangelists of languages like Go and Rust do the things that they do.

I spoke much about how artificially difficult my work was with Go, serving as reason for why I ultimately dropped it and attempted (failingly, for unrelated reasons) to use Scala. The kind of problem Go presented was one I had never encountered before: developer tooling that was bound and determined to tell me how to do my work. It wasn’t an artefact of beta-quality open source software, and it wasn’t mounted as ‘best practise’ either. Instead of workarounds I found the same ‘solution’ on the web, over and over again, to be this silly presumption that I was doing it wrong, no matter how I was doing it, simply because it wasn’t working. It was never an issue to anybody that the only reason it wasn’t ‘working’ was because the tool kept telling me no! The tool itself dictates the ‘correct’ code. Go programmers don’t even need to look at my code: in their world, what’s correct and incorrect have a meaning totally detached from what works and what doesn’t. The most genius part is, they automated the checking of this ‘correctness of their collective personal preference’ in the form of a compiler wrapper. This is the kind of program that can ruin a programmer.

Much discussion of the purpose of Rust as a systems programming language revolves around the idea of safety, and concretely we hear a lot about how older languages like C and C++ don’t offer it. More generally, a lot of people hold a vague disdain for those two languages, as if they’re a relic of a bygone era, and talk much on the internet about new languages vying to be the ‘C++ killer’. By far the most vigourous and thorough attempt at attaining such a title has come in the form of the Rust community online.

This is why it struck such a chord in me when I saw the author of a large, very computer-sciency framework-library to be sporting the adornments of a fringe political movement. It all made sense together in the context of persecution, and it confirmed the gut feeling I have had for a while now that after a point, there will be so much Rust code that it will be hard to avoid using it. Forcing Rust into the mainstream by sheer inertia seems to be the point here. There has always been an irony in the notion of a revolution, as it so often replaces one order with even worse tyranny. After all, if C++ is so untenable and bloated, and C is filled with so many ‘footguns’, the only just thing to do is to do whatever you can to replace it! Everybody is clearly held down by these inferior languages, so we need to make something superior and make sure that it stays that way. Why are we going about computer science in the context of social justice?

Until next time,
Alexander Nicholi