is AI expensive on us?

hitblast — Thu, 12 Mar 2026 00:00:00 +0000

Had a nice day; did some investigation on the code of a Minecraft launcher project I'm currently contributing to, and, guess what?

I got bombed by AI doom-and-gloom content again.

(did I go a bit fast on the description of the whole topic of- this entire blog entry there?)

Anyways, well, it was only two videos which I watched, one after another. I'll quickly hyperlink those down here:

"It Begins: An AI Tried to Escape the Lab" (more recent)
"This Will Be My Most Disliked Video On YouTube"

Both of the videos are by Species | Documenting AGI, and I quite appreciate the length and effort the content has. What I don't really appreciate about these are, is leaving the audience with cliffhangers.

Don't get me wrong but, I hate cliffhangers which feel more like a delayed but consistent jolt in your mindset, rather than consistent, balanced-out surprises which could pique your interest but at the same time, provide you with a sense of plateau.

I have seen this pattern emerge with AI-related YouTube doomers which I'm seeming coming across more nowadays, really, and I kind of not like the trajectory of it.

In a world where software quality is substantially declining by folds of ten, every, single, day, in my opinion, AI is probably one of the things which I believe humanity really needs to regulate in general. If you ask me personally, I'd not be surprised by how delusional the community has become over time with all these Qwen, GPT, LLaMa, Grok or even Claude (especially Claude) models overriding their sense of judgement.

There used to be a time where software was insanely predictable, and even though I'm nowhere near in the same grounds as the top researchers in this field to say this, but, we've quite lost that predictability with the new tools we're seeing emerge lately. Now don't get me wrong again, but, I'm quite frustrated by LinkedIn people screaming about the hype they're unknowingly flueing, full-steam, with those em-dashes you hate ("—" <- this).

We've lost originality in music, and I don't think its unjustified for me to say this. I had to quit Spotify because of the amount of saturation I was getting from all the repeated AI music plus my playlist which has been degenerating itself through all the recommendations I get.

I think it'd be pretty sad if you told someone from the 1900s that we've now lost originality, in music.

And,

We've lost originality in all the creatives. Yes, I'd count programming in it as well - programmers usually don't count themselves as creatives anyway other than an elite few but oh well... I also stumbled upon someone's comment in a random video I was watching, and I perfectly like their analogy:

Using AI for art and calling yourself an artist is literally the same as ordering food from a restaurant and calling yourself a chef for that.

On an even more serious note, someone had said this:

By giving AI, you've effectively granted stupid people to be egotistical about the creativity they don't have.

I, personally, like predictability. I, personally, also think that even if I had graduated from linguistics, I wouldn't just fire up Claude Code one day and decided that I want to be a programming languages designer and design an entire language without guilt in my head - that I'm skipping the cognition required to make that very object exist, without depending on external audit.

Have we really degraded that much?

Earlier this week, I was in a conversation with one of my friends on Discord - he's probably three years senior, but it very much surprises me that CS majors in my country don't know the fundamentals for building a simple web-based WireGuard/OpenVPN client. They just vibecoded the entire thing, with Antigravity, while not taking agency of their code, and calling it a day.

Now if you really like these tools, I'd not blame you. They're excellent at some things in particular. But guess what they're not excellent in?

Keeping your cognition alive.

The very same predictability we were promised in the early stages of development, is being stolen from us, explicitly.

Traditional algorithms are playing catch-up with all of this as well. One moment, I see a video on whether engineers are becoming dumber in my feed, the other moment I see some typical CEO ramp up their product saying it "doesn't hamper engineers". I usually tune into YouTube for some wholesome content that I want to watch (yes, the typical videos in which people comment "this is what YouTube is made for"), and it turns into an unpleasant experience within mere seconds of logging in.

Judge for yourself and I'd like to know where you find the predictable human interlace in this.

Software used to have QA. Even Anthropic's own deployments don't pass three nines nowadays. Are we really in for this deploy-and-break style too? Amidst all of this?

Rust's core motives are awesome. Do you know what's not awesome? People proudly naming their 0-1 employees LinkedIn/GitHub organization after a Rust acronym and pushing AI slop as it engulfs more of the corporate-controlled minds which are already pretty bullish on a tech we don't fully understand the effects of.

Phew..

Well, I don't know how well of a content-defined chugging of hate towards the world we're headed for I did right there, but I'd just like to ask you two, simple questions.

Is AI really expensive on us?
Is it too late to pull the plug?

As much of a satire I want this blog entry to be, it breaks my mind even more to think that it isn't.

christmas eve, and a battle to create a time capsule

hitblast — Tue, 30 Dec 2025 00:00:00 +0000

