This has been a year of Clojure (and DevOps). Since the beginning of the year, I have worked to persuade my team to adopt Clojure instead of (or rather in addition to) to the current mixture of Java and Groovy, argued to rewrite a key batch job in Clojure (thank you, Monica, for providing the business case!), and did all I could to spread Clojure knowledge and skill in the team and surroundings. It has been a success - the job has been rewritten, we have already benefited from it, and we are finishing a new, Clojure-based micro-service. I have learned a lot about Java vs. Clojure, about the value of business-level tests and "living documentation", about leveraging Spec and property-based testing, about core.async (and error handling). On the DevOps front, I have grown to really dislike Terraform (wishing repeatedly to have a proper programming language instead of the frustrating Terraform DSL and the hacks it requires, not mentioning the nightmare of upgrading providers and Tf itself; 🤞for CDK/cdk-clj), have spent more time then I ever wanted with Kubernetes (and am working hard on simplifying our infrastructure and replacing K8s with AWS Fargate and thus spending less time on operations and more on development), and fell more and more in love with Clojure REPL, whether embdded in a Java app, in an actual Clojure code, or opening the door (securely!) to a "serverless" container on Fargate.
Falling in love with Rust
dtrace.orgLet me preface this with an apology: this is a technology love story, and as such, it’s long, rambling, sentimental and personal. Also befitting a love story, it has a When Harry Met Sally feel to it, in that its origins are inauspicious… First encounters Over a decade ago, I worked on a technology to which a competitor paid the highest possible compliment: they tried to implement their own knockoff. Because this was done in the open (and because it is uniquely mesmerizing to watch one’s own work mimicked), I spent way too much time following their mailing list and tracking their progress (and yes, taking an especially shameful delight in their occasional feuds). On their team, there was one technologist who was clearly exceptionally capable – and I confess to being relieved when he chose to leave the team relatively early in the project’s life. This was all in 2005; for years for me, Rust was “that thing that Graydon disappeared to go work on.” From the description as I read it at the time, Graydon’s new project seemed outrageously ambitious – and I assumed that little would ever come of it, though certainly not for lack of ability or effort…
Originally published at the Telia Engineering BlogA month ago I have started learning Rust and would like to share my impressions, the good things I have appreciated, and the things I have struggled with. Why Rust, do you ask? Primarily to challenge myself, to leave the land of managed runtimes (Clojure, JavaScript) and to get as close to the metal as you can without assembly. Knowing a systems (&more) programming language is handy, for example for writing fast serverless functions and command-line utilities. Why not Go? For the same reasons why Clojure: it is more innovative, more mind-bending. Go is optimized, I understand, for approachability (and performance, of course) and is popular for writing web services - but it failed to capture the C/C developers at Google it was aimed at, I hear. Rust's focus is on performance and safety, the latter forcing it to take a really innovative approach to the issue of memory management. And some experienced C/C developers swear by it. So Rust already seemed more attractive to me and reading Bryan Cantrill’s Falling in love with Rust and Sylvain Wallez' Go: the Good, the Bad and the Ugly sealed the deal. From the former:Rust feels like a distillation of the best work that came before it.Platforms reflect their values, and I daresay the propagation operator is an embodiment of Rust’s: balancing elegance and expressiveness with robustness and performance.
When I was deciding what new language to learn, I could have picked the quite familiar Scala but chose instead Clojure - not despite of its lack of object-orientation, its immutable data structures, its too many parentheses on a single line - but because of it. (And because of Paul Graham’s Beating the Averages.) Why?!
Rust, not related to the video game also called Rust, is a promising systems programming language with novel features ideally suited for game development. Exposure and awareness within the game developer community, however, remains limited. In this post, I provide a gentle introduction to Rust and attempt to justify its place on your radar.
f5n.org - a personal website
Two years ago, I had a blog entry describing falling in love with Rust. Of course, a relationship with a technology is like any other relationship: as novelty and infatuation wears off, it can get on a longer term (and often more realistic and subdued) footing – or it can begin to fray. So well one might ask: how is Rust after the honeymoon? By way of answering that, I should note that about a year ago (and a year into my relationship with Rust) we started Oxide. On the one hand, the name was no accident – we saw Rust playing a large role in our future. But on the other, we hadn’t yet started to build in earnest, so it was really more pointed question than assertion: where might Rust fit in a stack that stretches from the bowels of firmware through a hypervisor and control plane and into the lofty heights of REST APIs?
My blog post on falling in love with Rust got quite a bit of attention – with many being surprised by what had surprised me as well: the high performance of my naive Rust versus my (putatively less naive?) C. However, others viewed it as irresponsible to report these performance differences, believing that these results would be blown out of proportion or worse. The concern is not entirely misplaced: system benchmarking is one of those areas where – in Jonathan Swift’s words from three centuries ago – “falsehood flies, and the truth comes limping after it.”