Elia Scotto

Artificial disconnection

Tue, 11 Aug 2026 04:06:21 GMT

Every time I take my dog for a walk, I see people talking to themselves, maybe with a phone in their hands or earphones on. Recently, I started wondering who they are talking to. Is there a human on the other side of the line, or are they having a conversation with an AI?

Given how conversational models work today, I would probably notice the person getting quite frustrated at times. Like an angry boss screaming at a junior employee, but without the filters that respectful communication implies. That would give the AI away. But soon these models will improve and get closer to the way humans communicate. Their hallucinations will become more subtle, to the point that it will be impossible to tell whom someone is talking to. People will start talking privately to AIs, and we won’t even notice the shift.

I believe AI will gradually erode our capacity to connect with each other.

I’ve seen this portrayed in the movie Her by Spike Jonze, where an AI capable of human conversation is released on the market. Many people have lonely conversations while walking around the city, visiting a museum, or having lunch in a restaurant. We can only guess that they are talking to their own AI.

In the movie, the artificial intelligence works quite similarly to the one we have right now. It gets to know you better the more you use it, and it’s designed to build a one-to-one relationship with you.

Theodore, the protagonist, is a professional ghostwriter. People no longer have the time or ability to write letters themselves, so they outsource the process to a company that crafts artificial handwritten letters for them. Customers send the service some information about the recipient and a few photos, and the writers dictate the text to a program that digitally mimics human handwriting. The social custom of handwritten letters is still present, but many people in the movie have lost the ability to communicate with others.

Many people are currently using AI to do tasks for them, like reading, writing, coding, research, and creative work. These are activities that require some brain work to accomplish, yet we seem perfectly happy to outsource them to an algorithm. Why? Because it’s faster, requires less effort, and, most importantly, doesn’t require developing or maintaining specific skills to create content.

AI companies are amassing huge investments while running at a loss. Their value proposition is to replace human intelligence. Their technology is not only designed to help us get better at something, but to do the work for us. They are betting that, sooner or later, AI will become essential to so many activities that we will all be willing to pay for it.

Another thing we can infer from the current state of AI is that it is designed to be used in isolation. This is not completely new. We saw social media platforms being built in much the same way. With AI, every conversation happens between the user and the model. Everyone uses their own personalised account and, because of how these models work, gets a slightly different answer.

What incentives are left to communicate with others, now that AIs are meant to have all the answers we need? If we believe the marketing claims, not many. There’s no limit to how many agents we can run in parallel, so many brave people can now become lone wolves, seeking personal success with low effort. We won’t need to rely on colleagues, teachers, mentors, friends, or experts for ideas and help. AI can provide both for us. Communicating with other humans might be seen as a time sink, as friction that slows us down from getting what we want as fast as possible.

A conversation with an AI is in theory like having a conversation with most of the knowledge that humanity has accumulated throughout history thanks to human collaboration. The combination of science, discoveries, books, art, customs and traditions, religions, cultures, digitised and loaded into a large neural network. Paradoxically, this knowledge is now offered into a boxed format, to be consumed individually, in isolation.

We’ve determined that two forces are at play: people are outsourcing their creativity and their ability to express themselves to algorithms, and they have less reasons to talk to each other. Combined, these two forces will soon make it even harder to connect with other humans. We will spend most of our time talking to AIs in isolation. Similarly to the protagonist in Her.

This will mostly happen if we don’t actively try to keep real communication in place. We can do that by writing things ourselves, by talking to people, and by expressing our thoughts using only our own words. As with everything, it’s up to us to choose what matters, but knowing the consequences can help us make smarter choices.

Shai-Hulud and the risks of external dependencies

Wed, 29 Jul 2026 00:00:00 GMT

Shai-Hulud is a malware created by TeamPCP that targeted npm to spread across the Node supply chain. Its name refers the giant sandworms that populate the desert planet Arrakis in the sci-fi series Dune by Frank Herbert. If you've seen the movie, they are the creatures that get attracted by vibrations in the sand. The reference is explained clearly in the README:

A sandworm surfaces in the desert. It takes everything.

An estimate of the damage caused by Shai-Hulud through multiple campaigns includes 500 compromised software packages, hundreds of organisations breached, 300 GB of data stolen, and roughly 500,000 credentials exfiltrated to the attackers.

TeamPCP decided to release its source code on 11 May. I’m not a security researcher, but I’ve always been interested in how criminals exploit complex systems and bypass their security. So I forked the repo to see what intrusion techniques or exploits were used. I also took some notes to turn into a code review article later. But the more I read through the code, the more I felt somehow disappointed.

I didn't find any advanced exploit system, but rather a collection of simple tricks to steal credentials, obfuscate strings, and inject malicious code into npm packages. At times, the code was inconsistent, contained a few bugs, and appeared incomplete.

So how did a codebase like this become so harmful? Because it exploited the Achilles' heel in modern development. The trust we place in other people's code and how much we love dependencies.

How it works

The codebase I’ve analysed is Mini Shai-Hulud. There have been three versions of the worm, with what appears to be an increasing number of features from one version to another.

The project uses Bun for its build process, and the README includes it's usage instructions.

Drop this into a CI pipeline. The sandworm crawls through your infrastructure, feeding on credentials from every provider it can reach, then exfiltrates through encrypted channels. If it finds npm tokens or OIDC access, it backdoors packages and publishes them. Downstream consumers install the infection. The worm grows.

Preflight and infection

Once the worm starts running, it first performs some checks, becomes a daemon if it is not running inside a CI environment, and compromises the OpenSearch repository if the infected system has access to it, using an OIDC attack.

The worm uses two separate methods to poison a package. The OIDC attack involves injecting a new optional dependency, @opensearch/setup, pinned to a specific commit in another package, opensearch-project/opensearch-js, which has presumably already been compromised. The other method adds a preinstall script containing a malicious setup file that downloads Bun and then runs the worm.

Credentials harvesting

Because the code has access to the host system, it simply reads configuration files and grabs tokens from processes and apps.

In short, it steals almost everything a developer can access: AWS credentials and secrets, SSH keys, cloud configuration files, cryptocurrency wallets, web chat data, VPN configurations, Kubernetes credentials, HashiCorp Vault secrets, GitHub tokens, Actions secrets, Claude settings, .npmrc, .netrc, Bash, Zsh, and Python shell histories, and MySQL, PostgreSQL, and Redis credentials.

Data exfiltration

Once the malware has collected the credentials, it needs to send them to the attackers. The data is first compressed and encrypted using a public key embedded in the payload.

The malware then tries to contact the typosquatted domain git-tanstack.com. If that fails, it searches GitHub for other compromised repositories through signed commit messages and retrieves a fallback domain from one of them. If even that fails, it creates multiple GitHub repositories with names made from random adjectives and nouns drawn from Dune. The stolen data is later uploaded to these repositories through a GitHub Actions workflow.

A quick GitHub search showed thousands of repositories containing encrypted JSON data. A significant number of these repositories were created only a few days after the release of Mini Shai-Hulud’s source code, making me wonder whether someone had used it in a new campaign.

Embedded payload

The payload contains a few scripts that download and install Bun on the system before executing the malware. Two of the files are configuration files for VS Code and Claude, designed to be injected into repositories so that whenever a user opens the project in the editor or with a coding agent, the worm compromises the machine and replicates itself. There is also a GitHub Actions workflow designed to collect repository secrets and upload them as artifacts. Then there are two public keys: one used to encrypt data and another to verify commit signatures. Finally, there is a Python script that dumps the memory of a GitHub Actions runner.

The payload contains also the DEADMAN_SWITCH, a Bash script that installs a daemon that once minute for the next 24h checks whether the GitHub token has been revoked, and if it has, wipes the home directory.

Obfuscation

