Essays on software development with a focus on quality and production engineering. Mostly.
Build systems are one of my favorite topics in software engineering. If I recall correctly, my interest in this area started when I got into NetBSD in 2002—20 years ago—and became a pkgsrc contributor. Packaging software for NetBSD made me fight various build systems and, in particular, experience the pains of debugging the GNU Autotools. Around that same time, I was also writing small tools here and there. Out of inertia, I used the GNU Autotools for these and, the more I used them, the more I saw an opportunity for improvement.
Rust is infamous for having a steep learning curve. The borrow checker, preferred idioms and design patterns, the meaning of core traits… these are all things one must learn before being proficient with the language. So, yes, Rust is hard, but does it matter in practical terms? Can we expect large-ish teams to succeed when adopting the language?
Earlier this week, a 2-year old post titled I want off Mr. Golang’s wild ride by @fasterthanlime made the news rounds again. This post raises a bunch of concerns on the Go language and is posted from the perspective of someone who prefers Rust. And, just yesterday, I noticed a comment on Twitter by @FiloSottile that, paraphrased, reads “Why is there so much hatred towards Go, especially from Rust developers?”. I wish I could answer this question with a “no, there isn’t”, but that would be a lie: in any large community, there will certainly be hateful people/opinions. If you have encountered such flamebait, I’m sorry, and I’m not here to defend it. What I’m here to do is look at the possible truth behind the claim that Rust developers dislike Go, and I wanted to elaborate on this based on my personal experience.
Dependency injection is one of my favorite design patterns to develop highly-testable and modular code. Unfortunately, applying this pattern by taking Rust traits as arguments to public functions has unintended consequences on the visibility of private symbols. Let’s look at why and what we can do about it.
Towards the end of 2021, I was playing with QB64 and thought that its default color scheme—called Super Dark Blue—was quite neat. It reminded me of QuickBASIC, which is what the whole program is supposed to do, but the colors felt vivid and modern. Take a look: QB64 with its default color configuration. “Naturally,” I wondered if I could adopt those colors in VSCode and Windows Terminal, as these are the apps I look at the most throughout a work day.
Over the last couple of weeks, I have been modernizing the codebase of the EndBASIC cloud service by applying many of the learnings I got from the development of EndTRACKER. The latter was a fork of the former and thus the foundations were the same, but as I iterated on the latter more recently, I got to refine my approach to writing a REST API in Rust. During this refactoring process, there was a small piece of the system that routinely got in the way for various reasons.
If you know what GAFYD stands for and have felt that signing up for a free account years ago was a mistake, you know you are in trouble right now. Those accounts are shutting down. The time has come to either pay up or move out, and you should decide what to do ASAP. It took me weeks of active effort to move my and my family’s data out of GAFYD and put it back into Google consumer accounts and other non-Google services.