DEV Community: Priyanshu Verma

Why I’m Shifting From TypeScript to Rust This Year

Priyanshu Verma — Thu, 12 Feb 2026 15:57:59 +0000

This year I made a decision that feels uncomfortable but necessary. I’m shifting my primary focus from TypeScript to Rust.

This is not a dramatic rage-quit. It’s not “TypeScript is bad.” It’s not hype chasing. I still respect TypeScript. I still use it. The browser understands JavaScript and nothing else, so obviously TypeScript will always be part of modern development. But relying on it as my core long-term skill no longer feels right.

This shift is about depth. It’s about leverage. It’s about choosing friction now to gain strength later.

For the last few years, TypeScript has been comfortable. Extremely productive. You can build full-stack apps quickly. The ecosystem is massive. Documentation is everywhere. You hit a problem, search it, and there are already ten answers. AI tools autocomplete entire features in seconds. It feels like flying.

But that comfort started bothering me.

When something becomes that smooth, that frictionless, you have to ask yourself what is actually defensible about your skill.

The reality is this: AI models are exceptionally good at JavaScript and TypeScript. The training data is enormous. Patterns are repetitive. The runtime is forgiving. Even senior-level TypeScript code can be generated in seconds. That doesn’t make TypeScript useless. It just means the barrier to output is extremely low, for both humans and machines.

And when a skill becomes low-friction for machines, its long-term defensibility changes.

This is the uncomfortable part people avoid talking about.

If you are only building in a language that AI understands better than you do, you are competing with a tool that doesn’t get tired and doesn’t need context switches. That’s not a great long-term strategy.

So I started thinking differently.

What if instead of optimizing for speed of building, I optimize for depth of understanding?

That’s where Rust entered seriously.

Rust is not just another backend framework. It’s not a “Node alternative.” It’s a systems language. That distinction matters. With Rust you can build web servers, sure. But you can also build operating systems. Game engines. Networking stacks. Embedded firmware. Database engines. Compilers. You can compile to Linux, Windows, macOS, ARM, and even bare-metal. You can run without an operating system at all.

That changes how you think.

You are no longer just writing API routes. You are dealing with memory layout, ownership, concurrency models, lifetimes, deterministic behavior. You are closer to the machine. That proximity forces you to understand what is actually happening.

TypeScript is about developer experience. Rust is about system integrity.

And I’m starting to prefer system integrity.

One of the biggest reasons is how Rust handles correctness. The Rust compiler is relentless. People joke about the borrow checker, but it’s not just a technical feature. It’s a philosophy. The compiler does not trust you. Even if you are confident your program will work, Rust will question every edge case.

And this reminds me of something very simple.

The Rust compiler is like your mom.

Imagine you say, “I want to go on a road trip.”

You are confident. You have planned everything. You know how to drive. You are excited.

And your mom says, “What if the car crashes?”

You respond, “That won’t happen.”

She says, “What if it does?”

You say, “That’s hypothetical.”

She says, “Still. What if?”

That is Rust.

Even when you are sure everything is fine, Rust forces you to think about the hypothetical crash. What if this reference outlives its owner? What if this task shuts down mid-execution? What if this error isn’t handled? What if this memory is accessed concurrently? What if the network drops? What if the process exits early?

It doesn’t accept optimism. It demands preparation.

And that’s exhausting at first.

Rust is not dopamine-friendly. It does not give you the instant satisfaction that scripting languages do. You don’t just write code and watch it magically run. You fight the compiler. You refactor. You restructure. You rethink ownership. You redesign your data flow. Sometimes you feel like you are losing to a machine.

But something changes after a while.

You realize the compiler is not fighting you. It’s training you.

It forces you to think in systems. It forces you to think about failure before failure happens. It forces you to design intentionally. That kind of discipline is uncomfortable but powerful.

TypeScript gives you fast iteration. Rust gives you strong guarantees.

TypeScript gives you flexibility at runtime. Rust gives you certainty at compile time.

TypeScript gives you speed of shipping. Rust gives you durability of shipping.

And I started asking myself what I want more of.

Another major factor is deployment philosophy. I’ve grown tired of runtime stacks layered on runtime stacks. Node behind reverse proxies inside containers inside cloud abstractions. Hundreds of megabytes deployed for something that fundamentally just responds to HTTP requests.

With Rust, you can compile a backend and embed a compiled frontend into a single binary. No Node runtime. No reverse proxy required. No external dependencies. Copy the binary to a Raspberry Pi and run it. It works. It doesn’t ask what version of something is installed. It doesn’t need npm install. It doesn’t need Docker if you don’t want it.

That simplicity is addictive.

It feels honest.

You build something. You compile it. You ship the artifact. That artifact is the product. There is something clean about that model. One more thing is that it is a binary even if someone gets it. they cannot see the code that we can say is a security feature.

Now, why not Go?

Go is good. I respect it. It compiles fast. It has strong concurrency primitives. It’s pragmatic. But for me, personally, it never felt expressive enough. The syntax feels procedural in a way that doesn’t match how I think. I come from an object-oriented background, and while Rust isn’t traditional OOP, its type system feels far more expressive and powerful.

More importantly, Go isn’t a systems language in the same sense. You cannot compile Go to true bare-metal targets the way you can with Rust. Rust’s reach is broader. That matters to me. I don’t want to just write web servers for the rest of my life. I want the option to go deeper.

This isn’t about language wars. It’s about surface area of capability.

Rust expands mine.

There’s also timing. Rust is modern but still relatively young in mainstream adoption. The market is growing. The ecosystem is maturing. But it’s not saturated. Becoming deeply competent in Rust today feels like investing early in something foundational.

And beyond market thinking, it feels intellectually honest. Rust makes you slower in the beginning. It removes shortcuts. It punishes careless assumptions. It makes you confront complexity directly instead of hiding it under runtime flexibility.

It is not beginner friendly. It is not easy. And that’s precisely why it’s valuable.

If someone wants instant feedback, fast feature velocity, and quick wins, Rust will feel like a nightmare. The compiler errors can be brutal. You might write code that logically makes sense, and Rust will reject it for lifetime reasons you didn’t even consider. It feels unfair at first.

But over time, you realize it’s making you sharper.

You start anticipating ownership issues before writing code. You design APIs differently. You think about shutdown signals. You think about memory footprint. You think about concurrency boundaries. You think about determinism.

You stop assuming things will work. You prove that they will.

That’s a different mindset.

I am not abandoning TypeScript. That would be unrealistic. The browser speaks JavaScript. Frontend ecosystems are deeply tied to it. Even if you use WebAssembly, JavaScript is still there. So TypeScript will remain part of my workflow.

But I don’t want it to be my only layer of competence.

Relying solely on TypeScript feels narrow. Rust feels expansive.

This shift is not about rejecting comfort for the sake of pain. It’s about choosing growth over convenience. I know this year will be slower in terms of output. I know I will spend more time reading compiler errors than shipping features. But I also know that the understanding I build will compound.

In a world where AI can generate boilerplate instantly, the real advantage is not how fast you can scaffold an app. It’s how deeply you understand the systems you are building on.

Rust pushes you toward that depth whether you like it or not.

And maybe that’s what I need right now.

Not speed. Not comfort. Not instant validation.

Depth.

That’s why I’m shifting.

Homelabing - Local to online setup suppressing CGNAT

Priyanshu Verma — Thu, 25 Dec 2025 12:44:45 +0000

In the journey of creating a Hub before we start programming or building website lets setup Pi in a way where we can access it on mobile internet.
For that we can use Cloudflare Tunnel or Tail Scale, but the problem is both are overpowered for this setup I don't want to use Cloudflare as an intercept between Me and my data. I can't trust any 3rd Party. So, not going to use that. I will not use Tail Scale because some features are awesome. But, it to use it I need to make accounts and every new person joins the network need to create an account on Tail Scale and I don't think. I will create an account on 3rd party to access my self-hosted server.
Now, This leads to setup my own VPN on Pi and connect to devices when I want to connect with Mobile network.

For That, I will be going to use WireGuard.
Why? Because it is open-source light and free.
Let's set it up.

Installing WireGuard on Pi.

sudo apt update
sudo apt install wireguard -y

And verify by printing it's version

wg --version

Now, for this to work, we need to create Pi's Private and Public Keys. To create, follow this.

sudo mkdir -p /etc/wireguard
sudo chmod 700 /etc/wireguard
sudo wg genkey | sudo tee /etc/wireguard/server_private.key | sudo wg pubkey | sudo tee /etc/wireguard/server_public.key

Now, you will find,

-rw------- 1 root root 45 server_private.key
-rw------- 1 root root 45 server_public.key

inside /etc/wireguard if not, then regenerate the keys.

For me, it worked. Now let's add some config.

sudo nano /etc/wireguard/wg0.conf

This config