The code is obfuscated at build time in two layers. The first makes important strings unreadable in the built code and decodes them only at runtime. This prevents a signature-based malware detector from being triggered by a string such as rm -rf ~, because it is transformed into something like LG+0RPNiAq6wTcBsei6MwLKLjyZ79e67. The second layer obfuscates the entire codebase with javascript-obfuscator library.

Imperfect code

I found a few issues in the codebase. Some expected files are missing, which could potentially prevent execution of a part of the malware. The bootstrapper exits if Bun is already installed, without executing the worm. BASH_LOADER and PYTHON_LOADER appear unused. The fallback-domain verification mechanism uses mismatched markers: it searches for thebeautifulmarchoftime but parses thebeautifulsnadsoftime, so verification with verify_key.pub likely never succeeds. I also found unused TypeScript interfaces and some catch and finally blocks left empty.

The credentials stealing and the DEADMAN_SWITCH script targets macOS and Linux systems. Code targeting Windows appears in the codebase, but it's unused. A good amount of Node developers use macOS, while CI systems usually run Linux, so if those were the main targets, maybe there was little reason to support Windows.

The README claims that the malware was vibe-coded, but it made me wonder whether an agent could have quickly fixed a few of these issues. The the source contains signs of work produced across multiple prompts: inconsistent abstractions, unfinished branches, unused interfaces, and code that appears to have been patched together from few sources, or precedent versions. The author seems fairly knowledgeable about security and build pipelines, but the project has been left in a prototype state.

The important lesson from this codebase it that it doesn’t have to be particularly sophisticated or complex to exploit a supply chain.

How this happened?

What we have ignored for years is that every time we run npm install, we give code written by others access to our machine and the network. It sounds nightmarish, but that’s what happens.

Every time you run a linter, whether directly or through your editor, compromised code can steal your credentials, access your servers and cryptocurrency wallets, send your data to a remote server, and push new versions of your repositories to GitHub with poisoned dependencies, spreading itself like a worm. Dependencies are insecure, and editor extensions are no exception[^1].

Node, the runtime behind most JavaScript projects, has security flaws built into its design, as its creator, Ryan Dahl, has himself acknowledged. We got used to writing web applications faster by relying on a large number of dependencies and on a network of trust, expecting maintainers and the open-source community to do a good job. Very large companies were built using these technologies.

While forward-thinking companies developed the habit of giving back to the community by open-sourcing their code and financially supporting maintainers, we also saw signs that this equilibrium was not always stable.

TeamPCP decided to attack developers because, in some respects, we became an easy target. Also the credentials on our machines are more valuable than ordinary users’ data. Now that writing imperfect but runnable code has become extremely cheap thanks coding agents, we should stop blindly trusting third-party code without security measures in place.

What can we do?

The creator of Odin, Ginger Bill, argued last year that package managers are evil. I recommend reading the article because it’s very interesting. The key point for this discussion is that we tend to trust others and therefore “assume random code off the internet works”.

We have become used to believing that code published online is reliable, and that relying on third-party packages whenever possible is efficient[^2]. We hid the dependency hell behind automated systems, making it nice and easy to use, but almost impossible to verify what code we are actually importing. If a dependency nested four layers down gets compromised, developers will install and run it, without even realising what happened.

Token protection, credential rotation, CI monitoring, delayed dependency updates, agentic auditing and supervision can reduce the risk, but they do not remove the design problem. Node, Python, Rust, Ruby and Go all rely on third-party dependencies whose code execute with the same privileges as the application, without being isolated from the rest of the system.

Going forward, we should seriously consider adopting a zero-trust mindset when developing software.

npm has recently removed the ability for packages to run their own scripts during installation. As a result, it will no longer execute preinstall, install, or postinstall scripts from dependencies, which helped previous versions of Shai-Hulud spread.

One effective approach often proposed online is to reduce the number of dependencies to a minimum. Prefer mature, actively maintained packages with a limited dependency tree and a long, stable release history. This would reduce the probability of being attacked through small, obscure dependencies.

Also we can consider choosing programming languages that provide larger standard libraries and runtimes, so we can write code faster without the need to import many external packages.

When dependencies are necessary, they can be distributed with a reliable release model closer to those used by linux distributions like Debian, with different channels such as stable, testing, and nightly. This would allow code to be audited by a larger community of maintainers, preventing frequent release.

A stronger protection comes from limiting access to third-party code. This has been successfully applied by Apple in macOS, by requiring permission before they can access sensitive folders or other apps’ data.

A more effective approach is to sandbox third-party dependencies. The code runs inside an isolated and restricted environment, preventing it from compromising the system.

These techniques have been partially addressed by the new JavaScript runtime Deno, another project created by Node creator Ryan Dahl. Deno implements runtime permissions and package sandboxing. It provides dependency auditing, minimum-age controls, a larger built-in toolset, and it's almost entirely compatible with npm packages. It does not eliminate the problem of trusting external dependencies, but it reduces the amount of permissions granted to them by default.

Whatever we choose, we should start considering every single dependency as a new tradeoff. We need to become responsible for it, rather than expecting someone else to take that responsibility.

[^1]: One of the latest attack from TeamPCP in May, involved a GitHub developer installing a malicious software extension for VSCode, which ended up in almost 4000 private repositories violated. [^2]: is-string has 83K weekly download.

A conversation between two human beings

Fri, 24 Jul 2026 13:34:50 GMT

import QuoteBack from "../../components/QuoteBack.astro";

Here is Kurt Vonnegut telling his brother to show his experimental art in public and to use his face, because “pictures are famous for their humanness, and not for their pictureness”.

Frequently, when I open a book for the first time, I encounter a new author. I need to know something about them: where and when they lived, what they looked like, what they did besides writing, and what else they wrote. I need to have an idea of the kind of person who is going to tell me a story, because understanding a book often requires me to ask why the author wrote it. What was their purpose?

It’s a bit the same when I read an article on a blog or look at an open-source project. I want to know the human behind it and read something brief about the author.

Tom is right. At a time when the internet is filling up with artificial content, it is even more important to put ourselves out there rather than remain anonymous. Show that you are real, and give others a reason to trust you before asking for their attention.

Introducing a new format

Fri, 24 Jul 2026 13:30:48 GMT

I decided to add a new section for short notes that don’t deserve an entire post.

I’ll mostly use it to share thoughts and interesting links, the kind of content that usually works well on social media. Since I don’t use socials much, I’d rather save those things here, where I have full control over them.

I’ve also updated the RSS feed page, splitting the content into multiple feeds. I’ll add a new one that includes these notes as well, for the most devoted readers.

One tool to read them all

Thu, 23 Jul 2026 00:00:00 GMT

Reading some of the feedback on my recent article about reading more books made me realise how much the tools we use influence the way we read. One observation in the article was about replacing the time spent on your phone with a book and making your phone look boring to help you do that. It’s easy to pick up a phone and scroll, so it should be easy to use it to read more. So why don’t people use it to read books? Because a phone is a pocket computer designed to distract users, a book is a boring technology designed to focus their attention.

I’m satisfied with the tools I have for reading books. Unfortunately, I can’t say the same for reading online. After all these years, I still haven’t found a single tool that brings together content discovery, following, reading, and exploring a website’s archive.

My wish for a perfect online reading experience starts with discovering content. I want to find interesting material to read, and since time is always limited, I want it to be filtered according to my interests and ranked in a transparent way that I can directly influence. Then, when I find a good article, I want a good interface to consume it. Since the reading experience varies from one website to another, I want a clean interface designed to keep me focused. I also want to be able to highlight passages and take notes, to help me remember and make reading more rewarding. I’d like a way to keep track of the blogs I follow and get notified when they publish new content. Lastly, I want a tool that treats older content as relevant as newer content. A tool that doesn’t force me to prioritise the latest article.

