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
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.tomlfile I was using included this snippet:
[services.concurrency] 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:
[services.concurrency] 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 and C++.
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
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 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 debt.
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 mind.
If you've made it this far, thanks for reading! Stay tuned to hear more about my experience at RC.