[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = <PASTE server_private.key CONTENT>
SaveConfig = true

I am using 10.10.0.1/24 for subnet, as It is easy to remember for me and will not conflict with anything.
Now I will enable IP forwarding
by adding net.ipv4.ip_forward=1 inside /etc/sysctl.conf and apply the changes with.

sudo sysctl -p

It should output 1
Now, let's enable wireguard

sudo systemctl enable wg-quick@wg0
sudo systemctl start wg-quick@wg0

and verify with sudo wg

Now it is time to install WireGuard Official Android app on mobile and add it as a Peer.
Will create a new tunnel generate public and private keys then on Pi in /etc/wireguard/wg0.conf will add peer in bottom.

[Peer]
PublicKey = <PHONE_PUBLIC_KEY>
AllowedIPs = 10.10.0.2/32

and reload wg

sudo wg-quick down wg0
sudo wg-quick up wg0

finally on mobile WireGuard will add

Address = 10.10.0.2/32
DNS = 192.168.1.1 # your gateway IP

and add a Peer over there

PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = <YOUR_PUBLIC_IP>:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Now at this point I don't have a static Public IP as my ISP don't know me doing homelabing. If you are able to get static IP then use it otherwise there is one workaround.
I will use DuckDNS, this will help me to mimic my dynamic IP to look like static and on top of it. It is free, Lightweight and No vendor lock-in also it is not a proxy but a DNS record. To hook it go to https://www.duckdns.org
create an account and add a domain name it whatever you want, it is not a public address just a link to your public IP.
and use that subdomain as an endpoint.

We need to make a cron job to update the latest IP on DDNS. For that on Pi will create a Script to do that.

sudo apt install curl -y
mkdir -p ~/duckdns
nano ~/duckdns/update.sh

using this

#!/bin/bash
echo url="https://www.duckdns.org/update?domains={YOUR_SUBDOMAIN}&token={YOUR_TOKEN}&ip=" | curl -k -o ~/duckdns/duck.log -K -

Update YOUR_TOKEN from DDNS token and YOUR_SUBDOMAIN with your own subdomain.
Now give some permissions and test it.

chmod +x ~/duckdns/update.sh
./duckdns/update.sh
cat ~/duckdns/duck.log

It should give OK. NOT KO if it says KO then you are KO setup failed check your token and subdomain.
Now let's add a cron

crontab -e

and adding this to run every 5 minutes

*/5 * * * * ~/duckdns/update.sh >/dev/null 2>&1

Now, let's try to connect turn VPN on in mobile it should connect and by running

sudo wg

You will see a device connected saying
latest handshake: X seconds ago

If not then Hello my friend me too. Our ISP uses CGNAT (Carrier-Grade Network Address Translation) so they can control the router and as a user we cannot forward and port on IPv4.

Then, What to do??
You know what, after hours of research, I found that I cannot forward port by any mean, so the last option is to use Tail Scale, and so far one of the requirements broke. But, it is not my mistake, I cannot control my ISB behavior so. I have to use Tail Scale.

So, we don't need DuckDNS now let's remove the cron and wireguard.
If you followed along, then you will feel what wasting time looks like.

crontab -l
rm -rf ~/duckdns
sudo systemctl stop wg-quick@wg0
sudo systemctl disable wg-quick@wg0
sudo apt purge wireguard wireguard-tools -y
sudo apt autoremove -y
sudo rm -rf /etc/wireguard

Then remove that port forward line from sudo nano /etc/sysctl.conf
Now, create an account at https://login.tailscale.com
Then add the devices and install it on Pi,

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

and done online.
You can check it on tailscale dashboard.

Now, we can focus on building online Pi is on local and online.
Just run a server running and good to go.

Homelabing interesting enough to say but why

Priyanshu Verma — Thu, 25 Dec 2025 12:06:15 +0000

So far, I tried to not tie myself to big techs for some basic stuff. Like, from starting I switched products for password management, media, IOT management. But stuck with vendor lock and tied to subscriptions and limited control.
Finally, decided to make a home server.
For me, it is not like buying a big rag, Plenty of storage, RAM, and heavy suite like proxmox or other. I started very small from a Raspberry Zero 2W. Why, because ~~money~~ I am a professional developer, I know to build a system that works in limited resources. This is not a bug but a feature. I will try to build tech from scratch that I can run on it. For Media and other IOT stuff.
Also, This is only for my use, I am not building a robust system for millions of users using simultaneously, It is for me only or my family.

This homelabing series is going to be technical and not for production systems. I don't care if I fry my Pi, it is just a learning journey, I might upgrade hardware in the future. We can start with Pi only.

For more context let me tell you what is my ground for now.

Raspberry Pi Zero 2W Board (ORIGNAL)
- 1GHz quad-core 64-bit Arm Cortex-A53 CPU
- 512MB SDRAM
- 2.4GHz 802.11 b/g/n wireless LAN
- Bluetooth 4.2, Bluetooth Low Energy (BLE), onboard antenna
- Mini HDMI® port and micro USB On-The-Go (OTG) port
- microSD card slot
- HAT-compatible 40-pin header footprint (unpopulated)
- Micro USB power
SAMSUNG POWER Prime 256 GB Micro SDXC Class 10 Memory Card
- capacity: 256 GB
- Read Speed: 160 MB/s
Power Adapter normal 2A for Powering Pi

That's the ground I have installed Ubuntu 64bit lite on memory card and setup Pi with a static IP from home router using it's Mac Address.
So far, nothing is installed, and I can ssh into Pi from my PC that is the bare minimum. Also, One more thing is There are two partitions I have divided unusable ~235GB of storage in ~200GB + rest. So I can deploy stuff on rest part which is ~35GB and can keep the media and all other stuff in that ~200GB part. Safe and simple.
Also, I have installed Samba and did setup so I can mount big 200GB part to my Windows PC and store files. It is easy no big deal.

This is the final ground from where I will be making it The way I want, which includes:

Simple IOT controlling Dashboard for remotely switching lights at home and other fun stuff.
host simple images and videos downloaded and store, no processing or indexing simple static serving.
Simple authentication so, I can restrict certain things and add my family members to access media.
Do it in a way so I can add more stuff in future like internal messaging or calling. These are basic enough right, remember we will be doing it under usable 416M ram.

I do have some rules that I will follow. I don't want to mess things by using software that I feel is not giving me control and heavy on the system.

NO cloud platform for processing or intercepting traffic like Cloudflare tunnel
No REACT, for building frontend.
Keep it accessible on remote location, (aka open to use even I am not connected to home network).
less latency
Easy to use for non-techy people.
SECURED!

Sounds crazy, but it is doable.
Let's see how it goes…

You Want a Future in Tech? Stop Building Templates.

Priyanshu Verma — Tue, 25 Nov 2025 16:33:30 +0000

Hi
So, Now everything around us has some sort of AI badge. Even on my Washing Machine. Seriously, Now it recommends me to select the mode based on my route.
Let me give you a brief introduction about me. I am a developer who works major in Web. And with AI now, I am able to make beautiful UIs in seconds and write code build my side projects in Hours. I just need a prompt and some <TAB> <TAB>.
Done.

Why I wrote this article

If we see it from managing or productive side then it is awesome. You are now able to do Hours of work in minutes. If you are in cooperate or have a job then It fits in very awesome way.
But, if it is easy then anyone can do it.
I observed that WEB DEVELOPMENT is not a hard thing anymore any one that know what to build can make websites.
Well. Now you say building UI with AI is nothing main thing is managing it, sustaining it. I know that. I am not saying any non tech can build or sustain it. I am talking about the competition. Already the competition in Web Development is very high very other person is build an AI SaaS for nothing.
And I think, Now companies and Startups don't need a lot of people for Web Development and which means less Jobs and less opportunities as most of the work is simple.

As a student or person who want to get in tech or want to learn something to earn money in long term. The path of learning about Web Development not looks safe anymore.

What is the future of Web development

If we see the growth of AI and the tools that are available right now like we have IDEs AI integrated and some generic packages or libraries which works very fine with AI like if We need the world of web and intelligence if AI we can conclude at using tech likeshadcn/ui and Better Auth for authentication also for backend serverless functions, ORMs like Prisma helps to build any product very easily Everything is open and works fine with AI. Famous AI models knows about these technologies and they work very effectively on these.

And in future it will get more better because almost 90% of the code of any website is open and there is a lot of data on which AI models can be trained. Every open-source frameworks, public tutorials, GitHub repos, countless blog posts, StackOverflow questions, boilerplates, templates, and design systems are public by default. And the feedback loop of the web makes things even easier for AI. If you write HTML or React, you instantly see the result. If something breaks, the browser reports the exact line.

AI eating this domain of tech very rapidly.

What do learn then

Before answering this question I want to ask why you get in tech. The problem with today's generation is that they think I will get in tech build websites and earn money. You and I we both know that the most easiest job in tech is to build websites and people choose it because it is simple.
The harsh truth is people became lazy and they want instant feedbacks that's why nowadays we don't see any projects like Linux, Git or some revolutionary tech because they are depended on AI. and AI knows Web better so defaults to it.

So, What to do uh? what should i learn. The answer is very simple do what AI cannot do. Programming is not dead. The humours are faking it. AI is not able to build a native app for windows, android, It is not able to build custom software for specific hardware, it cannot do cyber security. Literary it fails to code in system languages like C, C++, or Rust, Even in kotlin. You know why because the information build about these is less and building a solution for hardware or building an native app or doing cyber security stuff needs on demand actions that AI cannot replicate. Fields like DevOps AI cannot replace as it needs to work on demand according to external stimuli.

What is the point of building native

So, my friend why you should build a mobile app with native tech you can use JavaScript to build it.
Technically it works. It shows a screen, buttons click, cool. But then I’m like… bro look at our devices. We literally have super powerful chips now, like phones with GPUs that are better than old consoles, laptops with crazy CPUs, RAM is cheap, SSD is fast… and still I open 20 chrome tabs and the whole thing starts dying. I run a game on my RTX and it can’t even stay on 60 FPS. Why? Why are games 150GB now? Why is a simple chat app using 700MB RAM?

And the sad part is we all kinda became lazy. We just accept it. No one wants to build their own game engine because “eh too much work.” No one wants to create their own UI library because “just npm install something.” Everything is off-the-shelf now. Zero originality. Every website looks copy-paste same. Every game feels same. Every app has that same template vibe. We’re not optimizing, we’re just piling more stuff on top.

Can AI really Replace you

See, It depends on your skills.
Honestly… depends on what you’re doing. Like, seriously. If your whole skillset is just copying templates, building basic CRUD, making landing pages, doing the same loops everyone is doing, then yeah AI is on your heels. Because AI is literally trained on that stuff. It has seen millions of those patterns.

But the funny thing is the stuff I talked about above the messy parts, AI can’t touch that. It just can’t. It doesn’t know how to handle real hardware problems, memory issues, native bugs, performance tuning, cybersecurity attacks, networking glitches, weird OS behavior. That stuff is too real. Too unpredictable. Too out of the training data bubble. Only humans can deal with it.

And this whole “recession because of AI” panic? Bro, half of it is just people sitting in their comfort zone. They open VS Code, type two prompts into an AI agent, feel like a CEO for a minute, and then scroll reels for half an hour. Then they wonder why they’re not growing and blame AI like it’s hunting them personally. It’s not AI. It’s the fact that we all got a bit too comfortable building comfort zone software.

AI is not replacing the people who actually touch the real stuff the complex systems, the deep logic, the broken pipelines, the debugging nightmares, the places where you can’t just hallucinate a solution. AI is replacing the lazy, repetitive parts, the factory style coding that didn’t need a human in the first place.

Conclusion

At the end of the day it’s actually not that deep.
You wanna stay irreplaceable?
Just stop doing the bare minimum and calling it a “skill.”
Get out of the comfort zone stuff.
Start touching the parts of tech where AI straight up falls on its face.
Systems, hardware, native, security, actual optimisation is the real engineering side of things.

That’s literally the whole game.

Self-Hosting a Password Manager on a Pi Zero 2W

Priyanshu Verma — Sun, 28 Sep 2025 06:37:37 +0000

As a developer and tinkerer, I love taking control of my digital environment. This weekend, I decided to host my own password manager. My goal was simple: keep all my sensitive data private, accessible from multiple devices, while learning more about self-hosting, TLS, reverse proxies, and Docker on a low-power device. Here’s how the journey unfolded, along with problems I faced and solutions I discovered.

Choosing the Right Tool

I started by exploring the options. Cloud-based managers like 1Password or Bitwarden are convenient, but I wanted full control. Among self-hosted options, Vaultwarden stood out. It’s a lightweight, unofficial Bitwarden implementation, supports TOTP, and can run on low-resource devices like a Pi Zero 2W.

For a solo developer like me, Vaultwarden was ideal: small footprint, actively maintained, and feature-rich.

Step 1: Preparing the Pi

I installed Ubuntu on the Pi Zero 2W and set up SSH access to manage it remotely. Since I planned to use Docker, I made sure the system was updated and installed docker and docker-compose.

After verifying Docker installation with docker --version, I was ready to pull Vaultwarden.

Step 2: Running Vaultwarden in Docker

My first attempt to run Vaultwarden showed an important warning:

No persistent volume!

This meant that if the container stopped or was updated, all data would be lost. Lesson one: always map persistent volumes. I created a vw-data directory and updated docker-compose.yml:

vaultwarden:
  image: vaultwarden/server:latest
  container_name: vaultwarden
  restart: unless-stopped
  environment:
    ADMIN_TOKEN: "changeme"
    ROCKET_WORKERS: 1
    ROCKET_PROXY_PATH: "/pass"
  volumes:
    - ./vw-data:/data
  expose:
    - "80"

The ROCKET_PROXY_PATH="/pass" was critical.

Step 3: Subpath vs Subdomain

At this stage, I faced a design choice:

Option 1: Subdomain (vault.mydomain.com)
Option 2: Subpath (mydomain.com/pass)

Initially, subdomains seemed neat and clean. But there are trade-offs for self-hosted services:

Certificate complexity: With a subdomain, I would need a separate certificate for vault.mydomain.com. With a local or internal CA, managing multiple subdomains could get messy.
Future services: I wanted to host other tools (like a personal wiki or file server). Using a subdomain for every service could clutter DNS and complicate VPN/local routing.
Tailscale & mobile access: VPN solutions sometimes resolve only the main hostname. Subdomains occasionally fail or require additional DNS tweaks.

A subpath approach (/pass) solved these issues:

One certificate covers the main domain.
Reverse proxy handles routing internally to different services.
Makes scaling to multiple services simpler without touching DNS or VPN settings.

Hence, I chose /pass for Vaultwarden and left / free for other services. This required careful reverse proxy configuration, which I’ll describe next.

Step 4: Reverse Proxy with Caddy

I used Caddy as a reverse proxy to handle HTTPS and route /pass to Vaultwarden. My first attempt was basic:

panda.local {
    tls internal
    encode zstd gzip
    reverse_proxy vaultwarden:80
}

Problems immediately appeared: assets broke, WebSockets failed, and trailing slashes caused the interface to misbehave. Vaultwarden expects requests at the root, so a simple proxy was insufficient.

After research and testing, I implemented:

handle_path /pass/* {
    reverse_proxy vaultwarden:80 {
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-Proto {scheme}
        header_up X-Forwarded-Host {host}
        header_up X-Forwarded-For {remote_host}
    }
}

handle_path /pass/* strips the /pass prefix before forwarding requests to Vaultwarden. This solved:

Asset loading issues
WebSocket failures
Trailing slash inconsistencies

Step 5: TLS and Certificates

Since I wanted both desktop and mobile apps to trust my self-signed setup, I used mkcert to generate a local CA and certificates:

mkcert panda.local
mkcert pass.local

Copying the root CA to my desktop required careful path handling due to spaces in usernames, and mobile installation required converting .pem to .crt and manually trusting the certificate. Once done, browsers and apps stopped showing SSL warnings.

Lesson learned: TLS is critical, but self-hosting means you need to manage trust explicitly on each device.

Step 6: Remote Access with VPN

I didn’t want to open my home network to the internet. Using a VPN-like solution, I could access Vaultwarden remotely without exposing ports. Initially, there were DNS resolution issues with subdomains, but after adding entries to local hosts and configuring certificates correctly, remote access worked smoothly.

This setup also allowed me to think ahead: by using /pass, I left the root path free for future services, creating a small personal service ecosystem.

Step 7: Troubleshooting Common Issues

Here’s a list of the main problems I faced and how I solved them:

No persistent volume: Fixed by mapping ./vw-data:/data in Docker Compose.
Subpath asset/WebSocket issues: Resolved with handle_path /pass/* in Caddy.
SSL warnings: Generated local CA with mkcert, imported into desktop and mobile devices.
Trailing slash problems: Also handled by handle_path.
Remote access quirks: Fixed via local DNS entries and correct certificate paths.
Subdomain vs subpath confusion: Choosing subpath simplified certificates and routing for multiple services.

Step 8: Final Setup

By the end of the day, I had:

Vaultwarden running under /pass on the Pi Zero 2W
Full HTTPS support trusted on desktop and mobile
Remote access without exposing home network ports
Persistent storage for all passwords

Testing everything — creating accounts, logging in from mobile apps, syncing TOTP codes — everything worked flawlessly.

Reflections and Lessons Learned

Self-hosting is rewarding, but it comes with challenges:

Docker volumes prevent accidental data loss.
Reverse proxies can make or break subpath hosting.
TLS and certificates are critical; trust must be manually managed for internal or mobile clients.
Subpath routing simplifies multi-service hosting, while subdomains require additional DNS and cert management.

Small fixes like handle_path or importing a CA may seem trivial, but they make the difference between a broken interface and a smooth user experience.

Conclusion

Self-hosting Vaultwarden on a Pi Zero 2W might seem overkill for a single user, but for me, it was about control, privacy, and learning. The Pi handled everything surprisingly well, and Vaultwarden proved to be a solid, lightweight solution.

For developers looking to take control of their digital lives: start small, expect roadblocks, and treat each error as a learning opportunity. In the end, there’s immense satisfaction in seeing your own system, from certificates to WebSockets, working exactly the way you designed it.

Ever wondered why Windows or Android updates are so huge? This isn’t just about code – it’s about an entire hidden world of engineering farms, power consumption, and logistics. My new article opens that black box.

Priyanshu Verma — Sun, 17 Aug 2025 10:47:14 +0000

The Hidden Engineering Behind Building Massive Software Images

Priyanshu Verma ・ Aug 17 '25

#programming #cloud #architecture #learning

The Hidden Engineering Behind Building Massive Software Images

Priyanshu Verma — Sun, 17 Aug 2025 10:46:09 +0000

Hi,
You guys know me I try doing something new always so, recently When I first stared at the AOSP tree and saw the download size, I thought someone was pranking me. Hundreds of gigabytes? Thousands of repos? How could anyone reasonably build that on a laptop, even if it had more cores than a nuclear reactor? The truth pulled me down a rabbit hole I didn’t expect — one that rewrites what “writing software” even means.

Let me take you on a short film of how a piece of code becomes a massive, signed, tested, shippable image — whether that image is your phone’s system update, a Windows release, or a billion-dollar AAA game. This isn’t just about compilers and make; it’s about orchestration, scale, people and machines working together in a choreography most users never see.

I want you to imagine two scenes.

Scene one: a lone engineer, late at night, running make on a workstation. The machine hums. The screen scrolls error messages and warnings. The coffee goes cold. This image is still real in small projects, but it is increasingly a nostalgic relic.

Scene two: a humming build farm, rack after rack of machines, jobs queued and parallelized across continents, caches consulted in milliseconds, thousands of tests flaring green or red. Keys and signatures are applied in a secure enclave. An image rolls down the pipeline and — eventually — reaches a device on a user’s desk via an OTA update. That is the new reality.

Why the chasm between these two scenes? Why can’t we just “compile the code” and be done?

It starts with scale. Modern operating systems and flagship apps aren’t a few thousand files stitched together. They’re an orchestra of components: kernels, drivers, vendor binaries, runtime engines, media libraries, UIs, services, apps, localization packs, and every test harness you can imagine. Where a small embedded project might be measured in thousands of lines, Windows and Android live in the tens-of-millions-of-lines regime. Chrome, Android, and game engines bring along enormous native code, Java or managed runtimes, and gigantic asset pipelines. Each of these pieces has its own build steps, expectations, and quirks.

But scale alone doesn’t explain the orchestration required. Building a modern image is not just compiling source; it’s a multi-stage process that touches toolchains, packaging systems, signing infrastructure, artifact storage, and certification systems. You don’t merely turn C into binaries; you:

run code generators and preprocessors,
produce architecture-specific binaries (x86_64, arm64, etc.),
link enormous binaries (link time optimization and profile-guided optimization can be highly sequential and heavy),
bundle resources (localization, images, precompiled shaders),
compress and sign artifacts with secure keys,
and then subject them to thousands of automated tests on real hardware.

All of that introduces latency and makes naive parallelism insufficient. Even on a machine with 64 cores, disk IO, linking, and serialized packaging steps become chokepoints. The first full build, the “clean build,” necessarily touches everything: read tens of thousands of files, compile, link, pack. That’s expensive in time and in energy.

Which brings me to a second, often-overlooked consequence: the environmental cost. When you multiply full builds by dozens of devs, nightly images, pull-request validations, and continuous fuzzing runs, the energy footprint becomes non-trivial. Companies running nightly images and large CI matrices are effectively operating mini data centers. This reality has pushed teams to optimize for two things: reduce redundant work and reduce waste. Caching (ccache, remote action caches), incremental builds, and smarter CI orchestration are not just developer conveniences — they’re carbon optimizations.

So, how do teams cope? How does any sane engineering organization ship anything at all?

They split the problem. Software at scale is modularized and specialized. Teams no longer touch the whole tree. An engineer working on the window manager builds the window manager. A kernel engineer builds the kernel. These are unit-of-work boundaries. The full single-piece build is delegated to a build farm — a distributed system of machines that can run the complete set of compilation tasks in parallel, honor dependency graphs, and cache results aggressively.

Distributed build systems are at the heart of this approach. Google’s Goma (migrated to Reclient in 2025) and remote execution, Bazel’s remote execution, Microsoft’s BuildXL, and similar technologies allow compilation tasks to be farmed out, cached, and reused. Instead of each developer redoing the same heavy work, cached object files are reused across jobs and builds. The result: individual iteration latency drops from hours to minutes, and the full heavy build happens in a controlled, centralized way.

But distributed builds are only part of the story. There’s also a surprising orchestration layer: artifact variants and packaging. One codebase can produce dozens — even hundreds — of artifacts. AOSP, for instance, doesn’t generate a single image; it generates system images for multiple device families, variants with different Google services or OEM customizations, boot images, vendor images, and more. Windows similarly produces many SKUs, localized images, and platform-specific packages. Games produce builds for multiple consoles, PC configurations, and packaged installers. Each variant multiplies the amount of work and the number of tests.

Testing is another dimension that explodes resource needs. It is rarely acceptable anymore to ship untested large changes. Integration suites, fuzzers, UI tests, driver compatibility tests — these run on thousands of device instances, sometimes physically — and failures require reproducing on identical hardware. So the engineering pipeline must not only build; it must distribute, schedule, and record results from a massively parallel test farm.

This reality created an entire discipline: build engineering and release engineering. These teams are the invisible logisticians of software. Their job is not product feature work; it’s to ensure developers can iterate quickly, builds are reproducible, artifacts are traceable and secure, and releases roll out smoothly. Reproducibility is a central obsession: you should be able to rebuild an artifact deterministically so you can trust what went out to users and trace bugs back to a specific build. That means pinning toolchains, hermetic builds, recorded inputs, and deterministic packaging — a lot of boring-but-important work.

To me, one of the most compelling stories is the contrast between eras. In the ’80s and ’90s, building an OS was something you could conceive on a single workstation. Engineers would go home and let overnight builds run. Today, building Windows or a AAA title is akin to running a rendering farm for a movie: assets measured in terabytes, precompiled shaders, baked global illumination, and platform certification pipelines. Modern AAA titles have asset pipelines that are as much a part of the build — with their own distributed render farms — as the code compilation itself. The product is rarely “code”; it’s code times assets times compatibility matrices.

Windows is a vivid example. Its codebase has accreted decades of code, multiple languages, legacy interfaces, and vast driver ecosystems. Microsoft’s approach is to carve the monolith into components. Engineers iterate locally on targeted subsystems and push changes. A centralized farm, armed with sophisticated orchestrators, then runs full builds and regression suites. For Windows, the human problem isn’t “write the code”; it’s “ensure that code plays nicely with tens of thousands of hardware permutations and years of backward compatibility.” Microsoft’s build infrastructure is built to manage that complexity — not to make building trivial, but to make shipping possible and predictable.

And if you’re wondering whether AI will change this equation — write code and let machines assemble everything — the answer is: AI will help, but it won’t replace the choreography. Writing code is only a shard of the whole. The pipeline, the reproducibility, the signing, the compatibility testing, the device certification, the incremental build caches, the keys and signing policies, the human coordination, the rollback strategies — these are socio-technical problems. AI can suggest changes, even generate modules, but someone still has to decide which artifacts to build, how they get tested, what gets signed, and how to remediate a failing rollout. In short, AI can be an assistant, not the orchestra conductor — at least not in the near term.

If you want to dig deeper, here are a few research and reading touchpoints I keep returning to while exploring this world:

Read the Bazel documentation and the philosophy of hermetic builds.
Explore Google’s papers and blog posts on Goma / remote execution (they explain why distributed compilation matters).
Look up BuildXL (Microsoft) and the evolution of Git Virtual File System (GVFS) for handling huge repositories.
Search for the “Reproducible Builds” project — it captures why deterministic builds are so central to security and trust.
Check out material on remote caching and action caches (how CI avoids doing repeated work).

I find the story irresistible because it reframes what building software means: it’s less about the solitary craft of typing functions and more about designing resilient industrial processes. The magic of a software update isn’t the few lines someone typed last week — it’s the invisible machinery that compiled, tested, signed, and safely delivered that update to millions without breaking everything else.

If you’re curious, here’s one practical way to feel this under your fingers: don’t attempt a whole AOSP build yet. Instead, pick a subsystem (a kernel module, a small Android service, a game asset pipeline task), build only that module locally, replace it into a prebuilt image, and iterate. You’ll experience first-hand the dramatic speedups that modular work affords, and you’ll see why entire teams focus on making those iterations as fast and reliable as possible.

When people ask me what the future of software engineering looks like, I don’t see a world where developers are obsolete. I see a world where “developer” means more — you’ll need to understand not only code, but caches, CI graphs, reproducibility guarantees, artifact signing, and the economics of compute. The boring parts — the build farms, the signing policies, the orchestration — are where trust is forged. And that, I think, is a story worth telling.

Thanks for reading to the end. I know you have time to waste then also checkout my Github

— Priyanshu Verma

Why MindsDB is the Fastest Way to Build AI Agents Today

Priyanshu Verma — Fri, 27 Jun 2025 10:11:25 +0000

Hi,
In an era where building AI-powered applications often feels like assembling a spaceship from scratch, I discovered a different path — MindsDB. As a developer working on KbNet, I needed a way to automatically generate summaries of knowledge base articles using AI. Instead of setting up complex machine learning pipelines, I used MindsDB and built a working AI flow in hours — not days.

In this article, I’ll walk you through why MindsDB makes AI development so seamless, how it compares to traditional approaches, and how I used it to power a real-world feature in my app — a smart summary generator based on knowledge graph traversal.

The Problem Statement

I have structured data in a database that represents a knowledge graph. Each node represents a concept or article, and maps are AI flows — sequences of nodes leading to the current point in the journey.

Now, I wanted to build an AI Agent that, when given a simple prompt and a map reference ID, could:

Retrieve all nodes associated with that map.
Understand the sequence or path taken to reach the current node.
Generate a rich, context-aware summary — in natural language — that sounds more like a personal journal than a SQL dump.

Sounds fun, right? Except…

The Traditional Route — A Long Road

If I had taken the usual route, here's what I'd be doing:

1. Backend Setup

Start with writing code in Python, Node, or Java. Fetch nodes using raw SQL or an ORM. Serialize the data, clean it, make it usable. Basically, your app becomes a data plumber.

2. LLM Integration

Pick an AI provider (OpenAI, Hugging Face, etc). Write wrapper code to format prompts, manage tokens, and handle the response. Also, hello API key management and rate limits.

3. Agent Logic

You now write logic to:

Order the nodes by step_index or timestamp
Stitch the context manually
Format a prompt that gives the LLM just enough — but not too much — info
Clean and parse the LLM’s response
Retry if it fails, maybe fallback if the summary is junk

4. API Layer

Wrap all this in a nice endpoint. Add retries, validation, timeouts, and logs for the logs that watch other logs.

🕒 Total Time: Days (even weeks, depending on coffee supply)

⚙️ Complexity: High

🧩 Modularity: Low. Everything’s tightly glued

🚧 Maintenance: Fragile. Tweak one piece, test everything again

I’ve done it this way before. It works, but it's definitely not something you build in a weekend — unless you skip sleep and friends.

Enter MindsDB — Same Problem, Way Simpler

Now here’s where MindsDB shines. Instead of juggling a dozen moving parts, I was able to handle everything with a single SQL job and an AI agent declaration.

The Agent in One Command

Here’s the entire setup to create the AI Agent:


CREATE AGENT IF NOT EXISTS summary_agent
USING
  model = 'gemini-2.0-flash',
  google_api_key = 'your_key_here',
  include_knowledge_bases = ['kbnet_kb'],
  include_tables = [
    'db.maps',
    'db.nodes',
    'db.navigation_steps',
    'db.node_relationships'
  ],
  prompt_template = '...long descriptive prompt...';

Done.

This agent now understands:

The map structure
The nodes the user has explored
The steps they’ve taken
And it generates a journal-style narrative of their journey

It’s declarative. You don’t write logic — you explain the data and intent, and MindsDB takes over.

The System Prompt (What the Agent “Knows”)


"You are writing a reflective, journal-style narrative of a user's learning journey through a dynamic map of interconnected topics.

You have access to the sequence of topics, summaries, and actions taken (e.g., deeper, related, similar, backtracking).
(db.maps) all the user maps has [map_id]
(db.nodes) all the nodes has [summary]
(db.navigation_steps) steps taken by user has source and target [node_id]
(db.node_relationships) relationships between nodes

Reconstruct the journey as a first-person story. Make it immersive, curious, and human. Use topic connections and user direction to build a narrative arc."

That’s all. The rest — connecting the dots, generating the response — is handled internally by MindsDB.

The Job That Ties It Together

I created a scheduled job in SQL that:

Picks a pending summary request.
Sends it to the agent.
Stores the final summary and updates the status.


CREATE JOB IF NOT EXISTS summary_job AS (
  UPDATE map_summaries SET status = 'IN_PROGRESS'
  FROM (SELECT * FROM pending_summary_view LIMIT 1) AS d
  WHERE id = d.id;

  UPDATE map_summaries SET status = 'COMPLETED', summary = d.answer, completed_at = NOW()
  FROM (
      SELECT p.id, r.answer
      FROM summary_agent AS r
      JOIN (
          SELECT id, question FROM pending_summary_view WHERE status = 'IN_PROGRESS'
      ) AS p
      ON r.question = p.question
  ) AS d
  WHERE id = d.id;
)
EVERY 5 MINUTES
IF (SELECT COUNT(*) > 0 FROM pending_summary_view WHERE status IN ('PENDING', 'IN_PROGRESS'));

Now, every 5 minutes, MindsDB checks if there's work to do. If yes, it runs the agent, updates the database, and done.

🧪 Using the Agent is Just a Query

No API calls. No webhook hell. Just SQL.


SELECT answer FROM summary_agent WHERE question = 'Summarize the journey of map-id: xyz';

That’s the whole interface. Even the question field acts as the input channel.

💡 Why This Blew My Mind

🔥 Agent logic is declarative — no backend to maintain
🧩 It scales naturally — just add jobs or agents
🤹 Switching providers is trivial — change model = 'model-name' and <provider>_api_key.
⚙️ It runs inside the data layer — no glue code or extra microservices

I didn’t write a backend service, and I didn’t have to babysit an LLM. I wrote SQL. That’s it.

🧵 Final Thoughts

If you're someone who’s been through the mess of building LLM agents manually — gluing APIs, syncing data, writing retry logic — you’ll appreciate the simplicity of MindsDB.

It feels like what SQL should’ve always been:

Declarative data + Declarative AI = Just works.

With KbNet, this gave me a fast path to production without needing to build infra from scratch. MindsDB let me focus on what mattered — the experience — instead of the plumbing.

If you're working on something that could use an AI brain without a DevOps nightmare, give MindsDB a try. I’m not being paid to say this — I just had a good time not writing boilerplate code for once.

And honestly, that’s rare. Usually, the only thing AI helps me generate is more bugs.

Priyanshu Verma

GitHub
LinkedIn

MindsDB Made It Easy, I Made It Hard: Building an AI-Powered Knowledge Map

Priyanshu Verma — Mon, 23 Jun 2025 16:49:13 +0000

Hi,

It’s been a while since I posted anything tech-related. So, my friends, here we have it.

This article is all about how and why I used MindsDB for my next project: KbNet.

First Things First: What Even Is MindsDB?

Before I go deep into the technical rabbit hole, let me quickly tell you what MindsDB is.

MindsDB is this cool open-source project that makes building AI-driven applications super smooth. It basically reduces the headache of connecting a bunch of data sources and managing AI integrations in your app.

So instead of writing custom adapters and creating extra packages for every new data source, MindsDB just says:

"Relax, bro, I got you."

Some features that I personally loved:

Connect multiple data sources and pipe them into a unified output.
Create pre-built AI models with prompt templates (supports OpenAI, Google Gemini, and more).
Run background jobs and triggers on specific events.
Create a knowledge base with a single SQL command that handles embedding and storing automatically.
And yeah… a lot more.

But you know what? The best part?

MindsDB is SQL-based.

Everything. I repeat — everything can be done via SQL queries.

No SDK madness, no complex APIs.

(Yes, I’ll tell you why that made my life so much easier.)

But Wait, What’s KbNet?

Before jumping into the MindsDB part, let me give you some context.

So, what is KbNet?

In short:

It’s a web app (kinda game-like) that lets users explore different aspects of any topic and do some good old serendipitous discovery.

The idea?

We create a Knowledge Base and generate a map of nodes in a tree format for any topic.

The cool part? You can swipe through these nodes (yeah, swipe gestures FTW), go back in time, rethink your path, and even build a new branch from a completely different perspective.

I honestly wish life worked this way. If I could go back in time and create a new branch, I probably wouldn’t have chosen programming. 🤣

Why I Chose MindsDB (and Decided to Suffer Anyway)

Now, I had two choices:

Either build this system from scratch (why though?)

OR

Use something that can handle the AI and Knowledge Base part for me.

Thankfully, MindsDB came to the rescue and made the first half super smooth.

So smooth that I thought — "I can totally build this entire app in one week."

(Oh, how innocent I was.)

Then, in a moment of pure genius (read: self-inflicted torture), I decided to not use a graph database.

Instead, I went for a relational database (PostgreSQL!) with WebSockets.

Why? No idea. I probably wanted to challenge myself for no reason. (I hate past me.)

This Article: MindsDB Part Only

(I’ll talk about the database side if I ever open that schema again.)

How I Used MindsDB in KbNet

Key Use Cases:

Create a Knowledge Base
AI agents to generate explored summaries
Background jobs to ingest new data
Connect to many different data sources on the fly

The funniest part?

Once I wrote the initial seed file, I literally just needed to write simple SQL queries to set up everything — the Knowledge Base, AI agents, jobs, data connections… all of it.

And get this:

I didn’t even need to create a project folder. I just spun up the MindsDB Docker container and started testing queries directly.

No project setup, no dependency hell. Just a container and I’m good to go.

Once I had tested everything, I just wrapped my SQL queries into a file and made a simple POST request to the MindsDB API sitting inside the container.

Boom. Project initialized. No fuss.

Here’s the magic function I used:

export async function runMindsDBQuery(query: string) {
  try {
    const res = await fetch(`${mindsDBUrl}/api/sql/query`, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ query }),
    });

    if (!res.ok) throw new Error(`HTTP error! status: ${res.status}`);

    const rawData: any = await res.json();

    if (rawData.type == "error")
      throw new Error(`MindsDB error: ${rawData.error_message}`);

    const transformedData = rawData.data.map((row: any[]) => {
      const obj: Record<string, string | number> = {};
      rawData.column_names.forEach((col: string, idx: number) => {
        obj[col] = row[idx]; 
       });
      return obj;
    });
    return transformedData;

  } catch (error) {
    console.log("Error during fetch:", error);
  }
}

Yep.

This one function could:

Fetch from the Knowledge Base
Trigger AI agents
Run background jobs
Ingest new data

All of it.

MindsDB SQL Syntax is Super Simple

The basic structure to create anything in MindsDB:

`sql

[OPERATION] [RESOURCE] [name]
{PARAMETERS}

Examples:

`sql

CREATE KNOWLEDGE_BASE kbnet (...parameters...);
DROP JOB my_job;

To fetch data:

`sql

SELECT * FROM [RESOURCE];

The coolest thing?

Whether your resource is:

Twitter
GitHub
YouTube
Wed
AI Models
Databases

You get the data in a unified SQL table format.

No special transformers, no extra mapping.

Just SELECT and chill.

My Honest Thoughts

MindsDB solved half of my problems without me needing to overthink.

AI, Knowledge Base, Data Ingestion — all went buttery smooth.

And then, of course, I decided (for absolutely no good reason) to use PostgreSQL instead of a graph database to store the nodes.

"Oh, how bad could it be?" — Me, before designing the database schema

"I have made a terrible mistake." — Me, after designing the database schema

Let’s just say… I’ll tell you about the second part of this adventure if I ever dare to reopen that schema.

Life Lessons

SQL-first AI integration is a game-changer.
MindsDB is like your overachieving friend who actually makes your life easier.
Never trust your pen and paper system designs.

You will regret them.

Quick Links

Project Repo: GitHub – kbnet

See you next time with another mistake I’ll regret.

— Priyanshu Verma

When Life Gives You Time Off Install and Configure Neovim

Priyanshu Verma — Wed, 04 Jun 2025 09:54:47 +0000

Hello. So here’s what happened. I recently found out — almost accidentally — that I had summer vacations. Not the planned kind with beaches and iced tea, but the kind that sneaks up on you and leaves you staring at the wall asking, “Now what?”

Naturally, I had two options: waste time or waste time in a way that looks productive. I chose the latter. That’s how I stumbled into setting up Neovim.

If you don’t know what Neovim is… well, don’t worry, you’re probably happier that way. But if you’re curious (or just here for the chaos), let me walk you through how I went from zero to semi-obsessed with a glorified terminal text editor.

Why Neovim? (And What Even Is It?)

So here’s the thing — I recently started learning Go (aka Golang, aka "Google’s gift to minimalists"), and while going through a couple of tutorials, I noticed something... odd. A bunch of the devs in those videos weren’t using the usual suspects like VSCode or JetBrains. Nope. They were in vim. Like, full-on terminal-only, blinking-cursor, keyboard-ninja mode.

That alone didn’t convince me. But it did tickle my curiosity.

What’s so special about this ancient-looking editor that people still use it in 2025?

After a bit of Googling and Reddit lurking, I stumbled upon Neovim — the younger, cooler cousin of Vim. Neovim promised modern features, better plugin support, async everything, and a rabbit hole so deep that it practically dares you to fall in. So obviously, I took the bait.

I didn’t really need a new text editor. But I needed something to justify avoiding real responsibilities during summer. Neovim seemed perfect.

First Encounter: A Blank Screen and an Existential Crisis

Installing Neovim — or so I thought — was supposed to be the easy part.

A simple sudo apt install neovim, right?

Well, not for me.

I'm on WSL (Windows Subsystem for Linux), and when I ran:

sudo apt install neovim

I got hit with this:

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package neovim is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'neovim' has no installation candidate

What does this mean? Basically: “Neovim? Never heard of it.”

Apparently, Neovim isn’t in the default Ubuntu repo on WSL. Great.

So I headed over to the Neovim GitHub like any lost soul would and followed the official install steps:

curl -LO https://github.com/neovim/neovim/releases/latest/download/nvim-linux-x86_64.tar.gz
sudo rm -rf /opt/nvim
sudo tar -C /opt -xzf nvim-linux-x86_64.tar.gz

Then I added it to my PATH and cleaned up:

rm nvim-linux-x86_64.tar.gz
export PATH="$PATH:/opt/nvim-linux-x86_64/bin"

Finally, I typed neovim and hit Enter.

...“Command not found.”

Of course.

Turns out, the command is actually nvim.

Seriously? Who decided that?

Anyway — I typed nvim this time, and boom — it opened.

Well, “opened” is generous. What I saw was a blank terminal. No UI, no buttons, not even a helpful hint. Just a blinking cursor and the haunting silence of a terminal waiting for your next move.

After a deep breath and remembering that :q is the exit command, I hit i to go into insert mode, typed something random, hit Esc, and then typed :q.

Instead of quitting, it slapped me with this:

E162: No write since last change for buffer "[No Name]"
Press ENTER or type command to continue

I had no idea what that meant, but I definitely knew I didn’t like it.

This is the moment I panicked.

And like every sane human, I Googled: “how to exit Vim.”

There it was — my first real Neovim lesson:

:q!

The magic command to force quit.

I was in.

Well, technically, I was out — but you get the point.
You're doing a great job capturing the honest, fun chaos of learning Neovim. The tone and personality are strong — it’s like reading the journal of someone falling into a beautiful rabbit hole. Below is your draft enhanced for flow, clarity, and a touch of polish while preserving your voice and humor.

Next up: Configuring It to Make It Feel Like Home

To configure Neovim, I stumbled upon NvChad — mostly because I liked the name. It sounded like the kind of setup that might high-five you after a successful config. So, I pulled it in:

git clone -b v2.0 https://github.com/NvChad/NvChad ~/.config/nvim --depth 1

When I ran nvim, I realized it still wasn’t globally available. So I added Neovim to my PATH and gave it a friendly nickname while I was at it:

echo 'export PATH="$PATH:/opt/nvim-linux-x86_64/bin"' >> ~/.zshrc
echo 'alias vim="nvim"' >> ~/.zshrc
source ~/.zshrc

Now I can just type vim and it opens Neovim like a charm.

When NvChad launched, it brought up what looked like a package manager asking me to install a bunch of things. I pressed i, and off it went — downloading plugins and setting up the vibe.

Once it finished, I restarted Neovim and immediately changed the color theme. The keymap for this was refreshingly intuitive. The important thing to understand is the leader key, which is <space> by default. Pressing it in normal mode (not insert!) opens up a mini keymap menu at the bottom.

To change the theme:

<space> + t + h

A beautiful little theme selector popped up, and I picked my favorite. Instantly, the UI felt like mine.

Learning the Basics (It Feels Like a Game)

So far, here’s what I’ve picked up about using Neovim:

Modes

NORMAL mode — for navigating and running commands. (Esc)
INSERT mode — for writing text. (i)

Movement (aka the Game Begins)

Instead of arrow keys, Neovim encourages hjkl for movement:

h — left
j — down
k — up
l — right

It's weirdly satisfying. Like I’m playing a keyboard-only game.

(Neovim: The Roguelike Editor™?)

I found this and more inside the built-in tutorial:

:Tutor

Keymaps I Use Now

I’ll refer to the leader key (<space>) as <lk> from now on.

<lk> + h — open a new terminal
<Ctrl> + n — toggle file explorer
<Tab> — switch between open files
:w — save the file
<lk> + x — close currently opened file

Inside the file explorer:

a — add a new file
r — rename a file
d — delete a file
dd — delete a line at the cursor

It’s all starting to click. The muscle memory is slowly forming. And every time I don’t reach for the mouse, I feel a tiny spark of pride.

Plugins and LSPs: Making It Actually Useful

Now that I know how to move around without rage-quitting, it's time to make Neovim actually useful for coding.

Here's my current plugin wishlist — essential tools to help me survive:

✅ Auto format on save
✅ LSP support (language servers for Go, JavaScript, etc.)
✅ Copilot (yes, I sold my soul for AI auto-complete)
✅ Time tracker (for accountability and/or guilt)
✅ Discord Rich Presence (because I want people to know I’m tweaking my dotfiles at 2 AM)

Let’s Start Adding the Essentials

To test things out in a real-world scenario, I decided to open one of my Next.js projects — it just felt right to see how Neovim behaves with an actual codebase. Navigating was simple enough: I jumped into the project directory and ran vim.

And... boom. The interface opened — but instead of icons, I was greeted with mysterious question marks scattered across the UI. Classic font mismatch.

No worries — I quickly traced the issue back to my terminal fonts not being compatible with Neovim’s fancy icon setup. The solution? Nerd Fonts. After some browsing, I chose 0xProto Nerd Font, installed it, and set it as the default font in my terminal.

Problem solved. The icons rendered beautifully, and Neovim suddenly felt alive.

Getting Auto-Completion Working (The LSP Journey Begins)

With my project open, I quickly noticed the lack of auto-completion — something I’d grown dependent on. No popups, no suggestions... just silence. Time to bring in the cavalry: a Language Server Protocol (LSP) for TypeScript.

To get started, I needed to tweak Neovim’s configuration. I headed to my config folder — and naturally, used Neovim itself to edit it:

cd ~/.config/nvim && vim

A blank screen greeted me. If you’ve followed along, you’ll know how to open the file tree (check the previous section if not). Once inside the tree, I navigated to:

lua/custom/chadrc.lua

Inside that file, I added:

M.plugins = "custom.plugins"

This line tells Neovim to look for our plugin configurations in a custom file.

Next, I saved the changes (:w in INSERT mode) and created a new file:

lua/custom/plugins.lua

Inside this file, I scaffolded a basic structure:

local plugins = {}
return plugins

Now that the foundation was set, it was time to add the real hero: nvim-lspconfig. I edited plugins.lua and added the following inside the plugins table:

{
  "neovim/nvim-lspconfig",
  config = function()
    require "plugins.configs.lspconfig"
    require "custom.configs.lspconfig"
  end,
},

This configuration loads the built-in LSP setup while also pointing to our custom overrides.

Creating Our LSP Config

Now to wire up our actual configuration. I created a new folder and file:

Folder: lua/custom/configs
File: lspconfig.lua

(If you’re in Neovim’s file tree, you can press <Ctrl> + n to open the tree, move the cursor to custom, press a, and type configs/lspconfig.lua.)

In lspconfig.lua, I wrote the following:

local on_attach = require("plugins.configs.lspconfig").on_attach
local capabilities = require("plugins.configs.lspconfig").capabilities

local lspconfig = require("lspconfig")

local servers = {"tsserver", "tailwindcss", "eslint"}

for _, lsp in ipairs(servers) do
  lspconfig[lsp].setup {
    on_attach = on_attach,
    capabilities = capabilities,
  }
end

This sets up LSPs for TypeScript, Tailwind CSS, and ESLint. The best part? It’s extendable. I can easily plug in support for Rust or Go later by just appending to the servers list.

Installing Language Servers with Mason

Installing language servers manually is tedious, so I reached for Mason.nvim to automate the job.

Back in plugins.lua, I added:

{
  "mason-org/mason.nvim",
  opts = {
    ensure_installed = {
      "eslint-lsp",
      "prettierd",
      "tailwindcss-language-server",
      "typescript-language-server",
    },
  },
},

After saving, I relaunched Neovim and ran:

:MasonInstallAll

Voilà! Language servers downloaded and ready to go. At this point, TypeScript and Tailwind auto-completion were working like magic.

Adding Formatting with Prettier

However, auto-completion alone isn’t enough — we need formatting too. Even though we had installed prettierd, it wasn’t doing its job yet.

Enter: none-ls.nvim — the plugin that bridges formatters and linters to Neovim.

In plugins.lua, I added:

{
  "nvimtools/none-ls.nvim",
  event = "VeryLazy",
  opts = function()
    return require "custom.configs.none-ls"
  end,
},

Time for one last config file. I created:

lua/custom/configs/none-ls.lua

Inside it, I added:

local augroup = vim.api.nvim_create_augroup("LspFormatting", {})
local null_ls = require("null-ls")

local opts = {
  sources = {
    null_ls.builtins.formatting.prettierd,
  },
  on_attach = function(client, bufnr)
    if client.supports_method("textDocument/formatting") then
      vim.api.nvim_clear_autocmds({
        group = augroup,
        buffer = bufnr,
      })
      vim.api.nvim_create_autocmd("BufWritePre", {
        group = augroup,
        buffer = bufnr,
        callback = function()
          vim.lsp.buf.format({ bufnr = bufnr })
        end,
      })
    end
  end,
}

return opts

This hook listens for file saves and auto-formats the code using prettierd. Exactly what we need for a smooth dev experience.

And just like that, LSP support is fully integrated — from completion to formatting. My Neovim setup just leveled up.

Let’s Bring in AI ✨ (and Some Visual Flair)

Now that LSP and formatting are handled, it's time to supercharge my workflow — with AI!

🧠 Adding GitHub Copilot

Integrating Copilot with Neovim is surprisingly simple. I opened up my trusty plugins.lua file once again and added the following plugin definition to the list:

{
  "github/copilot.vim",
  event = "InsertEnter",
}

This tells Neovim to lazily load Copilot the moment I enter INSERT mode.

After saving the file, I restarted Neovim and ran:

:Copilot setup

This initialized Copilot and connected it to GitHub. If for some reason it didn’t load automatically, I nudged it manually:

:Lazy load copilot.vim

Just like that — Copilot was ready to start pairing with me. Smart suggestions, code completions, and a boost in productivity — unlocked!

Syntax Highlighting with Treesitter

With Copilot onboard, it was time to make the editor more readable and pleasing to the eyes. For that, I turned to Treesitter — the gold standard for syntax highlighting and parsing.

Again, I popped into plugins.lua and added:

{
  "nvim-treesitter/nvim-treesitter",
  opts = function()
    local opts = require "plugins.configs.treesitter"
    opts.ensure_installed = {
      "lua",
      "javascript",
      "typescript",
      "tsx",
    }
    return opts
  end,
}

I made sure to include tsx for React support, and of course, you can toss in other languages like rust and go if your stack demands it.

Now everything — from tags to braces — was beautifully color-coded and structured.

⏱️ Optional (But Cool): WakaTime for Coding Analytics

This one’s for the productivity nerds out there — like me. I love tracking how much time I actually spend coding, so I set up WakaTime, which gives me detailed insights into where my time goes.

To install the plugin, I added the following to (yes, again) plugins.lua:

{ "wakatime/vim-wakatime", lazy = false }

After restarting Neovim, I simply ran:

:WakaTimeApiKey

Then pasted in my API key from the WakaTime dashboard. Boom — time tracking was live. I could now see how long I spend inside Neovim, what languages I code in the most, and when I’m most productive.

With AI suggestions, beautiful syntax, and time-tracking all set up, Neovim was starting to feel less like a terminal — and more like an IDE.

Here's a polished and storytelling-enhanced version of your final section. It stays faithful to your technical steps, while improving clarity and flow:

Final Touch: Flexing on Discord with Rich Presence

For the final touch, I decided to bring in Discord Rich Presence so I can subtly flex my Neovim setup to friends — because why not?

After a bit of research, I learned that Discord RPC doesn't work out-of-the-box in WSL2 due to limitations in how it handles inter-process communication. It does work in WSL1, but I wanted to try getting it working in WSL2 anyway using a clever workaround.

Step 1: Add the Plugin

As always, I started by adding the plugin to my plugins.lua:

{ 'vyfor/cord.nvim', lazy = false }

Then opened Neovim and ran:

:Cord update

If it works at this point — you're golden. But like many WSL2 users, I hit a wall. So I followed these instructions to bridge Discord from WSL to Windows.

Step 2: Install Required Tools

You'll need two pieces:

socat — for socket redirection in WSL
npiperelay — to communicate with Windows named pipes

Start by installing socat inside your WSL terminal:

sudo apt install socat

Then clone and build npiperelay for Windows:

git clone https://github.com/jstarks/npiperelay.git 
go install github.com/jstarks/npiperelay

Now build it for Windows and place it somewhere accessible:

GOOS=windows go build -o /mnt/c/Users/<username>/go/bin/npiperelay.exe github.com/jstarks/npiperelay

Replace <username> with your actual Windows username.

Create a symbolic link for convenience:

sudo ln -s /mnt/c/Users/<username>/go/bin/npiperelay.exe /usr/local/bin/npiperelay.exe

Step 3: Hook into Your Neovim Launch

We now need to run socat and npiperelay each time we launch Neovim, so I created a wrapper function in my .bashrc (or .zshrc):

nvim() {
    if ! pidof socat > /dev/null 2>&1; then
        [ -e /tmp/discord-ipc-0 ] && rm -f /tmp/discord-ipc-0
        socat UNIX-LISTEN:/tmp/discord-ipc-0,fork \
            EXEC:"/usr/local/bin/npiperelay.exe //./pipe/discord-ipc-0" 2>/dev/null &
    fi

    if [ $# -eq 0 ]; then
        command nvim
    else
        command nvim "$@"
    fi
}

This ensures the IPC bridge is set up only once, and works whether I run nvim directly or pass it files as arguments.

If you prefer, you can rename this function or alias it to something else.

Done!

That’s it — a full minimal Neovim config:

📜 Syntax highlighting
🤖 AI with Copilot
🧠 LSP and formatting support
⌛ Time tracking
🕹️ Discord Rich Presence

Now I can code with AI assistance, auto-format on save, track my hours, and flex on Discord — all within a terminal. I wasted too much time setting this up, now I'm going to eat something.

Note: This guide reflects my personal setup and preferences. I am not affiliated with, promoting, or endorsing any of the tools or services mentioned. Please evaluate and use them based on your own requirements and discretion.

Follow me on GitHub @PriyanshuPz

Inside a Rust-Powered HTTP Server Built From Zero

Priyanshu Verma — Fri, 30 May 2025 13:53:09 +0000

I've always been curious about Rust. The buzz around its memory safety, zero-cost abstractions, and fearsome compiler made me both intrigued and intimidated. Instead of starting with tutorials or relying on heavy frameworks, I decided to try something different — build a tiny server from scratch.

Ah yes, because when normal people want to learn a new programming language, they start with "Hello World." But me? I thought, "Let's reinvent the wheel, but make it square, and also let's use only stone tools while we're at it."

It might sound boring, or even like a waste of time (and yes, at times it felt like that), but I ended up learning a lot through the process. To take things up a notch, I decided to do it using only the standard library — no external crates.

The challenge? Build a simple REST API server for a to-do app, with just the bare minimum. No tokio, no hyper, no serde. Just Rust's std library. At least, that was the plan — until things got overwhelming enough to reconsider. 😉

Spoiler: By "overwhelming," I mean the moment I realized parsing JSON without serde is like trying to eat soup with a fork — technically possible but an exercise in futility.

Setup and Getting Started

As a professional beginner, I started by watching a crash course on Rust before diving in. Trust me, I knew nothing about Rust.

"Professional beginner" is my politically correct way of saying "I have impostor syndrome but with extra steps." This way, when I inevitably mess up, I can say, "Well, what did you expect? I'm professionally bad at this!"

After watching a simple crash course and learning how Rust works and what its syntax looks like, I realized for the first time — it's not going to be simple.

Rust's learning curve isn't a curve at all. It's a brick wall with spikes on it, and the Rust compiler stands atop it, looking down at you with a mixture of pity and disappointment, like a cat watching you try to open a can of tuna with your bare hands.

DAY 1: In Which I Convince Myself I Know Rust

Ignoring the existential dread that comes with learning a new systems programming language, I installed Rust on WSL with a simple one-liner from Rust's official site. Then created a fresh project and started printing "hello world" so I could motivate myself that I do know Rust.

cargo new rust-server
cd rust-server
cargo run

Five minutes in, and I'm basically Jon Skeet of the Rust world. Put that on my LinkedIn.

After wasting some time patting myself on the back for successfully printing text to a console (a true technological breakthrough), I opened Rust docs for the standard library and found TcpListener. I quickly created a server using it:

let listener = TcpListener::bind(("127.0.0.1", 5000)).unwrap();

It was simple — just gave the address and unwrapped any error.

It is not recommended to unwrap any function that can give an error in production, because if an error occurs, it will panic and stop the program. Since this is not production code, I can do it.

In fact, I'll be sprinkling unwrap()s like confetti throughout this project. My error handling strategy: "If it breaks, I'll deal with it... never." This is what we call "confidence" in the software development industry.

After creating the listener, we need to listen for incoming requests. Here's how:

for stream in listener.incoming() {
    let stream = stream.unwrap();
    handle_connection(stream);
}

Very basic, single-threaded server that will listen for one incoming request at a time.

For now, I don't think I will add multithreading (I was wrong. I did that).

My famous last words. Right up there with "How hard could it be?" and "I'm sure we don't need unit tests for this."

With classic beginner energy, I unwrapped the stream and called handle_connection — a function I defined like this:

fn handle_connection(mut stream: TcpStream) {
    let buf_read = BufReader::new(&mut stream);

    for line in buf_read.lines() {
        let line = line.unwrap();
        if line.is_empty() {
            break; // End of headers
        }
        println!("Received: {}", line);
    }
}

Believe me or not, printing this took serious time.

By "serious time," I mean I spent 30 minutes debugging why my buffer reader wouldn't print anything, only to realize I had forgotten to actually send a request to the server. Yes, I'm that developer who checks if the monitor is plugged in after calling IT support.

It's very basic — create a buffer reader and loop through each line, printing it to the console.

At the end of the day, you'll see something like this:

Here, mut is used with &.

In Rust, mut is for making a variable mutable, and & is for referencing a variable instead of copying it.

So, &mut stream is a mutable reference. If you try to access or modify the stream again outside this function, you'll get an error (ownership rules!).

Did I mention Rust has ownership rules? It's like that friend who won't lend you anything without making you sign a contract in blood. "You can borrow my stream, but I need it back EXACTLY as you found it, or the compiler will hunt you down."

Received: GET / HTTP/1.1
Received: Host: localhost:5000
Received: User-Agent: curl/8.5.0
Received: Accept: */*

You're seeing how HTTP works. This is the protocol.

Ah, the raw HTTP request in all its glory. It's like seeing how sausage is made—oddly satisfying but makes you appreciate the abstractions that normally hide it from you.

In the first line, we have:

Method – what action to perform (like GET/POST). Case-sensitive. RFC
Request-URI – the path. Section 3.2
Version – the HTTP version. RFC

The rest are headers: Host, User-Agent, etc.

Yes, I'm actually linking to the RFCs, which makes me feel very important. Nothing says "I'm a serious developer" like citing RFC documents that nobody is actually going to read. But they're there, just in case you want to fall asleep really quickly.

If we send a POST request, we also get the body:

Received: POST / HTTP/1.1
Received: Host: localhost:5000
Received: Content-Type: application/json
Received: User-Agent: curl/8.5.0
Received: Content-Length: 21
Received: 
Received: {"hello": "John Doe"}

For now, we need to extract:

Method
Path
Body
Headers
Query parameters

Rest is useless (for now).

Extracting it from this plain stream isn't easy — it's just text with no types.

It'll be fun to do (it won't be).

