From Golang to Scala to Node: Tech choices of HALO

Penned on the 30th day of June, 2019. It was Sunday.

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.

At the same time, eventually I came to realise that Scala presented a lot of nuance in its expression that I could not deal with in a timely fashion. I don’t have a background in functional programming, despite my appreication for it in experimenting with Haskell and avoiding OOP every day with JavaScript. I had to face up and realise that Scala may be better approached at a later point in the project, to get the state-of-the-art scalability and performance it promises when we really need it. I need to have an alpha released this year, in 2019, first and foremost. Much like my limits in game programming when it comes to hardware-accelerated graphics, I had to know my limits and accept them for the sake of seeing the project through. This left one natural choice for me: Node.js.

I’ve worked with Node for years, and I can use it comfortably with npm and without, and with great conservation of dependencies. I’m as proficient in JavaScript as I am in C, and I know my iteration 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!