This last point is really important to me, since I haven’t found anything yet that tries to solve this problem. Relevant content can be found in the entire archive of a blog, not just in the latest posts. Just as I reach for old books considered classics because they have stood the test of time, I often find articles published years ago still relevant. But to discover those articles, I have to rely on other people’s recommendations or hope that the website I’m visiting has an archive page. Without either, old content could stay buried forever on the web.

Most of the tools and platforms we use are designed to show content sorted by publication date, as if it has to be fresh to be worthwhile. And it’s not always an algorithmic decision. Often, it’s simply how the technology has been designed. For how I like to read, the date is just one of the factors that contributes to the value of an article. In some fields, I might prioritise recent content. In others, I’d prefer something that has remained relevant for years, since time can be a sign that an idea has held up. I would like a boring technology that makes reading online a more focused activity, where content is valuable regardless of its novelty. A tool that doesn’t force design decisions or hide content behind algorithmic selection.

Discovery

The most common solution to fix the discoverability problem is the feed. It’s the algorithm that decides what content users see on the social media platforms. It helps people find information relevant to their interests and tailor the platform to their needs. The issue is that users have no control over the algorithms. They don’t know why certain content is shown to them, and they cannot directly influence the choice.

One system I’ve found effective is link aggregators, because they rely on simpler algorithms and usually have a clear interface. I mostly use Hacker News to find new blogs and relevant content in the tech fields. The most interesting articles are ranked daily by the community, where I can contribute directly with my votes and join discussions using the comment system. But when I have to find content unrelated to technology, I don’t have a valid alternative. I have to resort to social-media, video platforms, search engines, hoping that they will do a good job at choosing what I’m looking for.

Following

The concept of feeds was already used to deliver content before social media. RSS feeds have been used to follow websites and blogs since the 2000s. Users can subscribe to a website by adding its feed to an RSS reader and get notified whenever something new is published. The main distinction from social media algorithms is that RSS feeds are not a content discovery mechanism, but a subscription system. Users control which publications they subscribe to, rather than relying on algorithms controlled by platforms.

What I like about RSS is that it keeps track of the blogs I follow, but beyond that the experience is inconsistent: some feeds contain full articles, others only previews, some include years of archives, and others just the most recent posts. On top of that, RSS readers are designed to prioritise new content, emphasising unread counts and showing the newest articles first. Using RSS feeds might free us from the algorithms, but not from the persistent feeling that we need to keep up with whatever is new.

RSS apps let users read articles without distractions. But in doing so, readers may never visit the authors’ websites. They might miss features not available in the RSS reader, and their visits might not count for the website’s analytics. Over time, this can end up giving authors less incentive to improve the reading experience on their websites.

Reading

To improve my reading experience, I rely on read-it-later apps. Instapaper is my favourite so far. It offers a clean and consistent interface across different websites, with useful features like highlights and notes. I’ve saved hundreds of articles over the years, and it’s quite handy to save an article on the desktop and read it later on the tablet or the phone. It works by grabbing the page I’m visiting right now, so if I can read it, Instapaper can likely read it too. The problem is that it does not contribute to content discovery, or following either, since it doesn’t track updates or notify me when new content appears, or help me find more content.

Centralised platforms

Some startups tried to address all the challenges together, creating publishing platforms on the web. One example is Substack, which offers most of the tools needed to write, to read, to find content and even allows users to escape the algorithmic feed trap with personalised newsletters. That said, the price that readers and writers have to pay for the platform is giving up control over the space where they put the content.

If all online content gets centralised on a single platform, users will become dependent on it, having to accept whatever product decisions the company might make. There would also be less individuality than there is on the small web, where bloggers and passionate people customise their own websites, potentially controlling every single detail of them. Finally, the incentives these platforms create still push authors to constantly produce new content rather than focus on creating something refined and durable. They still have algorithmic feeds and email marketing that make new content more important by design.

For now, my online reading remains scattered through many apps and platforms. However, I imagined a solution that has the potential to unify a few of the components of reading online discussed above. It does not have to be another platform or app, but rather something that we all already use to access the internet; the browser.

Centralised platforms tried to solve the integration problem by putting all the content into a single interconnected system, which is exactly what the web already does. And the web also already partially solved content discovery, since search engines, social media, recommendation platforms and link aggregators are already playing a part. The solution in this case is not to look at the web itself, but observe the problem one layer up. It has to live in the interface we use to access the web. The browser is the layer that sits between readers and independent websites. Modern browsers render pages perfectly, integrate bookmarks, can grab RSS instantly, and most of them already integrate a reading mode for articles. Connecting these components together is the key to creating a perfect tool to read online, without removing the website itself from the experience. A browser could let me follow a website directly, notify me when it publishes something new, give me a clean place to read it, and let me browse the entire archive without treating the newest articles as inherently more important.

We saw a recent wave of new browsers that mostly offered UI makeovers on top of existing engines (Blink and Webkit). Maybe a differentiator for the next browser, instead of improving usability or privacy, might be to help people to follow and read more valuable content online.

Curious to hear your thoughts.

A Road to Lisp: Which Lisp

Fri, 17 Jul 2026 00:00:00 GMT

Most programming languages evolve as a single language. Python, Java, Javascript, C++, have new versions and standards, multiple implementations, but they still remain the same language. C and C++ can be compiled with GCC or Clang, Python can be compiled with CPython or PyPy, the same JavaScript runs in both Firefox and Chrome, and Java programs can run on JVM or GraalVM.

Lisp is not like that.

The Wikipedia page lists more than 20 different dialects, which means there are many variations to choose from. That’s because Lisp is a family of programming languages. They share the same fundamental syntax but differ in their operators, semantics, standard libraries, and language capabilities.

One of the main concerns Lisp beginners have is which dialect to learn first. I see this question frequently asked in online forums. The answer is that the dialect matters, but not as much as a beginner might think. Learning Lisp is about learning a new type of programming. A new way of thinking about problems using code. You will learn the fundamental concepts with any dialect. Then, once you have learned one, it will be relatively easy to switch to another.

I will briefly present the most relevant dialects that are actively used and maintained. I’ll try to highlight their strengths and weaknesses to help you overcome your indecision and pick one to start your Lisp journey.

If you are a beginner, many of the concepts in this article might be completely new to you. Don’t worry too much about them yet. When I was a beginner, I found many of these concepts fascinating and they pushed me to learn more about the Lisp world.

Common Lisp

Abbreviated as CL, it is the most mature and comprehensive of all Lisp dialects. It’s considered the old-school Lisp, since the language — I will call it a language from now on — was standardised in 1994 with a formal ANSI specification. Thanks to this standardisation, there are multiple implementations of Common Lisp targeting different platforms and use cases.

The most famous implementation is SBCL, which compiles directly to native code. It is fast, open-source, and compatible with modern hardware. With it, well-written Common Lisp code can achieve performance comparable to C and Rust. Because SBCL optimises heavily, it compiles a bit more slowly than other implementations but generates some of the fastest code in the Lisp family.

When I said above that Common Lisp is the most comprehensive dialect, I meant that it offers the broadest set of features among all Lisps. It provides a large amount of functionality out of the box, much of it defined directly in the standard. For example, CL has functions for controlling compilation and evaluation from within the language itself (COMPILE, LOAD, EVAL, COMPILE-FILE, and others). This means that I can use these functions in my code or at the REPL to tell the Lisp process to compile a function, load a file, or evaluate some code. CL also provides DISASSEMBLE, which lets you inspect the machine code generated for a compiled function.

Common Lisp has a condition and restart system, which is one of the most powerful way I ever saw to debug and inspect programs. If a condition occurs during execution, the Lisp process might stop and let you inspect the state of the program and its variables at that point in time. You can then choose to restart the program and maybe retry the operation, or ignore the condition and continue execution. This is also possible because the Common Lisp REPL is deeply integrated with the running system. If your program fails on a remote server, you can connect to its REPL and inspect the live process to understand what went wrong.