Spoiler: When a developer says something will be "fun," they mean it will be a soul-crushing exercise that makes them question their career choices. But hey, at least there's coffee.

Sending the Response

Right now, the request just hangs because we're not sending anything back.

It's like when you text someone a question and they read it but don't respond. Rude, right? Our server is currently that person.

Let's write a manual response:

let status_line = "HTTP/1.1 200 OK";
let contents = "{'hello': 'World'}";
let length = contents.len();
let response = format!(
    "{status_line}\r\nContent-Length: {length}\r\nContent-Type: application/json\r\n\r\n{contents}"
);
stream.write(response.as_bytes()).unwrap();

Boom. Response sent.

When I typed "Boom," I felt like I just launched a SpaceX rocket, but in reality, I just sent 18 bytes over localhost. Let's keep our achievements in perspective.

HTTP/1.1 200 OK
Content-Length: 18
Content-Type: application/json

{'hello': 'World'}

That's It for Day 1

That's all I did. Simple stuff — but I was happy. This bit of work taught me:

How to spin up a TCP server in Rust with only the standard library.
How HTTP requests actually look on the wire.
How to send a raw HTTP response manually.

More to come in Day 2.

I ended the day feeling like I'd accomplished something significant, when in reality all I'd done was reinvent technology from the 1990s. But you know what? Sometimes you need to go back to understand how to move forward. At least that's what I tell myself to feel better about spending an entire day writing what most frameworks do in three lines of code.

