DEV Community: Lakshit Singh

Complete Beginner's Guide to Linux Ricing

Lakshit Singh — Sun, 27 Jul 2025 04:38:25 +0000

In the Linux world, 'Ricing', refers to the process of customizing your machine, and create a custom environment for yourself. The term 'rice' originates from the old internet slang which meant 'to make it look nice' and is now majorly used for customizing a desktop environment.

The Ricing Culture, began soon after minimalist window managers like i3, or bspwm started to emerge in the early Linux days, providing users with a way to customize their entire desktop stack. Early on, this trend of customizing your desktop started to pickup and people started sharing configurations and screenshots with each other on early social platforms.

Linux is the holy grail for ricing. Linux is like a modular puzzle, it is built up of small pieces that are replaceable and customizable as per the users choice. Whereas, other operating systems feel like a brick. They offer no modularity, and you can in no way control what you do, except what they offer you. In Linux, or should I say, in some distributions of Linux, you choose exactly what puzzle pieces you need, and just the fact that offer exists is one of the biggest reasons why Linux is used.

I won't lie, I see why the other operating systems such as windows share the largest market share, its because most people do not want to deal with setting up their desktop, and then customizing it, but those that want more than just computing from their computer should definitely try out Linux.

Let me show you my configuration, and also one of the best rices I have ever seen.

Choosing A Linux Distribution

What is a Linux distribution or distro?

Linux in itself, is only the kernel, a Linux distribution however provides you with a full-fledged system built around the Linux kernel. Which generally includes a desktop environment, package managers, some core packages etc.

The choice of your Linux distribution can severely affect the level of customization you can achieve with your rice, while some systems are built to give people an easy way to experience some are built to provide you the choice for every component of the distribution. Ultimately, the decision lies in how much you want to deal with the customization of your operating system.

My go-to distro has become CachyOS, built on Arch Linux it provides a very high level of customization while also having the core packages. This lets me experience all the benefits without the risks of messing something up. Still, for anyone trying to mess with Linux on a deeper level, I would recommend installing Arch Linux first, since you will gain a deeper understanding of Linux itself and then you can move to whatever catches your eye.

Factors to consider when picking a distro:

Ease of Use
Personal Experience level
Package Managers
Community
Customization (If you're looking to rice)

Some popular choices:

Ubuntu/Debian: Ubuntu/Debian based distro's are often easy to use, are meant for beginners and offer a large user base. The downsides though are they are less customizable than its peers, and also has an average package manager. If this is your first Linux experience go for Ubuntu/Debian based.
Fedora/RHEL: Similar to Ubuntu, Fedora is meant for beginners and people who are not interested in customizing much. It is a bit better than Ubuntu at customization, offering several spinoff's with different desktop environments etc, but the package manager decent at best.
Arch-based(Manjaro, CachyOS): Arch-based distro's are built on top of Arch Linux, they provide a moderate ease of use, have a large community, since they adopt most of Arch's features and has one of the best package managers. They are moderately configurable, these are my recommendation for moderately experienced users.
Arch/Gentoo/NixOS: These distro's are meant for experienced users who want full control of their system, they too have a decent user base and community, and are often better than their counterparts for most stuff. Each of them have a unique approach towards an OS and I would highly recommend trying them out (I have also yet to try out some, but I am working my way towards them).

It is important to remember that there is no universal best distro - the right choice depends on youImage descriptionr skills, motivations, and willingness to tinker.

Desktop Environments vs. Window Managers vs. Desktop Shells

Desktop Environments: DE are full integrated graphical interfaces for your desktop involving layout, window management, File Managers, Settings etc. They provide you with full usability out-of-the-box. Some common DEs are GNOME or KDE Plasma.

Window Managers: WMs manage the placement, interaction and look of windows in an environment, they do not provide you with a complete system with everything out-of-the-box and do require some configuration to actually able to utilize them properly.

Desktop Shells: Desktop Shells are used to create custom UI layouts for your DE or WM, they provide ways to create and manage components and also abstractions for interacting with some system tools.

Desktop Environments offer ease-of-use while sacrificing customization and for ricing people generally move toward WM for the window management and Desktop Shells to enhance the look of the system.
There are multiple major types of WMs,

Floating/Stacking WM: Floating WMs allow the user to place and move around windows anywhere, similar to the Windows / Mac experience, the windows are allowed to be placed anywhere in the screen and are often placed in layers, where the focused window takes the top layer.
Tiling WM: Tiling WM create defined arrangement of windows so that a user can utilize the screen space more efficiently. There exists multiple types of Tiling WM that take unique approach to handling windows, for example, Niri - The Scrollable Tiling WM, or Hyprland - A dynamic tiling manager with multiple layouts.

There are a lot of types of WMs built for different people and it is essential to find what your needs are. For example, I prefer a scrollable WM (Niri) that lets me have windows on a scrollable strip, allowing me to efficiently reach any window while also ensuring it can take the full screen space. Another interesting WM is River, which uses a tag based system allowing windows to belong to multiple workspace at the same time.

Desktop shells, however, are pretty similar. The only thing that differentiates them is how they provide the API. For example,
Eww - provides a custom language, AGS - that lets you create components using TSX and TS, or Waybar - providing a collection of components and some customization. The decision relies on what you want to configure, a desktop shell such as AGS lets you create any and everything, Waybar is limited to a panel/bar whereas Eww also provides customization but has a learning curve for its languages.

My personal preference is AGS, since it allows me to create any and everything using TSX while also providing event-driven abstractions for stuff like communication with Hyprland, River, Pipewire (audio) etc.

Linux Shells and Terminal Emulators

Linux shells are special programs that provide a way to interact with an OS through a Command Line Interface (CLI). They allow a user to interact and talk with the OS using a set of text commands. Terminal Emulators, on the other hand are Graphical User Interfaces(GUI) sessions to run your shells.
Common Shells:

Bash: Bash is the most widely used shell and is default on most distro's.
Zsh: Zsh is known for its versatility by using plugin system to customize it (oh-my-zsh).
Fish: fish is considered a more user-friendly shell with some features of zsh such as auto-complete, suggestions etc.

As you go through your ricing journey, and just Linux in general, you will often interact with the terminal, be that for launching apps, configuring apps, scripting, debugging etc.

The basic utility of a shell is constant for all, the real core difference is apparent in a development environment where people might spend more time in the terminal than in any app. There, I suggest exploring more into the shell that fits you. For me, it was Zsh, providing extensive config through plugins etc I could change the way it looked, how it handled stuff etc.

Common Terminal Emulators:

Alacritty
Kitty
WezTerm
Ghostty

There are a lot of terminal emulators, and the only main difference they provide is how fast they are and what stylings they support. I have not delved deep into Terminal Emulators much, but I have been using Ghostty for quite some time. It is built in Zig, so its fast, and also provides and extensive configuration.

Power User Tweaks

Here are some tweaks to become a power user in Linux,

Custom Key-binds/Shortcuts: The ability to customize your key-binds are seldom appreciated by new ricers, for example, the simple fact that I can bind the opening of my most used apps to a key, makes it so that I don't have to require opening an app. Also, being in Niri, I can move windows, work-spaces, monitors all from a combination of Win, Shift, Ctrl and Arrow keys, making me almost never use my mouse. This is just the surface level, you can do much more, you can execute scripts, say to connect to Bluetooth, disconnect WiFi etc. There are endless possibilities.
Custom Scripts: Custom scripts are versatile in itself, from which you can manage anything that concerns your machine, auto-start apps, changing themes and wallpapers etc. But when paired with keybinds or apps like rofi/wofi they can really change your workflow.
Compositor Tweaks: I've never been a fan of compositor tweaks because they offer almost no performance boost, but to those who like eye-candy, this can be a game changer, adding blur, see-through windows etc can really enhance the look of your desktop.
Notification: Customizing your notifications can really build together your workflow, you can create a notification that systems that integrates well with your workflow/theme providing a refined look.

These tweaks are often secondary, only when a user is almost done with his main ricing, and is comfortable with Linux should he try to indulge in these, since they require some basic knowledge.

Tips From My Experience

Start Small: Do not try to create or expect to create a full rice in one sitting, ricing takes time, start with small components and then grow from there, integrating them with each other as required.
Color Scheme: It is better to create and stick to a color scheme or a palette at the start of your rice. Sit and find a wallpaper you like, either make the palette based on the wallpaper or convert the wallpaper to fit the scheme. With this, you will have an easier time figuring out the overall layout of your rice, and will also help it look cleaner.
Experiment: If you do not have a strict layout for a component, experiment with it, make multiple iterations and find out what fits your rice more. Yes, it will take time, but it will be a lot better than a crude implementation.
Documentation: Configuration is a key part of Linux Ricing, and thus almost all applications have a config file and documentation that tells you how to correctly interact with it. Do not try to skip over the documentation, you may find some hidden gems that can change your whole workflow.
Enjoy: Enjoy the process of ricing, ricing is meant for you, and you should not be influenced if people don't like your rice, what matters is you should.

Sharing & Managing Dotfiles

Dotfiles are all the config files for your apps, since they generally start with '.' and are kept in the '.config/' folder, they are referred to as dotfiles.

Managing your dotfiles is really important, as you start to dive deep into your rice, the amount of dotfiles will only increase, and hence dotfile management and sharing has become a major part of ricing. They offer multiple benefits, having a Version Control System like git, you can rollback to previous configs, or make porting to a new system highly efficient.
Generally the dotfiles are kept on GitHub or other similar hosting platforms. Although some dotfiles specific apps such as yadm or chezmoi exist, and are great, git provides more control over your file management.
A minimal git setup is,

Select folders/files to track, for this example we will take the .bashrc file.
Create a dotfiles folder where all your config will reside

mkdir ~/dotfiles
cd ~/dotfiles

Move the file to your folder and create a symlink

mv ~/.bashrc ~/dotfiles/bashrc
ln -s ~/dotfiles/bashrc ~/.bashrc

Initialize Git repository

git init
git add .
git commit -m "Initial commit of my dotfiles"

Back up to a remote repository

git remote add origin git@github.com:yourusername/dotfiles.git
git push -u origin master

Track and Update regularly

git add -A
git commit -m "Update zshrc and i3 config"
git push

Conclusion

Ricing is not just for eye-candy, it transforms your Linux workflow, where every part of your desktop/computer is picked by you and for you. It not only enhances your experience, but it also gives you a deeper insight into what your desktop is actually composed of. Some might think it unnecessary to know how your desktop works, but just gaining a basic understanding can drastically change how you handle your desktop, be that during debugging or everyday use.

Ricing is much more about the process than the end result, for some ricing never ends, there is always something more to tweak, another customization to add.

At the end, its all subjective, Ricing can be different, for me it can be a clean setup that allows me to work efficiently; for some it may be visual-flair or the process of creating something unique from scratch.
No rice is better or worse - what matters is that your setup works for you and reflects your own journey.

From Chaos to Clarity: System Design with the Right Tools

Lakshit Singh — Sat, 19 Jul 2025 12:42:10 +0000

Recently I have started to adopt the

'right tool for the job' mentality

when building my projects. The biggest impact it has is on the System Design aspect of the project.
Where I used to spend hours trying to juggle doing everything with one tool or language, now I spend about half the time researching the right tool for each part of the system and save myself a lot of tedious work.

Once you get into that mentality, a fundamental change happens in the project. Before, it was easy to setup the project and start coding it. But the bigger the project became, the more the drawbacks started to show, it became harder and harder to continue. Whereas, now, the project set up is harder, since you need to research the system design and architecture and set everything up, however, coding has become easier and more fun.

This shift has changed me for the better. Because I enjoy both the research and the system design, I find myself having much more passion and fun with my projects.

What is System Design?

Before we dive into how this change has affected me, and how to change for the better yourself, we should know what System Design is.

System Design is the beautiful and mysterious practice of

creating efficient and scalable systems

What does that mean?
It means creating and architecting software systems that can scale well, handling growth seamlessly - for example, scalability might mean growing an API from 1000 req/s to 100000 req/s, or growing an app to handle 1000 users instead of 100.
The meaning of scalability is open-ended, but it usually centers around performance, reliability and adaptability.

My philosophy of 'right tool for the job' drives this by breaking down a complex project into smaller parts, and then finding and researching about the best tool for that specific use case.
This also fits really well with the Micro-Service architecture, which is known for its scalability and is well taken within the software world.
This can involve dividing a project into microservices, or at least into smaller, more manageable components—even if it's not a full microservices architecture.

This approach transforms a complex project’s initial chaos into clarity.

Breaking free from the Single-Tool Trap

In my early days of building projects, I - like many beginners - Often shaped my project around whatever tool I was using. Though it is fine when learning or building small projects, but the rookies tend to bring this ideology with them whenever they make a more complex project.

Its not just a rookie mistake - even some businesses fall into this trap. But you can't entirely blame them, no one pays System Design enough attention; people only care about System Design as a way to crack interviews and jobs at various companies but its so much more than that. System Design can convert a good project into a great one.

To break free from the Single-Tool trap is too easy, all you have to do is explore. Explore other projects, other languages, other tools. Even if you don’t master every new tool, simply knowing what’s out there can make all the difference.

Case Study: My Journey in Architecting Complex Systems

In my recent projects, I’ve ventured into more complex territory, inspired by the gaps I noticed in my own developer experience. And following this, some complex project ideas have sprung in my mind. 2 in particular where I really let my inner architect come through.

I have been a backend developer at heart for quite a long time, and to no surprise, Its the field I'm the most comfortable in. Due to that, I have come to always try to split my projects into smaller parts, and oftentimes, the most variable is the Database.
Therefore, in my recent projects, I tend to split my databases across multiple tools. While I always use SQL as my main database, it comes with its downsides.

One such case I ran into was when I was building a post platform similar to reddit in some sense. There I encountered this drawback of SQL, recursive comments. When trying to replicate the recursive comment system of reddit, I found myself very confused and flustered by how such a system would work in SQL. What I thought of, with the help of the lovely people of StackOverflow was that I could create something similar with a table in the form of:

comment_id	parent_id	comment	on_post
1	1	"Hello World"	true

But this is a very crude implementation, in which parent_id is vague, it could either be the post_id or the comment_id of the parent comment, based on the on_post variable.
Also querying this would be complex and slow.

Thus I set out to find an alternative for this use case and I found, 'JSON' or I should say, MongoDB. The NoSQL database allowed me to store all the comments as a JSON file, with none of the on_post jargon and also have fast reads since I'm reading it all at once, no multiple queries.
Another similar use-case for MongoDB which I found is chat messages, SQL apparently is bad at handling large amount of writes, and although Cassandra, is better at that, the lack of a well known go driver made me choose Mongo.

I must mention that System Design not just contributes towards a more scalable project, but it also improves developer experience. In my chat app as mentioned previously, the fact that I can split up my backend code into parts such as WebSocket, REST and Auth etc, means that me, and other contributing developers have an easier time working together. Less merge conflicts is a gift for all.

How to Find the Right Tool

To find the right tool you must first find out what the job is. And thus the first step in designing a good system architecture is to first make a mental model of your project and to break it down into what you want to do. Only when you have carefully considered the scope of the project can you start with identifying the best tool.

Next comes research. If you’re new to the topic, start by looking for real world systems similar to what you want to build. Take a look at what tools they use, why they chose them, and whether those choices apply to your case. You will rarely find an exact copy of your use case and thus you will always have to consider the drawbacks and advantages.

AI can be invaluable for researching, you can give context to AI and also provide a overview of your knowledge, and let it provide you with the existing projects and what Architecture they use. Then for any thing that doesn't make sense, or any tool you haven't dealt with, you can get detailed information on its advantages and drawbacks.
Beware though, do not rely on the AI's System Design, always think for yourself if the tool fits you case. Have a conversation with the AI, ask it why, and why not.

How Microservices Amplify My Philosophy

My `right tool for the job' philosophy really shines in a microservices architecture. Generally a microservices architecture breaks a project into parts such as - Authentication, REST API, GraphQL etc and uses a message broker such as Kafka to send and receive messages to or from a service.
Each microservice has its own database and other components, with their personal design principles.

"But doesn't this increase overhead, or even increase complexity since there are multiple instances?"

It does, but its a fair trade. We do get more overhead, and there exists plenty of tools to manage it, but its a trade worth making for more:-

Scalability: Each service is isolated, and on its own VM, therefore they are not influenced, and can be scaled better.
Reliability: Breaking one part of the architecture doesn't make the whole app break.
Development: The most important of all is that it can make development clean, specially in a multi-team environment.

If we look at the architecture as a whole, yes, it will feel a lot more complex, since there are multiple services, interacting with each other etc. But when you look into each service itself, they are a lot more simplified, and this is what we want. A developer can create or update a service with a certain level of Abstraction from the other services.

Thus, a microservice architecture allows or even expands on my 'right tool for the job' philosophy, allowing a clean isolation of each service, and therefore less constraints when finding the right tool.

The Fun in System Design

While experimenting with System Design and building one for your app the I get to do two of my favorite things, and that is research and learn more about other tools. I have fun when I sit and research for hours how other products work, or how their implementation might not be for me.

My favorite thing though, is that I get to talk to people and get their opinions and give mine. To discuss about something I am passionate about with others who are just as passionate is like a cherry on top.

Another thing to note is that its not just the designing that is fun, since I get create cleaner services, and divide my code. I have a lot more fun coding as well, to actually create what I thought in my head. Sometimes it's boring, like setting up tailwind in a project, or eslint etc. But overall throughout the project I have a much better time.

My Lessons From the 'Make-It-Fit' Trap

I have spent a lot of time being deluded by the 'Make-It-Fit' mentality, but I think of it as a learning experience. Only when I spent my time doing that did I realize its drawback. Some may think of it as time wasted, but to me, no learning experience is a waste of time. And you learn from your failures.

What actually were the lessons?

Rigidity of Tools: Tools are often created for a use case in mind, If you try to expand on that and stretch them past their limits, you will realize it really quickly why that was a bad case. It will stop being a straight process. Yes, programming has its hurdles, but it also has its solutions. When you take a tool too far, It quickly devolves into constant problem-solving rather than productive building, and you have to replace the tool or stop relying on it.
Readibility: Most of the times, you end up having to create a workarounds to make it work. It may work, and yes it may even be less lines of code than using a different tool, but is it really the best way?

As you start to upgrade towards the 'right tool for the job' you will start to realize the small things as well, and I guarantee you will start to have more fun when programming.

Conclusion

There exists no 'Master Tool', something that will satisfy your use case perfectly for the whole application. You will need to compromise for most of the time, and you can reduce that compromise to almost nothing adopting the 'right tool for the job' mentality.

I could have easily given a list of tools I found, and for what use case they excelled at. But the realization is not in reading someone else's thoughts, Its by experimenting yourself and creating your own opinions. You may find out that you may prefer the Single-Tool approach, but Its you who must decide this.

All I can say is to try it out and experience all System Design and Architecture has to offer, don't just treat it as a way of cracking interviews.

Ultimately, system design is about personal growth, continual learning, and discovering what works for you. Enjoy the process and make it your own.

SourcewareLab: My Adventure of Learning and Laughter

Lakshit Singh — Sat, 12 Jul 2025 10:52:47 +0000

SourcewareLab is a growing community of people from all over the world, and differing experience levels. Their quote,

"Learn by doing."

captures all that they stand for.

SourcewareLab is a place where you can connect with peers, ask advice from experienced individuals, and make yourself a better developer. It is open to people from all experience levels, be it from beginner to senior.

My Learning Journey

I found SourcewareLab while browsing Reddit about a year ago.
When I first joined, I was hesitant to interact or collaborate with people, being introverted I didn't like talking anyways and not being confident in my English was just another insecurity that ate at me. I was afraid to mess up, afraid to embarrass myself.

Another thing was that I did not consider myself a good programmer back then. I considered myself inferior to the other people, who were actively engaging with the community, making PR's. Having only done small projects, and seeing people contribute, I felt incompetent.

Only when I actually just pushed through my insecurities and talked to the people did I realize that it was not the fact that I was incompetent, I was just a little less experienced than others. The cherry on top was the fact that people didn't laugh or dislike me. They genuinely wanted to help me.

After 6 months of actively engaging, and making contributions, I got the opportunity to manage and administrate the community and some projects, and I swore to myself to give back the same love I'd received. To not let anyone feel insecure, to make everyone a better programmer.

SourcewareLab's Unique Vibe

As I had mentioned before, SourcewareLab was created to help people from all experience levels, find like-minded people to talk to, and to make projects with.

Its fun to talk to people that share your same hate for JavaScript after an 8 hour coding period, or people that are there to cheer you on for your solo projects.
But, what really intrigued me, was that I now have much more fun just building projects with people.

Its different from solo development, when you interact with people, you look at other people's code, understand existing architectures, communicate and design the architectures or algorithms. I have found myself making better projects, and writing better code, just from talking with people, taking their suggestions and also discussing how certain aspects should work.

I almost always get some feedback before starting my projects, their scope, how they should work etc. This has helped me understand several different points of views and make better projects as a result of that.

Why Should You Join?

Joining and interacting in any community provides you with multiple benefits, such as networking, skill building etc

But what really helped me, and something I am really grateful for, is the fact that I have people to talk to about my passion. I had very few people in my life who I could talk to about programming.
Also the fact that I can now find people to make projects with easily, this has really helped me understand more about how group work is actually done, even in a professional environment.

SourcewareLab transformed my coding journey. From overcoming insecurities to building projects with global peers, it’s a place to grow and have fun. Join our vibrant crew on SourcewareLab Discord to code, connect, and create—start your adventure today!

[Boost]

Lakshit Singh — Sat, 05 Jul 2025 05:12:24 +0000

Lakshit Singh

Jul 5 '25

Learning 10 Languages: My Polyglot Journey

#learning #programming #coding #softwaredevelopment

Comments 3

8 min read

Learning 10 Languages: My Polyglot Journey

Lakshit Singh — Sat, 05 Jul 2025 05:11:46 +0000

The first thing an individual learns on their Programming Journey, is a language. Languages are a way for us programmers to communicate with the CPU and execute tasks, But languages are way more than that, they hold a much larger part in the bigger picture.

Personally, I have always felt a deep passion towards languages, and what they allow me to do, and thus, I have been always been learning and experimenting with languages, granting me a great sense of Adaptability. The greater purpose they served was that they allowed me to understand that languages, at the end, are tools.

You do not do the perfect job for the tool, but instead use the perfect tool for the job.

Why I Chose To Learn Multiple Languages

Although my journey to learning new languages started off as a way to better equip myself for the job market in my early days, it grew to something much more deeper. When I started to learn JavaScript as my second language, it was a different experience altogether from python, my first language.
JavaScript, although similar to python in dynamics, was something entirely new. Since it was made for the browser to interact with HTML and the DOM, the new functionalities it held, was the largest factor in me deciding to always keep learning new languages.

The main 'wow' effect I had was with C/C++. It was something entirely different, getting into the basics of OOP (I did not do much OOP in Python at first.), and also the introduction to my favorite topic of CS, Data Structures.

This gave me the realization that I can learn a lot from languages, especially languages that are not at all similar, or that have different purposes altogether.

Languages I Explored and Why

My languages in chronological order are:

Python: Was the language that ignited the passion and love for programming that I now adore. It remains as a nostalgic experience for me, but I use it little to nowhere.

JavaScript: Remains one of my most used languages still, but oftentimes, its not because its best for the job, but because people I want to contribute with, oftentimes don't know the best tool for the job. The only problem I have with JavaScript, aside from the fact that it is used everywhere, is that it does not have a type system, and although Typescript exists, "A leopard cant change its spots".

C++: Laid my fundamental foundation, this along with C, was my learning language as I like to call it. I do not create applications in C++ much, but whenever I want to learn a new low-level aspect, C++ or C is the go-to.

C: As I mentioned in C++, C was the go-to language for learning new concepts, especially for non-OOP related concepts. Since I get to make stuff from, pretty much scratch and understand better.

Go: Is the perfect tool for me. Since I mostly work with Backend, cli's, or tui's, Go is the perfect mixture of minimalism and low-level control, allowing direct access to syscall's etc. without the need of porting libraries from another language. *cough* Python *cough*.

Typescript: Is my second most used language, it solves the issue I had with JavaScript, which is it being dynamic-typed instead of static-typed, and perfect for large people working on a project. But, I still abhor using it for Backend development, since it does not align with my idea of using the perfect tool for the job.

Bash: My third most used language. Since I have started learning a little about DevOps, I have begun to write more and more bash files, may that be for configurations, ease of use or deployment.

Rust: Is something that blew my mind, it operates on a different paradigm than any other language I have learnt, to put it simply, its strict, intriguing and fast. I can definitely see the use-case of Rust, but for me, it sacrifices Developer Experience for a better and safer end product. I have yet to utilize Rust in a large project, and I am almost certain that my opinion will change, but I cannot guarantee whether it will be for the better or worse.

C#: Although I learnt it mainly for my internship, and I cant actually decipher if it was the internship experience, or the language, but, since I began using C# I've had multiple experiences with System Design patterns, that I did not previously. This has helped me in not only creating better software but also to understand it.

Zig: Similar to Rust, was something I learnt simply because it felt different, and... it was. In my opinion, Zig and Rust are similar, not in basis of how they work, or what they do, but in the ideology of providing a better alternative to low-level programming. Where Rust solves it through strict compilation errors, Zig solves it by giving the freedom into the developers hands'.

These thoughts, may appear opinionated to some, but I am proud of the fact that I created these opinions myself from my experience, they were not seeded into me.

How Languages Shape a Project

As one can guess, Languages can affect the performance of a program (Rust being blazingly fast, vs Python), Developer Experience (Python being easier to write, vs Rust) and Maintainability (Typescript's type system, vs JavaScript's).

But there are much more lesser known advantages, that are:

Ecosystem: A languages' ecosystem can severely affect how it works in a development environment, the fact that I would not have to write recurring parts of an application. For me though, more so than that, what matters is that I do not have to be overly reliant on dependencies to make a good project.

System Design: The design and architecture of a system is highly reliant on the language itself, we all know of the functional, procedural and object oriented languages, and as guessed they can affect how the program is structured, such as the abstract classes and virtual functions in object-oriented, the Model-View-Controller method in procedural (not exclusive), and pure functions or separation of concern in functional languages. Building upon this, a languages internal features, such as goroutines and channels in Go, also make it more distinct from other languages.

Languages I Moved Away From

Throughout my journey, there are languages that I no longer use in my daily life, some of these are:

C/C++: Although C/C++ are one of the greatest languages made, and shaped the way for modern language, in my opinion, age has caught up to them. C/C++ are still relevant, and I use them whenever there's a task that requires learning and working closely with systems, the reason I do not make app's in it tho, is that firstly, I prefer a procedural system over an object-oriented or functional system, and secondly, the current build system is a complex (I mean cmake etc) to the modern counterparts, and hence for me, it has become obsolete for anything other than learning stuff.

C#: I have spent a lot of time developing in C#, whether that be a side project or on my internship, the reason I have decided to not pursue it is because it is tied to Microsoft, you cannot access the full features without using Visual Studio (Windows locked). I am a person that likes my freedom, hence using Linux full-time (I use arch btw!), making other counterparts often overshadow C#.

Python: In my opinion, python is a great language, being easy to use even for beginners and also having fast libraries. The reason I left behind python is because, the more you write python the slower a program becomes. Python is heavily reliant on 3rd party libraries written in C or C++ for being able to compare to modern languages. More so a personal reason, is that I often don't like to rely on libraries at all, since they are dependencies.

JavaScript: Since discovering Typescript and utilizing it more and more, I now almost never resort to JavaScript for any task I have, I tend to use the better more type-safe alternative, Typescript.

The Advantages and Challenges

Being a polyglot has various advantages, some of them being

Versatility: By understanding, and using a lot of languages, I am able to understand and read properly most of the code I'm shown. Specially large projects with several sections, this makes it easy to navigate and understand multiple parts of a project and how they communicate with each other

Adaptability: By learning such complex and diverse systems, I believe to have gained the skill to be able to easily understand how some architectures or systems may work.

Community Engagement: Since I have learnt a lot of languages and systems, I am able to easily assimilate myself in a large number of communities and talks, finding common grounds and sharing opinions.

But like to any power, it also has its disadvantages, which are

Cognitive Overload: It oftentimes is hard to make projects or write code in new languages or my less used languages, since I keep repeating syntax or features of the one I used previously.

Context Switching: When switching between languages, such as the backend or frontend, it becomes hard to write code, especially more so in languages with a different syntax structures.

High Standards: By understanding the good and the bad parts of most languages I use, I have found myself sometimes wishing for a 'perfect' language, that has all the good features of all and none of the bad stuff. This also makes it hard to keep at new languages, that may do things differently, something that I think to be worse than other languages.

My Go-To Stack Today

By being a polyglot, and having accepted the "right tool for the job" mentality, my tech stack depends highly on the nature of the project. To give a rough Idea though,

Backend: I oftentimes find myself going for either Go, or Typescript. I use Go more personally since it is the superior choice, but Typescript is more widely recognized and thus is my choice when working with people.''

Frontend: I mean, is this even a question? What would you use for frontend if not JavaScript. As for UI Frameworks, I have worked with all major frameworks except Vuejs, but oftentimes I try to utilize Svelte.

Scripting: Similar to frontend, this is not even a debate, nothing comes close to bash for scripting purposes.

CLI's or TUI's: Normally, I would use Go and leverage the standard flags library or the Cobra library for CLI. And the bubbletea library and the charm.sh collection for TUI's. But I am interested in trying out some CLI's in Rust or Zig.

Systems Development: have not delved much in systems development, and have only recently started learning its basics, but I have plans to use either Rust or Zig for it. More so Zig because of the development experience and the freedom.

My Advice on Learning Languages

My advice heavily relies on at what stage an individual is, for a beginner, there is no better place than a course, or a series of videos to learn a language. They explain thoroughly from the most basic to the most complex parts.

For an experience individual though, they give too much information, since most courses explain from absolute basics, I myself oftentimes skipped multiple sections on syntax etc that were of no use to me. And for these I prefer the docs, since they go into much more detail, and also I can skip whatever parts necessary easily.

There is a clear plan I follow for the road to actually mastering a language after learning its features and syntax.

One thing to keep in mind is that the projects should always align with the usability of the language. Do not use Go for the frontend, and Javascript for Systems etc.

Self-Hosting from Scratch: My Journey

Lakshit Singh — Fri, 27 Jun 2025 08:13:54 +0000

Choosing The Pieces: Getting The Machine

Since the dawn of my Computer Science journey, I have wanted a server, something that would separate me from all those hosting platforms, and their limitations. Something I could call my own.
As I went along building projects, the need for a server only increased, I had grown from having 1-2 projects that required hosting to more than 4-5. And that was when the limitations of these hosting platforms became apparent.

I didn't just want to buy a VPS service, I wanted to go further, understand how it works. How the projects that I build are served to the world. What these Hosting Platforms do behind the scene. And I was not disappointed.

The Resource Revelation

Initially, when I was shocked with how little resources an app may require, for example, I found that a 6 core CPU with 32GB RAM and decent storage would be considered top of the line. Like, people host sites on Raspberry Pi's, a PC is a huge jump compared to that.
Another thing with server's is that they want resources from a very specific bracket, server's are most affected by CPU and RAM, everything else matters less.

Along with this specified spec-set, I also wanted to future-proof my server, so 10 years down the line, I wont be stuck with some dumb choices I made now. That is why I chose to go with the AM4 Platform, since AMD had announced support for a few more years, and Intel being on the down recently.

Hunting for Parts

With this in mind, I went to online stores, To Nehru Place (Biggest Tech Market in Asia) surfing through tens of shops to understand my options and getting advice from the shopkeepers. Finally, My exact spec sheet came to be:-

CPU: AMD Ryzen 5 3400G - 4 cores
RAM: 16GB DDR4 3200MHz
MOBO: Gigabyte A520MK v2
DISK: 300GB HDD

With the server finally built, It was time to dive into the world of Virtual Machines.

What is a VM? Understanding Virtual Machines

Before I actually explored how Virtual Machines worked, they were just a way to have another OS on top of my OS. While that is the crux of what a VM is, it is so much more than that.

Virtualization and Hypervisors

Like I said before, a VM allows an isolated OS to work on a host machine, the keyword being isolated, this implied that on one machine I could have 10-20 (or more) Virtual Machines (if the hardware allows it) and they would never affect each other, what is going on inside one VM is completely isolated from the processes from another.

This meant that instead of what I thought a server would be (A computer running tens of processes). I could isolate each of my work from each other, exactly what Docker does, but on a larger level.

Hypervisors were something even more foreign and fascinating to me, in a nutshell, Hypervisors manage the resources to each Virtual Machine, Like how much of the host machine's resource a Virtual Machine can have.

What is a Virtual Environment? Why Proxmox?

From my understanding, a Virtual Environment is a generic term for an isolated system, its an expansion on VM's. A Virtual Environment can either be a :

Virtual Machine - A full OS with its own kernel, like a real computer.
Container - A partial OS that shares the host's kernel.

And this is the crux of self-hosting.

Proxmox, is different from Virtual Environments, It provides an interface to interact with your Host machine, and also manage multiple Virtual Environments. One of the things I love about Proxmox, is that it provides a Web App to interact with your machine, that includes, this makes sure that I have to almost never attach a monitor to my server to interact with it.

Setting Up the VM

After understanding how VM's and Proxmox worked, It was finally time to boot up the server and install Proxmox.

Installing Proxmox

To people who have installed Linux on their machines before, this process like for any other OS.

You obtain an ISO
Etch it into a USB
Plug it in the PC
Get into the BIOS to boot from USB

And Voila! You just have to follow the instructions and you are done.

Although Proxmox was a little more complex than an Ubuntu installation, but it was nothing an Arch Linux user like me couldn't handle. (I use arch btw!).

Setting up a VM

Once the Web GUI was up and running, Creating a VM was pretty easy, just upload the ISO to the Web Interface, and choose that ISO when creating and that's it.

I went with Ubuntu Server, although every fiber of my being wanted to go Arch, or something Arch-based, I just didn't want to mess something up, since I wont be able to access the server and only have remote access through the web.

SSH + Networking

While I was setting up SSH, for the VM, I was confused:

"why is my Proxmox IP different from my VM IP?"
"and more so, both are different from my IP that ifconfig.me shows!"

That was when I learnt the important distinction between the Public IP and Local IP.
Public IP is what identifies your router or your LAN to other users on the internet, whereas Local IP is the address of each of your devices connected to your LAN, which is your WiFi. It is to locate what devices are connected to a network.

To my surprise, a Proxmox VM acts as a separate machine, and doesn't just use the same IP as the Proxmox, while it makes sense this would be the way it worked, I just never realized it.

This will allow me to better manage all my VM's, being able to SSH into each one, and not having to traverse the tree to access them.

My Hosting Architecture

My goal for my applications was to have them isolated, so something like nvm wont bother me when I start adding more stuff. The best option was to use Docker containers and of course, Nginx, to actually route requests to the specific containers.

What is Nginx?

Nginx is a web-server and reverse-proxy agent. In simpler terms, it routes the requests anyone makes to a specific port etc.
The flow is:

Nginx gets request
It compares to the rules I write
Sends the request to correct app/port
Returns the response back to the user

This is also called reverse proxy.

Currently my nginx configuration only has my main domain, when I add more projects, I plan to divide them into subdomains, that would make it more complex than it is now.

Since I had a domain from cloudflare, it already provided a proxy and SSL cert, so I luckily didn't have to configure that.

Docker Compose

For my applications, I went with Docker containers, since they ease the process of managing different applications, having isolated environments. Also with Docker, I could create github workflows (more in coming sections) that would save me a lot of work on each update.

With Docker Compose, I could simply have a compose consisting of an nginx image and all my containers, and utilizing Dockers fantastic networking system, manage all my servers from just one compose.yml.

services:
  nginx:
    image: nginx:latest
    container_name: nginx
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/conf:/etc/nginx/conf.d  # Nginx site configs
      - ./nginx/certs:/etc/ssl          # SSL certs if needed
      - ./nginx/logs:/var/log/nginx     # Optional logs
    depends_on:
      - app1
      - app2
    networks:
      - webnet

  app1:
    image: my-app1-image
    container_name: app1
    ports:
      - "3000:3000"  # optional, for dev/testing
    networks:
      - webnet

  app2:
    image: my-app2-image
    container_name: app2
    networks:
      - webnet

networks:
  webnet:
    driver: bridge

This would mean that adding a new service is as simple is creating a new entry in compose.yml, and uploading the image to DockerHub.

CI/CD & Github Actions

A CI/CD, Continuous Integration & Continuous Deployment, as the name suggests, is a process that would update my deployments whenever I push a change.

When I was researching about this, I got to know about Github Actions, and how it worked. And I was... impressed to say the least, Once I had the workflow working properly, I didn't have to do anything whenever a change was pushed. The Action would:

Build the Docker image
Push the Docker image to DockerHub
SSH into my server
Pull the Docker image
Restart my Docker Compose

This eliminated the need for me to do anything at all.

The Setup Begins: Problems Galore

Router Problems

When I did setup all this, I just expected it to work, but this was far from what I imagined, and that was when I realized that I had to configure my Router too.

My Router is my gateway to the internet, but it also serves as a protection from the internet. Any request that would come to my Public IP would have to go through my Router.

And That is the reason I had to configure my router, and allow Port Forwarding, which tells my router to forward any request coming from 80 (HTTP Port) or 443(HTTPS Port) to my server, using the local IP.

The problem? Well, my Router did not allow me to forward Port 80 or 443. Whenever I would, it would say that Port is already in use. The only thing I could find was that maybe the router had a Gateway interface for remote usage as well. And no way to disable that.

ISP Problems

Well lucky for me, I had an old router lying around that I could use for now. And to my surprise, It allowed me to port forward!

"The problem is solved! Right?"
No

If it wasn't the router, It was the ISP. For some reason, I could not access my port remotely, but if I did with local IP, it would perfectly. After wracking around trying to figure it out, I finally settled on the fact that my ISP is just blocking all requests at my ports.

Through some research and help, I found that cloudflare tunnels could help solve my problem. And after configuring it, I could finally access my site remotely.

The Silly Mistake That Cost Hours

For some context, the site I was trying to serve was my Portfolio website, in svelte. And svelte has 2 ways you could build it, having static html pages. Or an SPA(Single Page Application).

While I was trying it out, I chose the static method that seemed faster at that time, as I am not well versed in how building frontend applications work. But that was a bad choice.

After I tried that, and then learned more, I wanted to switch to the SPA (since it is smoother to traverse).

My error? In my compose.yml

pf:
    build: ./pf
    container_name: pf
    volumes:
      - pf-static:/app/build
    expose:
      - "5173"
    networks:
      - web
    environment:
      VITE_MAILER_URI: http://mailer:8888
      PORT: 5173

Notice anything?

- pf-static:/app/build
Yeah, I kept overwriting the build directory.

This was such a pain to solve, I kept trying to fix things, since I thought the error was in the application itself not building.
I even resorted to cloning the repository and building it locally!

Finally Online! Whats Next?

The feeling when I finally got it working was so exciting! I was jumping out of my chair after hours and hours of configuring. It was one of my most proud moments. I felt accomplished.

Whats Running?

Currently I have only my Portfolio and a Mailer API (That sends a mail to me). Which you can check it out here.Its still in development, only works on desktop for now.

I also have a local mailer API that sends email to me with various details. But that is not accessible from the public url.

Whats Planned?

I have a lot of aspirations and expectations from the server:

Gitea (Personal Git Service)
Other Projects
Adblocker
VPN
Grafana & Prometheus (Monitoring)