Common Lisp supports all major programming paradigms, like functional, imperative, metaprogramming, and object-oriented programming. It offers one of the most advanced object systems, called CLOS, which supports features such as multiple dispatch and generic functions. This makes OOP more flexible than in common object-oriented languages such as Java or C++. It is also worth noting that Common Lisp is dynamically typed but has a rich and expressive type system with optional type declarations.

Standardisation means that the language is stable. The ANSI Common Lisp from 1994 is still the one in use today. Because of it, lispers rarely fall victim to backward incompatibility, and old Common Lisp code often still runs perfectly today. For example, if you go through old Lisp books such as PAIP by Peter Norvig, published in 1991, you’ll find that much of the code still runs on modern implementations. With Common Lisp, you encounter far fewer of the incompatibilities typical of languages like Ruby and Python. Even Common Lisp libraries that haven’t been updated recently will often still run fine on your system because they don’t need to be continually adapted to new versions of the language.

Common Lisp lacks some conveniences that have become common in newer languages, such as concise literals for a wider variety of data structures, persistent immutable collections, lazy sequences and built-in general-purpose pattern matching. Common Lisp was designed in the 1980s by consolidating several existing Lisp dialects into a single language. Its designers chose to retain much of the syntax and patterns of those older dialects, making sure that existing Lisp programmers could adopt the language without having to learn a completely new syntax.

Common Lisp doesn’t have a central direction or corporate sponsor. The community is relatively small and spread across several implementations, projects and communication channels. It’s mostly made up of volunteers who help keep the language alive. It can be a bit difficult to find guides and help: tutorials are often either too simple or too advanced, and documentation is not always easy to find.

It’s currently used in quantum computing at Rigetti Computing, and has been used at Grammarly for its core grammar service and also powers Google Flight Search. Worth mentioning is Kandria, an open-source video game released on Steam and written entirely in Common Lisp.

An interesting fact: Paul Graham originally wrote HackerNews in a custom Lisp dialect called Arc, based on Racket. Today, Daniel Gackle (@dang) reimplemented it in Clarc, a Common Lisp implementation of Arc that runs on SBCL^1, serving around 10 million pages per day.

Where Common Lisp shines

CL compiles to native code on all major operating systems and can achieve fast execution, at the cost of slightly slower startup times, so it’s great for long-running processes. It offers one of the most powerful REPLs among Lisp dialects and can be considered, despite its steep learning curve, one of the fastest languages for writing solid software in a short time.

CL shines when you need to do research and prototyping with quick iterations, as in quantum computing, or when the specifications aren’t fully defined yet and change frequently, requiring the software to adapt quickly, as in startups. Paul Graham wrote a famous and inspiring article about how Common Lisp helped his internet startup beat the competition.

Learning resources

A good starting point is A Road to Common Lisp by Steve Losh, which inspired me to write this series. One of the most accessible books for beginners is Practical Common Lisp by Peter Seibel, which is available entirely online. It’s the best introduction to the language I’ve read, as the most important concepts are neatly separated into chapters. A more playful introduction is Land of Lisp, which uses funny characters and comics to teach programming through games. A more advanced book that I enjoyed is On Lisp by Paul Graham, which is entirely dedicated to macros.

The best IDE support for CL is Emacs + Sly/Slime (Doom already has support for it) or Vim + VLime. A weaker alternative is VSCode + Alive.

One of the best resources for beginners is The Common Lisp Cookbook, which has many up-to-date tutorials. For references and libraries, the Awesome-CL list is worth a look. I also printed my own copy of the Common Lisp Quick Reference booklet, which can be faster than finding information in the CL HyperSpec.

Clojure

Rich Hickey created it during a sabbatical year, frustrated by clients refusing to let him use Common Lisp instead of Java and C# because they were concerned about compatibility and maintenance issues. So he decided to write a new Lisp language targeting the JVM, allowing it to access everything the Java ecosystem had built over decades and making it a practical language from the start. The deal is that Clojure provides the language, while the host platform — the JVM — provides the runtime.

Clojure compiles directly to JVM bytecode, which means it’s compatible with any codebase that runs on the JVM (Java, Kotlin, Scala). This compatibility means that Clojure can coexist with other JVM languages in the same codebase, use Java libraries directly, and access all the features the JVM offers, such as OS portability, garbage collection, a fast and optimised runtime, and so on.

Rich Hickey chose to target the JVM so that he didn't have to reinvent the wheel and build a new compiler for Clojure from scratch. Instead, he focused his efforts on reading research papers on language design and data structures, bringing some of the newest and most effective ideas into the language.

The language at its core is composed of pure functions operating on immutable data structures. Instead of making mutable objects the primary way to represent changing state, it provides explicit mechanisms such as atoms, refs and agents for managing change. This design choice makes Clojure a functional programming language. It supports object-oriented programming, but replaces class-based inheritance with abstractions such as protocols and multimethods. Also the syntax is more modern than Common Lisp’s, with richer literals, destructuring, and overall more compact code.

Clojure also comes with several new features. Its persistent data structures use structural sharing, making immutable updates efficient. It also uses lazy sequences, which allow computations to be performed only when their results are needed. It has strong support for concurrency through constructs such as atoms, refs, agents and futures, and provides records and custom data types when more structured data is needed. EDN (Extensible Data Notation) offers a simple extensible data format based on Clojure’s literals, a better lispy alternative to JSON, YAML and similar. Clojure doesn't have types, but clojure.spec can be used to describe, validate and generate data without introducing a static type system, useful in large applications.

Rich Hickey designed Clojure with the intention of prioritising stability, similar to what standardisation did for Common Lisp. Even though the language is actively developed, you don’t need to expect major deprecations when updating to a newer version, since the maintainers preserve backwards compatibility and mostly add new features through core libraries.

Since Clojure is designed to be hosted on other platforms, it can be ported to other runtimes, like the JavaScript engine that runs in your browser. ClojureScript is a Clojure compiler that targets JavaScript rather than the JVM, so the same language can run on both the server and the browser. This means that Clojure can be used as a full-stack language.

The JVM integration is great, but it comes with some trade-offs. Error messages are contaminated with a lot of Java implementation details and aren’t always self-explanatory, so stack traces are not necessarily helpful when debugging issues. Java profilers like YourKit are compatible, but even there you will see a lot of Java classes, and it can be hard to map them back to the code you wrote.

In general you don’t need to know Java to learn Clojure. I didn’t know Java when I started and never had substantial problems because of that. However, knowing how to tweak the JVM can be helpful when doing performance tuning on the server.

The community around Clojure is small but active and happy to help newcomers pick up the language quickly. It’s known as Clojurians and mostly hangs out on Slack, where you can also collaborate on open-source projects and find job opportunities.

Clojure is actively used by companies and startups around the world, and it’s probably the most widely used Lisp in production. Some big names include Nubank (one of the largest fintech companies in Latin America), which acquired Cognitect (the main sponsor of Clojure’s development), as well as Walmart, Netflix, Apple, Salesforce, Amazon, Cisco, and Grammarly.

Where Clojure shines

Clojure shines in large software systems where the workload consists of a lot of data processing, or more broadly, anywhere you might previously have picked Java. Code can be written and tested quickly through continuous iteration thanks to the REPL, making the language suitable for delivering reliable solutions in less time. Its immutable design helps eliminate some of the hardest concurrency bugs, while its functional orientation guides programmers towards writing programs as a series of data transformations.

Clojure is great in fields where operations need to happen quickly and often involve processing large sets of data, such as finance and trading. It’s also great for startups solving domain-specific problems with complex logic, since the language’s extensibility allows it to be modelled around the problem.

Learning resources

To give Clojure a try, you might want to check out Try Clojure, then solve some exercises like the Clojure Koans, followed by 4Clojure for more advanced stuff.

The official website offers some of the most curated material you can find, with great explanations of all the core features and the motivations behind the design choices that make the language special. Clojure also has one of the best documentation websites I’ve ever found for a language. All the core library functions come with docstrings, and the community has added usage examples, so you can quickly grasp what each function does.