DAY 2: HTTP Parsing Hell, or "Why Don't I Just Use a Framework Again?"

Today's mission? Turn a chaotic stream of bytes into a neat little Request struct that we can actually work with. Think of it like decoding alien signals, except it's HTTP and slightly less cool. The goal is to be able to write code like this:

fn handle_connection(mut stream: TcpStream) {
    let req = Request::new(&stream);
    println!("REQUEST METHOD: {:?}", req.method);
}

Yep, just calling Request::new(&stream) should give us all the sweet, sweet info — method, path, headers, query, body. But before that happens, we need to teach our program how to read the stream and not choke.

If you're wondering "why don't I just use a library for this?" — congratulations, you're smarter than me. But we're committed to the bit now, so let's keep reinventing this particular wheel until it's almost round-ish.

So, To implement it let's create a struct named Request for this I will create a new file request/mod.rs. And create lib.rs file in root. Inside lib.rs I will register request/mod.rs like this:

pub mod request;

This will register this module, add you will get autocompletion if using VS Code.

Ah yes, autocomplete, the thing that writes 90% of my code for me. Let's be honest, without IntelliSense, most of us would be reduced to grunting and throwing rocks at our computers.

Now, Inside request/mod.rs let us define the struct.

#[derive(Debug)]
pub struct Request {
    pub method: String,
    pub path: String,
    pub headers: HashMap<String, String>,
    pub query: HashMap<String, String>,
    pub content: String,
}

