The Leafslug

Democracy

2026-04-18T10:05:05+02:00

There is a left and a right in politics.

And there are people that agree mostly with the left.

And people that agree mostly with the right.

And people that find it easier to be on the left.

And people that find it easier to be on the right. And people who find left beneficial to them.

And people who find right beneficial to them.

And people who love the ecstasy of being fans of the left.

And people who love the ecstasy of being fans of the right.

And people that just enjoy watching the game.

And players. They win or lose. It’s only a game to them.

And people who organize the game, not caring which side wins, as long as the tickets are sold.

But at the end, it’s just a game, when the left and the right are only fans and players.

Fucking Black-Hats

2026-04-07T15:09:05+02:00

Last time I wrote here was a while ago. At the time I was starting a very thorough redesign of this website. Nothing that you would notice. Mostly updating the backend to handle concurrency using the actor model, handling invariance using type-driven patterns, moving from SQLite to PostgreSQL, etc.

I did this because I was mostly trying things out. My blog’s backend was a way for me to try out things that I do not have the opportunity to try on my day job.

However, one fucking black-hat hacker ruined it for me. A few days ago, I received an E-Mail from Servinga, that the IP of the VPS I was using to host my blog was reported for violations. It was reported by multiple sources to have been port scanning, and looking for servers that exposed 2134 port. Kind of a traditional port that Trojans and other viruses used to communicate to each other.

Servinga was gracious enough not to end their contract with me. But to me, it was the last draw. I was already paying so much for the server and I already had exhausted a lot of the ideas I wanted to try. I set up the server with strict version control, and firewall. And I still could not figure out how it was infected.

But in the space of problems I would like to tackle these days, playing cat and mouse with black-hats is not on top of my list. So I spend a few hours, creating a static site generator from the source code of my previous website. Uploading them to statichost.eu. You are now reading that website.

I mourn the lost of my playground, ever so slightly. But this is for better. Maybe I write more in here. Maybe I take up projects that are less private. But for now, fuck the black-hat that ruined my playground.

Sorry

2025-09-01T19:47:43+02:00

If you are subscribed to my feed, you might have been bombarded by old items being marked as new in your feed reader. This is entirely my fault, and I want to apologize. I know this is extremely inconvenient. I hope you stay subscribed. But I understand if you feel otherwise.

The Reason

So, there is a reason why this happens. Mind you, this is not an excuse, just the technical reason.

When I started writing the software behind this blog, I was completely ignorant of the specifics of the ATOM format. And being frustrated and naive, I didn’t read the spec for it.

ATOM is a particular beast. And in the field for the <id> of the items, I should have put a URI. In my stupidity, I thought it was supposed to be the relative URL of each item. I know I was stupid.

And over the past year, with a lot of the rewrites, I put plenty of effort into not breaking the feed. However, for each post I had to set the feed ID manually, and keeping track of it became a rather tedious act. More unpleasantly, unless I removed those items or I broke it, my feeds never validated.

For this reason, I decided not to live in the shadow of my past mistake and let you bear the annoyance. I know. I’m a selfish ass. From now on, however, the <id> of each post is a UUID that is automatically created and kept in the database.

Hopefully, this is the last time I break your feeds.

My Dog Bites Me

2025-07-28T17:47:05+02:00

He is there, right before me and my destination. He knows where I want to go. And I know what he will do if I do it too quickly, too slowly, or in a manner that he deems not appropriate. He stares at my feet. Jumping on his four paws, he warns me of the oncoming pain. We have danced through the same routine night after night. But it doesn’t change anything: he is of the wolf lineage, and he cannot betray his ancestors through inaction.

I jump on the bed, jumping over him while doing so. His reaction is just as immediate, jumping twice his height, reaching the bed. Ready to bite me, with eyes as wild as his teeth. Slowly I sit and get into position. Now it’s the hard part: putting the blanket on my body.

Pinching the blanket, I pull it slowly towards myself self, My dog jumps on it, letting out a growl. He is not having it. “I should distract him somehow”, I think to myself. Looking around, there is nothing. Trying to move my wife’s blanket doesn’t result in anything.

Suddenly, I see it, his chew-treat that he carefully hid on the centre most layer of the blanket, truly invisible to every blind aggressor out there.

I put the treat in my hand, and move it in front of him, trying to make it seductive to him. I definitely have his attention. I throw it on the ground. He leaps towards it, and I jump at the now-free blanket, putting it on my body.

He notices this, turns around, he is not making this mistake again, at least not for the rest of the night!

Feeling over-confident, I try to adjust the blanket with my right foot’s toe. And that was the final straw. He jumps and bites my foot and then my ass, barking behind each push of his teeth into my skin. I scratch a little, a pinch of blood.

I start petting him to calm him down. He starts to cool down. I pet him more. Finally, content that I will not move any more, he jumps down the bed, on his own bed, by the foot of our bed.

It is unclear to me why my dog plays this same game every night, and mostly only with me. He doesn’t bite my wife as much. But every night at 11 o’clock, he has to bite while I’m getting in the bed. If we are staying awake longer, he will come and growl at us, communicating in his own way that “I’m tired, let’s get it over with”.

You might think this is an undesirable behaviour. Something that we should train him out of. But I find it funny. I would never ever opt out of it. He, for some reason, takes this to be his duty. I’m not sure why, but he is really dedicated to this. He has been for over 7 years now. And every night it is a bonding ritual we have, just like morning cuddles, or sitting by the porch after his walks. That painful moment does not come with suffering. It comes with exhilaration. And I miss it every night I’m away from him. Or he is unwell and too tired for it.

I don’t know. It might sound masochistic. But his cute face while growling, it is too precious to forgo.

Wait…

Oh, goddamn it! I forgot to take my pills! Fuuuuuuuck!

Scientists Don't Invent

2025-06-15T22:37:48+02:00

The world is going to end in just 12 years by mega volcanos.

I read in Information Weekly magazine when I was 9. I read it at the home of my grandparents; they had a subscription to this magazine. A pretty yellow magazine with stories, reader’s letters, kids sections, puzzles, and of course, a two-page “Science and Technology” right in the middle of the magazine. I was addicted to that section. I read that part right before I go to the puzzles and kids parts.

And I remember this exact news there that said that the world is going to end in 12 years by a series of massive volcanoes that will end civilization, kill the environment, and end life on earth.

You may be surprised to know that more than 20 years have passed, and we are not all dead!

Now this story has nothing to do with the rest and the main point of this post, but giving a narrative to a piece is going to engage readers to the article. So, are you engaged?

Anyhow, I have noticed that every article, podcast, video, or even book that has something like “scientists made…” or “scientists invented…” is usually written by an uneducated person who under-researched the material for his work.

Scientists are in charge of finding out stuff. They are amazing at this. They might create it on the side of science or as a consequence of it, but often the more interesting stuff is done by people whose main focus is not science.
The creating stuff is typically done by designers and engineers, who consult or use the work of scientists.
These articles may confuse academicians with scientists. But academicians that make stuff are not typically the same academicians that do science; their process is not the same, their papers don’t look the same, their journals are not the same, and they are hardly in the same circles ¹. A better-researched article mentions that these are biologists, or medical engineers. Or something like that.
Also, inventions done solely by academicians are notoriously dead on publication. So I would not count on them to change your world unless they were contracted by a private company.
These articles may refer to private companies. In these cases, a well-researched article usually mentions the company. A big company gives credibility to the world-changing product. A small company is an opportunity for a journalist to gain credibility by saying, “I was one of the first to report on X” when the company became ubiquity. Not mentioning it might say 3 things.
1. At best, the journalist is young and does not know how this might be affecting their career. In that case, I also do not trust their assessment of what can actually be a great deal.
2. They may have been lazy and not done good enough research on that work. This is rare, but if the journalist is doing this repeatedly, just lose them. They are not worth your time.
3. They may believe that the company, the startup, or the figures behind them are sketchy. And intentionally hide that fact from you. This is not a sign of a good journalist. But a clickbait creator.

And when you find them working in the same circles, there is usually a big banner on top of the most prominent wall of the room with “Interdisciplinary” written in bright yellow letters.↩︎

Search My Blog

2026-04-08T16:33:01+02:00

I just added a search functionality to my blog.

It uses SQLite’s fts5 extension on a virtual table.

FAQ

Why not Meilisearch?

Because I was already using SQLite and fts5 is pretty good.

Why not use Google?

Because I like you a lot and I don’t think Google should know about our secrets.

But isn’t Google the best search engine?

Yeah, I was using internet during the 2000s, too. But right now, my shitty excuse for a search engine offers a higher quality, with no tracking, no LLM bullshit, no ads, no pay-me-to-show-you-on-top¹.

Who asks these question frequently that you are always answering?

If I ask them frequently while I’m making it, they are technically Frequently Asked Questions.

Update on 08.04.2026

Sadly I have had to remove search from my blog because it is a simple static site now. But thanks for all the fish!

Although, I guess it would be funny if somebody paid me to show the results for their website on my own’s.↩︎

I love git. I replaced it with jj.

2025-06-13T22:53:41+02:00

Git is awesome. I love git. I recommended resources for it on this blog.¹ I have played with libgit2, and created custom cli tools for myself.

However, for the past two months, I have been using jj at work and on my personal projects. It is simply awesome. It is rebasing, on steroid. For most people, if you like git and you also like rebasing, you will definitely love this.

There have already been a lot of blog posts about it. ² And every day one more is added.

So just consider this my recommendation of jujutsu.

git-send-mail.io and git-rebase.io ↩︎
- jj init by Chris Krycho
- What I’ve learned from jj by Nathan Witmer
- Jujutsu in practice by Arne Bahlo
- And if you are sold, this is the best starting point out there, by the guy that wrote the defacto book on Rust: Steve’s Jujutsu Tutorial by Steve Klabnik
↩︎

And Back to Rust, Again!

2025-06-02T22:49:52+02:00

So, I re-re-wrote my blog using Rust. And bought a new domain. And commissioned a Leafslug illustration.

Why

I really loved Elixir. It was a great experience learning it. I really like the model of LiveView. However, Elixir’s more prominent figures and companies jumped into the latest hype. After the last one. After the one before that. All during half a year that I experienced it.

It doesn’t spark joy in me anymore.

Day-by-day, it feels less and less like a language that I like to use, a community I want to be a part of, and more and more like a proprietary language with a closed enterprise ecosystem. That’s not the vibe I like to code with. ¹

Don’t get me wrong. I think BEAM is bee’s knees. And I think the syntax of Elixir is amazing. I just don’t enjoy being in that community, working with libraries made for it, or consuming the podcasts that are so fascinated by the latest LLM crap.

So, since I was thinking about expanding the backend I wrote for my blog, I decided just to take the pill and re-rewrite² it again in Rust.

The Rewrite

So, it is not just a rewrite. The new rewrite has some particularly interesting characteristics.

(Almost) Everything is event-sourced. ³
The persistence relies on a single-table SQLite database file.
I wrote a client for it that makes sending posts and editing them much easier.
The markup is the lovely Djot, instead of Markdown.
A new, lovely domain! TheLeafslug.com
Simple CSS, No Tailwind. A more semantic HTML.

FAQ

Isn’t Rust an over-kill?

I’m not learning Python just to answer your question.

Isn’t event-sourcing an over-kill?

Not unless you want snapshotting, multi-tenancy, and state resolution.

Aren’t there better databases for storing events?

Yes, but they are actually over-kill.

Why changing the domain?

First, no one complimented the clever name of my last domain.
That domain is being held hostage by another registrar; that doesn’t let me move it elsewhere.
Leafslugs spark joy in me.

Why not…?

Ok, I’m done with your endless questions now.

A big red-letters on a yellow background sign that screams: SARCASM↩︎
The first version of this blog was actually written in Rust.↩︎
Are you interested in a post with an architectural breakdown? If you are, please send me a quick email at me@prma.dev.↩︎

How to change the title of a page in Gleam

2025-02-18T09:40:24+01:00

So, yeah. I’m posting front-end stuff as well now.

The Problem

So we have a framework called Lustre in Gleam that allows you to have multiple forms of client-side and server-side front-ends. And it is great. But it only manages a single part of the DOM with your specified id.

So if you have this index.html:

<!doctype html>
<html lang="en">
  <head>
    <title>🚧 Some weird website</title>
  </head>

  <body>
    <div id="app"></div>
    <!-- here is the interesting part-->
  </body>
</html>

And if you start your application in you main function like this:

let assert Ok(_) = lustre.start(app, "#app", Nil)

It will only change the <div> with the id="app".

So, how would you change the title of the page?

If you move the id from the div to the <html> tag, you would not be able to return a list of elements, as far as I understand ¹.

The solution

Create a file at src/set_window_title.js with this content:

export function set_windowTitle(title) {
  document.title = title;
}

And add these to one of your Gleam files:


pub fn set_window_title(title: String) -> effect.Effect(msg) {
  use _ <- effect.from
  do_set_window_title(title)
}

@external(javascript, "./set_window_title.js", "set_windowTitle")
pub fn do_set_window_title(title: String) -> Nil

Now if you call the set_window_title function as an effect, and pass it a string, it will change the title of the page, like a charm.

Thanks to Hayleigh Thompson, for the solution!

I am probably wrong on that. But I could not find any way to do so.↩︎

Are we there yet?

2025-02-08T21:26:29+01:00

Are we there yet?

Every. Single. Fucking. Time. I’m thinking of blogging this fucking question is the first sentence that comes up in my mind. I have no idea why.

Are we there yet?

It doesn’t even make a fucking sense. Most of what we try to achieve is not defined by specific, well-defined borders.

“Hey Rust developers, Are we there, yet?”, “Where?”. Other than a bored toddler nagging endlessly about the length of the road, in what other context does that even make any sense?

Are we there yet?

If you do not know how to define the there, why would you give a rat’s ass if you get there?

There you go, brain. Are you satisfied?

Moving to Germany

2025-01-18T14:02:49+01:00

I’m happy to inform you, dear reader, that after around three years of constant struggle and effort, I have finally received my German Visa.

And, I will be reunited with my wife, in about two weeks from now.

Also -since each time I have mentioned moving to Germany someone asks this - yes, I will be bringing Kitkat, my dog as well. Of course, I will. He is going to be Der Hund! And bellen, constantly,

P.S. I’m also looking for a job right now. If you know of any positions that could use my skills in Elixir, Go and Rust, please point me to it!

Inquiry Into Being

2024-12-14T10:07:12+01:00

Some years ago I started meditating. I began, motivated by the health effects of meditation. Mostly, I had trouble controlling my impulses.

It did wonders.

However, My efforts and motivations began to change into an introspective approach to understand consciousness and the state of being. I did not have anything in the way of anyone that personally could help me. Just a bunch of apps.

But alas, my efforts were abandoned because of some massive changes in my life.

I still don’t have anyone that personally guides me, but I began again. I mostly want to take it as far as “Waking Up” app by Sam Harris can take me, and then find my own path afterward.

Just a couple of weeks of practice and I feel being calmer and having some realizations about the nature of being.

How to start and stop Elixir application

2025-05-30T15:44:12+02:00

So one of the challenges I faced moving to the FreeBSD was that for the services I wanted have, I had to come up with a kill script for shutting down or restarting them.

The challenge is especially hard, since the PID of the Elixir applications multiplies. And you have to kill them by hand. And because of fault-tolerant nature of Elixir, it kind of feels like killing a hydra:

Cut off one head, two more shall take its place.

So what can one do? Just create a release, and the executable contains start stop restart and a bunch of more useful commands¹.

So build it like this:

mix release

And for example if the application name is blog and it is made using phoenix, you can do this:

PHX_SERVER='1' MIX_ENV='prod' _build/prod/rel/blog/bin/blog start

For a service on FreeBSD I settled on this script for my blog:

#!/bin/sh
#
# PROVIDE: blog
# REQUIRE: daemon
# BEFORE:
# KEYWORD: shutdown
#

. /etc/rc.subr

name="blog"
desc="blog - imadethissite.com"
rcvar="blog_enable"

project_dir="/home/prma/blog"

mix_exec="/usr/local/bin/mix"
daemon_exec="/usr/sbin/daemon"

mix_opts="phx.server"
secret_key_base="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

pid_file="/var/run/${name}.pid"
daemon_user="[your_user_name]"

server_port=4001
log_file="/var/log/${name}.log"

load_rc_config "$name" :"${blog_enable="NO"}"

start_cmd="blog_start"
stop_cmd="blog_stop"
compiled_path="_build/prod/rel/blog/bin/blog"

PATH=$PATH:/usr/local/lib/erlang27/bin/erl

blog_start() {

  cd ${project_dir} || exit
  echo "[BLOG] Starting BLOG at: http://localhost:${server_port}"
  su - ${daemon_user}  -c "cd ${project_dir}  && PORT=${server_port} PHX_SERVER='1' MIX_ENV='prod' SECRET_KEY_BASE=${secret_key_base} $compiled_path start" >"${log_file}" 2>&1 &
  echo "[BLOG] started!"
}

blog_stop() {
  cd ${project_dir} || exit

  echo "[BLOG] Stopping BLOG"
  $compiled_path stop
  echo "[BLOG] Stopped"
}

run_rc_command "$1"

