Today was my first day at the Recurse Center (RC). I had so
much fun hearing about what awaits me over the next ~12 weeks and meeting a bunch
of new people, all of whom seem to be just about as excited as I am!
A lot of the discussions I had with folks revolved around what everyone was planning
to work on during the coming weeks. I've been curious about a handful of programming
topics recently so I have some initial ideas for things to explore:
- I've been working my way through Robert Nystrom's Crafting Interpreters
and I have a couple of ideas for different directions to take.
- Andy Pavlo is a great speaker and writer and I'd love to dive into some of the
course material he has put together on database systems.
- Andreas Kling is my go-to for relaxing
and satisfying YouTube viewing. It would be a blast to contribute to SerenityOS in some way.
There are also a bunch of reading groups and other interesting gatherings to attend.
I'll probably attend lots of stuff early in the batch and see what sticks.
Most of all, regardless of what I am working on, I want to make a real effort to
communicate about it. I'd love to improve my writing and communication skills
significantly over the next few months.
In the rest of this post, I'll dive into some of the things I've been thinking about.
Joy in Programming
I love programming. I get a deep sense of satisfaction watching a program that I've written
solve a problem. I also love the craft of programming. There are so many different ways
to solve problems with code. Which way is the most expressive? Which techniques help
reduce or eliminate bugs? I'm constantly thinking about these sorts of things
whether solving an Advent of Code problem or starting a design document at work.
Often when I've started conversations about the practice of programming at work,
I've received blank stares from many of my coworkers. This has been pretty discouraging.
From everything I've read and everything I've seen so far, RC is the kind of place
where these kinds of discussions are met with curiosity from the people around you.
Whether they are experts in a particular programming topic or looking to learn more.
The summer after I graduated, I attended the Oregon Programming Languages Summer School
(OPLSS). Everyone there was psyched to exchange ideas about programming
languages across the full spectrum from theory to practice.
That was the last time that I remember being surrounded by a group of people so
enthusiastic about the subject at hand.
I really enjoy programming as a career. But necessarily, programming and the
practice of programming is a means to an end in a business context.
There is a lot of satisfaction to be had in generating business value, but
sometimes the drive to produce impact can quell some natural curiosity.
There isn't always time to peek under the hood and learn about the different
systems and abstractions that we lean on to get our work done, every single day.
This is what I'm most excited about being at RC. To have the time and space to
explore those nooks and crannies and muse about it with a bunch of likeminded people.
High-level Programming Language Runtimes
A lot of my background in the programming language space comes from my undergraduate
curriculum. I loved the PL classes in school, but there was a heavy emphasis on
static type systems and theory in general. Reading and working through Crafting
Interpreters has been a blast. High-level dynamic languages were generally derided
the years has me convinced that dynamic languages have their place, though I still
generally prefer to have a powerful static type system.
I'm really fascinated by all of the efforts that have gone into creating absurdly
fast language runtimes over the last couple of decades. I'm hoping to do some reading
starting with the smalltalk and Self optimization papers of the 80s and 90s, working
my way through LuaJIT in the mid 2000s and V8 and pypy in the late 2000s.
Ideally, I'd be able to incorporate some of those ideas into a Lox interpreter,
but that might be overly ambitious. We'll see!
Somewhat unrelated, I've been running into an issue where a C++ implementation
of Lox that I've been working on runs ~100% slower than clox on a simple
for loop example. Most of the time seems to be spent in
Not totally sure what's going on, but it'd be fun to dive deeper and do a write up.
Protohackers, Rust and Python
Since I wasn't sure how much time I would have amidst the orientation events,
this week, I've lined up some bite-sized tasks to tackle.
I started working on protohackers at the end of
August. I had started in Rust which has been a ton of fun. When I reached
problem 6 (Speed Daemon), I stalled a little bit as there was more synchronization
required than the previous problems. I made a couple of adjustments with the hope
that I might be able to make more sustainable progress:
DO to fly
DigitalOcean is great. It's super simple to spin up a tiny VM, ssh into it, grab
the latest copy of my code and run my program. I've been curious to get better
familiarized with fly.io and similar hosting providers.
For the most part, deploying via a Dockerfile
is pretty straightforward. I encountered two issues:
- I couldn't get UDP to work; protohackers problem 4 specifies a key-value store
accessed over UDP. I tried following the fly.io guide on UDP
but gave up before getting anything to work.
- The default concurrency settings caused my service to reject some connections when testing
my solution. The auto-generated
fly.toml file I was using included this snippet:
type = "connections"
hard_limit = 25
soft_limit = 20
For a while, I thought I had a logic error in my program that was causing me to
close connections before I found a log entry from the proxy layer that indicated the
concurrent connections were being limited. Eliminating the snippet from
no effect, but replacing those lines with:
type = "connections"
hard_limit = 150
soft_limit = 100
seemed to fix the issues.
Overall, fly.io is really pleasant to use. I don't have a lot of experience
using Heroku which seems to be the main comparison for fly. But the ability
to launch a service anywhere in the world from my command line is pretty neat.
It's still quite a bit faster to iterate over ssh, but I'm hoping I can find
ways to optimize my workflow.
Rust to Python
I'm pretty much head-over-heels for Rust. It's a really satisfying combination
of ideas from ML
That being said, there is a lot to think about when dealing with concurrency
in Rust. Sometimes you need to wrap something in
Arc<Mutex<...>> to provide
mutable access to some shared state across threads. Tokio is
fantastic, but you still need to think about multi-threading and synchronization.
asyncio offers a programming model that is conceptually similar to
Rust's asynchronous runtimes but without the need for synchronization (since programs
asyncio run the event loop in a single thread).
It took me a surprisingly long time to get an implementation working in python.
I don't have a ton of experience dealing with binary encodings in python, so that
took some adjustment. On the
asyncio side of things, it took me a while to figure out
that I might want to use
for the implementation of reading a single message from a client. In general,
I think I have an easier time discovering python documentation but an easier time
reading Rust documentation once I've found it.
I also made the embarassing mistake of forgetting to explicitly set
print debugging. I spent far too long trying to figure out why my service
didn't seem to start.
All-in-all, it was really satisfying to watch the last test case pass and I'm
excited to keep working on the rest of the problems that I haven't solved yet.
Maybe I'll find a chance to do a writeup on solving the problems in python and
Rust at some point during my batch.
I love reading programming language books and I had seen lots of recommendations
I am currently reading Chapter 16 which discusses the implementation of a small
platformer using the DOM for rendering the game world. The book is great. I really
enjoy the general style (a practical mix of functional and imperative) that Marijn
uses in his examples. He also uses a lot of closures, which I think are the most
powerful and expressive feature of high-level garbage collected languages.
But so far, the most interesting bits from the book have been general software
engineering concepts. Chapter 10 discussing modules opens with this gem:
A typical real program grows organically. New pieces of functionality are added
as new needs come up. Structuring--and preserving structure--is additional work.
It's work that will pay off only in the future, the next time someone works
on the program. So it is tempting to neglect it and allow the parts of the program
to become deeply entangled.
Marijn continues describing the issues of this sort of "entaglement". I thought
it was a really empathetic way of describing how some programs accrue technical
On the other side of the coin, there is a section in chapter 16 labeled
"Encapsulation as a Burden". Marijn discusses the tradeoffs involved when choosing
where to introduce abstraction in your programs. This
is a subtle topic that takes a lot of experience to master (I certainly haven't mastered
it yet). But Marijn makes convincing arguments and plants the seed in the reader's
Overall, it's been a great read so far! I'm excited to finish it up and maybe
If you've made it this far, thanks for reading! Stay tuned to hear more about my experience at RC.