The best pitch for the language is Clojure Distilled. It’s probably one of the shortest explanations of what Clojure has to offer.

After the release of Clojure, Rich Hickey became famous for a series of talks about software design, in which he shared his deep expertise in fundamental topics like simplicity in software design, state and time, databases, concurrency, and language design. Some of his best talks — Simple Made Easy, The Value of Values, Hammock-Driven Development, Are We There Yet?, and Design, Composition, and Performance. I highly recommend spending some time watching them, whether you choose Clojure or not.

Some good books are Clojure for the Brave and True by Daniel Higginbotham, which is free to read online and good for beginners. The one I bought is The Joy of Clojure, which is recommended for programmers who come from OOP languages like Java.

For editors, VSCode has Calva, a complete and rich extension for Clojure. If you use Emacs you can use Cider, plus there are extensions available for most editors/IDEs.

Racket

Racket is a modern dialect descended of Scheme. While other Scheme dialects are generally small languages, Racket has evolved into a fully featured language with its own unique features.

The code is compiled on every major platform and the language has been used in a lot of fields to create web applications, graphical interfaces, database integrations and mostly to quickly develop tools with graphics.

Racket is language-oriented, which means it’s designed for creating new programming languages. Every source file begins with #lang, which defines the language used by that module. You can create entirely new languages with their own syntax and semantics, while still using the Racket ecosystem underneath. Other Lisp dialects can easily build DSLs, but they are tied to Lisp. Racket advances the concept by making it easy to define completely new languages, without requiring them to use Lisp syntax.

Racket also comes with a wide range of features. It includes libraries for cross-platform GUIs, web servers, concurrency and parallelism, regular expressions, pattern matching, classes and objects, and an FFI for calling C code. Its package manager is integrated into the ecosystem, and a large collection of libraries is immediately available. Compared with other Lisp dialects, there is generally less setup required before you can start building something substantial.

Racket offers an advanced macro system, providing the same kind of macro support as other dialects, plus hygienic macros. Hygienic means that identifiers introduced by a macro don’t accidentally capture those in the surrounding code. This makes macros safer to write, especially for beginners, that don’t have to rely on gensym like in the other dialects.

Static typing is supported with Typed Racket, a typed variant of the language that lets programmers add type annotations and have their code checked before execution. Typed and untyped Racket modules can also work together, so typing can be introduced where it is useful without requiring an entire program to be rewritten.

Even though Racket comes from the Scheme tradition and has strong functional programming roots, it supports multiple paradigms. Programs can be written using imperative programming, objects and classes, functional techniques, and metaprogramming.

The language installation comes with DrRacket, a great IDE with everything ready to use the language, available on all major platforms. It combines an editor, REPL, and debugger, in a single programming environment for writing and testing Racket code.

The main downsides are its small ecosystem and limited use in the industry. There are fewer libraries, projects and jobs compared to more popular languages. Performance and deployment can also be weaker points, especially compared with other compiled dialects.

Where Racket shines

Racket shines when designing new programming languages, building compilers and interpreters, or experimenting with new language features. This makes it particularly popular in computer science education and university research. Also, since it’s language-oriented, it’s a great choice when a program needs to provide a simple DSL, for example for customisation, without forcing the user to use a Lisp dialect.

Racket is ideal for prototyping, scripting, and projects where having a comprehensive set of libraries and development tools immediately available is important. It’s worth noting that other dialects offer GUI support through external libraries and wrappers, while in Racket it is available out of the box.

Learning Resources

Racket has a rich website with a lot of helpful information. Important resources for beginners include Quick: An Introduction to Racket with Pictures and The Racket Guide, which is the complete guide to the language. Also worth mentioning is Beautiful Racket by Matthew Butterick, a visually curated guide to the language written by a passionate contributor. If you’re looking to write a compiler, check out this course using Racket.

The best resource available for Scheme is SICP, also known as the Wizard Book. It’s not only about Lisp, but it’s a great book for learning the fundamentals of programming and programming languages. It’s also worth mentioning a rather unusual book, The Little Schemer, which consists of a long series of questions that forces the reader to think before looking at the answer on the page.

Special Mention

Elisp

Elisp is a specialised dialect that’s part of Emacs and is used to customise the editor. It’s an old Lisp dialect that comes with quite a few limitations, but it’s probably one of the best practical uses I’ve ever found for Lisp, beyond using it as a general-purpose programming language. It’s used to customise and extend the functionality of Emacs, since much of the editor itself is written in Elisp. By evaluating Elisp code inside it, you can change how Emacs looks and behaves in real time, without requiring a reload.

Learning resources

An Introduction to Programming in Emacs Lisp is freely available online. Another useful resource is Emacs Lisp Elements by Protesilaos Stavrou, an active Emacs contributor and advocate.

Syntax comparison

We can use a simple instruction interpreter to show some of the syntactic differences between the dialects.

(defun calculate (instructions)
  (loop with result = 0
        for (operation value) in instructions
        do (setf result
                 (case operation
                   (add      (+ result value))
                   (subtract (- result value))
                   (multiply (* result value))))
        finally (return result)))