shell, eval are arguably more amazing. But the start and stop was the remedies that I could hardly find in the internet.↩︎

Making Many Many-To-Many Relations in Relational Databases

2025-05-30T15:22:28+02:00

Imagine you have a books table. And you have people table. You want to create a relation between the two table, giving credit to the people.

So a traditional many-to-many does this: 1. You create a table called books_people. 2. Each row of books_people have 2 references. book_id and person_id.

[book] 
       \
[book_id, person_id]
         /
[person]

If you only count authors this would work, perfectly.

But in making of a book, there are many more people involved: Translators, illustrators, etc. And sometimes a person could be also a translator as well. Or even an illustrator, on the same book! So, doing a simple traditional many-to-many does not capture their role. And creating a table for each role (translators, authors, illustrators) is not really feasible, and wasteful.

What do you do, then? We add a role column to the books_people table.

[book] 
       \
[book_id, person_id, role]
         /
[person]

And rename the table to involvements for good measure!

Today I Learned is not trademarked

2024-11-11T09:46:41+01:00

For the longest time, I believed that “Today I Learned” was an idea coming out of HashRocket. Which was a shame, since I really loved the idea, but I did not want to steal someone else’s idea. But, Today, I saw Julia Evans had a blog with the same name. Which caused me to reconsider my previous presumptions. So I searched for it, and lo and behold: It even has a subreddit!

So I got quickly to work, and here we have it!

Elixir on FreeBSD

2025-05-30T15:56:42+02:00

So, I deleted my blog. I deleted my sister-in-law’s work-in-progress website. I also deleted my Miniflux instance with the PostgreSQL Database it was using. With no back-ups.

Accidentally.

It was all using a single Debian 12 VPS, which I accidentally deleted when I was trying to delete another VPS instead. Dumb me.

I tried my best to deploy everything again, but even though nothing was changed, once again, the Debian’s old-is-good-because philosophy took another victim, and this time, it was me. The same problem also happened with Ubuntu. No surprises there. I am also wise enough to know nothing would be different with any of the RPM-based Linux distributions (CentOS, openSUSE, etc.).

A better OS

There was another option, one that boasted stability, and I was pleasantly surprised it wasn’t because of the same stupid shit that Linux server OSes so direly suffer from. You guessed correctly, FreeBSD. I started using it. Since the first ssh login, everything was much smoother.

Elixir

I also took the opportunity to rewrite my blog in my new favorite language, Elixir. Yes. I rewrote my Rust blog in Elixir. To continue with the craziness, it is actually much more performant than the Rust version ever was ¹.

Now I can absolutely go speak a day and night about how magnificent and wonderful Elixir is. And how, after experiencing Go and Rust, two statically-typed languages, I was surprised that a dynamically-typed language ² could actually be more reliable than a static one ³. But, suffice it to say that there is hardly any use case on the server-side that I cannot imagine Elixir being the best solution by a huge margin.

Right now, if you inspect this site, you will see two web-sockets being opened, and afterward, while you are browsing through the site, no additional HTTP requests being made. This is thanks to the power of the Phoenix framework’s LiveView library. Did I need that? Probably not. Is it more environmentally-friendly to not establish yet another TCP connection for each interaction, and instead have a 100KB (uncompressed) JavaScript? I am not sure! Was it for practice purposes? Absolutely!

IMadeThisSite.com

I’m also sporting a new domain. IMadeThisSite.com. Why? Well …:

The ownership of .dev does not put me at ease. Squarespace, as well as .dev‘s previous owner, Google, are not the most reliable and least predatory providers of any service. So my prma.dev domain always feels at a cliff’s edge.
I think I would enjoy putting this URL at the top of my resume, without any further explanations.
I mean, it is true! Ain’t it?

Some regressions

Along the way, there were a few compromises that I had to make:

I no longer use Djot. Why? Elixir does not have a good Djot parser, as of the time of this blog post, and I do not intend to write one for now.
I do not use FAMF for the post metadata. It is not because I lost faith in FAMF, I just wanted to see what fancy things I could do with it.

There are some speculations that it was because I was using MUSL instead of Glibc. Which I never found out. But it kinds of goes in the face of Rust’s motto of “A language empowering everyone to build reliable and efficient software”. Which seems only true, if everyone used a Glibc based Linux distribution, otherwise you might get a 10-second, CPU-at-100% load time for a fucking HTML at some unknown point in the code.↩︎
Only for now. José Valim (the creator of Elixir), Guillaume Duboc (A PhD student), and Giuseppe Castagna (programming language researcher) are working on bringing about Set-Theoric Types to Elixir. And judging by the other design decisions that José made, it is going to be fantastic.↩︎
It is absolutely not the case for any other dynamically typed language. The reliability comes, not because of the dynamic-ness, but despite it.↩︎

Services I No Longer Use

2025-05-30T16:03:05+02:00

I have lost interest in the Kagi search engine. I was very positive about it earlier, and I expressed my enthusiasm for it in my post called Giving My Experience of the Web a Makeover.

However, I have become disillusioned with their ongoing development. If you take a look at Kagi’s changelog blog, you’ll notice a strong focus on their LLMs. The blog post by Lori, titled Why I Lost Faith in Kagi, explains this matter further.

As an alternative, I am currently using DuckDuckGo, which I can’t say I enjoy all that much. But it is the lesser of several evils.

I have also moved my blog from uberspace. The reason was that I could not work without root privileges¹ or an up-to-date version of glibc².

Another service I said goodbye to was feedbin.com. Feedbin is a good service with a solid track record. However, if you’re not in the Apple ecosystem, you’ll have a second-rate experience. I am not part of that ecosystem, so after enjoying a year of using Feedbin, I replaced it with a self-hosted Miniflux and various third-party clients. I still recommend Feedbin to anyone who cannot (or would prefer not to) host their own Miniflux or who is in the Apple ecosystem. Feedbin is a really solid choice.

To install Docker or Nix.↩︎
Almost everything requires a more recent (>5.28) version of CentOS.↩︎

The XZ advantage over CrowdStrike

2025-05-30T15:29:42+02:00

May I remind you that the XZ incident ¹ was discovered because it was open-source (FOSS) by an open-source contributor employed at Microsoft, while the CrowdStrike ², a Microsoft Windows’ bug, was discovered when millions of people woke up to a fucking BSOD? It is as if there is something about FLOSS that prevents this kind of fuckup.

You know the XZ incident? A malicious actor called Jia Tang had inserted a backdoor into the XZ program. Likely targeting Linux servers?↩︎
A company called CrowdStrike distributed a patch to many enterprise Windows OSes through Microsoft’s update channel, bricking a massive amount of Windows installation — which, at the time of this writing, could only can be fixed manually.↩︎

"You are responsible for the consequences of your speech"

2024-07-14T20:17:49+02:00

I’m just joking! Why are you getting mad? – A comedian

It’s not a sexist joke, it is a joke about sexism. Why are you taking these jokes seriously? – Another comedian

Well, Here is a beautifully explained response from a linguist: You are responsible for the consequences of your speech (Yes, really).

Stupid Superhero Movies

2024-07-14T14:02:52+02:00

I hate this stupid doing the right thing ideological bullshit that superhero movies are pushing.

Oh, you have a trolley problem? The trolley will just suddenly fly, or a third track will just appear out of fucking thin air!

Just fucking grow up and take responsibility for the consequences of your actions. Will you?

gRPC was a mistake

2025-05-30T15:58:54+02:00

Ever since this morning, I have been bothered by the thought: gRPC added nothing but endless overhead to our product. Using it was an absolute mistake.

The greatest pitfall comes from the fact that the generated libraries are almost always useless directly, so you would need to define two different mappers, one from the Protocol Buffer-generated struct and one to Protocol Buffer-generated struct, manually. That mapping also takes away any performance, or ergonomic benefits gRPC may have had.

If you need streaming, gRPC is very good. But I would only use it in those specific circumstances, and every other endpoint would be JSON and HTTP ¹, and message brokers ².

And the compiler is also weird, the tooling is unsatisfactory.

The promised language agnosticism doesn’t pay off in small teams, since the generated library is usually so massive that reading it would take more time than just messaging your colleagues and asking for the fields in the JSON request body. In retrospect, we had much less trouble with end-points that did not incorporate gRPC.

For synchronous APIs.↩︎
For asynchronous APIs.↩︎

Files As Metadata Format

2026-02-27T16:53:53+01:00

YAML and TOML suck. Long live the FAMF!

What is FAMF?

File As Metadata Format (FAMF) is not anything horribly new. It is an extension of the Unix way of dealing with information.

Everything is a file.

Basically, each field of data is its own file; the key is the file name, and the content of the file is the field content. The exception is when the field is another set of information or a list of this information.

As an example, the metadata for this blog post could be structured like this:

title = "Files As Metadata format"
slug = "files-as-metadata-format"
published_at = "2024-07-05T21:17:36+03:30"
created_at = "2024-07-05T21:17:36+03:30"
updated_at = "2024-07-05T21:17:36+03:30"
group = "posts"
tags = ["famf", "information", "metadata"]

And the TOML would be added as some sort of header to the top of a Markdown or Djot document.

Now, if you are on Linux and you want to see the title of every post, you are kind of out of luck. You either have to create a pretty fragile script that uses awk and sed, and regex and won’t work tomorrow, or you will have to create/modify your own markup parser that gives you those titles. Never mind editing them.

Instead, imagine this file structure:

/posts
└──/files_as_metadata_format
   ├── content.dj 
   ├── upd_at
   ├── cre_at
   ├── title
   ├── slug
   └── tags

Each file contains only the information asked for. What is the content of upd_at? 2024-07-05T21:17:36+03:30 What is the content of the title? Files As Metadata format

If I want to publish it, I just do this:

date --iso-8601=seconds > pub_at # 2024-07-05T23:02:34+03:30

The folder would look like this. The application I built checks for the existence of the file and the validity of the date. And we are good to go.

/posts
└──/files_as_metadata_format
   ├── content.dj 
   ├── upd_at
   ├── pub_at <-- Here
   ├── cre_at
   ├── title
   ├── slug
   └── tags

A more advanced structure may look like this:

uses
├── cre_at
├── description
├── pub_at
├── tags
├── title
├── upd_at  
└──/things
   ├──/editor
   │  ├── main
   │  └── substitute
   ├──/languages
   │  ├── main
   │  └── substitute
   └──/os
      ├── main
      └── substitute

Imagine a page like my uses page. you have a list of stuff, and you have the information and content of the page itself.

Here you can see a key-value structure under things, where each value is its own object.

Now, you might have noticed the tags file. Isn’t that a list? Well, yes, it is, but it is just a list of single values. That is separated by a line break.

famf
information
metadata

You can easily parse this using awk, sed, fzf, your language’s split or lines function and on and on.

Why?

It is extremely simple; you don’t need to adhere to any kind of syntax, and you won’t need formatters. You won’t need special editors. You have the best tooling: bash, awk, cp, >, cat, sed, etc. If that’s not enough for you, you won’t need weird templates; they are easier to read, program, and track. You don’t need any parsers. You are free to use any language you want. You can put photos, zip files, binaries, texts, etc. You can also only read titles, publication dates, or any other fields without needing to parse all the files.

Wouldn’t that just reduce performance because of all the IOs?

Yeah, sure. I made a simple benchmark, actually. Here is the result:

bench    fastest       │ slowest       │ median        │ mean          │ samples │ iters
├─ famf  9.591 µs      │ 1.182 ms      │ 10.18 µs      │ 11.12 µs      │ 1000000 │ 1000000
╰─ toml  7.852 µs      │ 726.9 µs      │ 8.132 µs      │ 8.673 µs      │ 1000000 │ 1000000

As you can see, there is not that much of a difference. And this benchmark favors TOML, since the TOML is not inside another markup file, in which case you must first extract the TOML from that file, before you can parse it. While the FAMF structure does not work any differently, . Added to that, we are not counting the cases where you just want to get a list of titles. In those cases FAMF only opens the title files, while TOML, in the best-case scenario, has to use a specialized parser to read the stream of content, parse it until it reaches the end of TOML, and then it will give you the value. Which is not even what happens in the most actual real-world cases.

How about all the tooling?

Yes TOML, YAML, JSON and others have great tooling. You know what else has great tooling? Files! Every file manager, file manipulation tool, and file search tool is helping you navigate those bad boys.

The only thing lacking are schema validation tools.

And that should not be that hard to implement as well.

Is this actually new?

I am not sure. It should not be. But it is not a common practice outside of Unix file systems. And even then, .conf and .ini files, as well as other weird formats, are not uncommon.

If it is a better idea than JSON why won’t everyone use it?

I don’t know. Who cares! Shut up!

Update on 2024-07-08

Some people on lobste.rs started a very interesting discussion. One that is worth considering. And that is the limitations of how the file is being stored and accessed, and in general, file-system limitations; And lack of atomicity in changes.

The impact of a high number of inodes and the limitations of the number of inodes in Unix-like systems. A very valid point. For which I created 4 million directories, under each 40 text files, with different text content. I replaced a random file’s content using good ol’ sed. And, of course, I timed it. I did the same thing after deleting every directory but one. And timed it again. And did that manually a few times. The fluctuations in the performance of the system made more difference to performance than the existence of 3,999,999 other directories.
Atomicity in changing the information is also another interesting point. For example, if I want to update the content.dj file, I also need to change the upd_at file as well. In such cases, if I suddenly get interrupted, I might have changed the content.dj without changing the upd_at. Also, another program might have had the same idea of changing it. That is not desirable. However, TOML, YAML and friends only offer those nifty features if you are putting everything in one giant file. And that is because you have to load all the information at once, lock on the file, and then rewrite the whole thing. You may also think that you might change them line by line. But that is assuming that you know which lines, you have the proper serializer, and you don’t mind at least loading all the information on the memory or streaming the file, which only helps you with data-races.

In all of these cases, the answer is not TOML, YAML or JSON — or FAMF for what it’s worth. It is goddamn database.

Old Is Not Lazy

2024-06-27T08:37:00+02:00

When I was growing up, I viewed adults aversion to the new thing as a result of laziness.

Then I grew up. And I am noticing that many of the problems we are facing on a daily-basis, have shitty new solutions. When I look into before my time, I often find out there is a well tested, mature, and efficient solution, with its only fault being “not as shiny”.

I become less and less contempt with what I get with “new” stuff. The old stuff is also new to me. But they are not new to the world.

Simplicity Of Maintaining

2024-06-25T13:47:00+02:00

I think there is conflict with people that confuse simplicity of a programming language with simplicity of writing, reading and maintaining a program written in a language.

Iterators increase the complexity of the language, but at least for me, decrease the complexity and extensibility of my codes significantly.

Blog From Scratch

2025-05-30T15:42:27+02:00

First off, to all those who have subscribed to my feed: I am genuinely sorry for the massive amount of spam in the feed!

I have rewritten my blog from scratch. What was once a statically generated blog ¹, is now a fully functioning web server written in Rust.

Why

TL;DR: Learning and flexibility.

SSGs are great. They make the web a better place to be. They make it faster, lighter, more accessible, and more stable. You have a couple of pages, you create those pages, and… bam! You have a pretty and stable site for yourself. They have many, many varieties. Most, take a few templates and some Markdown files, and create a bunch of HTML pages. My favorite of this bunch is Hugo which pretty fast, feature-full, and well-structured. Others are more interesting; they basically create the same pipeline: content + template = HTML. Yet they have different presumptions. Of these bunch, I absolutely adore Soupault. This one uses HTML and CSS as their templating engine and does not presume any particular content type. You bring your own converter. You may use anyone or a few different Markup languages. It is fantastic.

However, each has its own flaws. And you can only go so far with static pages.

Some of the things that have constrained me:

I like to be able to choose which Markup language I use at each moment. I might like to write some on Markdown, others in Djot, Others still in Org-Mode. And then I do my own modifications, macros, and extensions. Some SSGs give you some choice in the matter. But other than Soupault, you are usually at the mercy of the choices of the SSG maintainer.
I would like to have dedicated feeds for each category. Most SSGs avoid letting you do that or give you limited choice on the format of the feed.
You can do wonders with templating languages. But the tooling is usually horrible; the disasters only manifest themselves when you visit and validate each page, and doing things like showing specific posts only on the feeds requires the SSG to make the metadata available to you and for you to do pretty clunky conditionals using the templating language.

And then, there are things that you can only do, when you have access to the Runtime of the server.

You cannot receive drafts and posts without having access to the coding environment — I don’t do it right now here, but I Intend to add one in the future.
Some things, like Web Mentions, require the access to server.
Having more interactivity, using things like HTMX, is simply not possible using SSGs.

Add to all of these the fact that I am a Back-end developer. Sometimes I may want to experiment with different ideas. Some of these ideas may not be a good fit for the projects I work on, during my day job. Or my teammates may not agree with me about their suitability. Having a web server as a home lab has been a great desire of mine!

What did I choose?

Over time, during the creation of the web application, I have experimented with different things. And I have made choices about others. Let me explain each.

Rust is a pretty great language. But One thing it is not is simple. I am very confident with Go. And I am also learning Gleam. Both of them later offer a much simpler workflow. However, wanting to have maximum flexibility, Rust is a better language for me. Added to that, things like dealing with nil-pointers in Go have been a source of constant pain in my ass. Rust offers less chance of Runtime error.

