Essays on software development with a focus on quality and production engineering. Mostly.
In the recent Remembering Buildtool post, I described how setting up a cache of configuration checks was an important step in Buildtool’s installation process. The goal was to avoid pointless repetitive work on every build by performing such common checks once. Episode 457 of BSD Now featured my post and Allan Jude wondered how much time would be saved in a bulk build of all FreeBSD packages if we could just do that same kind of caching with GNU Autoconf. And, you know what? It is indeed possible to do so. I had mentioned it en passing in my post but I guess I wasn’t clear enough, so let’s elaborate!
It is with great pleasure that I announce the release of EndBASIC 0.9.0 😎️. The major feature in this new release is the ability to launch publicly-shared files via a click of a URL without having to create an account first. Here, try running my jmmv/bounce.bas or jmmv/paint.bas demos in your browser, now!
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 and able to write code with ease. So, yes, Rust is hard, but does it matter in practical terms? Can we expect large-ish teams to succeed when adopting the language? I’d like to think that it does not matter much and that some initial difficulties in bringing people up to speed can pay off in the medium term.
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. If you are not careful, most of your crate-internal APIs might need to become public just because you needed to parameterize a function with a trait. Let’s look at why this happens 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.