This request struct will have these stored stuff we talked in Day 1. Also, added Debug macro for debugging it is optional. For this struct we need to define only one function named new which will intake the TCPStream reference and in result gives response or error string.
Filename: request/mod.rs

// ...request struct code
impl Request {
    pub fn new(mut stream: &TcpStream) -> Result<Self, String> {
     // processing code...
    }
}

Like this we can create a function which is public so can be accessed by anywhere taking TCPStream and resulting request.

I've gone for the Result<Self, String> return type because nothing says "I'm a Rust developer" quite like wrapping everything in Result. It's like putting your code in bubble wrap — sure, it's harder to use, but at least it won't break if you drop it.

Our first step is to grab all the text from the buffer and store it.
we need to read the bytes from the stream. For that, we define a couple of variables:

const MESSAGE_SIZE: usize = 1024;
let mut received: Vec<u8> = vec![]; // this will store full request
let mut rx_bytes = [0u8; MESSAGE_SIZE]; // temporary buffer

Q: Why use a fixed-size buffer like rx_bytes instead of reading directly into received?

A: Because stream.read() wants a fixed-size buffer to read into. I spent way too much time figuring that out. Don't be like me. Just use the buffer.

True story: I spent about an hour trying various combinations of .read_to_end(), .read_to_string(), and custom buffer strategies before realizing that TCP streams don't have a clear "end" until they're closed. The documentation mentions this, but who reads documentation, am I right? (Please read documentation.)