You may not have heard of Djot. Djot is created by the creator of Pandoc, the command-line utility that converts different document formats. It is pretty similar to Markdown, but with the significant advantage of being created by someone who has spent a significant amount of time working with markup languages instead of some random blogger suggesting something at some point in their blog post.

I am using a library called InkJet which uses tree-sitter to add syntax highlighting to my code blocks. I have injected it into the Djot parser I use, called Jotdown.

Also, I have decided to hard-code the contents for now. So at compilation time, every Djot file is read and embedded inside the web server. This just simplifies things for now for me. But I have implemented the whole thing so that I can inject dynamic contents later on.

During my API testing, I have noticed that the performance of the new version could not match the statically generated one, using the built-in server of Hugo. Upon further inspection, the culprit was the rendering process. Which took the time of serving up each page on the local storage from 5ms to 15ms. Though not a lot, It could be easily fixed using a lazily created on-memory cache layer for each page and feed. So each page gets rendered only once, right after I update the site. Easy.

`Uberspace`

Thanks to the suggestion of Benjamin Hollon, I have found a really small-web-friendly hosting service called uberspace.de with a generously priced €5/month service. The OS is a bit out of date right now ², and that is causing a bit of a pain during the build process, but honestly, their service is so lovely and Linux-friendly that I could not consider any other service!

What have I lost?

Everything has its trade-offs. And there are some really great reasons for not doing what I have done.

Previously, adding a blog post was as simple as creating a file, and running a Justfile ³. Right now, I have to create a couple of files, add the post to the dedicated array, and then build it using Nix Flake ⁴, and then rsync the resulting binary to the server and restarting the service using ssh.
Added to that, the compilation time is significant. And CPU-intensive. For some reason, some of the C dependencies of Tree-sitter that I depend on are not friendly to incremental builds. I am seriously considering dropping syntax-highlighting as a result!
Another con of this method is obviously having to pay for it! I cannot mooch off of sourcehut pages anymore!

It was generated using Hugo ↩︎
I have contacted their support team. They told me that they are working on an update.↩︎
Or Hipster’s Makefile if you will!↩︎
The build pain that I mentioned earlier!↩︎

Evils Of Effective Altruism

2024-05-13T11:24:00+02:00

I have been a Utilitarianist my entire life. While I didn’t have a name for it, I evaluated every action based on its eventual effect on the suffering and happiness of conscious beings.

Being born in an Islamic country, I was aware that my views were not shared by many. However, I always wondered why¹.

I instinctively became a feminist in an all-boys school, even in one of the most patriarchal countries in the world. Additionally, I ended up becoming a Vegan without any social proximity to anyone with that identity.

I became familiar with live and dead proponents of this branch of Prescriptive Ethics while exploring Ethics during my early 20s. Among them, I found agreement with some, such as Peter Singer, who advocated for Animal Rights and provided valuable insights into maintaining a consistent utilitarianistic view.

Peter Singer introduced the concept of Effective Altruism in recent times. In essence, it asserts that when being altruistic, your intentions are irrelevant. What truly matters is the improvement in the world following your actions. For example, a donation to charity that builds a church in your neighborhood is less ethically valuable than a donation that funds vaccinating children, even if the latter was done as a PR stunt.

However, as Molly White have so well demonstrated it ², Billionaires and Millionaires in Silicon Valley have bastardized this idea, to the point that they only do the PR stunt, if we are lucky.

In his book, The Most Good You Can Do, Peter Singer provides an example of one of his students who joined Wall Street to earn a significant amount of money, which they could then use for effectively altruistic purposes.

The example provided was meant to demonstrate the seemingly counterintuitive reasoning behind being effective in altruistic endeavors.

Those with significant interests in maintaining the status quo found parts of this example to be extremely convenient. In particular, the notion that “hoarding money can be ethical!” appeared to be their primary focus, while other aspects of the idea were largely overlooked.

This kind of bastardization of Utilitarian Ethics has been done before, most prominently by Joseph Stalin, to justify purges and famine. Specifically he used the term “Greater Good”. Which I believe at least has the tone of Utilitarianism.

In this case, we can argue that Joseph Stalin did not actually adhere to any utilitarianistic ethic principles, as his actions did not bring about much utility as a consequence of his actions. However, consequences are hard to predict, and judgments can only be made in hindsight. Due to the practical vagueness, anyone can find rationalization for any action. So, if this prescriptive ethics is so permissible that does not help anyone, is it really an acceptable theory?

In this case, Deontology fares much better, as it advocates specific actions. For instance, “lying is bad.” This is really helpful, as it allows you to simply avoid lying and be considered good. There is a quote used by Immanuel Kant ³ in his book Project for a Perpetual Peace: A Philosophical Essay:

Fiat justitia, pereat mundus

This quote, “Fiat justitia, pereat mundus”, literally means “Let justice be done, let the world perish”. In a deontological absolute world, people would not lie, even if one little lie could save the world from burning.

This example highlights an extreme case of adhering to deontology, but it also showcases the simplicity and straightforwardness of the concept.

However, even though rules of deontology are simple to know and hard to adhere to, there is a rich history of religious figures justifying their endless lies and actions in the name of deontological rules.

In the city where I reside, the Morality Police imprison individuals, administer corporal punishments, and even sanction death sentences, all justified by the Deontological rules of Islam. Additionally, there is the concept of Expedient Lies, where one lies for a specific purpose, if it helps the religion.

Oh we landed on the same place after all!

In our Effective Altruism case, I see a parallel. Justifying the accumulation of wealth without using it to significantly improve the world, under the guise of Effective Altruism, is akin to actively contributing to the preishment of world while not engaging in any acts of moral value, in the name of Deontology.

The intentional misuse of philosophies to justify horrendous actions is not a new phenomenon, nor is it exclusive to utilitarianism. Any moral perspective can be manipulated to rationalize any behavior.

But there’s another problem in this situation. A prescriptive theory should provide guidance. It should assist us in making decisions in our everyday lives. If it’s permissive, allowing anything to happen, is it still a good normative theory?

Here, I remain undecided. One argument for utilitarianism is that uncertainty does not usually hinder us. There is evidence suggesting that food X may cause cancer, and some evidence refuting it. We might not have a definitive answer at present. The current uncertainty in biology does not compel us to abandon the field entirely and gravitate towards the more straightforward and certain Jewish food regimen. But predicting the future is far from simple. As uncertainty grows, so does the challenge of adhering to utilitarianism.

This is often evident in more intricate situations. Where there is a likelihood of the interests of future beings conflicting with the social interests of presently living individuals.

In certain more evident instances, like slavery, animal cruelty, and sexism, utilitarianists have typically been ahead of their deontologist contemporaries.

For me, I think I will stick with utilitarianism. I believe that, in general, utilitarianism has been more clear than some other theories. And I don’t think individuals who abuse this theory are any more prevalent than those who have misused deontology.

You may have observed that I have not discussed another significant branch of prescriptive ethical theories, Virtue Ethics. Although I can appreciate the importance of incorporating virtues into one’s actions, I don’t see it providing any guidance on what is good and what is bad.

I have recently familiarized myself with the idea that there could be distinct Moral Instincts or Moral Senses influencing people’s diverse choices in Prescriptive Ethics. I might be situated at the far end of the spectrum in this context. If you want to know more about this, look into “Moral foundations’ theory”.↩︎
A very interesting and thoughtful post on her blog Citation Needed titled: Effective Obfuscation ↩︎
He used it as a demonstrative example, but he did not originate it.↩︎

u8 vs. u128

2025-05-30T15:52:11+02:00

A few days ago, I read a discussion on a YouTube video. The essence of the discussion was that memory layout and memory size matter.

So, an unsigned ¹ 8-bit integer (or u8 in Rust) takes up less memory and thus is faster than a u128. However, someone else added a caveat: the memory layout can differ based on the architecture. Another point made was that 32 and 64-bit integers are probably faster, as modern CPUs optimize these values thoroughly. Therefore, a u8 is probably slower than a u32.

On the face of it, the argument made sense. However, two things made me wonder:

Is it true?
Are the differences so vast that I should consider using u8, u32, or u64 for IDs of my structs instead of u128?

Like a good Bayesian thinker, I opted to look into some evidence.

So, I’ve written a program:

#[derive(Debug, Clone, serde::Serialize, serde::Deserialize)]
struct SomeThing {
    item: u128, /*and this one*/
}

fn make255() -> Vec<SomeThing> {
    (0..255u128/* <- changing this number*/)
        .map(|n| SomeThing { item: n })
        .collect()
}

// 65_535 * 255 =  16_711_425 // numbers
// 33_422_850 * 2 = 33_422_850  // Since we are reformatting those numbers once again when converting them back from strings
// 33_422_850 * 100 = 3_342_285_000 // For 100 times
fn main() {
    let material: Vec<_> = (0..u16::MAX/*65535*/).flat_map(|_| make255()).collect();
    let stringed = serde_json::to_string(&material).expect("fucked");
    let _unstringed =
        serde_json::from_str::<Vec<SomeThing>>(&stringed).expect("could not deserialize");
}

I created four editions of the above code, with u8, u32, u64, and u128.

I built them using cargo build --release.

Each run of the program would create around 33 million structs.

Each containing a number between 0 to 255 ², and then turn each into a JSON string and then turn them back into SomeThing structs.

As a backend developer, this covers one of the more important concerns of mine, which is serializing and deserializing ³.

I used hyperfine to run each binary 100 times. This means that for each type, we created 3 billion units.

Here are the results for the u8 version:

❯ hyperfine  --runs 100 ./u8version  --export-json 8.json
Benchmark 1: ./u8version
  Time (mean ± σ):     921.9 ms ±  72.6 ms    [User: 854.1 ms, System: 65.4 ms]
  Range (min … max):   801.2 ms … 1082.6 ms    100 runs

And here are the results for the u32 version:

✦ ❯ hyperfine  --runs 100 ./u32version  --export-json 32.json
Benchmark 1: ./u32version
  Time (mean ± σ):     957.6 ms ±  70.0 ms    [User: 860.1 ms, System: 95.1 ms]
  Range (min … max):   876.6 ms … 1134.1 ms    100 runs

And here are the results for the u64 version:

✦ ❯ hyperfine  --runs 100 ./u64version  --export-json 64.json
Benchmark 1: ./u64version
  Time (mean ± σ):     969.8 ms ±  21.9 ms    [User: 836.9 ms, System: 130.3 ms]
  Range (min … max):   890.5 ms … 1038.4 ms    100 runs

And finally, here are the results for the u128 version:

✦ ❯ hyperfine  --runs 100 ./u128version  --export-json 128.json
Benchmark 1: ./u128version
  Time (mean ± σ):      1.421 s ±  0.022 s    [User: 1.210 s, System: 0.206 s]
  Range (min … max):    1.371 s …  1.473 s    100 runs

So, compared to the u8 version, the u32 version took only 3% more time, the u64 version only 5% more, and the u128 version around 54% more time.

The difference between u8, u32, and u64 is so minuscule that I cannot help but agree that they are extremely optimized. It’s probably not faster than u8, but it is fair to say that when you are concerned with performance, u64 is still as solid as u8.

u128 is not as performant as the other types. But at this point, we should consider the amount of difference in time. Between u8 and u128, there was only a 15 nanosecond difference. To put it into perspective, you would need 4 billion u8 instances instead of u128 to save one minute of computation time on my computer.

In a back-end environment, such a small difference seems extremely negligible, making u128 with its extreme tolerance for integer overflow seem like a good deal.

Update 3 hours later, same day

Joshua Barretto suggested that I should use black_box to fence against possible compiler optimization. I took the benchmarkds again, and the results took significantly longer, around 50-60% more time. But they kept the same proportions. Specifically u8 took 1.498 seconds, u32 took 1.565 seconds, u64 took 1.615 seconds and u128 took 2.289 seconds.

Here is the modified code:

use std::hint::black_box;

#[derive(Debug, Clone, serde::Serialize, serde::Deserialize)]
struct SomeThing {
    item: u128, 
}

fn make255() -> Vec<SomeThing> {
    (black_box(0..255u128))
        .map(|n| SomeThing { item: n })
        .collect()
}

fn main() {
    black_box(|| {
        let material: Vec<_> = (0..u16::MAX)
            .flat_map(|_| black_box(make255()))
            .collect();
        let stringed = black_box(serde_json::to_string(&material)).expect("fucked");
        let _unstringed = black_box(serde_json::from_str::<Vec<SomeThing>>(&stringed))
            .expect("could not deserialize");
    })()
}

Unsigned means that it cannot contain anything less than 0.↩︎
That’s because u8 is limited to 255.↩︎
However, this may mean that another confounding factor is tinting our data: the libraries involved in serializing and deserializing may be the source of the difference. However, since I am looking for applicable scenarios, this works well in my favor.↩︎

Go Vs. Rust Readability

2024-04-14T22:19:00+02:00

Traditionally speaking, Go and Rust are not direct competitors on many fronts. Each take different trade-offs. But more often than not, you might need to choose one over the other. It is compared in the niche the other fails. Like low-level system development, which Rust easily rules. Or maybe dev-ops tooling which Go is easily good at it.

However, there are many overlaps in their use case. Think high-performance web-servers. In those spaces, we should compare other things. Like readability and maintainability of language. In this post, I want to share my thoughts on readability.

Tl;DR

Rust is not less maintainable than Go because Rust is less readable.

What I do not disagree with

Just to be clear, although I’m making a case for Rust and arguing that readability should not be as much concern, I would like to make clear that I’m not arguing against these common-sense statements:

Go is more readable.
Go has less overhead for people with no previous experience with language.
Readability is generally what you want.

Why readability is good

English is more readable than any programming language. However, readability is not the only measure that we are using for choosing a language.

Readability and clarity are not inherently good, rather it is a proxy for something else we value: A readable code helps us understand the flow of information in order to understand its logic, capture its bugs and extend it, easier. A line of code is read in many situations:

I want to find out how a piece of code can give rise to a specific runtime bug.
I want to audit it to see if it exposes any specific vulnerability, data-race, etc.
I want to add features to it, and I want to know where and how I should plug the new functionality to.
I want to make a code more robust, document it and make it more available for other people by refactoring it.
I want to review the code of my colleague to see if a set of fresh eyes could capture a new bug, or an inconsistent styling with the rest of the codebase.
I want to understand what a code base does. Maybe I’m trying to see if a software is spying on me, or maybe I’m trying to understand the way it calculated my taxes.

These are all noble pursuits. And in all these cases, readability is vital in preventing disasters and better experience in onboarding others.

Go’s readability is probably one of its best features. At my current and previous jobs, I have had to jump into different code bases with different levels of legacy and problematic codebases where junior developers with no-idea of idiomatic ways of coding Go left their projects without any context for the next developer.

Such low quality codes should take forever for one to decode. However, because of the beautifully simple syntax of Go, I could start to be productive and sending PRs in less than a day. Have you seen a codebase where all the back-end code was coded by a narcissistic lone-wolf meth-addict? Well, I have, and it’s an absolute shit-show. Yet, I committed my first edits in 3 hours. Go is excellent at that. And I can understand how a huge tech company with very quick employee turn-over can give rise to such language. Kudos to the Go team.

Surrendering Users' Data at Gun-Point

2025-05-30T15:32:12+02:00

Approximately a year ago, large companies in Iran began sharing their users’ information with the government.

As a result, people began boycotting these companies. Engineers working at these companies faced criticism for handing over the data and continuing to work for these organizations. In response, they posted on their social media platforms, seeking sympathy and asking: “What would you have done if the army intelligence simply walked in and demanded all your data?”. That is a fair question. I cannot but agree that, given the same situation, I would have likely done the same.

However, I was not in that situation. And that is the point.

The engineers in these companies have built an impressive body of knowledge about their users. So much so that some of them have managed to assemble a team of AI- and Machine-Learning- experts, supplying their marketing teams with predictive information and trained models to increase their market share by playing with prices and outperforming their competitors. So the amount of information they have gathered is indeed impressive, and it far exceeds the amount needed for the app to function effectively.

So, why do these engineers continue to store data they don’t actually need? I have three possible reasons:

They lack creativity in finding solutions that only gather information that is justified by the need.
They are unwilling to risk their jobs.
They lack understanding of the risks associated with storing these data.

Let me offer an example of how things can be better:

Imagine that Tim is tasked with cleaning up inactive users from the database and moving their data into an archiving database.

How can Tim recognize the inactive users?

Tim comes up with the solution of keeping track of user login dates. A giant append-only list for each user, where the time and date of each login is appended. From this data, Tim can identify users who have not logged in for over six months.

This solution does more than just the job. It also provides a body of knowledge about user habits, their access to the internet, and the ratio of actions per login. This information, combined with data from other sources, become rich data sources that allow tracking every single step any user takes.

Instead of the append-only list approach, Tim could have implemented a simpler solution using a boolean value for each user. Initially, this value would be set to false, and once a user logs in, the database would update it to true. After six months, Tim could easily generate a list of users who have not logged in. This approach is more cost-effective, less susceptible to abuse, and still achieves the same result as the more complex solution.