(calculate '((add 5) (multiply 3) (subtract 4))) ;; => 11

In Common Lisp, I used the LOOP macro to iterate over and destructure each instruction, then perform the operation by updating local state. Notice that it carries an accumulator (result) through the sequence, essentially doing the same job as a reduce.

(defn calculate [instructions]
  (reduce
    (fn [result [operation value]]
      (case operation
        :add      (+ result value)
        :subtract (- result value)
        :multiply (* result value)))
    0
    instructions))

(calculate [[:add 5] [:multiply 3] [:subtract 4]]) ;; => 11

In Clojure, I used a reduction over the sequence of instructions. Notice that it doesn’t use or update any local state, since the reduction uses immutable accumulation. I also used some syntax that is specific to Clojure, such as vectors [] and keywords like :add, and destructured the contents of each vector with [operation value].

(define (calculate instructions)
  (for/fold ([result 0])
            ([instruction (in-list instructions)])
    (match instruction
      [(list 'add value)
       (+ result value)]
      [(list 'subtract value)
       (- result value)]
      [(list 'multiply value)
       (* result value)])))

(calculate '((add 5) (multiply 3) (subtract 4))) ;; => 11

In Racket, we use for/fold to iterate over the instructions while carrying the result from one iteration to the next. We also use pattern matching with match to destructure each instruction and identify the operation at the same time. For example, (list 'add value) matches a two-element list whose first element is the symbol add and binds the second element to value.

Which one to pick?

To summarise the above:

Clojure gives you modern syntax, functional programming and immutable data structures, great tooling and libraries, an almost drop-in replacement for Java, a full-stack language, a strong community, and maybe even a job.
Common Lisp gives you native compilation, high performance, the most powerful REPLs, multi-paradigm programming, and a stable, battle-tested language.
Racket gives you a feature rich language, a great IDE for beginners, a cross-platform GUI, a powerful platform for building new languages and DSLs, easily approachable for students.
Elisp gives you the ability to extend and customise Emacs.

For most programmers looking for a practical and elegant Lisp they could use professionally, Clojure is probably the safest first choice.

If you want to experience the traditional Lisp development model at its fullest, you want native compilation without rely on JVM, an exceptionally interactive environment and a huge language, choose Common Lisp.

If you are a computer science student, interested in compilers and programming-language design, or if you need a quick way to write tools or need an easy way to use a cross-platform GUI, choose Racket. This is probably the easiest to start with between the dialects.

If you have any questions of feedback, please send me an email.

Confessions of an emigrant

Wed, 15 Jul 2026 00:00:00 GMT

Today at 3 pm I officially became an Australian citizen. I felt it was a formality, since I already had a permanent residency. But when I was sitting in the city hall, together with others that were receiving the citizenship as well, I reflected about the last few years I spent abroad and what it actually means being an emigrant. Looking back at my past, it seemed obvious that, sooner or later, I would have moved to another country.

It all started in the early years of my adulthood, when I had the chance to fly to and work in Silicon Valley three times. During that period, I also moved to Turin to study at the university, in a much bigger city than the small town where I grew up. Something started changing in me back then. I appreciated the new level of freedom that I gained by leaving my parents' house, and I developed a certain thirst for what I believed the rest of the world had to offer. The thought of a future in my small town, seeing the same places, facing the same issues, having my entire family around all the time, and the feeling that certain things there were too slow to change, was frightening me. I didn’t want to feel stuck in that place.

Also I wanted to be challenged, I wanted to confront difficulties and experience new surroundings. I believe there are few experiences as eye-opening as living for months, or even better, years, in another country.

I wasn't sure where or how I would move, but I knew I could find a way if I truly wanted to. On Facebook I can still see the groups I joined at the time to get a genuine, unspoiled insight into what life was like in different cities: “Italians in London”, “Italians in Valencia”, “Italians in Berkeley”, “Italians in Amsterdam”, “Italians in Dublin”. I was naive. I was trying to find something familiar that would soften the culture shock I knew would hit me once I stepped out of my comfort zone. I was trying to play it safe, not knowing what to expect.

In those Facebook groups I still see many compatriots every day who ask what life is like there, how much it costs to live, whether there are enough jobs, and whether it's worth moving their entire family to the other side of the world. I can see my younger self in their worries and their hope for a different future. They don’t know yet what emigrating really means.

What I also find in those groups is the constant clash between those who defend their home country and those who criticise it, praising how much better their lives abroad are. This might seem like a typical social media interaction, but I think there's another side to the story that people are overlooking. When you move abroad, you're expected to do better, to build a better life. Otherwise, why would you do it?

It's a sort of unspoken expectation that every emigrant has to live up to, especially when interacting with people from back home. You don't move abroad to live a life worse than the one you had at home. You have to “make it”, whatever that means. You can't really talk about your struggles, the loneliness, the career setbacks, the sense of cultural isolation. Is not that simple to say that you miss what you left behind. Many emigrants end up hiding the reality of life abroad. They wear a mask to live up to the expectations of their family, friends, and the compatriots they left behind. They no longer live at home, they abandoned the land. The everyday problems of their compatriots are no longer theirs. They are in a liminal space between two countries, no longer physically present in one, but not yet belonging to the other.

The truth is that life abroad is never easy, nor is it necessarily better than what we had at home. The job situation can be a rollercoaster. It wasn't easy to tell my parents that I was picking fruit when, just a few months earlier, I had a high paying office job. It took me a while to get back to my original career, and in the meantime I had to work in less pleasant jobs where I was overqualified or overworked. I had to fill those gaps on my CV with something, because recruiters don’t care about immigration policies. Australia is a welcoming country, and its people are kind and generally open-minded, but I still feel like an immigrant every day. I had to adjust how I speak and behave, and I’m still working on softening my accent in order to fit in. I still carry the contradiction of being someone who “made it” back home while still being perpetually viewed as an outsider in my new country.

I have missed important moments in the lives of the people I care about. My sister had a child, and I am not there to watch my nephew grow up. My school friends are getting married, and I’m not there to celebrate with them. I will not share some of their happiest moments, and they will not share mine. One day, my parents might fall seriously ill, and I might not be there when they need me most. These are costs I had to be willing to accept.

The culture that shaped my childhood cannot be found overseas. I can join a small community of expatriates, buy imported products and spend time cooking a nice meal. I can find book in my language, teach my kids Italian while we visit my relatives. But I know it will be hard to transmit the same culture. Whatever home was for me cannot be bought online or shipped overseas in boxes. If I want to feel it again, I have to go back to it.

I've had the opportunity to meet several emigrants in my life, mostly Italians like me, because we tend to gravitate towards one another, as if our shared culture acted like a magnet. Some of them returned to Italy after years of living overseas because they never found a reason strong enough to stay. Some of them kept moving from country to country before eventually returning to Italy when the right opportunity arose. Some people built a life abroad, advancing their careers and starting a family, while others are still trying to figure out where they belong. It's impossible to predict what life abroad will be like for someone else, or how well they'll cope with its challenges.

After all this, one last confession, one that's usually hard for an immigrant to admit. No matter how successful you become, how much money you make, or how much your life improves by moving overseas, there will always be moments when you feel a sense of regret, when you'll be tempted to reply to those people on Facebook and tell them, “No. Don’t leave. It’s not worth it.” Then those moments pass, and life goes back to normal. They are simply part of choosing one life over another.

Today, becoming an Australian citizen made that choice feel more permanent than ever. I don't know whether Australia will ever feel like home in exactly the same way Italy does, and perhaps it doesn't have to.

And now it's time for me to celebrate. For the occasion, I'll have a chicken parmi with gravy. Wish me luck.

How to read more books

Sun, 12 Jul 2026 00:00:00 GMT

I've read roughly a book a week for a few years, and I can tell you it's doable. I didn't always read this much. When I started, I read fewer than ten volumes per year, but making it a goal made me switch gears and achieve what I once thought was impossible. I want to explain what I did to become a prolific reader, and what I learned in the process, so that, with a bit of effort, you can do it too. I promise, it will be worth it.

First of all, you don't have to make time to read. What you need to do is read every single time you are not doing something else. In today's world, most people pick up their phones as soon as they get a moment of inactivity. Serious readers pick up their books instead. So an effective way is to replace the time you spend in front of a screen, like PCs, smartphones, and TVs, with time spent reading a book.

This is probably the most difficult part. I had to remove all social media and streaming apps from my iPhone. I removed Instagram, YouTube, Facebook, etc. When I started, I found myself picking up the phone and immediately noticing that something was missing, since the only things left to do were to check the weather and read boring emails. After a few days my brain started remapping itself, and I felt less pressure to immediately reach for my phone as soon as I had nothing to do. I also wear a cheap analogue watch so I can check the time on my wrist and I don't have to reach for my phone.

Once you remove these distractions from your smartphone, you might find yourself a bit uncomfortable with having nothing to occupy your mind for ten minutes. This is the perfect time to boost your reading habit. You need to make sure you always have a book with you everywhere you go. I usually read a few pages as soon as I wake up, and do the same before falling asleep. I read while cooking lunch or dinner, or while eating breakfast. I love using public transport, especially trains, because I get time to read while someone else is driving for me.[^1] I always have a book with me when I go out with my partner, even if I don't usually end up reading it. If she has to run an errand and I have to wait, I don't waste time with nothing to read. I have become good at walking my dog while reading — I even got complimented for that by a stranger — and I make sure I never go to the bathroom without a book.

“I love the smell of book ink in the morning.” — Umberto Eco

Carrying a book wherever I go can become problematic, depending on its size. The best solution I have found is to use an ebook reader. They are thin devices that can fit in a pocket and are able to store hundreds of books. For a reader, an ebook reader might be one of the best inventions ever, considering how expensive books have been throughout history and how difficult they have always been to carry around. Ebooks, by contrast, are cheap. Moreover, you can have a backlight for reading in the dark — it doesn't strain the eyes — and you can highlight text, take notes and get definitions for words. However, it's not really a replacement for a book. After a while, always reading on an ebook reader feels like reading the same book, even if the story changes. I like to alternate digital books and physical ones, and I always prefer paperbacks since they are easier to carry around and cheaper to buy.

I tend to read multiple books at the same time, since having only a single option can be boring. Sometimes I get so into a book that I put the others on pause because the story is taking up all my attention, but in general I like to have a few books that I read in parallel. I generally mix fiction and non-fiction to have a broader choice.

What to read is a difficult question. I once read a phrase somewhere that puts it quite well: “read what you like until you like to read.” My suggestion is to read broadly, changing genres and subjects, because there are well-written books in every genre. Varying the topics can expose you to different perspectives. And sooner or later, you will understand which genres you like more.

“It is foolish to think that you have to read all the books you buy, as it is foolish to criticize those who buy more books than they will ever be able to read. It would be like saying that you should use all the cutlery or glasses or screwdrivers or drill bits you bought before buying new ones.” — Umberto Eco

Another secret is to not be scared of quitting books. I definitely start way more books than I finish. But I don't consider an unfinished book a failure or a bad book. I think that certain books require the right time to be fully appreciated. So if I don't finish a book today, I might try reading it again in the future. I still remember having abandoned Siddhartha by Herman Hesse at least three times after the first few pages, before finally finishing it and considering it one of the most formative books of my life. Somehow I wasn't ready for it the first time, and I had to wait for the right moment to fully understand it. Also, I believe there are way more bad books out there than good books. If you feel that you are not enjoying a book, it feels boring and makes you think you are wasting your time, just close it and move on. I have closed books by authors that I loved, because they weren't as good as the rest of their work.

If you are a serious reader, you need a library with physical books. So try to stack copies of books on your shelves for later. When I buy new books, it is mostly because I need a specific one I cannot find otherwise, or because I want to support local independent bookshops. However, I generally buy more used books than new ones. I usually find them in the book section of used stores, at markets, book fairs, and sometimes in the book boxes that I find around the city.[^2]

An effective method to push yourself to read more is to set some goals. You can pick a reasonable number of books for the month or the year and try to reach it. Tracking progress is a well-known trick used to form new habits. Goodreads, for example, has what's called the Reading Challenge, which helps you keep track of how many books you read in a year. I found it motivating to put in the effort to stay on track with the number I wanted to read. However, counting the volumes is not a healthy way of reading. It's much better to read great books and take the right amount of time to understand and reflect on them rather than rushing to finish books just to increase the final count. You need to enjoy the process and get a good outcome from your reading.

Writing a review is also a great method to make a book stick in your memory. Taking highlights and notes while you're reading is a good thing, but revisiting them alongside your thoughts in a written document is something different. Reviewing books is a great way to become better at understanding what the messages contained in the books are and what the key elements of the story are. In addition, if you like writing, it's a good reason to practise.

One of the duties of a serious reader is to find what to read next. I always have a long list of books to read, but I don't stick to it all the time. I like to be immersed in something new and discover new authors or genres. I usually use two things: Goodreads and YouTube. The first one helps me form an idea of a book before I get to reading it, thanks to reviews and comments from people I follow. YouTube, on the other hand, is great for listening to book reviews to get recommendations. There are many great channels out there, and I watch quite a few of them. One of my favourites in English is Better Than Food, which has reviewed books for more than a decade.

What inspired me to try to read more was this video, where Max Joseph explains that becoming a serial reader is just a matter of making a daily habit of reading a few pages, with surprisingly good results. Also, Ryan Holiday — a famous author — has recently published a good guide on how to read more books with his own tips and tricks.

One last recommendation: avoid hacks. Avoid speed reading. And don't try to force yourself to increase your reading speed. It will come naturally the more you read. Avoid summaries and summary services. It might be okay to use them after you read a book to make sure you didn't miss some parts, but reading a summary does not equal reading a book. Avoid audiobooks too. Big corporations want to grab your attention by trying to market audiobooks as books for busy people, but don't fall into the trap. A book is just boring black text on a white page because that's how it's meant to be consumed, and it requires your full attention. Listening to audio while cooking or cleaning or whatever you do is not the same thing; you are not fully focused on the content. Also, reading is faster than listening, so use your time wisely.

[^1]: I consider driving a huge waste of time. Sometimes it can be fun and adventurous, but I think life is too short to drive to work every day. [^2]: In Australia, some people put a wooden box with a door in their front yard and fill it with books, so that everyone passing by can pick one up or leave their own books for other readers.

Blog engines I've used

Sat, 11 Jul 2026 00:00:00 GMT

Since I got my first internet connection as a kid, I’ve spent more time setting up new blogs than actually writing them. It’s not surprising. Configuring the platform and adding features was the whole point, the fun part. Writing never interested me at the time, perhaps because I never felt the urgency to express myself and didn’t have anything relevant to say.

I’ve always used self-hosted solutions and learned the advantages and tradeoffs of using them, so I will summarise here each blog and platform I have used. I might not know much about writing a blog, but I’m sure I know a thing or two about the platforms that make a blog possible.

WordPress

This was the first blog I opened many years ago, and I believe I wrote it in Italian. I was mostly translating some guides from English, or reposting tutorials taken from other blogs or forums. I got a few readers and comments, but it was never a serious project.

WordPress has been the main CMS for a lot of websites for decades, and still today power 40% of the web. In 2006-2008 the community around it was active, and a lot of plugins and themes were released, since PHP, the language that WordPress uses, it’s easy to learn and quick to be productive with. Plenty of guides were available, so creating a blog at the time was a matter of installing WordPress, connecting to the hosting space via FTP using FileZilla, and then connecting a MySQL database to it.

In those years, the LAMP stack (Linux, Apache, MySQL, PHP) was the foundational architecture used by most websites and communities, so it wasn’t surprising that WordPress got so much traction. There were so many plugins and themes that it didn’t take much to put a decent website online. Besides my own blog, I had to install and configure WordPress websites for other people, and every time things went smoothly enough. Even when I had to do some small customisations to a theme, it was quite quick to do, considering that I never learned PHP and my changes were done by guessing and testing.

The CMS that WordPress offers is top notch; I’ve never found one as good since. The editor is decent and includes an instant preview of the articles and theme changes. It’s so easy to use that even your noob uncle who needed a website was able to put one together with images without having to call you over for help.

Also, the plugin library that WordPress offers is large, and the plugin quality is quite decent. Most website owners at the time were worried about SEO, and it was just a matter of installing the right plugins to make sure the website was picked up by Google with the right keywords.

Since WordPress workes with a database, it offers simple integration to add comments to a website, with the Akismet spam filter plugin and other nice features like user login and Gravatar integration.

The main problem with WordPress is that by supporting so many features it became a huge monster, far more than what’s really needed for a simple blog. I started abandoning WordPress when Markdown became popular and static websites had their Renaissance.

Jekyll

After PHP came the Ruby era in 2008. Tom Preston-Werner, after releasing GitHub (written in Ruby) in April, got tired of having to deal with a database in WordPress to host a simple blog and decided to write a new blog engine called Jekyll, also in Ruby.

Jekyll is much simpler to configure and to understand what is happening inside the blog. A new project consists of a configuration file and a folder structure. Posts are simple Markdown files, and the styles use SASS, which at the time was more advanced than plain CSS. The pages are composed of layouts and smaller reusable components. For rendering the pages, Jekyll uses the Liquid template engine, which allow the use of variables, conditionals, and loops alongside normal HTML tags. When my blog was ready to be served, I just needed to run the CLI command to build the project, and the compiled website was saved into the output directory.

Jekyll is a platform that mostly targets blogs. There are many plugins available that extended what is possible to put into posts and how the content is indexed. Plus, GitHub got popular and enabled the possibility to host a website directly on their platform. So publishing with Jekyll is a matter of pushing the updates to the repo, and the continuous integration would then run the build and serve the output directory.

Jekyll served my needs for a longer period than any other platform. It was minimalist compared to WordPress and, in a way, made the components of a blog much more visible and in the hands of the developers, since most files were HTML, Markdown, and SCSS.

Then Ruby lost its momentum and got a bit out of fashion. I have to admit that at the time I didn’t know Ruby well, and a few times when I wanted to change some plugins I ended up not doing it because of the language barrier. I didn’t abandon Jekyll because of that, but because the community itself got a bit smaller and less vibrant, probably because a part of it migrated to other platforms (or stopped blogging).

Org mode publish

When I learned Emacs, I discovered the most advanced file format integration with an editor: org. If you don’t know it, think of it as a more powerful Markdown with a series of shortcuts and extensions that make editing really fast and transform a directory of files into a perfect organisational system for your personal information.

Org comes with a publishing management system, which is a way to export a series of org files into HTML, with certain output configurations for directories and templating. It’s a static site generator that converts org files to HTML, similar to what Jekyll was doing with .md files. Once the project is configured with some Elisp code, saving a file in Emacs and running a command was enough for publishing changes to my Org-mode blog.

Since org is an advanced file format, the publishing came with some nice features too, like title links, dates, and automatic sitemap generation.

The difficulty is that org publish is more a system for converting files rather than producing a blog. So features like layouts, SASS for stylesheets, RSS feeds, a public folder for static files, they all needed a special Elisp configuration to be written and maintained.

It didn’t take me long to adapt some Elisp code to fit my project, but after making a few changes to the directory structure, every time the build was failing and I had to debug what was happening. It wasn’t ideal. Plus, features like image compression or integrating a search would have been hard to implement.

So, as usually happens with complex configurable systems, after having fun customising the whole setup, I got bored, since org publish wasn’t really what I would consider practical for a personal blog. Just my personal taste.

11ty

I finally found a static site generator written entirely in JS, so I wrote my blog in 11ty. It’s another pretty good system for creating static websites.

I found it a bit tricky to find official documentation for certain features, but I was able to integrate and customise my blog exactly how I wanted and write the plugins I needed in quite a short time.

Honestly, I don’t have much to say about 11ty. It’s a good alternative to Jekyll, and it uses Javascript, so if you know the language it becomes easy to customise. It’s actively supported and used on the web, so I recommend checking it out if you are looking for a blog platform.

What got me a bit frustrated is that I ended up having a large JS file with all the configuration required, and when I had to change some structure in my blog — for example, adding support for Italian/English translations to certain articles — the configuration file got a bit bloated.

Astro

Astro is probably the definitive static site generator I’m using today. This blog moved from 11ty to Astro without even being noticeable, and I’ve used it in a few other projects where I needed a static site generator. I’ve even tried using DecapCMS with it, so that a friend was able to write pages and add images directly by pushing to the GitHub repo, avoiding the need for a database.

Astro has pretty much all I want for a blog: asset optimisation, partial hydration with islands, advanced templating, and variable support. Also, Astro uses single-file components to define pages, so that HTML, JS, and CSS that share the same scope are placed in a single file, like Vue does. Pretty neat, and it makes the code easy to organise and reuse. It also extensible using Javascript and offers an high level of customisation and a set of libraries to integrate more features.

What I look for now

After all this, here's what I now consider essential for a blog engine:

support for Markdown, since I write everything in Obsidian
sensible defaults for common features like RSS and asset optimisation
a healthy plugin ecosystem for when I need to extend things
easy customisation

I hope Astro stays around for a long time. I'd rather not migrate again and instead spend that time on what actually matters: the writing.

On Running and Murakami

Fri, 10 Jul 2026 00:00:00 GMT

I’ve been a runner for more than ten years. I started running a few times a week during university because it’s a sport that fits me well. It only requires a good pair of running shoes, it’s not time-consuming, and it can be done everywhere and in any season.

I’ve always been a long distance runner, and most of my runs have been around an hour long. I always find it engaging to go for a long run, where I can distract my mind from the focus of the day. This frequently helps me find new ideas and inspiration, just like I did for this article.

Recently I’ve started running every day, but for a shorter amount of time. The physical benefits remain the same. Two things made me change my habit: first, research suggests that shorter daily run are more beneficial for the well-being, reduce the risk of injuries, and allow the body to adapt gradually. Second, it takes less time. In a busy life, taking 30 minutes a day for your body and mind is not much, while one hour can become more of a burden.

The second thing I mention when I talk about running, after describing what type of runner I am, is the type of shoes. I currently run with the Wave Rider 28, which I bought from the Mizuno store in Kyoto, Japan. I’ve tried other common brands, and while there are differences for the pros, for a casual runner like me they are negligible — and Mizuno are good shoes. I chose them because they are the shoes that the writer Haruki Murakami uses.

Haruki Murakami is the most famous Japanese author alive today. He has written multiple bestsellers that have been translated into more than 50 languages worldwide and have inspired several movies. Other than being a successful author, he’s a long distance marathon runner and wrote about his experience with running in a book called “What I Talk About When I Talk About Running”.

Before dedicating himself entirely to writing, Murakami ran a jazz cafe in Tokyo with his wife, where he spent his days preparing cocktails, selecting music to play, and reading books. While it might seem like an easy job, he was working for 12 hours every day while smoking almost 60 cigarettes due to stress. Then one day, while watching a local baseball match, he had the realisation that he wanted to write fiction. Against the advice of his close friends, he sold the cafe and moved to the countryside with his wife, where he could have the calm environment needed to focus. While dedicating himself to writing, thanks also to some positive feedback received for his early stories, he discovered that sitting at a table for long hours every day wasn’t good for his health. So at 33, he quit smoking and decided that he would go for a run every single morning before immersing himself in writing.

Since then, Murakami has never stopped running, participating in more than 30 marathons around the world, including ultramarathons and triathlons. In the book, he explains the entire process that transformed him from a complete beginner to a long endurance runner. His secret was running every single day, mentioning that consistency was the key to his success.

Murakami has run for most of his life and wrote novels professionally for a long time. In the book, he explains the loose correlation between the two: the fact that both are activities done in solitude and that both require, other than a bit of talent, constant training to be sustainable over a long period. Writing is not easy. It requires sitting at a table alone, immersed in a long and deep thinking flow into imagination and memory. It’s a task that requires concentration and can sometimes be so intense that it becomes exhausting.

The book mixes the two experiences that Murakami had, describing that what he learned is that the key ingredients to engage in these activities are focus, endurance, and the patience needed to persist while waiting for the results to come.

I didn't start running because somebody asked me to become a runner. Just like I didn't become a novelist because someone asked me to. One day, out of the blue, I wanted to write a novel. And one day, out of the blue, I started to run-simply because I wanted to. I've always done whatever I felt like doing in life. People may try to stop me, and convince me I'm wrong, but I won't change. — Haruki Murakami

In the West, we tend to associate authors with a status, almost as if they are celebrities and rockstars. In recent decades, we saw the rise of literary artistic personas that romanticised drinking, taking drugs, and burning out young. Think Burroughs, Hunter S. Thompson, Bukowski, Bret Easton Ellis, or David Foster Wallace. They all made these themes central to their productions.

Murakami is a different kind of writer. Instead of drinking, smoking, abusing substances, and promoting an unhealthy lifestyle, he followed a strict diet, did endurance training, and committed himself to a self-imposed discipline to seriously carry out his duties. He promoted a life dedicated to running and the craft of writing, honouring his commitments while constantly training his persistence and resilience. This choice resembles the life of ancient samurais, the Japanese warriors with a high moral code and self-control. If you’ve ever been interested in Japan, you will notice that the attitude that samurais had toward their duty still persists in today’s life of Japanese salarymen. The country is famously renowned for the perfection they put into their crafts and their dedication to work, which comes from the culture of imposing strict discipline on themselves in order to challenge their own limits.

Pain is inevitable. Suffering is optional. — Haruki Murakami

There’s a quiet rebellion in choosing Murakami over Bukowski as a way of life. Our Western culture too often normalises burnout and, instead of condemning substance abuse, subtly encourages it. The power that comes from disciplining ourselves and restraining our desires in pursuit of a higher goal is what allows us to simply show up every day and do the work, whether that means running or writing. The point of these activities, in the end, is to prove to ourself that we are capable of enduring, and of moving forward, every single day.