Now the scary part: the loop.

loop {
    let bytes_read = stream.read(&mut rx_bytes);
    match bytes_read {...}
}

This loop keeps reading the stream into rx_bytes, and each chunk is pushed into received. We stop reading once fewer bytes are read than our buffer size — usually meaning the request has ended.

Also, remember: I'm just sharing my experience. If you copied this loop from Stack Overflow, check it before you run it. 😂

Let's be honest, we're all copying from Stack Overflow. The difference between junior and senior developers is that seniors know which parts to modify after copying.

match bytes_read {
        Ok(bytes) => {
        received.extend_from_slice(&rx_bytes[..bytes]);
        if bytes < MESSAGE_SIZE { break; }
        }
        Err(err) => {
            println!("error: {:#?}", err);
        }
    }

We are handling two condition if result is OK and on Err. For error, we are doing basic console logging. And For Ok. We are getting a variable named bytes which is a usize integer that is the number of bytes that were successfully read. Only need to convert it in string and then extract the information.

The error handling here is what I call "log and pray" — we print the error and hope someone is watching the console. This is state-of-the-art error handling for weekend projects.

Now, second step is to convert this received vector in string:

let request_text = String::from_utf8(received).unwrap();

This allows us to convert it into string. Now, will split this request_text with newline character. And create some HashMap variables to store headers and query parameters.

let mut request_lines: Vec<&str> = request_text.split_inclusive('\n').collect();

// Store headers and query parameters
let mut header_map: HashMap<String, String> = HashMap::new();
let mut query_params: HashMap<String, String> = HashMap::new();

Ah, the classic "split and collect" pattern — the programming equivalent of opening a UPS package with safety scissors. It works, but there's a lot of awkward maneuvering involved.

Now, let's start extracting stuff. Foremost the easy one http method which is in first time.

// First line of HTTP request, e.g., "GET /path?x=1 HTTP/1.1"
let request_line = request_lines[0];
let mut parts = request_line.split_ascii_whitespace();
// Extract HTTP method and full path
let http_method = parts.next().unwrap();
let full_path = parts.next().unwrap();

Here, We have taken first line from the request_lines vector we created. Then, split that with whitespace and assigned first part as the http_method and second to full_path.
full_path will have our path name and query parameters that we will extract by separating this with ?.

Notice those beautiful .unwrap() calls? That's me saying "I trust this HTTP request to be perfectly formatted." Which is like trusting a toddler with cake — it's gonna get messy.

// Separate path and query string (e.g., "/search?q=rust")
let path_and_query: Vec<&str> = full_path.split('?').collect();
let path = path_and_query[0];

After separating the first one will always be the path and rest we will handle if the length of the path_and_query is greater than 1 which means query params are passed than.

if path_and_query.len() > 1 {
    let query_string = path_and_query[1..].join("");
    let query_pairs: Vec<&str> = query_string.split("&").collect();
    for pair in query_pairs {
        if let Some((key, value)) = pair.split_once('=') {
            query_params.insert(key.to_string(), value.to_string());
        }
    }
}