Storing plaintext passwords is undeniably a mistake, as it provides more information than necessary for anyone with good intentions. To address this issue, passwords are hashed instead. The purpose is not to know the actual password but to confirm, with reasonable certainty, if a user has provided the same password before.

A salted hash can achieve this goal, ensuring that the stored information is sufficient for verifying user authentication.

Similarly to how storing plaintext passwords is a mistake, any other information on our databases can also be misused to harm users.

So if you’re more than just digital mercenaries, solely focused on the next paycheck without giving a shit about the consequences for others, I implore you to adhere to some professional principles. Don’t blindly agree to every request from the marketing team. Instead, ask yourself if you would be comfortable with your own data, in these databases, being breached or falling into the hands of an authoritarian regime or even your marketing team.

"Why We Can't Have Nice Software"

2024-02-06T09:23:00+01:00

As a young pup in my early twenties, I once held a naively hopeful perspective on those massive entities we call corporations. I foolishly believed that Big-Tech companies actually possessed good intentions. Why would anyone with a choice between a morally satisfying choice and mere pittance of extra profit, go for the latter? Why bear such a guilt for slightly higher profit? So what if Google and Microsoft produced buggy or sub-par products? They probably have bad engineers, and slightly unsavory intentions.

Many years later, and after observing countless fuck-ups by corporations, I no longer feel as optimistic about the amount of fault that lies in their intentions as I see perfectly competent software engineers who work in these companies. The hierarchy of these companies incentivize middle and top-level management to pressure for more and more of these slightly-higher profits. Although the profit may seem proportionally small, it has significant implications for every managerial employee’s career.

Emphasizing the adverse effects of such forces on consumers, Andrew Kelley published an affectionate essay on his blog, called Why We Can’t Have Nice Software, which I highly recommend reading.

git-rebase.io

2024-01-31T13:32:00+01:00

Ever since a while back, I started giving a damn about my Git commits and workflow. Before that, I used git mostly as a tool to push my code to GitHub.

However, as soon as I began working with Sourcehut and contributing to the Pimalaya project, I found myself caring more and more about each commit and the information contained in them.

Doing so, however, can be impractical without using git rebase. git rebase is an amazing tool for organizing and cleaning up commits, as well as organizing a patchset. However, due to its many functionalities, it can be overwhelming to learn from Stack Overflow or random Google searches or using the --help flag.

Drew DeVault created git-rebase.io, which is a great tutorial for learning how to use git rebase -i properly. I strongly suggest trying to run each command and following along with the tutorial, as they can be more concretely learned when you do.

git-send-mail.io

2023-12-29T16:10:00+01:00

Git is an amazing tool, and a massive one at that. Most of us know and agree about that fact. Sure, there are things that use more interesting approaches to the underlying data structure ¹, but for the most part, Git offers a world of wonder that no other system has.

As it happens, many developers only use a handful of features of Git, which is a shame, since those features fit much better in a workflow that includes more of Git’s features ².

One such feature is git send-email, which I have been using recently to contribute to the Pimalaya project ³.

This command lets you send a patch-set ⁴ via email to someone or a mailing list. This is how Linux Kernel development is done and how SourceHut ⁵ works.

However, this workflow is foreign to most developers. Drew DeVault ⁶ created a very nice webpage on git-send-email, which guides you through using this rather amazing command.

I’m referring to Pijul and Darcs.↩︎
This, of course, is thanks to the mass adoption of GitHub, which, to be frank, offers a workflow that is probably mostly advantageous to absolute beginners in programming and subpar to full-time developers. Although I can see myself being wrong on this point as well.↩︎
Probably one of my upcoming recommendations.↩︎
Or a set of commits, if you will.↩︎
Another one of my upcoming recommendations.↩︎
Drew co-created SourceHut, which should also connect some dots for you as well.↩︎

Guilty Pleasures

2023-12-26T20:57:00+01:00

For a long time, I have been wondering about my guilty pleasures, trying to figure out which pleasure, in particular, I feel guilty about. I think about other people’s answers, looking for things one does not need much practice to enjoy—‘satisfactions of pigs’, as John Stuart Mill would have put it. He famously wrote:

It is better to be a human being dissatisfied than a pig satisfied; better to be Socrates dissatisfied than a fool satisfied.

He argued that the quality of pleasures is much more important than their quantity. Listening to Bach, even if it brings little joy to someone, would always trump the manic joy of attending a Britney Spears concert.

However, as it happens, I am not a Millian. I find that argument bogus. I don’t feel any shame about listening to the cheesiest ’80s music and then complimenting that with Mozart’s Requiem.

Don’t get me wrong. I have a strong sense of guilt. I am a vegan. I help others when I can. And I regularly make life-changing decisions that may not favor my well-being but end up benefiting others. I just have not found many places in my life where guilt and pleasure co-exist.

I figured that my sense of guilt probably sucks every ounce of pleasure from different activities. That theory seemed shaky, at best.

Then, just an hour ago, it hit me. I have been looking in the wrong place. My two guilty pleasures? Fine coffee and fine audio equipment. It might sound quite strange to feel guilty about these. But consider this: My ethical stance in life is firmly rooted in Hedonistic Utilitarianism, which basically means to do whatever it takes to bring the most amount of pleasure and the least amount of suffering to the world. For example, the pleasure I take in eating meat does not surpass the suffering it brings to the animals from which the meat came.

If I have some amount of money, I should spend it in such a way that it creates the most joy in the world. That surely includes myself, but probably a hungry kid on the street could derive much more pleasure from the same amount of money I am spending on headphones and coffee. For sure, these lavish purchases mostly fall under the mid-range products of a European household. But I live in a third-world country, and even with the salary of a developer, they are still more than most people are willing to pay, here. I am ashamed to admit that I enjoy fine coffees and fine headphones.

It turns out, I am a proud pig and an ashamed Socrates.

Honk! Honk!

Fake Nuance

2023-12-17T19:10:00+01:00

On a daily basis, I express an outrageous opinion about technology.“Apple should abandon Swift altogether and use Rust instead of just dancing around this move” I once declared. To the best of my knowledge, that is a fair opinion. If I am a fool for thinking this way, then I am a fool. If, instead, I state that all languages have a good reason for being there and express that Swift is something amazing just to avoid sounding foolish, I will be a silent fool, but a fool nonetheless.

At least when my foolishness is expressed, some good Samaritan or an offended opposer might add nuance to my opinions and make me a wiser person than I currently am. In five years, I will be wiser, while the person who chooses to sound wise when they are not will still be a fool.

Taking the fool-forever-road is so ingrained in our polite and technical manner that we don’t think about it much. A rather obvious example of this is when we respond with “It depends” to any technical question. My friend, if you don’t know how to answer the question of “what it depends on” clearly, you are not being nuanced; you are just a fool like the inquirer of the question, hoping that your intuition comes to your rescue when you are held at gunpoint for a decision.

Be a fool once in a while; it is much better than being one all the time.

SOLID is a premature optimization

2025-05-30T15:23:48+02:00

Honestly, the primary challenge I encountered with complex codebases originated from adhering to SOLID principles. Surprisingly, they appeared to turn the straightforward task of making any changes into a Herculean feat. Introducing numerous cumbersome abstractions also took a toll on performance.

Talk about actual premature optimizations!

I much prefer something like CUPID principles. More information on CUPID

Git For Persistence Layer

2025-05-30T16:00:01+02:00

I’m entertaining with the idea of making a personal web-server that uses git instead of a database. Yet I don’t have any idea how well such a thing would work. More importantly, I’m not sure about the API. Perhaps instead of using the standard REST, I could use Telegram or Matrix instead of creating a whole frontend.

Holidays For Rustaceans

2023-12-04T09:11:00+01:00

For Rust developers, the passion stems from a combination of 10% performance, safety, and tooling. The remaining 90% is the bliss of holidays free from on-call disruptions.

Popularization of The Wrong Thing

2025-05-30T15:53:41+02:00

There are people who proudly declare:

I used to like X, but then it became popular, so I don’t like it anymore.

I fucking hate these people. What a bunch of douche-bags. Do you consider yourself superior to others?

However, there are circumstances where I believe that this perspective is valid and can be seen as a positive stance to take.

The Adventurer

There is a group of people who enjoy uncovering unknown valleys, experiencing them, and staying committed until they reach a more popular stage. They relish the thrill of discovery and take pleasure in popularizing things.

One such group is composed of individuals who embrace emerging programming languages, with Zig and Nim serving as good examples. Some of them thrive in the startup scene, where they are comfortable taking risks and making decisions that have a tangible impact. However, in a more stable environment, when things become mainstream, their services are no longer required. Their advocacy and contributions are graciously acknowledged, and they happily move on to the next cutting-edge endeavor—a clean break.

The Adventurer’s Friend

Similar to the first group, there are individuals who relish spending time in less mainstream communities. It’s true that you can always find individuals with egotistical tendencies in these non-mainstream groups, as they seek to exert authority over others. However, there are also truly brilliant people who are dedicated to their craft, and they are both driven by their passion and drive the development of their crafts. You might encounter them later on as they become giants in their fields, but at that point they may become too preoccupied to engage with people they don’t already know.

These communities are incredibly dynamic and enjoyable. Your actions can influence the trajectory of the entire community’s existence.

The Misunderstood

The reason for this post is that I’ve recently found myself in this group.

If you delve into any modern art history book, you’ll encounter fascinating descriptions of abstract art. Its intended message is simple, in contrast to figurative art, which aims to depict tangible subjects. Abstract art seeks to convey emotions without adhering to reality, much like instrumental music. The history of abstract art is marked by experimentation and truly impressive works, both technically and emotionally.

However, if you search for abstract art on most art trading websites or social media, what you’ll discover is a type of decorative art. It experiments with various elements but often lacks novelty. Nevertheless, it can add exceptional charm to your hallway’s wall. This is a valid art form that enriches the world. However, for those seeking experimental abstract art that conveys emotions like hatred or sorrow, it’s increasingly challenging to find it because the more popular usage of the term ‘abstract art’ leans toward the decorative.

However, what recently placed me in this group was not the above. Instead, it was a few years ago when I fell in love with a genre of music called Lo-Fi. Lo-Fi music is a genre with a nostalgic approach to music, incorporating background noises from phonographs, sound clips from old movies, and yet embracing contemporary techniques. Apps like Loffee perfectly capture this kind of music for me.

Unfortunately, over the past couple of years, Lo-Fi has been used interchangeably with chill-hop ambient music. Most people use it as background music during their focus sessions, and you might hear it in coffee shops and YouTube videos. The famous Lofi Girl YouTube channel also features music that I can only describe as ambient chill-hop. If you search for Lo-Fi music, you’ll predominantly find that genre, which saddens me because I spend hours searching for music in my favorite genre, only to encounter ambient music.

Dear Readers

The reason for my post is to ask if you are aware of any good sources for the Lo-Fi music I’m searching for. If you do, please reach out to me.

If, by chance, I discover a reliable source, I will update this post below this line.

Diversity Quotas

2023-11-04T12:31:33+01:00

Honestly, I cannot say that diversity quotas are radical feminism; or in any terms extreme. Especially since they are implemented in societies that have endured thousands of years of cultural, institutional, and governmental oppression of women and minorities, which, we have yet to witness significant progress in achieving true equality for these oppressed groups.

Equal opportunity does not entail placing the food on top of the trees and then asserting that the whale just didn’t take it while the chimp did.

Python And NixOS

2023-11-02T08:33:00+01:00

The problems surrounding Python programs on NixOS seem never-ending. I often have to refrain from installing most Python programs. On each update, another one of them breaks during installation – either their tests don’t pass, or their dependencies fail in some way.

And to be honest, I give the benefit of the doubt to NixOS, seeing its result with other languages, and knowing what I know about pip.

Test of 10x Developer

2023-10-16T21:40:00+02:00

The true test of 10x developer is that you put two of them together, each debugging each-others code, then you if they kept their 10x status, they are the true 10x developer. My guess would be that their population will reduce to less than that of unicorns’.

Usage Restriction of Software Licenses

2023-10-16T21:35:00+02:00

Please think twice before saying, “usage restriction is good because you might want to prevent someone from using your tool for war, crime, etc.”

Like, you know that a poorly enforced license won’t deter a person in that situation from using your software, right?

There are probably better arguments for including usage restrictions in a software license; this one is a terrible one.

Rust Skills Transferability

2023-10-16T21:34:00+02:00

While the skills learned in Rust, like working with the borrow checker, may seem limited to Rust itself, the claim of their intransferability is somewhat overstated.

Understanding the borrow checker is specific to languages using it, but the approaches it encourages are typically advanced and valued by experienced engineers. And often, it is evidenced by the patterns that are simplest to implement.

The obvious exception to that is unwrap() and expect(). Even though the ? operator is a step towards simplifying that process, it is undeniable that the hassle of creating and managing errors is not simpler than the extra 8 characters introduced by the .unwrap().

Rust's Productivity

2023-10-16T21:34:00+02:00

I think the best way to characterize Rust’s productivity, is to put it on a quality axis.

If you want low quality code (prototyping, etc.) Rust is much less productive than the alternative.

For medium level of quality, Rust is similar to others.

For high quality code, Rust is much more productive than any alternatives.

Quality is intentionally vague, to encapsulate performance, leanness, documentation, and security.

Prototyping in Software development

2023-10-16T21:34:00+02:00

I think when you are proposing a fast prototyping phase in programming, you should be able to answer these questions:

What don’t we know that we hope to find out with this prototype?
Why is this the best approach for finding the answer to that question.
When is the prototype going to be deleted? If you cannot answer to these questions, what you are proposing is not a prototype, it is prototype quality end product. A knock off, if you will. A bad practice distilled.

O'Reilly Book Covers

2023-10-16T21:34:00+02:00

There is a retired burned out offended wild life photographer out there responsible for the O’Reilly’s book covers, after they were told “You’re a photographer, that’s the same thing as graphic designer, give us 500 book covers, here is $1.”

Older, Better Technologies

2023-10-16T21:34:00+02:00

It is very illuminating to see that using older style technologies, may lead to better experience. This just goes to show that many of the features and complexity and progress are not for people, but for profit of a few. That, of course, is a wild speculation of the highest order.

Centralization Around GitHub

2023-10-16T21:34:00+02:00

I find the situation around GitHub centralization distressing. And this extreme reliance on GitHub is worrying. Maybe in time things change. But the moment I find a job and thus don’t need to keep my repos on GitHub anymore, I would like to move to a more federated forge.

Codeberg seems like the closest option. I will just simply mirror my commits to GitHub for the time being, slowly retiring them when I’m sure that Codeberg remotes have the necessary configurations and flows that are needed. I don’t think I can retire my account though.

Every place I worked or want to work, are using GitHub. I cannot but worry about the same amount of enshitification that twitter and Reddit has taken, to also come for GitHub.

Dynamic Linking is the Wrong solution

2023-10-16T21:33:00+02:00

Dynamic linking for the reason of security is the wrong solution, only propagating the problem of language and application developers to the downstream package distributors.

It is basically saying, yeah, I wrote this package with this language and dependencies, but you will be the one paying for my choice of technology.

Of course, down stream people also shouldn’t have accommodated these software. Except they did and now, there are multitudes of ecosystems operating this way.

I Hate Jira

2025-05-30T15:25:14+02:00

I absolutely hate Jira. It is when you spend hours of valuable time, prioritizing tasks that take less time doing than setting them on Jira.

ADHD not Being Real

2025-05-30T15:38:30+02:00

ADHD is not real. It is just unmotivated kids needing more structure.

– Some lady today

Therefore:

Cancer is not real. It is just overly horny cells needing to chill the fuck down.

– Probably the same lady, assuming no double standards

Missing Rust Blogpost

2023-10-16T17:27:00+02:00

There is a blog post missing in the Rust sphere: How to not obsess over performance gain and improve changeability of Rust applications.

In other words, imagine that you want to move a function used in one file to another. How would you do that in under ten minutes?

The Tragedy of The Tech-Stacks

2025-05-30T15:34:42+02:00

Back in 1958, there was this thinker named Garrett Hardin who kicked off his well-known piece titled “The Tragedy of the Commons” in the following way:

At the end of a thoughtful article on the future of nuclear war, Weisner and York concluded that “Both sides of the arms race are… confronted by the dilemma of steadily increasing military power and steadily decreasing national security. It is our considered our professional judgment that this dilemma has not professional technical solution. If the great powers continue to look for solutions in the area of science and technology only, the result will be to worsen the situation.

Then, Hardin goes on to rattle the foundations by delving into a colossal issue — the challenge of population expansion. He breaks it down by saying that when you have a shared resource, and each individual aims to squeeze out the most benefit for themselves, the result is a harm inflicted upon everyone, even the very ones taking those actions.

Now, picture this famous analogy. Imagine a stretch of grassland, claimed by three farmers. Each of them brings their cow out to graze on it daily. Sounds reasonable, right? But then, one fortunate farmer’s cow becomes pregnant. This stroke of luck leaves him with two cows, effectively doubling his profits. Observing this triumph, the other farmers follow suit, diving into a spree of buying and breeding cows, aiming to maximize their individual gains. However, this frenzy leads to a rampant grazing that leaves the grassland bare and barren. Ultimately, the once lush grass disappears, and the insatiable appetite of the voracious cows brings about their own starvation. In the end, all the farmers are left with no cows, their initial wealth transformed into a state even worse than before.