foreshadowing: this is future me looking back at this post, and feel like I skipped a lot of code explanations which would've been a great addition. regardless, this was written within a strict timeframe so, hopefully you'll grant my mistakes while reading :3

During the afternoon of 25th December, I was just casually hopping around Discord in search of what to do. I randomly joined a voice channel on my Minecraft team's server, and one of my friends also (luckily) hopped in. <@Itsmemonzu>, turns out, was also looking for something to do; and a second friend joined to aid him with his idea shortage.

Previously, his urge led him to install Zed on his beefy machine (after I told him about how it uses the GPU for rendering his code), and somehow all of a sudden he wanted to do all-things Zed only. The second friend, in the meantime, suggested him that he makes a time capsule program. I'll return to this in a bit.

Now as a matter of fact, the size-to-functionality ratio of his previous applications were pretty unrealistic - say, 64 megabytes for doing a GET request to the Minecraft Server Status API, and after he himself recognizing the problem, my futile attempts to motivate him back to use C# for his desktop apps were all turning to vain. He eventually turned to Python for this one.

Then suddenly he had asked - "how about we do a programming challenge over this?"

Hmm, not a bad idea!

I hadn't had a programming battle with someone ever since the prehistoric days of HackSquad 2022, so doing this was going to be fun, and Monzu's learning nature was also going to be interesting to analyze within the challenge. We eventually agreed on a few things:

Different stacks. Obviously. He'd be using Python while I'll do the same program in Rust.
We'd both be using a shared algorithm for determining (but this has some lore to it, so be alert while reading).
We'd have to finish it within the Christmas Eve - a fully working copy of our projects, that is.

I'll be attaching more context along the way with this entry. Till then, the game was officially on for both of us!

intermediate planning

We were connected to the same Podium VC we initialized with for the entirety of the challenge, and while talking, we both discussed some common frameworks for our programs:

His stack	My stack
Good old Python as usual.	Rust for me.
The Rich frameworks. Great for TUI/UX. He wanted his CLI to be fully interactive.	clap for me since I didn't want my iteration to be interactive at all for saving some time.
TinyDB as the database, since he was already fluent enough working with JSON tokens.	I wanted to build my own database for the work, hence I'll be creating ChristmasDB.

Now let's discuss the initial concept of a time capsule. As our friend Rem had described it, a time capsule is:

"A program that saves a text and keeps it away, and finally returns it after a certain time."

Here's a bit of my thinking process:

My first thoughts after seeing his idea was - bootstrapping such a simple concept into a CLI and not making others bored would be a difficult task. I had to think of something which Monzu wasn't planning about. I'd have to ensure two things:

Make the code insanely simple to use. That'd consume more of "my" time, but it'd ensure that the entire thing works on all the three major desktop platforms I'd be targeting.
I'd have to wrap everything in just the ChristmasDB layer so that commands are only hardcoded iterations of the stuff I want to do.

And, based on what I heard from Monzu:

He wanted to use the least amount of commands so that his CLI was fully usable by just the press of a few keys (except for typing the actual text).
He also wanted to take advantage of Python's dynamically-typed ecosystem to reduce code as much as possible.

And, based off of the sentence Rem had told us, we'd have to create a way to actually "put the text away from the user", so that it is not accessible before the time the user allocates, so we'd need a way to encrypt the text and make it undetectable without some sort of deciphering mechanism.

ignition

We had started by discussing about the common stuff at first. He (and eventually I too) had decided to call each input of the user a "capsule", which had the following fields attached to it:

The actual text, but ciphered.
The datetime indicating the exact moment the text was ciphered away.
The lifetime of the text. Things can't be permanent, just as in life.

He first thought of running a background job to give real-time insight of the datetime to the program, but I had a simpler solution in mind since spawning workers for a project like this was blatant overengineering. So, seeing him mess up his core analogy of the program we were about to make, we decided to share our algorithm. It was pretty simple:

The program would only work when executed - not in the background, so that's one axed thing.
Since we're already tracking two time-tracing fields (2 and 3 above), it'd be very easy to calculate future_time (in this case, the approximate time when a particular capsule should be unlocked). This would work by incrementing the user's given duration as a timedelta to the time when the capsule was created.
If the user wanted to check whether a capsule was unlockable, it'd just check a condition: if (future_time < present_time) {... # do unlock stuff}

monzu's route (algorithm)

After all of the yapping about the initial brainstorm phase, we were finally ready to start working. While I was entirely focused on the ChristmasDB layer, Monzu was honestly making some pretty good strides. He had started off by creating his input layer which was composed of numbers, and occasionally, some text. Primitive in nature, but works.

He was also streaming for me to help with some of his stuff so I had a sneak peek at his input strategy:

Create a capsule (1)
Check for unlockable capsules (2)
Unlock capsule (3); Your choice (1/2/3/exit):

Turns out he was going all-bland on the CLI, leaving the opportunity to simplify things a little. I didn't know whether this was going to change for the lifetime of the challenge, but we'd see shortly.

I also asked him regarding his backend logic and whatnot. He was busy handling timedelta and datetime objects with his TinyDB instance. Inspecting some of his "last" code that was uploaded to GitHub, I can see some remnants which I'm bound to explain in this blog:

# P.S.: My indentation got wrecked copy-pasting this snippet.

    elif action == "3":
        print("[white][bold]Which capsule do you want to unlock?[/][/]")
        num = int(input(":")) - 1
        # Check current time
        now_time = datetime.now().timestamp()

        # Accessing JSON Data
        parse = database.all()
        unlock_time = float(parse[num]["time_limit"])

(online snippet's here)

I'll provide some entirely personal comments from here onwards (and some sweet, sweet lore).

Going into the snippet, I could do nothing but get flabbergasted by the inconventional naming conventions (even though the code's working perfectly). The unreliable parsing from parse[num]["time_limit"] might also seem a little vague at first, since there isn't a strict schema being enforced due to Python's core json implementation being dynamic in nature.

As a matter of fact, during the primary (and late-game) stages, Monzu himself ended up parsing the time_limit field as integers rather than datetime instances, and even when he did end up parsing correctly, he passed datetime objects directly into the schema for reflecting back. *confused Monzu noises in the background wondering why it ain't behaving like Rust*

As of the shared algorithm we were talking about implementing, his way of implementation was, again, using the time_limit field. The snippet is this:

def checkCapsule():
    now_time = datetime.now().timestamp()

    # full database init here
    # I removed all comments except this one
    parse = database.all()

    for i, unlock in enumerate(parse, start=0):
        unlock_time = float(parse[i]["time_limit"])
        if now_time >= unlock_time:
            print("[green][bold]You can now unlock your Capsule No." + f" {i + 1}")
        if now_time < unlock_time:
            print(
                "[red][bold]Your capsule No.[/][/]"
                + f" {i + 1} [red][bold]is not unlockable yet.[/][/]"
            )

(online snippet's here)

For some weird reason, he ended up implementing the same algorithm twice in two different places. I mean, okay, that's why functions exist. But, have a look yourself:

    elif action == "2":
        checkCapsule()  # implements check
        time.sleep(5)
    elif action == "3":
        print("[white][bold]Which capsule do you want to unlock?[/][/]")
        num = int(input(":")) - 1  # de-facto inputs

        now_time = datetime.now().timestamp()

        parse = database.all()
        unlock_time = float(parse[num]["time_limit"])  # recall here
        if now_time >= unlock_time:  # also recall here

(online snippet's here)

I hope you clearly see the minor details I've pointed out in front of you. The code works nicely, no comments regarding that. But, it'd just break with one algorithmic change (saying just for the name of explanation).

my route (algorithm)

Now, not to brag or anything about code - in fact I actually write pretty bad Rust, and considering the fact that other, more knowledgable people use the stack with lifetime specifiers, generics and whatnot for simple data parsing like this, I truly am new to this. However, I took a different approach to the same problem he took upon.

He still hadn't handled the encryption layer, but I picked the good old AES encryption method as my staple. I was also learning about its implementation at the same time since I had never implemented it to date on a CLI project. Within the ChristmasDB layer, I also implemented a few functions which did the following:

One function for comparing now_time and future_time.
One for generating a new ChristmasDB instance with a user-defined password. This would generate a [0u8; 32] key unique to the particular password.
One function for generating a new capsule from a given text. This one did the following in order:
1. Prepare the cipher. This includes generating a new iv for each text powered by rand::rngs::OsRng, which'd later be used to create a cipher by attaching with the key created beforehand.
2. Applying a keystream to the text so that it gets ciphered.
3. Store it within a capsules variable within the store.
One for autosaving the database, since I'm too lazy to setup manual CRUD operations along the way. I'd use autosave() after the inner logic of the add_new_capsule() and remove() commands to write the instance to disk automatically.
One for decrypting a Capsule object (yes, I used structs for capsules too).
And finally, one to remove a capsule instance from the store.

The code is too long for me to include here, so I'll just include the primary algorithms here. Rest will be linked.

For checking whether a Capsule should be deciphered, the is_awaiting_decryption() method had been implemented by me as such:

// yes I used serde for the whole store
// that too in JSON
#[derive(Deserialize, Serialize, Clone, PartialEq)]
pub struct Capsule {
    data: Vec<u8>,
    nonce: [u8; 16],
    should_be_kept_for: Duration,
    time_added: NaiveDateTime,
}

impl Capsule {
    pub fn is_awaiting_decryption(&self) -> Result<bool> {
        // This uses NaiveDateTime from the `chrono` crate.
        if let Some(future) = self.time_added.checked_add_signed(self.should_be_kept_for) {
            Ok(future < Local::now().naive_local())
        } else {
            bail!("Duration overflow when computing unlock time.")
        }
    }
}

I will also include the decrypt() function for you to have a sneak peek:

    pub fn decrypt(&self, cap: &Capsule) -> Result<(String, usize)> {
        let mut data = cap.data.clone();

        // AES 256 in CTR mode; this is just a type-override from the `ctr` crate.
        let mut cipher = Aes256Ctr::new(&self.key.into(), &cap.nonce.into());
        // Apparently applying keystreams twice reverses the encryption.
        cipher.apply_keystream(&mut data);

        // Improper parsing handled since keystreams can be improperly applied,
        // given that the user has provided a wrong password.
        let text = String::from_utf8(data).context("Invalid UTF-8, possibly a faulty password?")?;

        let idx = self
            .capsules
            .iter()
            .position(|x| x == cap)
            .context("Capsule not found! Did you delete it manually? :suspicious_eyes:")?;

        Ok((text, idx))
    }

(get the full ChristmasDB snippet here)

I had a lot of fun making this work.

Returning to the original lore, I also implemented CORNELLI_PASS as an environment variable through which the user would apply to set a password. I looked at Monzu's iteration, and I couldn't find a password. Seems like he stole the password side of things from the user and entirely put it on the hands of his own program; which is, I don't know whether to call clever, but the solution kind of works, but then again it becomes pointless.

Oh and, I'd only create two commands:

keep "anytext" <duration>: Keeps a capsule and keeps it away till the set duration.
mailbox: Gives you a surprise Stardew Valley-style view at the messages you're meant to see at the moment, probably left by your past self.

two new interfaces

I was kind of envious of his implementation, for that he managed to at least get a primitive solution up and running that fast. I was being very lazy to pass a mutable string variable to an io::stdin() call, so much so that I had to compensate with even harder clap arguments.

Anyhow, I had previously created rust-cli-template for my personal projects, so that came in handy. I had just cloned and deleted the .git folder to gain a headstart. This was before all of the algorithmic lore described above. By now, Monzu was getting into the encryption part of things, and I was just starting off with the UX.

I implemented the storymode-like interface for mailbox. Also, something different had also started happening while I was doing that.

By the time they had joined, it was almost 6 hours that Monzu and I were talking in the channel for, and they found us in completely different states. I had spend a ludicrous amount of time optimizing the database, so I was pretty much clear for UX. I had also yoinked the duration-parsing (1h2m1s-style) from trimsec to get some boost. On the other hand, Monzu was only just getting into duration parsing. Frantically enough, he started seeking help from both furti and wolverton regarding some other topics.

Wait, aren't they supposed to be judges?

Anyways, he had also asked me about duration-parsing beforehand. At first we concluded that only doing it by the day would be cheap enough for the project, but upon looking at the actual problem, neither programs would've been able to track the correct decryption time if we had done that, so I skipped over the simplification idea. Turns out, Monzu didn't get the clarification and he had implemented a days-only parser.

I was seeing an unreasonable amount of panic within - I bet he could've hardened his runtime for comfort (no pun intended).

He ended up adding a positional parsing method for the duration (x hours, x minutes, x seconds, non-comma-separated). Having a look at his source, we can see exactly that alongside his self-password mechanism:

          # Parse key from key.txt
           with open(keyFile, "rb") as keyFile:
               readKey = keyFile.read()
               f = Fernet(readKey)
           message = f.encrypt(input().encode())
           user_input = input("Set time limit: (i.e 2 50 30 (day/hour/minute)) ")
           days, hours, minutes = map(int, user_input.split())
           time_limit = datetime.now() + timedelta(
               days=days, hours=hours, minutes=minutes
           )
           if isinstance(time_limit, datetime):
               database.insert(
                   {
                       "message": str(message),
                       "time_limit": time_limit.timestamp(),
                       "current_time": str(datetime.now()),
                   }
               )
               print("[red][bold]Your message has been capsulized!")

(original snippet's here)

a chaotic release

Seeing Monzu's unreasonable panic, furti gave him an additional 10 minutes (which ended up scaling to 30 minutes since Monzu was ignoring that). We also saw some late-game failures in his code. Remember the datetime and timedelta objects we were talking about? Turns out he was parsing them wrong again, and this time he was fully yelling in the voice channel.

This isn't supposed to be a Monzu-rant blog entry, but he quite literally realized that datetime and timedelta were distinct data types and not derivations of language primitives. Quite fun.

We had another bit of coding leftover. Monzu was closing in on the finish line, and I was already finished, looking for further polishing ideas. I even tried downloading the Stardew Valley Overture soundtrack just for the demo for presenting the mailbox command, but ultimately that didn't turn out well, so I scrapped the idea.

Once Monzu was finished, we were counting down for the CI builds. He was pretty much off with the Python interpreter and the pyinstaller library for packaging. My builds actually failed once since I had kept the old bin names from where I had gotten the workflows (one of my previous projects), so I had to restart it with freshly. After that, we both submitted.

And then, we made both of the projects public.

I released the repository with the name "cornelli", and Monzu released his by the name "Shomoy", which means "time" in Bengali.

Both furti and wolverton were checking out our repositories. My project was first tried out by wolverton, which he cleared without hesitation (and also gave me a nice rating, thanks wolverton if you're reading this). While reading the documentation, he had also asked for some alignment with the setup procedure, since I didn't include the particular setup procedure for PowerShell/cmd, and setting CORNELLI_PASS failed inside that particular Windows environment. I'm pretty glad I could fix that by just changing export to set inside the command.

As of Monzu, his road was a little bit rocky. The primary issue being him not including a sort of "dependency lockfile" in his project, ultimately leading to furti and wolverton running the following command to install the three dependencies:

$ pip install rich cryptography tinydb

After some iterations, wolverton (watching my stream) and I managed to get his application running.

I won't take the courtesy of the overall review. That goes to the judges.

Wolverton had left a massive review for both of the projects. He rated in four categories: documentation, installation, the actual program and overall. On the contrary, furti left a huge almost-40-minute review on both of the projects, which is private so I won't be sharing it here.

verdict by the judges

Even though the overall result was biasing towards different things, both Monzu and I faced criticism and questions for our design choices. For example, the CORNELLI_PASS pattern I was using got questioned by furti since in the v1 release, it wasn't behaving well at all for some mailbox entries. We ended up fixing it later on.

On the flip side, Monzu faced criticism for the following things:

Providing no lockfile.
Providing zero documentation (he actually erased his README.md while force-pushing without prior knowledge).
Changing the codebase at the time of the review and telling judges to download the latest source.
Having several dependencies.

And with that, we got ourselves two new projects.

cornelli: Write to your future self.
Shomoy: A time capsule for your terminal.

I'm very thankful that I had agreed to do this challenge, as this was close to a teeny-tiny hackathon for both of us. Hmm, maybe I could continue this with my friends?

Till then, thanks for reading this entry <3 signing off.

the art of believing that life's "fixable"

hitblast — Fri, 14 Nov 2025 00:00:00 +0000

So, today, I was looking at that one building from our balcony, which is seen the tallest, and is especially beautiful during the sunsets. I was thinking about numerous stuff and suddenly that one thing felt beautiful - and I found myself, thinking in mind, maybe there's an intergalactic space, or less likely, a star, sitting at exactly the angle I was looking at the building in.

Regardless.

That's one of the many random thoughts I have during the day, and even though at that moment I felt like maybe I could write a book extending my glossary of thoughts about just that one building. But that'd be useless, wouldn't it? Who likes to continuously yap about a building. Rather, I thought perhaps let's extend it into something which I can actually write about in my blog.

Speaking of extending - I actually learnt how to extend a HashMap when I was working on defaults-rs for my Mac tooling/apps company. It's fairly easy -

Prepare the existing hashmap, or maybe if you're in a function, get a mutable reference to it, so assuming if the variable was some_map, you'd have to do: fn merge(&mut some_map) -> HashMap<String, PrefValue> {...} (here PrefValue is the enum used for separating types in a CoreFoundation value).
Prepare the other hashmap. That's what I'd do inside the function.
Call: some_map.extend(new_map.clone())

I just wrote a raw representation of what I'd do in Rust (that I learnt today). I don't even know if this would make clippy happy, but you get the point. I like sharing, and I don't know, maybe you like reading :D or do you? :eyes:

The thing that I actually wanted to share through this is, the lack of open talk, and I'm very much afraid at how its scaling better than AI data centers nowadays. Researchers suggest that loneliness is at peak during these times, and yet people buy subscriptions to talk to their favorite custom characters/avatars "powered by AI" (well maybe I don't know, maybe transformer models are simply feeling more understanding than humans nowadays? I'm no one to judge).

I actually find it kind of frustrating that we are literally surrounded by people around us - and yet we feel so lonely, and that so many people are suffering from the same issue but no one is willing to give up their attention-seeking machines to stabilize their dopamine economy. The world's simply not like that anymore.

Or, is it?

Quitting my phone has been fairly easy so far. I'm studying for entrance, and even then sometimes I get attracted by my laptop to do some programming on the open-core organization I'm trying to establish. Maybe it's a good thing - maybe it's not. But regardless, I have found myself to be much more attracted to work when I'm not using my phone. Programming feels like a craft - and genuinely I think those AI gurus who are generalizing the attention economy and spreading false-positives on LinkedIn about how AI is giving them x%+ gains are simply missing the point of cognitive debt in a spectacular fashion. And, I think it doesn't just apply to programming, it applies to all means of life.

Let me remind you that these are the same algorithms which feed on your data for their survival and keep you engaged. Maybe you won't even find a toddler nowadays who wouldn't eat without TikTok sitting right in front of his underdeveloped eyes.

Anyways,

Let's return to open-talk. What happens after you do leave your phone for good?

I mean this article surely wasn't about phones or AI or even that hashmap merger I previously mentioned. I'm just trying to get you on flow with my thoughts of the preface here - it's just harder to explain without it. Open-talk is significantly undervalued in our society. In a world where you can get your answers from a non-emotional reasoning artifact, its generally costly to do so. But it does preserve one critical aspect. Organic conversations.

Maybe you get your answers slow. Maybe its generally fuzzier, and even conflicting in some cases due to a second ideology being involved during the conversation, but you eventually share pieces of you which you otherwise couldn't. Not even to a chatbot - your conscious simply won't allow for it.

Maybe I got that part covered. Let's talk about a different aspect.

How about, umm... enforcement of thoughts? Okay this one's good..

I'd like to believe in the fact that most problems we think of everyday, including the overestimation of goals, are created by just us. We simply overcalculate things we have not even reached. I'd also like to believe that this is a clear indication of escalated overthinking. I mean, most people don't even get to start that one initiative they thought was groundbreaking, just because they had enforced the thought in their neural pathways that it simply was too far-reaching.

My take? You have no risk of failure (except its something different which I'm not covering here), so there's no risk in trying to succeed in something. Enforcement will only get you so far - and possibly even lock you into your own demise.

I think I've covered this aspect too, let's cover a different one.

Umm..

Well, let's talk about something else for now.

I've written this blog entry without too much markdown because it gives me the creative liberty/space I need for my brain to stretch the vocabularies out into something meaningful. I got this habit from minimalizing my desktop setup. I've done the following:

Plain window management (caps-lock as the hyper key).
Very minimal Neovim (although I've been writing stuff in Zed which is specifically for programming). I do love to keep the raw completions and LSP just in case I do decide to write some code, though.
Tried to translate formal gibberish into casual manuals when I'm writing my GitHub READMEs.

So, what minimalism actually did to me is, I've started to do my conversations in a more straightforward way, which leaves pathways and some additional working memory on my brain open if I decide to add some creative salt. What this does is - it gives you the raw open-talk feel, but instead now its generated by you, which is kind of self-healing in a way.

It also elevates the liberty you wish to have in your creations or probably even your thoughts. The Internet's so much of a simplified and generalized nonsensical wasteland nowadays that we're often forced to believe that there's only one or two ways of presenting something. Let it be our personal blogs, or even our posts on social media.

Social media engagement is also a big aspect of loneliness, which many people don't want to leave. I mean, leaving wouldn't be an ideal advice in this case, rather, what you can try is "desensitizing" your social media.

I regularly talk in places with E2E encryption enabled. One cool option is WhatsApp - but with the crazy amount of data Meta ingests from these platforms, there's no wonder why I get insanely accurate advertisements on its child platform Instagram. So I ditched both of them, rooted for something that only me and my personal contacts can use. In the process, I have also deactivated a bunch of other social medias in favor of more desensitized ones like BlueSky and Mastodon.

What it really gave me is, I got the transparency to show up not just in my projects, but also in my social profiles. It helps me present the originality I really want to produce, and hopefully you will too.

Have some real conversations. With the people you love.

Keeping faith in the fact that life's fixable is what I believe to be a genuine form of mental art. I don't think its too much to yap about, but life actually fixes itself if you just allow the small, incremental changes to happen. What I really meant by representing these three tiny aspects is that, even though the descriptions might be regulated to small terms, these issues actually add up, and often scale to millions of people. It's like we're at the brink of selling melancholy, quite literally.

But, by displaying these aspects, I also wanted to share my take on how they can easily be removed.

That's a lot of yapping. See you next time!

my fish shell experience, and why I might not need it

hitblast — Sun, 25 May 2025 00:00:00 +0000

a misleading title

Well, fish is indeed a good shell (I'm not foreshadowing at all, totally... maybe?) for those who prefer scripting in a simple language, and some modern features like on-the-fly autocompletion and more. And, at the time of writing this entry, I'm still using fish on my Mac.

I've been an avid bash user for over 5 years now, and although I switched to zsh during my first transitional period into macOS, the urge to write automated scripts for solving other tasks and doing mundane tasks really brought me back to bash.

However, as many people jump in to oxidize their toolchain and generally every set of software they use, I decided to give some oxidized tools a try as well (by "oxidized" I'm referring to apps/tools written in Rust). And, the trend isn't really new! I've been using Rust-based tools for quite a while, including:

zoxide - a replacement for cd
eza - a replacement for ls
mise - my personal favorite; a replacement for asdf for managing toolchains ... and many others

And in the process of using them, I have actually created some of my own, simple tools:

cutler for automating my macOS setup, acting as a replacement for manual scripting
hookman for writing git hooks with TOML files

Rust is really an awesome language for the developers of the 21st century in my opinion. It's safer, faster than most languages and the compiler really helps out at even the silliest of optimization mismatches.

does it deliver?

Thing is, it does.

Rust's speed along with its concurrency features, if coupled with tokio for async, or rayon for multithreading, can lead to major performance bumps which can also be seen in literal desktop apps too! The edge CLIs deliver over desktop apps is that, it's just a lot more fun (and significantly faster) in terms of I/O and general throughput if you're a terminal fanboy.

So, after judging all of this, I decided to give a Rust-based shell a try.

getting my hands dirty

I installed the shell with this command:

brew install fish

# add to shell entries and init
sudo sh -c 'echo /opt/homebrew/bin/fish >> /etc/shells'
chsh -s /opt/homebrew/bin/fish

Now my first impressions with the shell was, "How in the world is it fetching completion data without me even needing to put a config file?"

I honestly got surprised with the out-of-the-box experience of fish. It automatically sets up autocompletion. Though, I ran into a few difficulties at first:

My typing speed wasn't really syncing with the completions (a crucial detail we'll get back to later on).
I still needed to setup vim keybindings with fish later on since I'm used to having h j k l for moving around.
All of the commands showed up perfectly during auto-suggestions, but they didn't work.

solving the config crisis

So, after running into the difficulties, I had to figure out how to configure fish on my laptop. I have a dotfiles repository which you can find here, or in the homepage of this website. I use this repository to keep all of my desktop configuration in place.

According to the documentation, the config file should reside in the following directory:

$HOME/.config/fish/config.fish

I had to go to the dotfiles directory manually and create the file after undoing my symlinks to the home directory:

cd dot  # zoxide coming into play

stow -D . -t ~
mkdir -p .config/fish/config.fish && touch .config/fish/config.fish

# redoing the symlinks
stow . -t ~

Now, the first difficulty I ran into here was that, I actually didn't think fish would initialize the config file itself, so creating the file manually with my editor threw an error. So, I had to run stow with the --adopt flag in order to fetch the generated config:

stow . -t ~ --adopt

I have a handy LLM setup going on my primary editor, Zed, which I sometimes use to write shell scripts and automate the process of writing repeated data. So, I figured, why not just pull up a model to solve the configuration crisis?

I had two files to essentially migrate:

(Reference) The .bash_profile file for variable initializations and PATH mods, and
(Reference) The .bashrc file for program initializations

Essentially, the config.fish can do both at the same time, so I needed to merge them. I quickly told my model to present me a migrated example, and it sent me this:

# ~/.config/fish/config.fish

# ————————————————————————————————
# 1) Environment variables
# ————————————————————————————————

# TERM
set -x TERM xterm-256color

# Load Homebrew environment (PATH, PKG_CONFIG_PATH, etc.)
eval (brew shellenv)

# Add any local bin directory
set -x PATH $HOME/.local/bin $PATH

# ————————————————————————————————
# 2) Aliases & functions
# ————————————————————————————————

# Aliases in Fish are really just functions
function cat;    bat $argv; end
function ls;     eza --icons=never -l $argv; end
function lz;     lazygit $argv; end
function lzy;    lazygit $argv; end
# ... other aliases

# Convert your bundleid() helper:
function bundleid
    osascript -e "id of app \"$argv[1]\""
end

# ————————————————————————————————
# 3) Third‐party tools initialization
# ————————————————————————————————

# cutler (macOS preferences)
eval (cutler status --prompt)

# mise
eval (/opt/homebrew/bin/mise activate fish)

# fzf: load key bindings & completion
# Adjust path if yours is elsewhere
source /opt/homebrew/opt/fzf/shell/key-bindings.fish
source /opt/homebrew/opt/fzf/shell/completion.fish

# starship prompt
eval (starship init fish)

# zoxide
eval (zoxide init fish)

# any other per‐shell init can go here

Already, I could see a few conflicts from my own eyes:

fish isn't really a POSIX-compliant shell, meaning that syntactical differences are common. But here, I was seeing way too many "similarities".
fish mostly doesn't really need completion setup, and I had to have a look at what it was initializing for fzf and other programs.

Nonetheless, I copied the config the AI had generated and pasted it in config.fish, and oh boy there were errors.

The syntactical differences really came to play in this case. Statements like eval aren't really necessary when it comes to using fish. I can do something like:

starship init fish | source

... to replace the following:

eval (starship init fish)

So, I got to work, and eventually after completing the migration of both files, I got an end result which looks like this in my current dotfiles:

# ~/.config/fish/config.fish

# ————————————————————————————————
# 1) Environment variables
# ————————————————————————————————

# Disable greetings
set fish_greeting ""

# Editor
set -x EDITOR nvim
set -x VISUAL nvim

# Currently, Ghostty isn't that recognized of a terminal
# So, set to xterm-256color for support during ssh sessions
set -x TERM xterm-256color

# Disable Homebrew auto update
set -x HOMEBREW_NO_AUTO_UPDATE 1

# Load Homebrew environment (PATH, PKG_CONFIG_PATH, etc.)
/opt/homebrew/bin/brew shellenv | source

# Add any local bin directory
set -x PATH $HOME/.local/bin $PATH

# ————————————————————————————————
# 2) Aliases & functions
# ————————————————————————————————

function cat;    bat $argv; end
function ls;     eza --icons=never -l $argv; end
function lz;     lazygit $argv; end
function lzy;    lazygit $argv; end
function lazy;   lazygit $argv; end
function mactop; sudo mactop --color white $argv; end
function updateall
    brew update; and brew upgrade
    mise upgrade
    uv tool upgrade --all
end

function bundleid
    osascript -e "id of app \"$argv[1]\""
end

# ————————————————————————————————
# 3) Third‐party tools initialization
# ————————————————————————————————

# cutler
cutler status --prompt

# mise
mise activate fish | source

# starship prompt
starship init fish | source

# zoxide
zoxide init --cmd cd fish | source

This was after probably thirty minutes of debugging of the config file. I am pretty satisfied with how it turned, now moving on...

getting them keybinds running

In my original .bashrc file, I did this to enable h j k l and other Vim keybindings:

set -o vi

It was pretty easy to set up. But, given that fish's community is comparatively smaller than that of bash's, I had to Google around for quite a while until I found this:

# had to run this command
fish_vi_key_bindings

Running this command would essentially modify ~/.config/fish/fish_variables to include the Vim keybindings option. And now I could finally use it like I use bash!

the lovely things about fish

I've noticed a couple of major pros:

The Vim keybindings are more precise. In bash, I would struggle with doing edits to my commands in NORMAL mode. This doesn't happen on fish, and I can easily perform the required edits without messing up my texts.
The default prompt is customizable in an intuitive way, so my need for starship was essentially gone (though I am still using it).
Plugins. I'm yet to try these but I'm seeing positive reviews everywhere.

For the hipsters out there, fish can actually be an excellent choice for manipulating data within shell, and just using it for general shell commands can also be a delightful experience.

and, the cons for me

Okay so, remember how I mentioned my typing speed early on in this entry? Well..

Typing around 130-150wpm obsoletes the need for an autocompletion setup, assuming you have a muscle memory for typing commands, which I essentially do. I use shell commands everywhere, from self-hosting services on cloud to ssh-ing into other devices. And after years of typing commands, autocompletion is a feature which has essentially been "wiped out" of my memory. Why need an autocomplete if your brain does it for you?

And, typing in such speeds only makes the command appear as flickers on your screen. This alone renders my use case for fish virtually "useless", except when I really need to see some documentation for a command without typing man <command> or brew help <command>, though I prefer the latter more.

Also, since fish is not POSIX-compliant, I can't run shell scripts which derive from zsh or bash. It would also probably result in me losing my muscle memory in bash over time, which would result in a major con for me since I write a lot of CI/CD pipeline code for deploying my applications.

Finally, fish, for the most part, is slower than bash. This might come as a surprise, but bash uses C as its primary source language and can often deliver the fastest, no-bloat terminal experience. However, since we spend most of our time inside terminal applications and not shells, it should not be that big of a deal.

Depending on your personal scope of usage, fish can be a really great alternative to bash. I personally find bash "enough" for the things I do - run code, do light data manipulation and just generally enjoy the terminal side of things. It may be different for other people, but at the end of the day, it's your "personal preference" which makes you choose the perfect combination of workflows to go with.