Further, query_string is the string after joining the rest of the stuff excluding the path. You can see the spreading [1..] This will exclude 1 index keeping rest same.
Afterward, again splitting this with & because request might have multiple queries. Then looped query_pairs splitting with = once and inserting the values in the HashMap we created query_params.

Every time I write code like this, a framework developer somewhere sheds a single tear. We're essentially manually parsing query parameters like it's 1999. Next, I'll be setting up my Geocities page and adding a visitor counter.

Fun fact till now we just manipulated only first line of the protocol. So, let just remove that first line from the request_lines so, it will no conflict with upcoming stuff.

// Remove the request line (already processed)
request_lines.remove(0);

Now, third step is to extract body and header so to do that we need to separate them by \r\n in to pieces first will be the headers part and rest is body. Let's get the index of this blank line:

let blank_line_index = request_lines.iter().position(|&line| line == "\r\n").unwrap();

After getting the index just spilt off body out

let body_lines = &mut request_lines.split_off(blank_line_index);
body_lines.remove(0); // Remove the blank line itself
let body_content = body_lines.join(""); // Reconstruct body as a single string

Here, .split_off() will give the part including the index provided so, removed that in the second line with .remove(). You can observe that I have specified &mut in variable body_lines this will give a mutable reference of the body_lines that is why we are able to remove first line. While implementing I realized for the second time — Rust is not for noobs.

"Rust is not for noobs" should be their official slogan. The Rust compiler is like that strict teacher who makes you show all your work and won't let you get away with anything. "You're using a mutable reference here, but did you declare ownership rights? I THINK NOT."

Again stitching body content in a string that can be parsed by serde or custom parser. I am not going that deep for now. If you have a hobby to waste time reading these types of devs log than you can try yourself to build one parser or pin me to do. (sarcasm)

Let's be real: if you're still reading this, you either have an unhealthy fascination with HTTP parsing or you're my mom (hi mom!). Either way, I'm concerned about your hobbies.

Last step, the headers! Well it is similar to query params with for loop, if you are following along then you can, you do this by your own buddy. Come-on, remember what you read in starting.

Oh, you actually want me to explain the headers parsing too? Fine, here's roughly what it would look like:

for header_line in &request_lines {
    if header_line.trim().is_empty() {
        continue;
    }
    if let Some((key, value)) = header_line.split_once(": ") {
        header_map.insert(key.to_string(), value.trim().to_string());
    }
}

It's basically the same idea as parsing query parameters, except with a different delimiter. If you're having trouble with this, maybe programming isn't for you. (I'm kidding, it took me three tries to get this right.)

And… that's it! That's Day 2.

You can now instantiate a Request from a raw TCP stream and access method, path, query, headers, and body.

If you read all this and are still here, maybe you have a strange hobby of reading dev logs like these. Either way, thanks for coming along the ride. 🤝

Day 2 complete, and all we've done is parse HTTP requests manually, something that libraries have been doing reliably for decades. But hey, we've learned how HTTP works at a fundamental level, which is... useful knowledge to have, I guess? Let's pretend this wasn't a gigantic detour into "things you'll never need to implement yourself" territory.

DAY 3: Responding With Style (Or At Least Valid HTTP)

So far we have a rust server where we can handle the request like this:

fn handle_connection(mut stream: TcpStream) {
    let req = Request::new(&stream);
    println!("REQUEST METHOD: {:?}", req.method);
}

Now, we need a way to send response in a good manner currently we are doing it manually, and it is boring too.
So, similar to Request we will create a new struct for Response than will create some functions to send the response back.

Boring is programmer-speak for "I've typed this same boilerplate 17 times and I'm starting to wonder if computers were a mistake."

This is the manual code:

let status_line = "HTTP/1.1 200 OK";
let contents = "{'hello': 'World'}";
let length = contents.len();
let response = format!(
    "{status_line}\r\nContent-Length: {length}\r\nContent-Type: application/json\r\n\r\n{contents}"
);
stream.write(response.as_bytes()).unwrap();

What we can do is create a function to intake status code, content and optionally headers then return that response. Also, to write this response we can create a function to resolve. In practical let us code to handle some endpoints:

Look at all those string concatenations and hard-coded header values. This code is begging to be abstracted away. It's like watching someone solve a Rubik's cube by peeling off the stickers — it works, but it hurts my soul.

fn handle_connection(mut stream: TcpStream) {
    let req = Request::new(&stream);
    let res = match req {
        Ok(req) => {
            let res = match req.path.as_str() {
                "/hello" => {
                    let default_name = "World".to_string();
                    let name: &String = req.query.get("name").unwrap_or_else(|| &default_name);
                    let payload = format!("{{\"message\": \"Hello, {}!\"}}", name);
                    Response::json(200, &payload, None)
                }
                &_ => {
                    let payload = "{{\"message\": \"Invalid Path\"}}";
                    Response::json(400, &payload, None)
                }
            };
            Response::resolve(&res)
        }
        Err(s) => {
            let payload = format!("{{\"message\": \"{}\"}}", s);
            let res = Response::json(500, &payload, None);
            Response::resolve(&res)
        }
    };
    match stream.write(res.as_bytes()) {
        Ok(_) => {}
        Err(_) => {
            println!("FAILED DISPATCHED RESPONSE")
        }
    }
}

In this code snippet, we are matching the request path and conditionally executing required code. Here Response::json() and Response::resolve() function today, we will implement these are helping us in sending a clear formatted response.

This is what I call "nested match statement hell." It's like Russian nesting dolls, except each doll contains a slightly different way of saying "something went wrong."

Let's start by creating a new file response/mod.rs and add this in lib.rs file like we did for Request.

In response/mod.rs we will create a new struct named Response containing status code, body and headers. Then will implement two functions we decided ::json and ::resolve.

pub struct Response {
    status_text: String,
    headers: Vec<(String, String)>,
    body: String,
}

impl Response {
    pub fn json(status: u16, body: &str, headers: Option<Vec<(String, String)>>) -> Self {
     // conversion to response code
    }

    pub fn resolve(response: &Response) -> String {
        // response to string code
    }
}

You know you're writing Rust when half your code is just setting up structures to make the other half cleaner. It's like spending 3 hours organizing your desk before starting a 10-minute task. But hey, that's why we love it!

These functions are going to be very simple firstly ::json() will calculate the body length and initialize some predefined headers

let content_length = body.len();
let pre_dermined_headers = vec![
    ("Content-Type".to_string(), "application/json".to_string()),
    ("Content-Length".to_string(), content_length.to_string()),
];
let headers = headers.unwrap_or_else(|| vec![]);

We are using content type to be json as this function is only for json if you want you a creation for HTML you can do similarly.
Now, will creating a variable for status text which is a string like for 200 200 OK, 201 201 Created, and so on.

let status_text = match status {
    200 => "200 OK".to_string(),
    400 => "400 Bad Request".to_string(),
    500 => "500 Internal Server Error".to_string(),
    _ => format!("{} Unknown", status),
}

I love how we're handling only three HTTP status codes here. It's like opening a restaurant that only serves breakfast, lunch, and dinner, but nothing in between. Want a mid-afternoon snack? Sorry, "418 I'm a teapot" is not on the menu.

To keep it very simple I've added only three codes, you can extend it if you want.
Lastly, return this response struct and our ::json() function is done.

Self {
    status_text,
    headers: [pre_dermined_headers, headers].concat(),
    body: body.to_string(),
}

Now, only ::resolve() function is remaining which is a simple logic to stitch all these stuff together and create a string to send

let mut response_str = format!("HTTP/1.1 {}\r\n", response.status_text);

for (key, value) in &response.headers {
    response_str.push_str(&format!("{}: {}\r\n", key, value));
}

response_str.push_str("\r\n");
response_str.push_str(&response.body);

response_str

This resolve function is basically doing the same string concatenation we were trying to avoid, but now it's encapsulated so we can pretend we don't see it. This is what we call "abstraction" in the industry — putting ugly code in a box and giving it a nice name.

So far, now we have somewhat usable rust server that intake request and throw response in little good manner.

It was day 3 of mine, And I think we can create simple to-do API with this. The only remaining is to add multi-threading that is the last chapter.

"Somewhat usable" is developer-speak for "it works on my machine under perfect conditions, but I wouldn't trust it with actual users." But we're making progress! We've graduated from "completely unusable" to "somewhat usable" in just three days.

DAY 4: Multithreading Madness, or "How I Learned to Stop Worrying and Love the Thread Pool"

Today marks the final day of this dev log. It's been an exciting, fulfilling journey — a low-level, hands-on exploration of building an HTTP server in Rust using nothing but the standard library. From parsing raw TCP streams to crafting custom Request and Response types, and now finally implementing a thread pool — this was more than a weekend project. It was a masterclass in systems programming, Rust safety, and architectural thinking.

"Exciting" and "fulfilling" are the words I use in public. In private, it was more like "frustrating" and "why did I choose this again?" But now that it's over, I can pretend it was a smooth, enjoyable experience. That's how memory works!

Let's dive into Day 4, which was all about making our server concurrent and robust. But as with all systems work, the deeper story isn't just what I built — it's why I built it that way.

Or more accurately, why I thought reinventing thread pooling was a good use of my time when perfectly good libraries exist. But here we are.

Motivation: From Sequential to Concurrent

Initially, our server could handle one request at a time. If a user hit /hello, and inside that handler we added something like:

std::thread::sleep(std::time::Duration::from_secs(5));

The whole server would freeze for 5 seconds. No other request could get through. That's obviously not how real-world web servers behave — not even the simplest ones.

It's like having only one cashier at a grocery store who also has to bag your items, fetch missing products, and check inventory. You'd have a line out the door faster than you can say "unexpected item in bagging area."

The natural next step: let's add multithreading.

I began with a naive approach, just like any curious Rustacean learning the ropes would.

First Stop: Spawning a New Thread per Request

Here's the naive, simple version:

for stream in listener.incoming() {
    let stream = stream.unwrap();
    std::thread::spawn(|| {
        handle_connection(stream);
    });
}

This actually works well for testing — the server no longer blocks on a single request. We can add delay inside the handler, and other clients won't wait.

But here's the caveat: we're spawning a new thread for every single connection.

What happens if someone sends us 1,000 requests per second? We spawn 1,000 threads per second. The system dies fast. This is a textbook Denial of Service vector.

It's like hiring a new employee for each customer that walks into your store. By the end of the day, you'd have 500 employees standing around, payroll would be impossible, and your store would be too crowded for any actual customers.

So I pivoted to a better design.

The Thread Pool Model

A Thread Pool is like a team of waiters at a restaurant. You don't hire a new waiter for every customer. You just hand tasks to whoever's available.

Or think of it as a group of interns eagerly waiting to do your grunt work. "You there, handle this HTTP request! You, parse this JSON! The rest of you, stand by for more tedious tasks!"

Technically, a thread pool keeps a fixed number of threads alive. Each thread waits for a job. When a job (like an incoming HTTP request) arrives, it's pushed into a shared queue. The next available thread grabs it and handles it.

This avoids overloading the OS scheduler with thousands of threads while still enabling concurrency.

In Rust, building a thread pool from scratch meant juggling:

Threads (from the standard library),
Channels (std::sync::mpsc) for sending jobs,
Mutexes and Arcs for safe, shared ownership of the job receiver.

Let's walk through the code.

By "let's walk through the code," I mean "brace yourself for a cavalcade of Rust's most intimidating concurrency primitives." If you've never seen an Arc<Mutex<mpsc::Receiver<Box<dyn FnOnce() + Send + 'static>>>> before, well... you're about to.

📦 The ThreadPool Code: Building a Worker Army

We created a new module: lib.rs (or thread_pool.rs if separated), which defines ThreadPool.

`ThreadPool` Struct

pub struct ThreadPool {
    workers: Vec<Worker>,
    sender: Option<mpsc::Sender<Job>>,
}

It holds:

workers: a vector of threads.
sender: a channel to send jobs into the queue.

We define Job like this:

type Job = Box<dyn FnOnce() + Send + 'static>;

A job is just a closure you can run once. It must be thread-safe (Send) and have a static lifetime (since threads can outlive their scopes).

Look at that type alias. If you can read that and immediately understand what it means, congratulations! You've achieved Rust enlightenment. For the rest of us mortals, it's a boxed closure that can be sent between threads and lives for the entire program.

Creating the Pool

pub fn new(size: usize) -> ThreadPool {
    assert!(size > 0);

    let (sender, receiver) = mpsc::channel();
    let receiver = Arc::new(Mutex::new(receiver));
    let mut workers = Vec::with_capacity(size);

    for id in 0..size {
        workers.push(Worker::new(id, Arc::clone(&receiver)));
    }

    ThreadPool {
        workers,
        sender: Some(sender),
    }
}