He coins it as the “Tragedy Of The Commons.” I prefer to see it as a powerful representation of what often dampens the enjoyment across the software terrain for every key player involved: the user, the developer, the CEO, and the investor.

How meta!

The Clever One, The Frustrated One and The Scared One

Now, let’s meet a familiar figure, the one we often encounter, the embodiment of many developers out there. We’ll give her a name: Sarah. Sarah’s eager to dive into a fresh technology - one that could potentially elevate her current position. So, how does she tackle this? She begins by exploring a domain, and within that, she sets her sights on a specific technology. Let’s designate this domain as something imaginary, to prevent any inadvertent offense. How about we refer to it as “Front-End Development”?

For Front-End Sarah finds out a few different contenders in the field. She asks herself what could the industry be thirsty for? The naive answer she arrives at, is “the most reliable one, the one that is the pleasure to develop and the one that has the most advantages”. Oh, Sarah, you impractical idealistic perfectionist, you!

Now, delving into the realm of Front-End, Sarah stumbles upon a handful of potential contenders. She ponders, what might the industry truly crave? Her initial, somewhat naive response is, “The most dependable option, the one that brings joy to the development process, and the one that boasts numerous advantages.” Oh Sarah, you, impractical, idealistic, perfectionist you!

Armed with these benchmarks, she opts for the Elm language (yet another mythical being). She proceeds to dive into Elm, driven by her enthusiasm. However, curiosity gets the better of her, and she sneakily glances at the job listings on LinkedIn. To her astonishment, she discovers a mere trio of job opportunities for Elm. This baffles her, leading her to question the accuracy of her initial language assessment.

Seeking insight, she turns to Tom, an exceptional CTO she’s acquainted with, to discuss whether Elm lives up to its hype. Much to Sarah’s astonishment, Tom echoes her initial convictions regarding Elm. He affirms that, indeed, Elm proves to be an exceptional language, boasting enduring dependability, a well-established ecosystem, and a delightful development journey.

Sarah, now even more puzzled than before, directs her confusion towards Tom, questioning whether he’s in the process of recruiting Elm developers. Once again, Tom’s response is resolute: “Absolutely not! Where could I possibly locate a pool of Elm-savvy developers? However, we’re actively seeking out JavaScript experts!” (once more, a language name sufficiently distanced from any existing real-world instances).

After a brief moment of contemplation, Sarah bursts out, “What about me?”.

Tom responds with a shake of his head, stating, “Oh, that wouldn’t work. You see, for any given application, we require a team of 20 individuals to consistently handle maintenance and bug fixes. Where on earth would we come across 20 Elm developers?”

“Well, shouldn’t Elm apps theoretically require significantly less maintenance, given the multitude of bugs that are caught during the initial development stages?” Sarah counters silently within her mind. An idea begins to form, one she opts to keep to herself, “Ah, so maintaining a delicate codebase might indicate a higher demand for fresh JavaScript developers - implying enhanced job security!”

Feeling rather clever, she decides to validate her hunch by perusing the (imaginary) yellow pages, named Glassdoor. And lo and behold, an endless scroll unveils a plethora of distinct job listings, all centered around JavaScript.

Well, Sarah learns JavaScript and all her beliefs gets validated, she becomes a very wealthy engineer, with a great job security, with each company she enters trying to keep her, year-after-yer, while other companies trying to persuade her by higher and higher offers. Or at least that was the boring version of this post that did not start with the word “tragedy”.

Instead, she uncovers that her counterparts, much like herself, had also been quite clever. A multitude of newcomers gravitated towards the language flaunting the highest job listings. Each job opening faced a surplus of around a hundred contenders. The “victor,” so to speak, emerges as the individual boasting the most qualifications and the most modest salary expectation. Or should we even label them as victors, considering that the instant they dare to dream a little bigger, a fresh job listing crops up, promptly displacing them with the next eager contender.

Tom, our trusty CTO, worn out from the cycle of on-boarding one low-budget, novice developer after another, vents his frustrations to the CEO. The CEO engages in discussions with the investors, who share the same dissatisfaction due to their profits being eroded by an inefficient workforce. They call upon the CEO to devise a remedy for this predicament.

The CEO returns with a strategy to shift from JavsScript to Elm technology. The investors, content with the proposal, take a brief pause to deliberate. A few days later, they rejoin the conversation, expressing a notable apprehension. “Elm is practically unheard of! None of our rivals employ this language. That’s a substantial gamble we’re not prepared to take!”

Arash, the CEO, CTO, CFO, Product Manager, and the visionary founder of a fledgling startup, confronts the very same imaginative quandary of selecting a technology stack. Given the inherent high-stakes nature of startups, Arash adopts a prudent approach by examining the practices of more established corporations, such as those overseen by individuals like Tom in his role as CTO, in order to identify a tried-and-true trajectory.

The Lose-Lose-Lose situation

At every juncture, every individual optimized their decisions for personal gain. At each instance, a superior option was presented, and they acknowledged the benefits it offered. Nevertheless, they settled for the inferior alternative (for the sake of avoiding any unnecessary debate, let’s refrain from mentioning that the hypothetical lesser choice was JavaScript, naturally). As a result, each person finds themselves in a less advantageous position than if they had collectively embraced the superior alternative. This impact ripples beyond individuals, extending to the entire ecosystem, hindered by the precarious edifice of abstractions left behind by the swiftly growing number of predecessors.

So, why did they all fall short of enhancing their own lives and the lives of others? Was it the technology’s flaw? Or did the ecosystem falter? You’re astute enough to deduce the answer; after all, you had the wit to discern the languages I implicitly referred to in my hypothetical scenarios.

The Solution

I must admit, I’m uncertain. The nuclear arsenal continues to expand, even though the era of the Cold War has long passed. Thankfully, our world hasn’t been ravaged by nuclear conflict. Rather, it’s the interplay of mutually assured destruction and the realization by the leaders of those two nations that not embracing an alternative risk could lead to dire consequences. This, at least, has placed us in a relatively improved state.

Simultaneously, we find ourselves grappling with Garrett Hardin’s preoccupation — the persistent challenges of overpopulation and looming environmental catastrophes. Evidently, the far-reaching peril of not embracing an alternative is of such extended duration that it transcends the immediate concerns of the very generation opting against alternatives. The burden of their choices is instead borne by their descendants:

Fuck those brats.

In the world of software, the tempo is notably faster, the stakes less dire compared to earlier circumstances, and the individuals engaged are often more honest than politicians and notably smarter than the average voter.

However, the remedy doesn’t entail adhering to an oddly precise series of ritualistic maneuvers. It’s a more daunting challenge. Just as Garrett Hardin titled his article, the solution remains much the same:

The population problem has no technical solution; it requires a fundamental extension of in morality. — Garrett Hardin

Dear Reader

I know! The ghastly claim of “to improve developer experience we first should grow an ethical sense”, seems absurd. Yet I see no specifically little amount of gradual change, where at least someone on the whole chain did not bite the bullet and risk it.

Call Me Perma

2025-05-30T15:37:03+02:00

I find myself seated in the passenger’s seat of my mother’s car, as we make our way to an appointment with an educational psychologist. A sense of confusion and concern lingers within me, stemming from my mother’s sudden and puzzling reaction to my C-graded report card. The journey passes quietly, and we arrive at the specialist’s office without exchanging a word, leaving me still uncertain about the purpose of our visit.

The psychologist initiates our session by administering a series of aptitude and intelligence tests appropriate for my age. Throughout the process, my mother’s keen gaze remains fixed on me, intensifying my nerves. Eventually, the psychologist validates my mother’s suspicions, revealing that my intellectual capabilities far exceed those of my peers. This revelation prompts my mother to shed light on the purpose of our enigmatic expedition:

You see, you are not stupid, you are actually very smart, you just lack self-esteem!

Was that truly the root of the issue? While self-esteem was a factor in my unhappiness, I couldn’t help but feel that my lack of effort had deeper origins.

Oh, but this wasn’t the first round of this comical saga. You see, on previous occasions, my dear mother would strategically place a glass of water right between us, like a cosmic prop. And what was the grand purpose behind this visual spectacle, you might ask? Well, it was her way of nudging me into a philosophical monologue about that very glass. In simple terms: > Hey, kiddo, you’ve got a shortage of optimism; you’re the sort who tends to spot the half-empty glass in life.

And then we have my dear old dad, the master of responsibility training. He had this grand plan to shape my character, using internships as his secret weapon.

Off you go, my young apprentice!

He’d exclaim, nudging me into one vocational adventure after another. His hidden message?

Kid, I’m passing down the sacred skill of handling responsibilities!

The age-old parental strategy.

And there you have it, my childhood summed up, right from the time those kindergarten teachers began their chorus of complaints about my apparent “refusal” to embrace the songs that my peers had effortlessly committed to memory months before.

As the days went by, I began to adopt a personal mantra: > I’m the poster child for laziness, the embodiment of irresponsibility, with motivation and vision nowhere to be found.

Oddly enough, despite knowing full well the significance of education and being genuinely captivated by the realms of science and math, my actions seemed to tell a different story altogether. It’s as if I was presenting evidence that contradicted my own beliefs. Perhaps deep down, I questioned my care for my parents, struggled to find motivation, or maybe I secretly aspired to master the art of freeloadery.

The haze of doubt began to lift when I embarked on an ADHD medication journey, and lo and behold, I experienced the novel sensation of being able to sit down and read a paragraph without my mind spiraling into chaos. It was like finally playing a video game where you no longer wonder if you’re in control of that character’s movements or not. My epiphany was quite the reverse: “Oh, wait a minute, I can indeed make decisions and stick with them?”

Let me tell you, this realization was liberating, to put it mildly. Suddenly, I had the capacity to invest time in the very things that had ignited my curiosity.

ADHD has had a profound impact on my life since childhood. One revelation that became clear after seeking medication was the extent to which I had surrendered agency and intentionality.

My existence had been defined by reactivity, with a noticeable absence of honed decision-making skills. I found myself in a state of passivity, or even worse, mere reactivity. Nonetheless, I consistently strive to reclaim it.

Recent Victories

Over the past few years, I’ve encountered an almost comically disproportionate share of misfortune and have found myself under substantial duress. Yet, I’ve navigated my way through these challenges.

I won’t delve into the specifics of these misfortunes, although those in my social circles can attest to their unusual frequency.

However, I can share that I’ve achieved several noteworthy milestones during this time span: acquiring programming skills, entering the workforce, entering marriage, and most recently, opting to unofficially change my name.

Formally, I remain Amirhossein, and I’m content should anyone choose to continue addressing me as such-I hold no animosity toward it. Nevertheless, it inadequately captures the depth of my identity.

Amirhossein and Perma

The name Amirhossein is a composite of two Arabic names, Amir and Hossein, both of which carry two meanings. As for the firsts of these meanings, Amir translates to “prince,” while Hossein signifies “Good-junior.” The amalgamation results in the interpretation of “Junior Good Prince.”

However, I find myself at a loss when attempting to establish a personal connection with any aspect of this interpretation of this name. This brings us to its secondary and perhaps more intended connotation.

In Shia Islam, there exists a concept akin to Christianity’s sainthood, known as “Imam”. However, these Imams are asserted to be leaders of the Islamic community. The first of these figures holds the title Amir-al-momenin, or the “prince of the faithful”, commonly abbreviated as Amir. The third Imam, the second son of the first, was named Hossein . Both individuals deviate significantly from pacifism.

While these historical and linguistic connections hold merit, I must underscore a significant twist: since the age of 15, I have consciously disavowed Islam and theism in their entirety.

I find “Perma” to be a more fitting option, resonating more harmoniously with my ears. Moreover, it aligns with certain themes and passions that hold significance in my life. It closely aligns with the ethos underpinning this blog. I’m captivated by the philosophy of the PermaCulture and PermaComputing movements-albeit not necessarily their current implementations. My fascination lies in harmonizing with the world rather than coercing it to conform to my presence. Moreover, the notion of leaving a lasting imprint on the world holds a special allure for me. However, this yearning leans more toward the aesthetic realm rather than being rooted in utilitarian aspirations.

Dear Reader

If you’ve known me previously, you might have observed my recent shifts in usernames, emails, and name. Across the internet, I’ve opted for Prma instead of the more direct Perma, as the latter is frequently claimed or could serve other entities more fittingly.

However, this change isn’t indicative of a complete unveiling of my authentic self. Thus, referring to me by my previous name isn’t as insensitive as the act of dead-naming. Rather, this transition signifies the inception of a renewed chapter, one marked by heightened purpose and intention.

While I do prefer and hope for the usage of Perma moving forward, I’m entirely at ease if you choose otherwise. Your decision in this regard is genuinely respected.

Dishonesty of Optimizing for Developer Time

2025-05-30T15:50:25+02:00

Based on some individuals’ viewpoints, they emphasize optimizing for developer time or productivity as their main priority, rather than giving top precedence to aspects such as performance, robustness, or correctness.

The Thesis

Their argument revolves around the idea that developers’ time is more valuable and expensive than server resources. They often use phrases like “You can always refactor,” “You can always optimize for performance,” or “We will fix bugs later on” to support their viewpoint. While this perspective may be considered ingenious, it is contingent on proper planning, weighing the trade-offs, and actually acting upon those decisions.

My Antithesis

However, if this were genuinely the case, more substantial effort would have been invested in refactoring or choosing a more rigorous language than JavaScript, for example, a language that can significantly boost performance in the long run.

Fixing bugs in backends written in JavaScript, PHP, or Python is certainly feasible, but adding performance improvements can become challenging, if not improbable. More meticulous programming tools automate the process of finding and fixing even the most elusive bugs and come with significant performance optimizations. The ability to make well-founded assumptions about the program allows for better optimization.

This approach often leads to a situation where future engineers, tasked with rewriting the MVP program in a more scalable language, face an archeological rediscovery process.

So, if they are not genuinely optimizing for shorter development time, what are they doing?

Lifting The Veil: The Actual Thesis

It appears that they prioritize short-term gains over achieving greater long-term goals.

A language like Rust, while providing benefits like enhanced safety and reliability, requires significantly more time to produce a binary or APIs. The manual labor of finding bugs is taken over by the compiler and the language’s semantics. If the focus is on developer productivity, then this automation is naturally desirable. However, what one truly desires to convey is “I have this feature, even though it may have some bugs and performance issues, I have it nonetheless.”

The Synthesis

That may be a positively good idea for trying the market to see if there is any for that specific idea, for most software developments though, the actual intention is not experimentation, as the novelty of product and business plan do not warrant a need for experimentation. Rather, having something to sell, as fast as possible. That’s for start-ups. Where there is both legitimate and illegitimate short-termism. But more established enterprises may have this pairing as well. While there are A/B experimentations going on, trying different approaches to see which works, middle management might also like the addition of another achievement in their yearly reports.

A rapid way to discern whether it falls under the category of experimentation/prototyping MVP achievement-oriented project is to examine whether there is a notably extended period allocated for the program’s rewrite compared to its initial development phase.

Dear Reader

Similar to many phenomena, short-termism can indeed have legitimate applications. The reluctance of many to embrace this term is rooted in its improper and illegitimate uses.

Certainly, there are well-intentioned individuals who advocate for developer productivity. However, those with ample experience will acknowledge that long-term developer productivity is not synonymous with low-overhead development, and, more often than not, these two objectives are incompatible.

Criteria For Choosing Tools

2025-05-30T15:45:43+02:00

The web is utterly fucked. But anyone with some resources at hand and curiosity at heart and intentional tool selection can have a decent experience.

The Reasons

The web’s lamentable state can be attributed to several factors. Allow me to enumerate them concisely for clarity:

Bloated beyond reason.
Plagued with incessant ads.
Prioritizing feature over bug fixes, if addressed at all.
Designed to cater to journalists and advertisers, neglecting your needs.
Imposing confinement and isolation upon you.
Failing to empower users like yourself.

A Brief Digression

The final point warrants further elaboration.

The internet is, in fact, a tool. It is something that is made to help someone achieve some goal.

The captivating world of Web 2.0 and Social Media (the somethings) - initially promising to empower people (the someones), granting them enriched social connections (the some goal). A promising start, indeed, leaving many with pleasant experiences during the inception of Web 2.0.

But, alas, as time went by, the very incentives that drove these Social Media companies veered them off their intended course. They embarked on a divergent path, straying from their professed mission, and now, Web 2.0 primarily serves as a platform to amplify the voices of journalists and celebrities (the actual someones), propelling them towards greater fame and recognition (the actual some goals).

The driving force behind these shifts? The ever-persistent quest for revenue from advertisers, pushing them to create content that captures maximum engagement. The more captivating, the more lucrative.

Regrettably, the landscape has birthed what I would call the “four horsemen of reactionary engagement”: the doomsday, super political reporter; the enraging, populist racist politician; the trolling, impulsive CEO; and the drama-driven, vacuous celebrity.

In a nutshell, it appears you’ve been played for a fool. Social media’s purported aim of empowering you is nothing but a delusion.

Go Empower yourself

