Showing 11 posts
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.
The GNU project is the source of the Unix userland utilities used on most Linux distributions. Its compatibility with standards and other Unix systems, or lack thereof, directly impacts the overall portability of any piece of software developed from GNU/Linux installations. Unfortunately, the GNU userland does not closely adhere to standards, and its widespread usage causes little incompatibilities to creep into any software created on GNU/Linux systems. Read on for why this is a problem and the pitfalls you will encounter.
We have all seen discussions go like this: someone first complains that an application like Google Chrome is wasteful because it uses multiple GBs of memory. Someone else comes along and says that memory is there to be used for speed and therefore this is the correct behavior: if the computer has multiple GBs of free memory, an application such as Chrome should make use of all the available memory in the form of a cache to be as responsive as possible. Makes sense, right? Yes, it does makes sense—as long as Chrome is the only application running. Let’s explore why this is not a great idea.
A recent tweet that caught my attention read: “principal engineers should be on-call”. Of course they should be! I’m “surprised” they aren’t everywhere, but I can imagine some reasons to justify their situation. Let’s change that in this thread. 🧵 👇
A good philosophy to live by at work is to “always be quitting”. No, don’t be constantly thinking of leaving your job 😱. But act as if you might leave on short notice 😎. Counterintuitively, this will make you a better engineer and open up growth opportunities. A thread 👇.
Monorepos are an interesting beast. If mended properly, they enable a level of uniformity and code quality that is hard to achieve otherwise. If left unattended, however, they become unmanageable monsters of tangled dependencies, slow builds, and frustrating developer experiences. Whether you have a good or bad experience directly depends on the level of engineering support behind the monorepo. Simply put, monorepos require dedicated teams and tools to run nicely. In this post, I will look at how almost-perfect caching plays a key role in keeping build times manageable under such an environment.
During my 11 years at Google, I can confidently count the number of times I had to do a “clean build” with one hand: their build system is so robust that incremental builds always work. Phrases like “clean everything and try building from scratch” are unheard of. So… you can color me skeptical when someone says that incremental build problems are due to bugs in the build files and not due to a suboptimal build system. The answer lies in having a robust build system, and in this post I’ll examine the common causes behind incremental build breakages, what the build system can do to avoid them, and how Bazel accomplishes most of them.
If you have followed Windows 10 at all during the last few years, you know that the Windows Subsystem for Linux, or WSL for short, is the hot topic among developers. You can finally run your Linux tooling on Windows as a first class citizen, which means you no longer have to learn PowerShell or, god forbid, suffer through the ancient CMD.EXE console. Unfortunately, not everything is as rosy as it sounds.
The pkgsrc package database, which by default lives in /var/db/pkg/, should not be there. Instead, it should be under /usr/pkg/libdata/pkgdb/. The same applies to FreeBSD’s and OpenBSD’s ports and also Debian’s dpkg, but I’ll focus on pkgsrc because it’s the system I know best. Let’s see why the current default is suboptimal and why libdata is a good alternative.
The scripts that live under /etc/rc.d/ in FreeBSD, NetBSD, and OpenBSD are in the wrong place. They all should live in /libexec/rc.d/ because they are code, not configuration. Let’s look at the history of these systems to see how we got here, why this is problematic, and how things would look like in a better world.