We create a sender/receiver channel pair.
The receiver is wrapped in Arc<Mutex<>>, so it can be safely shared between threads.
Each worker is spawned with a cloned handle to the shared receiver.

That Arc<Mutex<>> wrapper is the Rust equivalent of putting something in a special box with a lock on it, then making photocopies of the box. Everyone gets their own copy of the box, but there's still only one thing inside, and only one person can unlock it at a time.

The Worker: Thread That Never Sleeps

struct Worker {
    id: usize,
    thread: Option<thread::JoinHandle<()>>,
}

Each worker has an ID and a thread handle. Inside Worker::new:

fn new(id: usize, receiver: Arc<Mutex<mpsc::Receiver<Job>>>) -> Worker {
    let thread = thread::spawn(move || loop {
        let message = receiver.lock().unwrap().recv();

        match message {
            Ok(job) => {
                job(); // Execute the closure!
            }
            Err(_) => {
                println!("Worker {id} disconnected; shutting down.");
                break;
            }
        }
    });

    Worker {
        id,
        thread: Some(thread),
    }
}

Each thread loops forever, waiting for a job via the channel. If it gets one, it runs it. If the channel closes, it breaks the loop and shuts down.

You know what this reminds me of? Those poor souls at the fast-food drive-thru window, eternally waiting for the next customer to pull up, ready to take their order until the restaurant closes (the channel shuts down). Except in our case, the orders are HTTP requests, and the food is... JSON responses? This metaphor might be breaking down.

Submitting Work

Back in main.rs, we replace:

handle_connection(stream);

with:

let pool = ThreadPool::new(4);
for stream in listener.incoming() {
    let stream = stream.unwrap();
    pool.execute(|| {
        handle_connection(stream);
    });
}

And define execute as:

pub fn execute<F>(&self, f: F)
where
    F: FnOnce() + Send + 'static,
{
    let job = Box::new(f);
    self.sender.as_ref().unwrap().send(job).unwrap();
}

This sends the job to the shared channel, where a worker picks it up.

Notice how we're using generic function parameters, type bounds, and lifetime specifications just to... send a function to another thread. Rust makes simple things complex so that complex things can be simple. It's like doing extensive paperwork to get a library card, but once you have it, you can borrow any book without further hassle.

Cleaning Up: Implementing Drop for ThreadPool

When our server exits, we don't want zombie threads. So we implement Drop:

impl Drop for ThreadPool {
    fn drop(&mut self) {
        drop(self.sender.take()); // Closes the sending side of the channel

        for worker in &mut self.workers {
            println!("Shutting down worker {}", worker.id);

            if let Some(thread) = worker.thread.take() {
                thread.join().unwrap();
            }
        }
    }
}

This cleanly shuts down each worker.

The Drop trait is Rust's version of a cleanup crew. It's like telling your party guests "Please take your belongings with you when you leave" instead of finding random shoes and jackets in your house weeks later. Memory management is just good manners.

🧱 The Final Structure of the Server

By the end of Day 4, here's what the server looks like:

Request: Parses method, path, headers, query params, body from raw bytes.
Response: Provides Response::json and Response::resolve to build HTTP responses.
ThreadPool: Handles incoming connections in parallel.
handle_connection: Contains the actual routing and logic for endpoints like /hello.

When you step back and look at it, we've essentially recreated tiny, limited versions of:

hyper (HTTP parsing)
serde_json (JSON handling, though barely)
tokio or rayon (concurrency)

All to... parse an HTTP request and return "Hello, World!" I'm not sure whether to feel proud or deeply question my life choices.

🎉 Final Thoughts

Five days ago, I started with nothing but an idea: can I build a fully working HTTP server using just the Rust standard library?

Five days ago, I also had friends, social interactions, and a healthy relationship with sunlight. I've since traded these for the satisfaction of parsing HTTP headers manually.

Here's what I ended up with:

✅ Parsed raw TCP streams into Request structs

✅ Built a structured Response system with content-type headers

✅ Implemented conditional routing (/hello) with query param parsing

✅ Added a concurrent thread pool to handle multiple connections

✅ Cleaned up threads gracefully using the Drop trait

✅ Never used a single external crate

✅ Questioned my sanity approximately 17 times

It wasn't just about learning how to write TCP servers. It was about understanding the internals that most high-level frameworks abstract away.

It's like learning how a car engine works instead of just driving the car. Will this knowledge help me get to the grocery store faster? Absolutely not. But will it make me feel superior when talking to people who just drive their cars without knowing what a carburetor is? You bet.

This server is far from production-ready, but it's clear, readable, and educational. You can easily extend it with features like:

POST form data body parsing
File upload/download
Static file serving
Logging middleware
TLS support (with crates like native-tls)
Async I/O using tokio (if leaving stdlib constraint)
A will to live (this one might be harder to implement)

But for now, I'm happy.

This journey reminded me that you don't always need more abstractions. Sometimes, starting from scratch helps you understand what abstractions are truly worth.

It also reminded me that there's a reason why web frameworks exist, and why nobody in their right mind parses HTTP manually in production. But hey, learning is fun, right?

Thank you, Rust, for making low-level work feel safe and expressive.

And thank you, dear reader, for sticking with me through this unnecessarily detailed account of my descent into HTTP parsing madness.

🔚 End of Dev Log

💡 If you read this and decide to build your own server from scratch — do it. You'll never look at actix-web or warp the same way again. You'll look at them with tears of gratitude in your eyes, whispering "thank you for existing" as you add them to your dependencies.

🛠️ Signing off — see you in the next low-level adventure! (Which, if I'm smart, will involve a lot more use of established libraries and a lot less reinventing of wheels.)

LinkedIn
Project GitHub

How to Find Build-Worthy Ideas

Priyanshu Verma — Fri, 18 Apr 2025 08:22:29 +0000

Hi again 👋

This blog is a part of the Intro – Build What You Imagine Series. Feel free to check out other parts and learn along the way.

🧠 Problem: Finding Project Ideas Isn’t Hard

Finding project ideas isn’t as difficult as most people think. You're surrounded by problems every day—from the moment you wake up to when you go to bed.

Let me give you a few personal examples:

I want a product that shows all my notifications in one place when I wake up.
A plugin that can auto-generate a to-do list and show yesterday’s journal in Obsidian.
An app where I can save my thoughts, and then ask AI to summarize how my day was.
A simple util app to use my phone as a PC mic.

These are tiny daily pain points. Some already have solutions, but they’re either filled with ads, not customizable, or need me to share personal data—which I’m not comfortable with. If the tool were open-source or self-hostable, I’d try it. But in many cases, they simply don’t exist.

So, what’s the alternative?

Build these apps yourself.

Yes, seriously. Just like I noticed these small gaps, you have them too. You’ve probably caught yourself thinking, “This app should really have this one extra feature…”

And then maybe you thought: “I can build this.”

That’s the moment you grab onto. These small ideas may not make you money, but they teach you a lot, sharpen your skills, and if you solve your own problem well—you now have something to show off with pride.

💸 I Have an Idea. Can I Make Money From It?

Great! You’ve found an idea you’re excited to build. But now you’re wondering—

Can I earn money from it?

The short answer?

You can. But don’t think about money right now.

If your first goal is money, your focus shifts away from building.

If you chase money first, you’ll likely get neither skills nor money.

Let’s be clear—building projects is an art, not just business.

I’m not saying you shouldn’t aim to monetize. But before that, build the skills. If you can solve a couple of personal problems and you’re happy using your own product, then it’s ready for the world.

Share it online. Launch it on Product Hunt or LinkedIn.

You’ll always find people who share the same problem—and if they love it, you’ll naturally find a way to monetize.

👨‍💻 Do You Really Want to Be a Developer?

If you’re a beginner, especially someone who picked computer science just for the money—there’s a hard truth:

You’ll likely struggle if you're not motivated by curiosity.

CS and development require patience, persistence, and a desire to create.

If your initial goal is only income, you’ll burn out fast.

So, what should you do?

Build for fun.

Build to learn.

Make anything:

Websites
Mobile apps
CLI tools
Games
Math animations
3D models
A unified chat app that runs in your terminal and on your phone
Your own cloud console

🌌 The sky is the limit.

Ideas are everywhere—most people just ignore them. Builders don’t.

The key is to start building and keep building. If you document your journey online, you’ll open doors: internships, jobs, freelance gigs, and more.

Build for skill first.

Money is a byproduct.

✍️ What’s Next?

By now, you’ve probably got a few ideas floating in your head. Here’s what to do next:

Write your ideas down.

Yes, physically—pen and paper. Don’t use AI yet.
Define the problem each idea solves.
Resist jumping to AI to ask how to build it. Why?

Because AI can overwhelm you and show you someone else’s way of doing it.

Your idea is unique. You’re solving a personal problem.
Avoid instant setups or templates.

You’ll end up copy-pasting without understanding the core.
Keep it simple.

Don’t overengineer. Solve just 2 small problems. Keep the scope tight and clear.

Later in this series, I’ll show you how to use AI productively during the build phase. But not now. First, learn to think, break down problems, and structure your ideas yourself.

🧾 Conclusion

The goal of this post was to help you:

Find build-worthy ideas
Get excited about building
Let go of the money-first mindset (for now)

Building something just for yourself, even if no one else uses it, is worth it.

You learn. You grow. You create.

We’ll get into execution and building in future posts.

For now, grab a notebook, look around you, and start writing your ideas.

That’s it for today.

Thanks for reading.

— Priyanshu Verma

DEV Community: Priyanshu Verma

Why I’m Shifting From TypeScript to Rust This Year

Homelabing - Local to online setup suppressing CGNAT

Homelabing interesting enough to say but why

You Want a Future in Tech? Stop Building Templates.

Why I wrote this article

What is the future of Web development

What do learn then

What is the point of building native

Can AI really Replace you

Conclusion

Self-Hosting a Password Manager on a Pi Zero 2W

Choosing the Right Tool

Step 1: Preparing the Pi

Step 2: Running Vaultwarden in Docker

Step 3: Subpath vs Subdomain

Step 4: Reverse Proxy with Caddy

Step 5: TLS and Certificates

Step 6: Remote Access with VPN

Step 7: Troubleshooting Common Issues

Step 8: Final Setup

Reflections and Lessons Learned

Conclusion

Ever wondered why Windows or Android updates are so huge? This isn’t just about code – it’s about an entire hidden world of engineering farms, power consumption, and logistics. My new article opens that black box.

The Hidden Engineering Behind Building Massive Software Images

Priyanshu Verma ・ Aug 17 '25

The Hidden Engineering Behind Building Massive Software Images

Why MindsDB is the Fastest Way to Build AI Agents Today

The Problem Statement

The Traditional Route — A Long Road

1. Backend Setup

2. LLM Integration

3. Agent Logic

4. API Layer

Enter MindsDB — Same Problem, Way Simpler

The Agent in One Command

The System Prompt (What the Agent “Knows”)

The Job That Ties It Together

🧪 Using the Agent is Just a Query

💡 Why This Blew My Mind

🧵 Final Thoughts

MindsDB Made It Easy, I Made It Hard: Building an AI-Powered Knowledge Map

First Things First: What Even Is MindsDB?

Some features that I personally loved:

But Wait, What’s KbNet?

So, what is KbNet?

Why I Chose MindsDB (and Decided to Suffer Anyway)

This Article: MindsDB Part Only

How I Used MindsDB in KbNet

Key Use Cases:

MindsDB SQL Syntax is Super Simple

My Honest Thoughts

Life Lessons

You will regret them.

Quick Links

When Life Gives You Time Off Install and Configure Neovim

Why Neovim? (And What Even Is It?)

First Encounter: A Blank Screen and an Existential Crisis

Next up: Configuring It to Make It Feel Like Home

Learning the Basics (It Feels Like a Game)

Modes

Movement (aka the Game Begins)

Keymaps I Use Now

Plugins and LSPs: Making It Actually Useful

Let’s Start Adding the Essentials

Getting Auto-Completion Working (The LSP Journey Begins)

Creating Our LSP Config

Installing Language Servers with Mason

Adding Formatting with Prettier

Let’s Bring in AI ✨ (and Some Visual Flair)

🧠 Adding GitHub Copilot

Syntax Highlighting with Treesitter

⏱️ Optional (But Cool): WakaTime for Coding Analytics

Final Touch: Flexing on Discord with Rich Presence

Step 1: Add the Plugin

Step 2: Install Required Tools

Step 3: Hook into Your Neovim Launch

Done!

Inside a Rust-Powered HTTP Server Built From Zero

Setup and Getting Started

`ThreadPool` Struct