Before you proceed, there’s a prerequisite to address: overcoming the fear of missing out. Now, how one achieves this is not within my scope to divulge, but I can assist you in understanding why these fears are unfounded.

Consider this: Have you truly missed out on anything of genuine importance? Reflect on whether the latest controversial statement from Donald Trump has genuinely altered the course of your life. And if it did, was Twitter (or whatever they dub it these days) truly the sole or optimal medium for receiving such information?

Even in Iran, where official channels are notorious for propagating falsehoods, Twitter appears to be excessive. For me, friends and private messages reliably convey essential information. And indeed, individuals might spend considerable time on Twitter, but isn’t the fundamental pledge of social media the relay of information? If that need is already being fulfilled through other means, what purpose does Twitter truly serve?

If you find yourself fortunate enough to reside in a country with trustworthy official channels, and your well-being hinges on crucial information like hurricane alerts, rest assured that dedicated services cater specifically to such needs. Similarly, if you derive pleasure from reading news articles, I suggest identifying the authors whose work you value and following them directly. However, if these activities do not align with your interests, then quite frankly, you have no real necessity for engaging with this “stuff”.

Oh, my friend, let me share with you a sobering truth about these companies — they’re akin to emotionally abusive partners, manipulating you into believing you’re nothing without them. They demean you, calling you stupid and incapable of managing your life without their presence. They cunningly weave a narrative of how your life is all thanks to them, that your friendships exist solely because of their benevolence.

But don’t be fooled by their deceiving ways. They mangle your interactions, force-feeding you ads and utter nonsense, all while claiming it’s an act of love. And when their misdeeds come to light, they stage a grand spectacle of apologies and vows to change, only to strike back even harder later on.

It’s time to break free from this toxic cycle. I know it’s daunting, and fear may grip your heart initially, but liberate yourself from their clutches. You will discover a life far better than you ever imagined. You deserve more than this relentless manipulation. Embrace the freedom that awaits, my dear friend.

How to find a good tool

Step One: Find The Low-Hanging Fruits

You stand at the precipice of transformation, ready to change your life for the better. The first step is to identify the areas in your life that require attention. What needs are you seeking to fulfill? And upon which inadequate services are you currently relying?

In my case, I sought:

A steady flow of lightweight information.
Daily interactions with fellow enthusiasts akin to myself.
A means to uncover specific data.
A reliable way to send emails.

For too long, I depended on subpar sources to meet these needs. For the first two, I found myself reliant on Twitter, Instagram, Reddit, and Google News. As for the third and fourth requirements, I resorted to Google’s services. However, all of these platforms consistently fell short and inflicted undue stress upon me.

Step Two: Find Effective Replacements

In my earlier post I have mentioned that I already have replaced most of these services with better ones. But I have not mentioned what constitutes an effective solution.

In my previous post, I alluded to having replaced many of these services with superior alternatives. However, I haven’t delved into what exactly makes a solution effective.

Allow me to outline the criteria and guiding principles for an empowering tool:

It should not cause you any harm.
It should not lock you in.
It should not feel frugal.

Now, let me delve into the rationale behind these criteria:

1. It should not cause you more harm than good

If a tool causes more harm than good, why persist in using it at all?

To safeguard your interests, ensure that the tool operates with transparency. Platforms that intentionally harm users are less inclined to be forthcoming about their inner workings. Opt for open-source and audited software, provided you trust the incentives and capabilities of the auditors, as this fosters transparency.

Moreover, it is crucial to align the incentives of the tool’s creators with your own. While there will always be some degree of misalignment, not all cases are equal. Selling or renting software may incentivize developers to plan for obsolescence, sell incomplete products, or enforce lock-ins. Yet, these misalignments are overshadowed by the egregious discrepancies inherent in ad-driven models.

2. It should not lock you in

Indeed, the peril of being locked into a tool becomes evident when the company’s incentives undergo a shift. I experienced this firsthand in 2015 when I was a loyal Evernote user with a premium subscription, trusting it with all my valuable information. However, when Evernote decided to drop right-to-left language support crucial for the Middle Eastern languages, my pleas for assistance fell on deaf ears. They deemed the region unworthy of attention, leaving me stranded and unable to utilize my data effectively.

The true pain emerged when I attempted to export my information and realized I was trapped in their ecosystem. They held my notes’ hostage, providing them back only in a non-standard format through XML or JSON files. This, my friends, was the dreaded lock-in, and I had to endure a labyrinthine journey of manual extraction to break free.

To avoid such a predicament, one essential question should be posed:

Will it be more difficult for me to switch to a competitor once I’ve fully adopted this service compared to my current situation before using it?

If the service retains your data and only offers it back in a non-standard format, it becomes significantly more challenging to transition to a competitor after investing your notes into the first service. Be vigilant and consider the implications before getting entangled in such situations.

3. It should not feel frugal.

Let us keep in mind the essence of this endeavor: to enhance the quality of our lives. Undoubtedly, there are noble causes that may necessitate adopting a certain level of frugality, as was the case for me with animal rights, which amusingly led me to embrace veganism.

However, advocating for these causes demands energy, and it might inadvertently lead to isolation. We must acknowledge that not everything can or should be a constant battle. The purpose of utilizing these tools is to improve our lives, not to make them more arduous.

If safeguarding your privacy to the utmost extreme is your goal, then by all means, employ complex passwords for each site and commit them to memory. Nevertheless, we must be mindful that our fighting energy is finite. Thus, it becomes essential to prioritize and channel our limited energy toward the most urgent and meaningful issues that truly resonate with our hearts.

Dear Reader

You are on the right path, and I believe in you wholeheartedly! Trust me, I’ve been through this journey myself, and it turned out to be a delightful and straightforward experience. Take heart, for you can certainly achieve it too! Keep going, and you’ll soon realize how much better and easier life becomes. You’ve got this!

Giving My Experience of Web a Makeover

2023-07-19T10:34:00+02:00

Back in the good old days, I found myself drawn to the wonders of the internet, captivated by its virtual world, teeming with individuals who resonated with me, people I admired, or at least aspired to emulate. The communication channels of that era felt more personal, more akin to a lively conversation passed on through word of mouth.

More of Those Days

In those youthful days, I’d eagerly scour the web for words that piqued the interests of my teenage self, and with a simple search, Google would present me with a treasure trove of blogs authored by kindred spirits. I’d venture into the realms of Twitter, FriendFeed, Facebook, Orkut, and the myriad other social platforms, spending precious moments escaping the painful realities of feeling marginalized by my parents, teachers, and peers at school.

The internet of that era held a special place in my heart; it offered solace and kinship. Even though I may not have been as popular as some within those social circles, I cherished engaging in conversations within a vibrant crowd of amazing individuals, the very ones I admired deeply.

As time marched on, many of the cherished online spaces I once loved to fell by the wayside, while others morphed into monstrous entities, becoming tools of ostracization. Although I personally may not have been the target of such mistreatment, I could discern the toxic environment that fostered and emboldened bullies.

Even the search engines, once a source of discovery and connection, began to falter. Each passing day brought forth an ever-increasing deluge of hyper-SEO-optimized, meaningless content and tech-centric sites merely driven by profit, overtaking the slots that were once reserved for passionate individuals with independent blogs.

As the landscape transformed, I gradually came to terms with the nostalgic allure of those bygone days, realizing that it had become a remnant of the lost innocence of the early internet or clouded by my own flawed perception of what truly transpired.

The sense of desperation that had gripped me started to crumble when Elon Musk’s actions on Twitter triggered a disillusionment, pushing me to reconsider Fosstodon-an open-source social platform. And oh, what a fortuitous decision that turned out to be. It was as if I had stumbled upon the early days of FriendFeed, where genuine exchange of information thrived, embodying the very essence of the social web I yearned for.

But a part of me questioned this fortunate discovery. Could it merely be a chance occurrence, a fluke in the otherwise distorted realm of human-generated nonsense? I grappled with doubts.

Then, as if destiny had a hand in it, the second revelation struck-a website called Kagi, delivering yet another blow to the illusion I had held onto. The cracks in my previous beliefs widened, challenging me to confront the harsh realities of the digital landscape.

Kagi, an unconventional paid search engine, piqued my curiosity, prompting me to give it a try. What unfolded before my eyes left me astounded-a screen brimming with blog posts dedicated to the concept of PermaComputing occupied the very first page of results. At that moment, it dawned on me that the beloved world of independent blogging, which I had presumed to be on life support, had not faded away as I had believed. Instead, it thrived, resilient and as potent as ever. It was the so-called social media platforms and search engines, the very entities I had placed my trust in, that had ultimately let me down, betraying the internet I held dear.

The illusion that once clouded my perception had dissipated into thin air.

Determined to instigate a change, I took my first footsteps in the path full of transformations. I am currently in the midst of that process, but I have successfully identified the type of experience I desire. I have pinpointed a few readily available opportunities and have taken proactive measures to secure them for myself.

Foremost, I yearn for an authentic perspective of the internet-a genuine representation of the collective human experience rather than a mere showcase of the glossiest and most superficial elements. To fulfill this aspiration, I sought out a suitable search engine, and as I mentioned earlier, I found my answer in Kagi-it aligns perfectly with my vision.

Furthermore, I crave a steady stream of thoughtful and sincere content. To achieve this, I turned to an RSS aggregator to curate and deliver such material to me consistently. Feedbin emerged as the ideal choice, serving as the conduit for fulfilling my appetite for meaningful discourse.

I discovered another low-hanging fruit on my path towards a more fulfilling online experience-a social website optimized for community rather than being driven solely by journalists. This gem came in the form of Mastodon.

In my quest for a trustworthy email service that respects my privacy and shields me from the relentless influx of spammers, I received a recommendation for ProtonMail. Taking heed of the suggestion, I made the switch and, so far, I find it to be a satisfactory choice.

Update: I am using Migadu these days. 2023-11-14

You may have noticed that out of the four aforementioned solutions, three are paid services. Additionally, two of them are closed-sourced, while one-the email service-poses the risk of vendor lock-in. Although this may not be the ideal scenario, I weighed my options against a set of criteria that I had established. In the end, these choices emerged as the better alternatives, despite their limitations.

However, I realize that this post has already grown quite lengthy, and the criteria I employed deserve a more thorough elaboration. Therefore, I will save their exploration for a future post, where I can delve deeper into these ideas deserving of greater attention.

Dear Reader

At present, I find immense joy in my renewed online experience-a sense of tranquility and refuge washes over me whenever I delve into the internet. I wholeheartedly urge you, dear reader, who may be experiencing similar frustrations to those of my past self, to take a moment and reevaluate your internet usage. There is a strong possibility that the internet can be a much more pleasant and gratifying space than what you might be feeling at this moment. I know this to be true because I am living it right now. Embrace the journey of exploring better alternatives and reclaim the joy in your online interactions.

HTML, The Programming Language

2025-05-30T15:27:28+02:00

The eternal dispute over whether HTML counts as a proper programming language seems to bring out the best and worst of our community’s collective rational faculties. A veritable feast of half-baked attempts to define away the problem by appealing to whatever convenient characteristics the speaker happens upon, combined with a sprinkling of more serious thinkers seeking some grand philosophical theory to explain it all. But don’t get your hopes up - you won’t find any silver bullet solutions here folks. Just a parade of armchair theoreticians grasping blindly for some sense of clarity amidst the fog of poorly thought out positions. So gather ’round, listen up, and prepare yourself for another round of pointless squabbling. The fun is just beginning!

The Loops And The Features

Individuals frequently endeavor to delineate programming languages by differentiating them from HTML, contending that a programming language possesses specified traits. Traits that might encompass looping structures, conditional statements, or even compilations. Alas, these efforts are founded upon retrospective comprehension - reliant on past personal observations of what constitutes a programming language. This flawed methodology, inherently, undermines the legitimacy of their claims inasmuch as they concurrently explore discrepancies between what is deemed not to be a programming language. A circular argument ensues, lacking genuineness, and thus futile in supporting the allegation that HTML lacks programming language attributes.

Alright, listen up! Let’s say I’m dead set on accusing Tom of being a thieving scoundrel while vehemently asserting that Amanda is as innocent as can be. To make my case, I start off by drawing a sharp contrast between Tom and Amanda. Then, after much contemplation, I concoct a ridiculously specific definition of a thief: “Anyone who happens to be a man in his sixties with an academic background in History.” Can you believe that? Now, picture this - imagine we go ahead and convict every poor soul who fits this outrageous description. Well, I’ll tell you right now, that’s a load of nonsense! It simply won’t fly, and anyone with half a brain can see how utterly flawed and impractical that notion is.

The Turing Completeness

Now, let me tell you about those folks who prefer a more unified approach when it comes to defining something, like a programming language. They often rely on axioms, you know, those fundamental principles that serve as the bedrock of reasoning. One of the most famous examples is the notion of Turing completeness being the ultimate defining factor. At first glance, it may not seem problematic. But here’s the burning question: Why on earth would we go down that route?

Think about it. We create distinctions in definitions to aid us in effectively communicating a concept among ourselves. As far as I know, most programmers couldn’t care less about whether a programming language can perform every single computation imaginable in theory. No, sir! Instead, they value the practical aspects like ease of use and reliability when it comes to solving a specific set of problems. So, how in the world would that earlier theoretical claim serve us in our day-to-day tasks? It’s a real head-scratcher, especially when you consider that such a filter would let languages like brain-fuck and whitespace pass through, while disregarding total programming languages that could actually lead to more robust and dependable software.

But here’s the kicker - some people actually advocate for this madness. They’ve come up with a seemingly cohesive definition of a programming language, but their motivations for choosing that definition are nothing more than an afterthought. As a result, their definitions are utterly useless, or at the very least, useless to those who couldn’t care less about denigrating a language. Can you believe it? What a ridiculous state of affairs!

Dear Reader

Now, let me be clear, my intention here is not to rally behind HTML and extol its virtues. Instead, I aim to shed light on our incessant desire to bestow added significance upon the definition of our work. And, quite frankly, I implore you to put an end to it. You see, a programming language can possess capabilities or be lacking in them, and a programmer may be focused on orchestrating the flow of information or on its presentation. We come in all shapes and forms, each with our unique approaches. Attempting to establish some sort of gate-keeping mechanism in this endeavor will only result in programmers overlooking the fact that they may just require HTML and CSS to fulfill their job requirements. This, in turn, contributes to the sorry state of the web-bloated and disheartening.

Let us cherish our roles as creators and refrain from placing undue emphasis on the definition of our jobs, but rather, let us focus on the outcomes we produce. After all, we are all creators and problem-solvers at heart.

Consider Developer's Snack

2025-05-30T15:48:03+02:00

During my early 20s, I found myself immersed in the world of sustainable architecture as an architecture student. Engaging in various workshops centered around this field, one particular experience stands out as a monumental turning point in my life. It was a workshop conducted by a renowned professor in Iran, where I gained valuable insights.

Within this workshop, we collectively brainstormed strategies to harness heat sources for a four-member family’s house, aiming to optimize its thermal efficiency. We considered a range of possibilities, including solar and geothermal heat, as well as the heat generated by the kitchen oven. However, there was one significant heat source that eluded our attention, as pointed out persistently by the professor.

Eventually, he provided us with a clue: “You seem to have overlooked four 37-degree Celsius heaters.” It dawned on us that we had forgotten to factor in the heat generated by the family members themselves. Their body heat, a natural source of warmth, had slipped our minds entirely.

Reflecting on a more recent occurrence, a certain paper began circulating, comparing the energy usage footprint of different programming languages. Yet, I couldn’t help but notice that the discussions surrounding this paper overlooked a crucial aspect-it solely measured the energy footprint at one specific point in the application’s life-cycle.

It is essential to recognize that the energy usage of a programming language extends beyond a mere snapshot analysis. To truly grasp the overall impact, we must consider the entire life-cycle of the application, accounting for factors such as development, deployment, maintenance, and eventual retirement. Only then can we gain a comprehensive understanding of the energy implications associated with different programming languages.

The Paper, As The Thread We Pull

The paper, titled “Energy Efficiency Across Programming Languages,” delves into the exploration of various problems and their corresponding solutions, which are implemented across multiple programming languages. The researchers conducted an analysis of the electricity consumption associated with each implementation. In essence, the primary focus of the study revolves around determining the relative energy efficiency of different programming languages, with C emerging as the most efficient and serving as the benchmark for measurement.

C      | 01.00 | ▓
Rust   | 01.03 | ▓
Java   | 01.98 | ▓▓
Python | 75.88 | ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
Perl   | 79.58 | ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓

These results carry considerable weight, although it is essential to address a common misconception surrounding their implications. Contrary to popular belief, these findings do not unequivocally assert that a C program is inherently more environmentally sustainable than its Java counterpart.

Consider The Snack

In the field of sustainability literature, there exists a concept known as Life-Cycle Assessment(LCA). LCA involves evaluating the environmental impact of a product throughout its entire life cycle, encompassing aspects such as raw material extraction, manufacturing, and disposal or recycling.

When applying this concept to the assessment of software life cycles, we realize that there are several significant factors that have been overlooked. Allow me to provide some insights on these important considerations.

