When I first began working on the HALO software suite in earnest, I set out using a relatively new programming language: Golang. However, I learned pretty early on that Go was seriously debilitating, not so much for the kind of work I was doing, but for how I was approaching it. I detailed these problems on my personal weblog, and it basically boils down to the relentless insistence the Go tooling—and indeed its entire ecosystem—has in forcing me into doing my job their way.
Who are they? Mostly, the Go language community. Consensus is driven by its input, and all the local Go enthusiasts keep tabs on it like their current anime or TV show. There’s a collective process to decide, once and for all, the “officially sanctioned” way to go about something, and once the decision is made, it’s a done deal. If there is no consensus on the sort of problem you’re running into (for instance, modules before Go 1.11), then you’re expected to bring it up and drive the community to make a call. If they have made a decision and that doesn’t work for you, then you’re pretty much SOL. Expect the only solution to be “rework your codebase and methodology to fit the language’s preconceived ‘solution’.” If that’s not ass-first problem solving, I don’t know what is.
From a social standpoint, this has predictable outcomes. Most of the time Discord chats and IRC channels will be condescending towards you and question your work into oblivion, and then tell you you’re “doing it wrong” instead of answering your questions. With the language community core practically recognising nothing outside their personal awareness or jurisdiction, this makes Golang effectively useless the moment you step outside the farm gates.
This is an impossible cost for me, or really anybody with a schedule or time constraints at all, to bear for the privilege of using nice things like Goroutines or nifty slicing semantics. People with jobs, or folks who want to finish something some time this decade can’t afford to spend an indefinite amount of time negotiating and shilling for mindshare on whatever is troubling them, whenever that might come up. Corporations adopted LLVM, and not GNU, for this exact reason.
I may go in depth on why I find Golang’s presumption that it should tell me how to do my job not just personally abhorrent but socially and economically asinine in another post, probably not on this devlog. In any case, the decision was made to drop it.
The next big question of course is, now what? Golang is a no-Go, so what shall be used instead? Well, if you read to the end of my earlier post (linked above), you’ll see that the decision was made to use Scala. Keyword: was. Now I get to talk about why that didn’t pan out, as promised weeks ago on Twitter.
For Scala, I don’t have some savoury blameless exposé to account for why it was dropped, unlike Golang. What I did understand, though, is while Scala was not evangelical about its tooling or ecosystem, even as they offer a pretty universal build tool for getting things done, in reattempting my work with Scala I ran into a lot of technical problems trying to break out of SBT’s simplistic moulds. Going with pragmatism-to-a-fault was ill-fated just as it was with Golang. The reason was more understandable: complications brought about by the underlying JVM, and lack of resources around using Scala without SBT.
I’ve worked with Node for years, and I can use it comfortably with
npm and without, and with great conservation of dependencies.
times will be second only to Python scripting, which is what HALO really
needs. So this is where we are. Node is by no means perfect, and I could
enumerate a lot of complaints if I really had a reason to. At the end of
the day, its tooling and ecosystem are highly voluntary, I can follow the
language well, and I can work fast enough for my time frame to finish this
project by some measure this year.
If you follow my personal weblog, you might’ve noticed these “language trials” follow an ascension on the Three Tiers of Programming Languages. While I would still like to do something more in-depth later on, this post touches on the fundamental problems presented by Golang and similar ‘newfangled’ languages in a less topical sense. This is a class of problems that is certainly not unique to Golang, and it’s worth being aware of because of what it implies in work. If you like to focus on getting work done and leaving the politicking to the management, you might find similarities between the management and this very phenomenon. Thanks for reading!