Programming for enjoyment is wildly different than most programming for work, as the two are motivated by different desires. For work, the primary goal is usually to ship something quickly that helps the business goals with least expenditure. For enjoyment, my goal is to learn as much as possible, and tackle problems that are rich with technical challenges (e.g. devising an algorithm) rather than simply labor (e.g. converting the front-end from UI Framework v2019 to UI Framework v2020).
For hobby work, I most enjoy starting with a minimal base, and building everything that sits atop it. This exposes me to many interesting parts that would otherwise be hidden in a dependency. It also ensures every piece fits together easily, as they're all built on the same set of assumptions and goals. Lastly, it makes development enjoyable, as each piece is perfectly constrained to just what's needed; there are no multi-million line frameworks to dig through, no interop into other languages, and no complex builds inherited from dependencies that try to suit every possible use case.
Although this style of programming isn't great for the business world, it does make a programmer better at the business style of programming. When it comes time to pick a dependency, it's much easier to choose wisely when you already understand what it needs to do inside, and what tradeoffs the developer had to choose from. When you need to debug complex interactions, it's much easier when you're already familiar with the protocols involved and how they behave.
All of this is a long way to say: when I pick up a new language, I usually start by building up an environment of libraries that free me from taking dependencies later. I also find this a nice way to focus on learning the language, rather than trying to learn a language while also solving a new problem. Today, that new language is Rust. The next bunch of posts will center around these libraries as I bring up each one.