Firstly, the authors of the paper have primarily focused on the runtime of a specific set of problems. This means that their applications follow a sequence of starting up, solving the given problem, and then exiting. Consequently, the results obtained are biased towards programming languages that excel at efficient startup and shutdown processes. However, this perspective fails to account for the behavior of servers and long-running processes. Servers, for instance, typically start up once per day or even less frequently and spend extended periods in the computational phase. If a programming language is efficient during the initial startup but requires frequent restarts during runtime, this crucial aspect is overlooked.

But we shouldn’t stop there. Another aspect to consider is compilation. While Rust is indeed an impressive language, its compilation process is significantly more resource-intensive compared to Go. Rust yields highly efficient binaries, but the energy expended during the compilation process is also considerably higher.

Furthermore, the improved quality of Rust’s compiled binaries becomes relevant when we consider the potential presence of bugs and the subsequent need for recompilation. More permissive compilers may result in programs with a higher likelihood of bugs, necessitating additional rounds of debugging, fixing, and retesting. It’s important to acknowledge that this discussion goes beyond the developer’s running computer and includes factors such as sustenance needs, energy consumption to support their biological functioning during the process of bug fixing, and the overall impact on the environment.

Additionally, the continuous deployment or release cycles, repackaging efforts, and the use of CI/CD practices all contribute to the ecological footprint. Recompilation for each platform targeted, as well as the network costs associated with distributing binaries or source code to different endpoints, also significantly impact the environment.

The problem of compatibility further compounds the issue. Programming languages with runtimes shipped separately from the package, such as Python, Lua, and other scripting or JIT languages, as well as those based on virtual machines like JVM, often require reprogramming or the inclusion of older runtime versions when breaking changes occur. This adds to the complexity and environmental impact of software development and packaging.

Furthermore, poorly designed programs can accumulate significant technical debt over time, resulting in rewriting. Although the language and toolchain themselves may not directly cause this, the ecosystem surrounding languages like JavaScript, PHP, and Python tends to encourage short-term thinking. In contrast, languages like Rust, C, Fortran, and others that focus on system-level development promote long-term support and are home to projects that have thrived for several decades.

Moreover, the variability in usage patterns must be taken into account. While languages like C and C++ require substantial energy for compilation across different platforms, languages such as Rust, Go, and Java mitigate the duplication of energy required to support multiple platforms within a single application.

Finally, we must consider the energy expended in the development, maintenance, and support of programming languages. Languages like Rust offer remarkable expressive capabilities, not merely due to better timing or superior thinking but also as a result of extensive collaborative efforts. Conversely, languages like Elm undergo minimal changes over time.

It is worth emphasizing that the energy required to learn a language, the environmental consequences of mistakes made during coding (e.g., unintentionally sending a million requests to thousands to different servers), variations in energy usage among developers from different countries, and the decreasing lifespan of hardware are all factors that contribute to the overall consideration.

Dear Reader

The crux of the matter is that complexity pervades these considerations, demanding our thoughtful attention and appropriate mitigation for each aspect. Failing to acknowledge and address each facet places us at risk of optimizing solely for one element while sacrificing the other to the extent of rendering our efforts absurd.

It is important to note that I have deliberately omitted discussions about post-harm mitigation. Our focus has been on reducing harm itself. Exploring the costs associated with bootstrapping and averting catastrophic scenarios would expand beyond the scope of this essay.

FLOSS For Software Longevity

2025-05-30T16:02:22+02:00

Free/Libre and Open Source Software (FLOSS) is a captivating realm within software development. What makes FLOSS particularly intriguing is its deviation from conventional business goals, leading to planned longevity and a distinct approach to sustainability.

Reasons

Let us delve into the unique qualities of FLOSS and the factors that contribute to its better suitability for longevity.

The longevity of the FLOSS business model serves it well

The common business models are better suited for short-term goals. There are two major approaches: selling or renting.

Small to mid-sized software companies predominantly prioritize the sale of their products. The concept of product longevity, while acknowledged as necessary, assumes a secondary role rather than being a central objective. Its primary function lies in establishing trust among consumers. Once the initial excitement surrounding the launch of a new and captivating product subsides, these companies swiftly shift their attention to the next innovation. The success of marketing these novel products heavily relies on users’ fear of missing out and the perceived loss of functionality associated with the previous iteration. Unfortunately, this often leads to the inclusion of unnecessary features, deliberate planning for obsolescence, and resistance against the right to repair. In this cycle, longevity takes a backseat as the perpetual replacement of one product with another take precedence.

Conversely, larger companies place a premium on the rental model for software. Instead of users owning the software outright, they opt for subscription-based payment models for continuous usage. One might assume that these companies would prioritize stability to retain their subscribers. However, practical implementation often takes a different route. These companies rely on monopolistic tactics, such as acquiring competitors or launching extensive marketing campaigns to stifle new entrants. In cases where competition persists, they resort to content exclusivity, coercing users to purchase their product alongside competitors’ offerings. Consequently, users find themselves utilizing these products for prolonged periods not due to their exceptional quality, but rather because they perceive limited alternative options. The subscription model may make sense when paying for a service, but it doesn’t align with current software development. Paying subscription for developing and bug-fix of a product is simply paying for the privilege of using an incomplete version of a product.

In contrast, companies adopting a pay-for-enterprise-support model for open-source products, such as Canonical and Red Hat, exhibit commendable practices. Their primary emphasis lies on longevity. If the software is functioning adequately, their tasks are straightforward, eliminating the need to address the same issue repeatedly for each client. Longevity serves as both their evidence and modus operandi. They provide support for software that has already weathered numerous instabilities. They employ different development stages, such as alpha, unstable, stable, and long-term releases. These features can subsequently be passed on to other distributions with more robust objectives, such as RHEL.

Although these companies may impose charges for bug fixes, their underlying offering revolves around selling stability and longevity (think Ubuntu Pro). This approach is not driven solely by inherent benevolence but rather stems from a lack of alternatives. They are unable to monopolize a product that can be cloned, forked, and utilized to initiate independent ventures. Nor can they vend software that others can fork, enhance, and sell at higher prices or even distribute for free. Their sole viable course of action entails creating a product that strikes a balance, avoiding both excessive limitations that render it futile and excessive complexity that complicates support.

FLOSS engineers prioritize quality over quantity

As we discussed, most businesses prioritize product quality only until it reaches a level sufficient for selling.

This often leads to engineers being pushed and encouraged to develop faster, sacrificing quality and stability when it hinders “beating the competition to market”. I’m sure I’m not alone in feeling dissatisfied with creating instant legacy products and leaving behind a trail of subpar, useless software. It leaves no room for pride in one’s work.

As a result, engineers who value quality find satisfaction in other avenues, such as personal projects or contributing to libraries and tools they use themselves.

The dynamics of development in these situations differ. Open-source software often lacks the same level of resources, making maintainability a crucial concern. Allowing technical debt to accumulate in a project one maintains can result in paying a hefty price, even in a short period. The more users a project has, the more the burden of technical debt becomes apparent-quite the opposite of the industry’s “move broken things, fast” mentality.

Consequently, successful open-source products tend to have meticulous and uncompromising maintainers.

Another important aspect to consider is that open-source software greatly enhances one’s resume. Similar to a resume, open-source projects showcase an individual’s best work. They are like first dates, where you present yourself at your best. Consequently, open-source projects motivate developers to create their finest code and documentation.

Furthermore, transparency is a vital aspect of open-source projects. Engaging in dubious practices, such as intrusive telemetry, can agitate the surrounding community.

In summary, there are four main reasons:

The cost of maintainability
The positive impact on one’s resume
Counteracting the lack of satisfaction caused by lower quality software in daily work
Embracing transparency

FLOSS exhibits a greater degree of diversity

When it comes to a biological ecosystem, its resilience stems from the diversity of its members. Let’s imagine a scenario involving a moth that feeds on maple tree branches. In a jungle filled with maple trees, the moth can feast and reproduce endlessly. However, there’s a twist.

Around 10% of the maple trees have developed a variation of their membrane that is toxic to the moth, purely by chance. Now, if the moth tries to feed on these trees, it has a 1 in 10 chance of being fatally poisoned. If there were only a single moth, it would be the end of its lineage. However, imagine a population of 100 moths, and 10% of them have accidentally developed immunity. These “super moths” may be larger and more resistant to the trees, but they are also more visible to predators like birds. And so, the cycle continues.

The diversity of approaches within a biological ecosystem is crucial. In the context of biological beings, the exchange of random sets of genes through sexual reproduction likely emerged as a means to enhance resilience. Microbes that prey on others, on the other hand, face a more challenging situation, as the result.

These advantageous mechanisms resulting from diversity are also present in the software ecosystem.

The needs and threats faced by a server differ from those faced by a German student’s laptop. While Linux is ubiquitous in the open-source desktop realm, there are numerous slightly different Linux distributions available. These variations encompass different themes, preinstalled applications, package managers, and even packaging architecture models. Additionally, there are kernels compiled with different flags and versions.

Given this remarkable diversity, it comes as little astonishment that Microsoft’s ardent campaign during the 2000s against the comparably youthful, less cohesive, and resource-limited Linux met with abysmal failure. Strikingly, in a twist of events, Microsoft has lately unveiled its very own Linux distribution and dedicated years to crafting the Windows Subsystem for Linux.

To the proprietary realm, an ecosystem characterized by the development, redesign, and forking of diverse products, yielding a multitude of solutions, may appear inherently inefficient. Yet, from the perspective of permaculture and PermaComputing, such an ecosystem manifests as nothing short of utopia.

FLOSS demonstrates a higher level of robustness

FLOSS transcends being a mere generator of independent variations that begin anew each time. It represents a system where progress builds upon existing foundations, with each subsequent layer amplifying the importance of the underlying ones. Irrespective of how many stories above the ground one ascends, the ground level remains a paramount concern if its integrity is jeopardized. Prominent examples of this phenomenon can be observed in projects like curl, the kernel, and OpenSSL. Although these initiatives were initially initiated by individuals, they have evolved into integral components of numerous other undertakings. The driving force compelling many individuals to contribute to these projects stems from the realization that the cost of abstaining from participation would be significantly greater.

However, it is important to recognize that this process is not always pleasant. Consider the immense pressure on OpenSSL developers. If they were to become overwhelmed and exhausted like many other open-source maintainers, the consequences could be significant.

Yet, when such challenges arise (and they do), we all become aware of them. We sense the danger and collectively strive to find solutions. This is in stark contrast to the situation when a proprietary software developer abandons a company. Until a replacement is found, users are left unaware and vulnerable to potential security threats posed by malicious hackers.

Thanks to this collective effort and attention to robustness, many foundational open-source software programs have remained the best tools for the job even after decades of use.

Dear Reader

Now, esteemed reader, I trust you comprehend the rationale behind why individuals with a penchant for enduring solutions find the realm of FLOSS far more fertile than its alternatives.

Moving in Rust is Pure

2023-04-09T09:14:00+02:00

The act of moving arguments within Rust’s functions serves as a compelling means to uphold the purity of the function. By embracing this practice, we ensure that the function operates on unique ownership of its inputs, preserving the integrity and immutability of data, which are fundamental tenets of functional programming.

Moving a Variable to a Function in Rust Doesn’t Make It Impure

So as an introduction, if you don’t know Rust:

In Rust, we have this concept of moving variables. It is like this:

// A variable is made.
let a_variable = some_value;

// It moves into this function.
_ = a_function_that_takes_ownership(a_variable);

// We cannot use a_variable anymore! So, we cannot do this!
let b_variable = a_variable;

Now I consider a_function_that_takes_ownership to be a pure function. However, it raises a possible confusion:

Doesn’t a function that takes ownership change the state of the outer function? Isn’t that a side effect?

I argue that it doesn’t. Here is why: a function is not a function call. Let’s visualize it:

      ________outer_function_______
--in->|       __inner_f___        |-out->
      | -in-> |          | -out-> |
      |       ------------        |
      -----------------------------

So we have two functions. One outer, and one inner:

Each function should have inputs and an output
Other than their outputs, they should not change anything outside their function space

If these conditions are not met, our function is not pure.

Step 1

Now consider a variable [V]:

      _____________________________
----->| [v]   ____________        |----->
      | ----> |          | -----> |
      |       ------------        |
      -----------------------------

Step 2

With our outer function, we create a function call for the inner function:

      _____________________________
----->|       ____________        |----->
      | [v]-> |          | -----> |
      |       ------------        |
      -----------------------------

Step 3

It is no longer in the state space of the outer function. The inner function takes ownership of it:

      _____________________________
----->|       ____________        |----->
      | ----> |   [v]    | -----> |
      |       ------------        |
      -----------------------------

Semantically, for the outer function [v] was used in the function call and then dropped. Which does not violate our rules. For the inner function, it just got an input and returns an output. So it makes semantic sense.

In practice, it also makes the same guarantees as any other pure function: - No null pointers - No mutable state - No side effects

If the caller .clone() our value and make a copy of it and pass that to the inner function, it provides us with no other guarantees, other than more memory usage and slightly longer code.

Why does it matter?

Well, honestly, it doesn’t. I just had to decide if in a pure function I can consume a self, if I want to make it a pure function, considering that I cannot make it const. This was my thinking output. Now you are the outer function.

Pure Rust

2025-05-30T15:49:34+02:00

If you are not familiar with Functional Programming FP, you are in for a ride. I will try to explain FP in more practical terms.

A definition to work with

FP is a declarative way of writing a program that consists mostly of pure functions that operate on and produce immutable data. That was many other unfamiliar words. Let’s make it concrete.

Making it more concrete

Here is a function in Rust that we will work on:

fn main() {
  // Calling `calculate_my_lateness` seems like magic.
  // We don't know how it calculates it, and why it is doing that.
  let mut status: bool;
  calculate_my_lateness(&mut status);

  // This sometimes crashes and sometimes, it does not.
  assert_eq!(status, true);
}

// The point of this function is to tell us if we are late
// Ask yourself, how would you write a test for such a function?
fn calculate_my_lateness(status: &mut bool) {
    let current_time = std::time::SystemTime::now();
    let expected_time = std::time::SystemTime::from(SOME_SPECIFIED_TIME);

    status = current_time <= date_time;
}

Now, let’s make it pure and while we are at it, we introduce pure functions and some principles as well.

Pure functions return at least one output

That means that if you have a function named some_function, you will have at least one argument some_input and it will return at least one output some_output.

fn some_function(some_input) -> some_output

Why do we do this? When we are calling a function, we are expecting something to happen. In FP world, the only acceptable something is an output argument. A lack of output is symptomatic of one of these two unacceptable situations:

Our function does nothing. In which case, why are we even bothering to write it at all?
Our function is doing a side effect. Which means that it is changing something other than what is inside the function. These functions don’t let us know or control what they are doing inside, without making us look at the source code. We will get back to this throughout this post.

Please note the emphasis on symptomatic.

So let’s make it return the output:

fn main() {
  let mut status: bool;
  let output = calculate_my_lateness(&mut status);
  //--^^^^^^------------ we have an output now

  assert_eq!(output, true);
  //---------^^^^^^----- which we use here
}

fn calculate_my_lateness(status: &mut bool) -> bool {
    //-notice that we are returning something--^^^^--

    let current_time = std::time::SystemTime::now();
    let expected_time = std::time::SystemTime::from(SOME_SPECIFIED_TIME);

    status = current_time <= date_time;

    status // <- what we are returning
}

Pure functions don’t mutate state

As I mentioned before, a function does something when it returns something and changes the state of something outside itself. We call that a side-effect. You may have noticed that our function takes a mutable variable of type bool and changes it. In our first iteration of the function, we needed it. But now, we grew out of it. So let’s just delete it.

fn main() {
  // let mut status: bool;  <- we don't need this

  let output = calculate_my_lateness();
  //--------------------------------^ we don't need to take status any more

  assert_eq!(output, true);
}

fn calculate_my_lateness() -> bool {
    //------------------^^- we don't need to take a mutable variable

    let current_time = std::time::SystemTime::now();
    let expected_time = std::time::SystemTime::from(SOME_SPECIFIED_TIME);

    current_time <= date_time //  <- what we are returning
}

Now isn’t this better? When I call calculate_my_lateness() I’m not worried about the function changing anything it’s not supposed to anymore. Let’s move on.

Pure functions return output only based on their argument

Which means that when I call calculate_my_lateness(), I should not expect it to do something different each time I run it. Why is that? There are two reasons:

Transparency: You should know what parameters change the output of a function, without needing to reading the function body.
Testing: It is hell of a lot easier to test a function that you can just control without needing to change the time of your computer. Won’t you say?

Let’s do it in two steps this time.

Step one: Don’t use global variables

You may have noticed SOME_SPECIFIED_TIME. This is a variable we use to make a SystemTime which we compare current time with to know if we are late or not. The problem here is these two:

We need to write a new function, each time we have a new meeting.
We also don’t know what time current time is being compared to, unless we first read the function, and then find out what it uses as SOME_SPECIFIED_TIME.

fn main() {
  let output = calculate_my_lateness(SystemTime::from(SOME_SPECIFIED_TIME));
  //---------------------------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^-
  // now the caller is supposed to provide the time

  assert_eq!(output, true);
}

fn calculate_my_lateness(late_as_of: SystemTime) -> bool {
    //-------------------^^^^^^^^^^^^^^^^^^^^^^-----------

    let current_time = std::time::SystemTime::now();

    current_time <= late_as_of
}

Step Two: don’t use functions with side effects inside your function

Imagine that you have a non-alcoholic drink, if you add another non-alcoholic drink to it, it is still non-alcoholic. But if you add an alcoholic drink to it, it will not remain non-alcoholic anymore. A pure function is only pure, if all the functions that are being called in it, are pure. And std::time::SystemTime::now() is definitely not pure. Now, at some point we need to get the current time, but we don’t need to do that where it is hidden from the caller.

fn main() {
  let output = calculate_my_lateness(
                   SystemTime::from(SOME_SPECIFIED_TIME),
                   SystemTime::now(),//<------ we provide the time
  );

  assert_eq!(output, true);
}

fn calculate_my_lateness(late_as_of: SystemTime, target_time: SystemTime ) -> bool {
    //-------------------------------------------^^^^^^^^^^^^^^^^^^^^^^^-----------
    target_time <= late_as_of
}

Now the nice thing here is that we can easily test this function now!

// main and calculate_my_lateness are not shown here. Don't be alarmed.

#[cfg(test)]
mod tests {
    use super::calculate_my_lateness;
    use std::time::SystemTime;

    #[test]
    fn being_late_works() {
        let res = calculate_my_lateness(
            SystemTime::from(A_TIME),
            SystemTime::from(A_TIME_THAT_IS_AFTER_LATE_TIME),
        );
        assert_eq!(res, true)
    }

    #[test]
    fn being_early_works() {
        let res = calculate_my_lateness(
            SystemTime::from(A_TIME),
            SystemTime::from(A_TIME_THAT_IS_BEFORE_LATE_TIME),
        );
        assert_eq!(res, false)
    }
}

Imagine doing this with the first function!

One more step

OK, I lied… Somewhat. Have you noticed the one glaring, lack of transparency and control here? It’s the <=. You may need to read the function here, if you have this simple question:

If I call the function exactly, at the precise moment that I specified to be late_as_of, will return true, or false?

Now, not answering this question using the function signature,won’t make my function less pure,but still, it is a much nicer experience for the caller to be able to rely on their IDE’s autocomplete to tell them what happens.But how the hell should we do that? Easy! We take a comparator function as input!

fn main() {
  let output = calculate_my_lateness(
                   SystemTime::from(SOME_SPECIFIED_TIME),
                   SystemTime::now(),
                   |late, target| target > late, // here the caller passes the function
                                                 // you can also provide a few different functions yourself to make it easier for the caller
  );

  assert_eq!(output, true);
}

fn calculate_my_lateness(
    late_as_of: SystemTime,
    target_time: SystemTime,
    comparer: fn(SystemTime, SystemTime) -> bool, // magic happens here
) -> bool {
    comparer(late_as_of, target_time)
}

Now the caller is providing us we have everything we need. We did not hide one single thing.

Isn’t this just more work for caller?

Well, yes. Yes, it is… if calling functions without understanding them is the only work that the caller of our function is doing.

Otherwise, our caller knows everything they need using their language server, can change everything they need, have the assurance of our tests and don’t need to crawl through our source code, and they will face much fewer bugs where they don’t know where it came from.

It may seem unnecessary for this simple function, but imagine much more complex functions.

Making things nicer: A spicy problem

So we have all this power and transparency. But the elephant is in it room: We have a very shitty API. Let’s make it nicer using a technique called currying (hence the “spicy” pun). What it means is: as well as taking functions as argument, we can return functions. That way, our calculate_my_lateness function can become a function-maker. Let me make it more concrete.

Consider the use case

Let us suppose that we want to find time in our list of times that is not late. Currently, we have to call the whole function, repeatedly, and include every argument.

// we are in main, don't be alarmed
let output_time1 = calculate_my_lateness(
    SystemTime::from(SOME_SPECIFIED_TIME),
    SystemTime::from(FIRST_TIME), //<------ we provide the time
    |late, target| target > late,
);

let output_time2 = calculate_my_lateness(
    SystemTime::from(SOME_SPECIFIED_TIME),
    SystemTime::from(SECOND_TIME), //<------ we provide the time
    |late, target| target > late,
);

let output_time3 = calculate_my_lateness(
    SystemTime::from(SOME_SPECIFIED_TIME),
    SystemTime::from(THIRD_TIME), //<------ we provide the time
    |late, target| target > late,
);

// etc...

This is not great. Here, We can just make a function that only takes our target time.

fn calculate_my_lateness(
    late_as_of: SystemTime,
    // target_time: SystemTime <------------ we don't need to take this argument anymore
    comparer: fn(late_as_of: SystemTime, target_time: SystemTime) -> bool,
) -> fn(target_time: SystemTime) -> bool {
     //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^---- notice that we are now returning a function

    |target_time: SystemTime| -> bool { comparer(target_time, late_as_of) }
    //^^^^^^^^^^^^^^^^^^^^^^           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    //         |                this is where the calculation of lateness happens
    // we are taking target time here
 }

You might ask, “well, how does this help?”

// we are in  main

// now our late_before_time_x is not of type bool,
// rather it is of type Fn(SystemTime) -> bool
let late_before_time_x = calculate_my_lateness(
    SystemTime::from(SOME_SPECIFIED_TIME),
    |late, target| target > late,
);

// So we can just:
let first_result = late_before_time_x(FIRST_TIME);
let second_result = late_before_time_x(SECOND_TIME);
let third_result = late_before_time_x(THIRD_TIME);
// ...much less boilerplate

Why `const` just won’t do

Veteran rustaceans among the readers of this blog might ask: “why not just use const to mark that functions are pure?” Well dear veteran, if you can make a function const, do every one a favor and actually do it. In fact, I regularly use clippy::missing_const_for_fn lint and suggest you to use it as well. But that does not guarantee that our functions are pure, or that every pure function can be const. Here are my reasons:

const functions can take &mut something as their arguments. Taking mutable references is definitely not very pure-function-y.
You cannot const trait methods in stable Rust, as of now. And considering that every function call inside a const function should be const as well, you are extremely limited, without any reasons that have to do with pure functions.
Many libraries don’t to use const on the functions that are const. Again, limitation without pureness reasons.

Making things declarative

There is this often repeated old joke that says:

There two hard problems in programming

Cache invalidation

Naming things

– Phil Karlton

And here we are concerned with the second one.

In the imperative universe, we usually name our functions using verbs. Think calculate_my_lateness.
In the declarative universe we are concerned with our output, we use nouns. Think lateness_calculator.

This makes the intent of our function clear. How it is implemented under-the-hood is not what matters to the caller. They only care about what they get out of it. If you now are thinking that you cared about that part before, consider the things that we just can answer by seeing the arguments that our function takes. We don’t need to rely on our function name anymore to tell use how the function is calculating lateness. We only need to know what it’s intention is.

Dear Reader

In this post, I just preferred to focus on the heart of FP: pure declarative functions. However, functional programming brings with it a set of extremely useful tools, patterns, etc. most well known are iterators, maps, folds, filters, etc. Honestly, they are well explained in other resources. My only suggestion would be to check out itertools crate.

Hachyderm or Fosstodon

2025-05-30T16:04:10+02:00

Ever since I have moved to the mastodon platform after the great twitter migration, I was curious about two main instances. One being Fosstodon, an instance oriented around FOSS, another being Hachyderm, an instance that introduces itself as social media for technical professionals.

Eventually, I decided to go with Fosstodon, as I liked what I was seeing there more. But I couldn’t put my finger on what it was that I liked more about Fosstodon, even though many of my favorite people resided on Hachyderm, the instance owner of the Hachyderm herself, being one examples.

Initial Theories

Initially I thought Hachyderm was more business-oriented. It seemed that people on Hachyderm were more interested about talking about broader technologies like kubernetes and docker, while at the same time there was a lot of talk about codes and programming practices.

I thought maybe all the programmers on Hachyderm are working with more proprietary and enterprise solutions and as such they were less likely to share details of their daily programming.

But that theory didn’t hold true, as there was as much toots in my timeline on Fosstodon about business related stuff as there was on Hachyderm.

Until last night that I realized that maybe what I was seeing was the difference of ideas between operations interested people vs people involved in developing software. And as a backend-developer, I could see more relevant content from the development side.

So I set to examine my assumptions. Like a good Bayesian.

APIs, Searches and Methods

To start with, I looked into different websites that could help me search per-instance results. That way I could search different keywords in each instance and compare the results. However I could not find such a thing. Every search engine I tried lacked the ability of filtering by instance.

After that, I looked into the Mastodon APIs myself. Long-story short, I found timeline API to be particularly useful:

GET /api/v1/timelines/tag/:hashtag HTTP/1.1

Using this I could get a list of toots in JSON format that had specific hashtags. And then filter those results to only get the actual URL. I used curl to make API requests and jq to filter-out the keys I was not interested in.

curl 'https://hachyderm.io/api/v1/timelines/tag/container?&limit=1000' | jq '.[].url' >> hash.json

And then, I had to filter out results that were not from Hachyderm or Fosstodon. And sort each. For filtering awk was perfect, and then for sorting the sort command is good enough.

awk '/fosstodon|hachyderm/ {print $0}' hash.json | sort > res-ops

I just had to come up with a few keywords that I could associate more with operations and a few for development.

As you may have noticed, my methodology is hardly scientific and extremely reliant on subjective definitions. My goal was to find a good-enough-for-my-decision result. Not anything more.

I ended up with these words on different sides:

Operations	Development
Kubernetes	Refactor
Monitoring	Debugging
Docker	Greenfield
Container	Framework
Terraform	Compiler
Deploy	Interpreter
Baremetal	Testing
Vm	Ide
Admin	Library
Server	DesignPatterns
_	LSP
_	NodeJS
_	Rust
_	Auth

The difference in their numbers are not important to us, only the proportions of the results of each may be relevant.

The eventual code looks like this.

#!/usr/bin/env bash

# Ops-related keywords
curl 'https://hachyderm.io/api/v1/timelines/tag/kubernetes?&limit=1000' | jq '.[].url' > hash.json
# ... (additional curl commands)
awk '/fosstodon|hachyderm/ {print $0}' hash.json | sort > res-ops
rm hash.json

# Dev-related keywords
curl 'https://hachyderm.io/api/v1/timelines/tag/develop?&limit=1000' | jq '.[].url' > hash.json
# ... (additional curl commands)
awk '/fosstodon|hachyderm/ {print $0}' hash.json | sort > res-develop
rm hash.json

The Result

On the ops query we have 32 toots from Fosstodon and 44 toots from Hachyderm.

Fosstodon ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
Hachyderm ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓

So far Hachyderm seems to have more activity with Operations related hashtags. On the other hand it could be that people on Hachyderm are generally more talkative than Fosstodon about every part of the stack. So let’s hold development as the control.

On the development queries we have 49 results from Fosstodon and 24 results from Hachyderm.

Fosstodon ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
Hachyderm ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓

That seems like a staggering difference. ¹

Dear Reader

I have no idea why this difference is so harsh. But for my purposes I have enough information to update my beliefs to make a decision for now that satisfies my accuracy-requirements for this decision.

Staggering differences are often a sign of weak research. So take this part with a grain of salt.↩︎

Power Structure of Social Networks

2022-11-15T21:38:00+01:00

Why do some nations fail and rise so quickly? The answer to these questions has a surprisingly relevant answer to the recent migrations from a Twitter to Mastodon.

Power Centrality

Basically the idea is that:

In any system of governance the authority is constrained to the resources it has available.
And for the authority to make a change, it has to answer to the resource providers.
Given a set interdependent institution one could form check-and-balance system.
If the dependence is not formed in a way that is biased towards zero-sum relationships the authority thrives.
For the society to thrive it should be considered an institution on its own.

Let’s make a few different forms of government considering the rules I just discussed.

As dependence on involvement of people only comes when governments want more power and cannot retain the resources necessary from the land, High Natural-Resources and High People-involvement tend to be mutually exclusive.

High Centrality, High Natural-Resources, Low People-involvement

Let’s imagine a dictatorship on a land with rich natural resources. Dictatorship is a strongly centralized form of government. As such, the dictator does not have any dependencies. You might think that the government does need its people. But most of the time, such dictatorship has all that it needs from the naturally available resources.

The dictator does not have to answer to anyone, and they have all the means necessary to make rapid changes, good or bad. The whole of the nation rise and fall quickly. The civic progression does not accumulate in time and only will be there while the dictator let it be.

The government does not need people uniting, form a danger to the government. Such authorities are highly motivated to bring social conflict, such as racism. Which may even lead to genocide by members of the society.

Think of Middle-east with its rich natural oil.

High Centrality, Low Natural-Resources, Low People-involvement

Now, let’s imagine a dictatorship on a land with no natural resources, and no inclination to involve people.

Such a nation will not flourish. The dictator is extremely constrained in its power.

It has no validity among its people. As such it is unsuccessful in enforcing any law, good or bad. Such a nation sees lots and lots of coup d’états. The authority is more alike a warlord.

Think of Central African nations.

High centrality, Low Natural-Resources, High People-involvement

Such a dictatorship, is a highly populist government. The dictator threats people as the main form of resource. Such nations can rise quickly. But before too long, the authority will figure out that he only needs society’s approval, but not its growth. And if you need approval, there is no quicker and better way than a common enemy. As such, such nations become too hostile to other nations. And may end-up using genocide as a means of keeping the country united.

Think of Germany during the Hitler era.

Low Centrality, High Natural-Resources, Low People-involvement

Such a nation looks great from the outside, but inside? It is polarized to say the least. These nations, just like any other nation with Low-Centrality is stable. The is formed by a group of institutions which keep each other in check. But alas, what good is it, if it is not for people?

Such governments end up becoming extremely rich. But because people are not required for the government to perform, most of what the government is doing is providing value for the few that can provide them the resources they need.

Such governments nations are subject to low progression in the civic laws, are extremely hard to change, and form strong bonds with few entities. As people are seen as a barrier, government’s like this tend to have a lot of controversial and theatrical surfaces, but end-up deciding things behind closed doors.

Think of the USA during recent years, as it managed to put a huge people’s involvement.

Low Centrality, Low Natural-Resources, Low People-involvement

These governments are stable, but irrelevant. They fail to bring order, or protection for their people. And they don’t provide any infrastructural benefits the society.

Think of Afghanistan Right after the USA army left it.

Low Centrality, Low Natural-Resources, High People-involvement

This, at least for now, seems to be somewhat the better of them all, but with some caveats. These governments are highly stable, and highly motivated by providing value to the people. They accumulate wealth and culture overtime. They are, also, resilient to hostile neighbors and bad actors. These societies tend to look good on the outside, but much better on the inside.

However, such governments are only weak to adapt to any radical changes, as the changes only happen when the people will it to happen. That means that these societies tend not to be the leaders or experimenters of different sorts of progress. However, they may end up reaching the top of the leader board in time.

Think of Germany, today.

How does it relate to the Twitter and Fediverse and… ?

Well, there is an analogy to be made here.

We can see the body(s) that runs, maintains, develop and moderate a social network as a form of a government. The users as the people and society. And the way that the proverbial social-network governments are being funded as the determining factor of people’s involvement in governance.

In that regard we can think of Twitter, Facebook as highly concentrated. Considering that their power is immensely related to the number of users they have, we may be tempted to see them as somewhat of high in involvement of people. But in actuality, people do not need to be actually participating in governing such a system. As they are the product, and the value comes from external means. That means that the users ended up being the natural resource of the land that is being sold for resources to the external actors.

As such we end up with both exploitation of the users and their lack of ownership of their own data.

So, what can be the solution?

Considering how unfortunate this situation is, there have always been a few different alternatives. Let’s just review them.

There are systems that don’t count users as product, but as the customer. Such services, though small have a better record of listening to users.

However, as any centralized system, they are unstable, they remain small, and to keep users, they resort to vendor lock-ins. They also resort advertisement instead of increasing real value. Think of apple with its anti-advertisement campaigns against Microsoft.

Another solution might be highly centralized systems without any sort of resources. These tend to be highly volatile and fast to disappear.

So, decentralization might be the way to go.

As low-centrality but highly-resourcefulness goes, I can only think of mailing groups. Mailing groups stand on the shoulders of mail providers.

Decentralized as mailing is, the ecosystem overwhelmingly is provided by a few companies that their main products are again, people. As discussed earlier, such systems tend to not have much progress. At least, not for the non-governing bodies. And indeed, that has been true. Mailing and mailing groups is as user-friendly and feature-full as they have been 15 years ago.

Which makes us resort to our last option. Low centrality and High involvement of people. Such a system has been the model for open-source development. Where the governance is highly motivated to help the people the same time as the people are highly motivated to help the governance. Such a model has ended up being extended into forms of social governance. Where users fund their instances, help development and do volunteer moderation. And indeed, again, the parallel is not surprising: These systems tend not to have the greatest of the starts, but they end up enduring, and becoming more resilient.

Mastodon, Pixelfed and other federated, open-sourced social networks, operate in such a model. And I like to think of people moving from Twitter to Mastodon as realizing that they matter and can should be more.

Credit

This work is highly inspired and heavily reliant on Daron Acemoglu’s fantastic book, Why Nations Fail. A must-read.