DEV Community: Farhad Rahimi Klie

Linus Torvalds: The Programmer Who Changed the World With Linux and Git

Farhad Rahimi Klie — Wed, 19 Aug 2026 01:52:52 +0000

From a personal computer project to Linux, Git, and the foundations of modern computing.

When we talk about the people who shaped modern software development, one name stands out: Linus Torvalds.

He is best known as the creator of the Linux kernel, the core software that powers Linux operating systems and countless servers, smartphones, embedded devices, cloud systems, and supercomputers.

But Torvalds created something else that programmers use every day: Git, the distributed version-control system.

His story is interesting because it demonstrates an important lesson in software engineering:

You don't always need to begin with a giant plan. Sometimes, a small technical project can grow into something much bigger than you imagined.

Who Is Linus Torvalds?

Linus Torvalds is a Finnish-American software engineer and programmer, born on December 28, 1969, in Helsinki, Finland.

He became interested in computers at a young age and eventually studied computer science at the University of Helsinki.

In the early 1990s, personal computers were becoming increasingly popular, but the operating systems and development environments available to students were limited.

Torvalds was interested in operating-system technology and began experimenting with a computer running MINIX, an operating system created by Andrew S. Tanenbaum for educational purposes.

That experimentation eventually led to Linux.

The Beginning of Linux

In 1991, Torvalds started developing an operating-system kernel as a personal project.

At first, Linux was not intended to become the foundation of a massive global ecosystem.

It was simply a project for learning and experimentation.

The original announcement was famously modest. Torvalds described what he was working on and invited other people to try it.

That small project eventually became the Linux kernel.

The important distinction is:

Linux is technically a kernel, not a complete operating system by itself.

The kernel manages fundamental resources such as:

CPU scheduling
Memory
Processes
Devices
Filesystems
Networking
System calls
Hardware interaction

A complete Linux-based operating system combines the kernel with many other components.

For example:

Linux-based operating system
│
├── Linux Kernel
│   ├── CPU management
│   ├── Memory management
│   ├── Process management
│   ├── Networking
│   ├── Device drivers
│   └── Filesystems
│
├── System libraries
├── Shell
├── Utilities
├── Desktop environment
└── Applications

This architecture is one reason Linux became extremely flexible.

Why Was Linux Important?

Linux was released as an open-source project.

That meant programmers around the world could study the source code, modify it, improve it, and contribute changes.

This created a powerful development model.

Instead of one company controlling the entire operating system, thousands of developers and organizations could participate.

Over time, Linux became important in many areas of computing.

Today, Linux is widely used in:

Web servers
Cloud infrastructure
Supercomputers
Embedded systems
Networking equipment
Development environments
Containers
Android's kernel foundation
Routers
Internet infrastructure

A huge amount of modern computing infrastructure depends on Linux.

The Linux Development Model

One of the most interesting parts of Torvalds' work isn't simply the code.

It is the development process.

The Linux kernel is developed collaboratively by a large global community.

A simplified version of the process looks like this:

Developer
   │
   ▼
Writes a change
   │
   ▼
Creates a patch
   │
   ▼
Patch is reviewed
   │
   ▼
Maintainer reviews it
   │
   ▼
Changes move through subsystem maintainers
   │
   ▼
Linux kernel integration
   │
   ▼
Testing
   │
   ▼
Release

This model allows thousands of contributors to work on an enormous codebase while maintaining a structured hierarchy of review and maintenance.

What Is the Linux Kernel Actually Doing?

Imagine you write this C program:

#include <stdio.h>

int main(void)
{
    printf("Hello, world!\n");
    return 0;
}

Your program doesn't directly control the hardware.

There are layers between your application and the physical machine.

A simplified model looks like this:

Your C Program
      │
      ▼
C Library
      │
      ▼
System Calls
      │
      ▼
Linux Kernel
      │
      ▼
Hardware

For example, when a program needs to read a file, it eventually asks the operating system to perform that operation.

The kernel handles the interaction with the storage device.

This is one of the fundamental responsibilities of an operating-system kernel:

providing controlled access to hardware and system resources.

Linux and C

If you're learning C and interested in operating systems, Linux is particularly important.

Much of the Linux kernel is written in C, along with some architecture-specific assembly code.

This makes Linux an excellent real-world example for understanding systems programming.

You can encounter concepts such as:

Pointers
Structures
Memory management
Processes
Threads
Interrupts
System calls
File descriptors
Virtual memory
Scheduling
Device drivers
Networking
Synchronization
Concurrency

For someone who wants to understand how computers work underneath high-level applications, studying Linux can be extremely valuable.

Torvalds Didn't Stop at Linux

Linux is the project most people associate with Linus Torvalds.

But he also created another extremely important piece of software:

Git.

Git is a distributed version-control system.

It was created in 2005 during a difficult period in Linux kernel development.

The Linux kernel project needed a powerful way to manage contributions from many developers.

Torvalds decided to build a new version-control system.

That system became Git.

What Is Git?

Suppose you are developing a project.

You might have:

project/
├── main.c
├── database.c
├── database.h
└── README.md

You make changes today.

Tomorrow, you change something else.

Then you realize:

"The project worked yesterday. What did I change?"

Without version control, this can become painful.

Git solves this problem by recording the history of your project.

A simplified Git workflow looks like:

Working Directory
       │
       ▼
     git add
       │
       ▼
   Staging Area
       │
       ▼
   git commit
       │
       ▼
 Git Repository

You can then inspect previous versions of your project.

Why Git Became So Important

Git has several powerful properties.

1. Distributed

Every Git clone can contain the complete repository history.

That means developers don't necessarily need to depend on one central server for the repository's history.

2. Fast

Git was designed to handle very large development projects efficiently.

This was particularly important for the Linux kernel.

3. Branching

Developers can create branches for different features or experiments.

For example:

main
 │
 ├── feature-login
 │
 ├── feature-database
 │
 └── bugfix-memory

Different developers can work on different branches and later merge their work.

4. History

Git records commits.

For example:

A → B → C → D → E

Each commit represents a point in the project's development history.

This makes it possible to understand how a project evolved.

GitHub and Git Are Not the Same Thing

This distinction is important for beginners.

Git is a version-control system.

GitHub is a platform that hosts Git repositories and provides collaboration features.

You can use Git without GitHub.

You can also use Git with other hosting platforms or your own servers.

Think of it this way:

Git
│
└── Version control

GitHub
│
├── Repository hosting
├── Pull requests
├── Issues
├── Collaboration
└── Other development tools

Git itself was created by Linus Torvalds.

Torvalds' Programming Philosophy

One reason Torvalds is influential is his strong focus on practical engineering.

Operating-system development requires thinking about:

Performance
Memory
Hardware
Concurrency
Reliability
Compatibility
Maintainability
Scalability

A small mistake in low-level software can affect an enormous number of systems.

That makes kernel development very different from writing a small application.

Why Linux Is Difficult to Build

If you're learning C and thinking:

"I want to build my own operating system."

Linux demonstrates just how large that problem can become.

A modern operating system requires many subsystems.

For example:

Operating System
│
├── Boot process
├── Kernel
│   ├── Process management
│   ├── Memory management
│   ├── Scheduling
│   ├── System calls
│   ├── Virtual memory
│   ├── Networking
│   ├── Filesystems
│   └── Device drivers
│
├── User-space libraries
├── Shell
├── Utilities
└── Applications

You don't need to build everything at once.

A beginner can start much smaller.

For example:

Step 1 → Boot a tiny program
Step 2 → Print text
Step 3 → Handle interrupts
Step 4 → Manage memory
Step 5 → Implement processes
Step 6 → Add system calls
Step 7 → Build a filesystem
Step 8 → Add networking

This incremental approach is much more realistic.

What Can We Learn From Linus Torvalds?

There are several lessons programmers can take from his career.

1. Start With a Real Project

Linux began as a personal project.

You don't need to wait until you know everything before building something.

Build.

Then discover what you don't know.

2. Learn How Computers Actually Work

If you only learn high-level programming, you can build useful applications.

But learning lower-level concepts gives you a different understanding of computers.

Study:

C
 ↓
Assembly
 ↓
CPU
 ↓
Memory
 ↓
Operating System
 ↓
System Calls
 ↓
Hardware

You don't have to become an expert in every layer immediately.

But understanding the layers is extremely useful.

3. Read Other People's Code

Linux is one of the largest examples of real-world systems software.

Reading mature code teaches you things tutorials often don't.

You can learn:

How large projects are organized
How abstractions are designed
How errors are handled
How data structures are used
How concurrency is implemented
How performance matters
How APIs evolve

However, don't start by trying to understand the entire Linux kernel.

That's an inefficient approach.

Start with smaller subsystems and concepts.

4. Understand Version Control

If you are serious about programming, Git is not merely another tool to memorize.

You should understand:

repository
commit
branch
merge
rebase
remote
diff
tag

These concepts become essential when working on real software projects.

5. Build Things That Are Difficult

Torvalds' work demonstrates the value of tackling technically challenging projects.

You could build smaller versions of systems such as:

Text Editor
      ↓
Shell
      ↓
Filesystem
      ↓
Database
      ↓
Network Server
      ↓
Compiler
      ↓
Operating System Kernel

You don't need to build a production-quality version.

The goal is understanding.

For example, building a small database in C can teach you:

Disk layout
Pages
Buffer pools
Indexes
Serialization
File I/O
Memory management
Concurrency

Building a filesystem can teach you:

Blocks
Inodes
Directories
Bitmaps
Allocation
Metadata
File descriptors

These projects make abstract concepts concrete.

Linux Is Bigger Than Linus Torvalds

An important point is that modern Linux is not the work of one person.

Torvalds started the project and remains its creator and principal maintainer, but Linux has grown through contributions from a massive international community.

Companies, universities, independent developers, and organizations have contributed to its development.

This is one of the most impressive aspects of open-source software.

A project can begin with one programmer and eventually become a global engineering effort.

A Simplified Timeline

1969
 │
 └── Linus Torvalds is born
       │
1980s
 │
 └── Develops an interest in computers
       │
1991
 │
 └── Begins developing Linux
       │
1990s
 │
 └── Linux community grows
       │
2005
 │
 └── Torvalds creates Git
       │
2000s–2020s
 │
 └── Linux becomes fundamental
     infrastructure for modern computing

The Bigger Lesson

The most interesting part of Linus Torvalds' story isn't simply that he created Linux.

It's that a relatively small technical project can become enormously important when:

The problem is interesting.
The implementation is useful.
The project is shared with others.
Developers can contribute.
The software continues to evolve.

Linux demonstrates the power of collaborative engineering.

Git demonstrates the importance of tools that make collaboration possible.

Together, they have had an enormous influence on modern software development.

If You Want to Follow a Similar Learning Path

You don't need to try to become "the next Linus Torvalds."

Instead, focus on becoming a strong programmer.

A practical path could look like this:

C Programming
      ↓
Data Structures
      ↓
Algorithms
      ↓
Linux
      ↓
Systems Programming
      ↓
Computer Architecture
      ↓
Operating Systems
      ↓
Networking
      ↓
Filesystems
      ↓
Databases
      ↓
Large Software Projects

Then build projects.

For example:

Project 1 → Shell
Project 2 → Text Editor
Project 3 → HTTP Server
Project 4 → Database
Project 5 → Filesystem
Project 6 → Compiler
Project 7 → Small Operating System

Each project forces you to learn another part of computer science.

Final Thoughts

Linus Torvalds' career is a remarkable example of how software can grow from a personal experiment into infrastructure used around the world.

Linux changed operating systems.

Git changed how developers manage source code.

But perhaps the most valuable lesson is simpler:

Build things.

Don't wait until you understand everything.

Start with a manageable problem.

Write the code.

Break it.

Debug it.

Read documentation.

Study other implementations.

Improve it.

Then build something harder.

That's how small programming projects turn into serious engineering experience.

And that's one of the most important lessons we can take from the story of Linus Torvalds, Linux, and Git.

How to Build Your Own SQLite Database From Scratch

Farhad Rahimi Klie — Sun, 16 Aug 2026 05:31:33 +0000

Have you ever wondered what actually happens when you run a SQL query like:

SELECT name FROM users WHERE id = 10;

Where is the data stored?

How does the database find the correct row?

How are tables represented on disk?

How does the database survive after the program exits?

And how does a database engine turn SQL into operations on bytes, pages, indexes, and files?

Instead of only using a database, let's build a small SQLite-like database engine from scratch in C.

We won't try to recreate all of SQLite. That would be an enormous project. Instead, we'll build a small educational database engine that teaches the fundamental architecture behind relational databases.

By the end, we'll understand how the pieces fit together:

                 SQL Query
                    │
                    ▼
             ┌─────────────┐
             │ SQL Parser  │
             └──────┬──────┘
                    │
                    ▼
             ┌─────────────┐
             │ Query Plan  │
             └──────┬──────┘
                    │
                    ▼
             ┌─────────────┐
             │   Executor  │
             └──────┬──────┘
                    │
                    ▼
             ┌─────────────┐
             │    B-Tree   │
             └──────┬──────┘
                    │
                    ▼
             ┌─────────────┐
             │ Buffer Pool │
             └──────┬──────┘
                    │
                    ▼
             ┌─────────────┐
             │ Disk / File │
             └─────────────┘

Let's build it step by step.

1. What Are We Actually Building?

Our goal is a small database executable:

$ ./mydb database.db

Then we can interact with it:

db > CREATE TABLE users;
db > INSERT INTO users VALUES (1, "Farhad");
db > INSERT INTO users VALUES (2, "Ali");
db > SELECT * FROM users;

And eventually:

1 | Farhad
2 | Ali

The important part is that the data should remain after the program exits.

If we run:

$ ./mydb database.db

again, the database should still contain:

1 | Farhad
2 | Ali

That means we need persistent storage.

2. Why C?

C is an excellent language for learning how databases work internally because it gives us direct control over:

memory
pointers
structs
files
byte arrays
serialization
memory allocation
system calls
data structures

A database engine ultimately deals with a lot of low-level concepts.

For example, a database page might simply be:

unsigned char page[4096];

Those 4096 bytes could contain:

+----------------------------------+
| Page Header                      |
+----------------------------------+
| Slot Array                       |
+----------------------------------+
|                                  |
| Records                          |
|                                  |
+----------------------------------+
| Free Space                       |
+----------------------------------+

At this level, there is no magic.

It's bytes.

Our job is to give those bytes meaning.

3. The Architecture

Before writing code, we need an architecture.

A simplified database can be divided into several layers:

┌───────────────────────────────┐
│          SQL Layer            │
│ Lexer / Parser / Statements   │
├───────────────────────────────┤
│        Query Executor         │
├───────────────────────────────┤
│       Access Methods          │
│       Table / B-Tree          │
├───────────────────────────────┤
│         Buffer Pool           │
├───────────────────────────────┤
│          Page Cache           │
├───────────────────────────────┤
│        Storage Manager        │
├───────────────────────────────┤
│        Database File          │
└───────────────────────────────┘

We'll implement these components incrementally.

4. Step 1 — The Database File

The simplest database can start as a normal file.

For example:

database.db

We can open it with:

FILE *file = fopen("database.db", "r+b");

Or create it if it doesn't exist:

FILE *file = fopen("database.db", "w+b");

But simply writing random structures into a file isn't enough.

We need a storage format.

5. Step 2 — Pages

Databases generally don't treat the disk as one giant byte array.

Instead, we divide the database file into fixed-size pages.

For our educational database:

#define PAGE_SIZE 4096

A database file might look like:

database.db

┌──────────────┐
│ Page 0       │
│ 4096 bytes   │
├──────────────┤
│ Page 1       │
│ 4096 bytes   │
├──────────────┤
│ Page 2       │
│ 4096 bytes   │
├──────────────┤
│ Page 3       │
│ 4096 bytes   │
├──────────────┤
│ ...          │
└──────────────┘

If the database has 100 pages:

100 × 4096 = 409,600 bytes

A page gives us a fixed unit for storage and caching.

6. Why Pages?

Suppose we need record number 500.

We don't want to read the entire database file.

Instead, we determine which page contains the record:

record
   │
   ▼
page number
   │
   ▼
database file offset

The offset is:

offset = page_number * PAGE_SIZE;

For example:

page = 10

offset = 10 × 4096
       = 40960

So page 10 begins at byte 40960.

7. Step 3 — The Pager

Now we create one of the most important components:

the pager.

The pager is responsible for moving pages between the database file and memory.

Conceptually:

             RAM
       ┌──────────────┐
       │ Page 0       │
       │ Page 4       │
       │ Page 7       │
       └───────┬──────┘
               │
               │
          ┌────▼────┐
          │  Pager  │
          └────┬────┘
               │
               ▼
       ┌──────────────┐
       │ database.db  │
       └──────────────┘

A basic pager structure might look like:

#define TABLE_MAX_PAGES 100

typedef struct {
    int file_descriptor;
    uint32_t file_length;
    void *pages[TABLE_MAX_PAGES];
} Pager;

The pages array stores pointers to pages currently loaded in memory.

8. Loading a Page

Suppose we request page 5.

The pager checks:

if (pager->pages[5] == NULL)

If it isn't loaded, allocate memory:

pager->pages[5] = malloc(PAGE_SIZE);

Then read the page from disk.

Conceptually:

database.db
     │
     │ read page 5
     ▼
┌─────────────┐
│ Page 5      │
└─────────────┘
     │
     ▼
RAM

This is the beginning of a buffer pool/cache.

9. Step 4 — Rows

Now we need to decide how a table row is represented.

For a simple database, let's define:

typedef struct {
    uint32_t id;
    char username[32];
    char email[64];
} Row;

A row might contain:

id       = 1
username = "Farhad"
email    = "farhad@example.com"

But we cannot simply assume that a C struct's memory layout is our database format.

We should explicitly serialize the row.

10. Serialization

Serialization means converting a C structure into bytes.

For example:

C structure

Row
┌───────────────┐
│ id            │
├───────────────┤
│ username      │
├───────────────┤
│ email         │
└───────────────┘
       │
       ▼
   serialize
       │
       ▼
Bytes on disk

We can write:

void serialize_row(Row *source, void *destination)
{
    memcpy(destination, &source->id, sizeof(source->id));

    memcpy(destination + 4,
           source->username,
           sizeof(source->username));

    memcpy(destination + 36,
           source->email,
           sizeof(source->email));
}

And later deserialize it.

This is important because the database file needs a well-defined format.

11. Step 5 — The Table

Now we can store rows inside pages.

Initially, we could use a very simple layout:

Page
┌──────────────────────────────┐
│ Row 0                        │
├──────────────────────────────┤
│ Row 1                        │
├──────────────────────────────┤
│ Row 2                        │
├──────────────────────────────┤
│ Row 3                        │
├──────────────────────────────┤
│ ...                          │
└──────────────────────────────┘

For example:

#define ROW_SIZE 100

#define ROWS_PER_PAGE \
    (PAGE_SIZE / ROW_SIZE)

Then:

page_number = row_number / ROWS_PER_PAGE;
row_offset  = row_number % ROWS_PER_PAGE;

This gives us a simple way to locate rows.

12. Step 6 — The REPL

Now let's create an interface.

A REPL means:

Read → Evaluate → Print → Loop

Our program could display:

db >

The user enters:

db > insert 1 Farhad

Our program reads the input:

char input[1024];

while (1) {
    printf("db > ");

    if (!fgets(input, sizeof(input), stdin))
        break;

    // process input
}

At first, don't implement SQL.

Start with commands like:

insert
select
.exit

This makes development much easier.

13. Step 7 — INSERT

Suppose the user enters:

insert 1 Farhad

The database needs to:

Input
 │
 ▼
Parse command
 │
 ▼
Create Row
 │
 ▼
Serialize Row
 │
 ▼
Find page
 │
 ▼
Write Row
 │
 ▼
Mark page dirty

Conceptually:

Row row;

row.id = 1;
strcpy(row.username, "Farhad");

execute_insert(&row);

14. Step 8 — SELECT

Now:

select

should read all rows.

The executor might:

for each page
    load page

    for each row
        deserialize row

        print row

Conceptually:

database
   │
   ▼
Page 0
   │
   ├── Row 0
   ├── Row 1
   └── Row 2

Page 1
   │
   ├── Row 3
   ├── Row 4
   └── Row 5

This is essentially a table scan.

15. Step 9 — From Commands to SQL

Once the storage engine works, we can start implementing SQL.

Instead of:

insert 1 Farhad

we want:

INSERT INTO users VALUES (1, 'Farhad');

And:

SELECT * FROM users;

Now we need a lexer and parser.

16. The SQL Lexer

The lexer converts characters into tokens.

For:

SELECT * FROM users;

we might produce:

SELECT
ASTERISK
FROM
IDENTIFIER(users)
SEMICOLON

The input:

SELECT * FROM users;

becomes:

┌────────┐
│ SELECT │
├────────┤
│   *    │
├────────┤
│  FROM  │
├────────┤
│ users  │
├────────┤
│   ;    │
└────────┘

17. The Parser

The parser takes those tokens and builds a representation of the query.

For example:

SELECT * FROM users;

could become:

SelectStatement
├── columns: *
└── table: users

For:

INSERT INTO users VALUES (1, 'Farhad');

we could create:

InsertStatement
├── table: users
└── values
    ├── 1
    └── Farhad

18. Step 10 — The Query Executor

The parser tells us what the user wants.

The executor determines how to perform it.

For example:

SELECT * FROM users;

might become:

Parser
   │
   ▼
SELECT statement
   │
   ▼
Executor
   │
   ▼
Table scan
   │
   ▼
Read pages
   │
   ▼
Read rows
   │
   ▼
Return results

This separation is extremely important.

19. Step 11 — Slotted Pages

Our first page layout was very simple.

A real database needs a more flexible structure.

This is where slotted pages become useful.

A page might look like:

┌─────────────────────────────┐
│ Page Header                 │
├─────────────────────────────┤
│ Slot 0                      │
├─────────────────────────────┤
│ Slot 1                      │
├─────────────────────────────┤
│ Slot 2                      │
├─────────────────────────────┤
│                             │
│ Free Space                  │
│                             │
├─────────────────────────────┤
│ Record 2                    │
├─────────────────────────────┤
│ Record 1                    │
├─────────────────────────────┤
│ Record 0                    │
└─────────────────────────────┘

The slot array tells us where records are located.

This allows records to have variable sizes and move around within a page without changing their logical identifiers.

20. Step 12 — Record IDs

Instead of identifying a record simply by its memory address, we can use a logical identifier.

For example:

RID
├── page_id
└── slot_id

So:

RID = (12, 4)

means:

Page 12
Slot 4

This gives us a stable way to refer to records.

21. Step 13 — Free Space Management

Eventually pages become full.

We need to know:

Which pages have free space?

A simple free-space map could track this:

Page 0 → full
Page 1 → 1200 bytes free
Page 2 → full
Page 3 → 3000 bytes free

When inserting a record, the storage manager searches for a page with enough free space.

This is one of the fundamental responsibilities of a storage engine.

22. Step 14 — B-Tree Indexes

A table scan works:

SELECT * FROM users WHERE id = 1000000;

But it can be very slow.

If there are one million rows, scanning every row is expensive.

We need an index.

A common database index structure is a B-tree or B+ tree.

Conceptually:

                  [50]
                /      \
              /          \
         [10,20,30]     [60,70,80]

The index lets us navigate toward the desired key instead of scanning every row.

For:

WHERE id = 70

we navigate:

23. Why B-Trees?

B-trees are particularly useful for storage systems because they reduce the number of disk/page accesses required to locate records.

Instead of:

Page 0
Page 1
Page 2
Page 3
...
Page 1,000,000

we can navigate through a tree:

             Root
              │
       ┌──────┴──────┐
       ▼             ▼
    Internal       Internal
       │             │
       ▼             ▼
     Leaves         Leaves
       │
       ▼
     Record

The database doesn't have to inspect every row.

24. Step 15 — Buffer Pool

Disk is much slower than RAM.

Therefore, databases keep frequently used pages in memory.

A buffer pool might look like:

RAM

┌───────────────┐
│ Frame 0       │ → Page 17
├───────────────┤
│ Frame 1       │ → Page 4
├───────────────┤
│ Frame 2       │ → Page 31
├───────────────┤
│ Frame 3       │ → Page 9
└───────────────┘

When the database requests page 17:

Request Page 17
      │
      ▼
Is it in buffer?
      │
   ┌──┴──┐
  yes    no
   │      │
   ▼      ▼
 return  read disk
          │
          ▼
       buffer

This dramatically reduces disk I/O.

25. Dirty Pages

Suppose we load a page:

Disk → RAM

Then modify it:

RAM
Page 5
  │
  └── modified

The page is now dirty.

Eventually we need:

RAM → Disk

So a buffer frame might have:

typedef struct {
    void *data;
    uint32_t page_id;
    int dirty;
} Frame;

If:

frame->dirty = 1;

we know the page must eventually be written back.

26. Step 16 — Transactions

Now we reach a much more serious database feature.

What happens if the program crashes halfway through a write?

For example:

Transaction:

1. Update row A
2. Update row B
3. Program crashes

We don't want the database to end up in an inconsistent state.

Transactions provide atomicity.

Conceptually:

BEGIN
   │
   ├── operation 1
   ├── operation 2
   ├── operation 3
   │
COMMIT

Or:

BEGIN
   │
   ├── operation 1
   ├── operation 2
   │
ROLLBACK

27. Step 17 — Write-Ahead Logging

A common technique is Write-Ahead Logging (WAL).

Before modifying the actual database page, record the change in a log.

             Transaction
                  │
                  ▼
             Write Log
                  │
                  ▼
             Modify Page
                  │
                  ▼
               Commit

If the database crashes, the log can be used during recovery.

This is one of the major steps from a toy database toward a real database engine.

28. Step 18 — Database Catalog

Once we support multiple tables, the database needs metadata.

For example:

CREATE TABLE users (...);
CREATE TABLE products (...);

The database needs to know:

users
 ├── columns
 ├── types
 └── root page

products
 ├── columns
 ├── types
 └── root page

This metadata is often called the system catalog.

Our catalog could contain information such as:

Table name
Column name
Column type
Column position
Index information
Root page

29. Step 19 — Data Types

Eventually our SQL engine should understand:

INTEGER
TEXT
REAL
BOOLEAN

For example:

CREATE TABLE users (
    id INTEGER,
    name TEXT,
    age INTEGER
);

Internally, a row might be serialized as:

┌──────────┬────────────┬──────────┐
│ id       │ name       │ age      │
│ INTEGER  │ TEXT       │ INTEGER  │
└──────────┴────────────┴──────────┘

The serialization layer needs to understand each type.

30. Step 20 — Query Execution

Eventually we want queries such as:

SELECT name
FROM users
WHERE age > 18;

The execution pipeline becomes:

SQL
 │
 ▼
Lexer
 │
 ▼
Parser
 │
 ▼
AST
 │
 ▼
Query Planner
 │
 ▼
Execution Plan
 │
 ▼
Executor
 │
 ▼
Index / Table Scan
 │
 ▼
Pages
 │
 ▼
Rows
 │
 ▼
Result

This is where our database starts becoming a real database engine rather than a file-based storage program.

31. A Practical Development Roadmap

Don't try to build everything at once.

Build the database in stages.

Stage 1 — File Storage

Implement:

database file
page size
read page
write page

Stage 2 — Pager

Implement:

Pager
page cache
page loading
page flushing

Stage 3 — Rows

Implement:

Row
serialize
deserialize

Stage 4 — Table

Implement:

insert
select
table scan

Stage 5 — REPL

Implement:

db >

with commands such as:

.insert
.select
.exit

Stage 6 — SQL Lexer

Implement tokens:

SELECT
INSERT
CREATE
FROM
WHERE
INTEGER
TEXT
IDENTIFIER
NUMBER
STRING

Stage 7 — SQL Parser

Build an AST for SQL statements.

Stage 8 — Slotted Pages

Implement:

page header
slot directory
records
free space

Stage 9 — B-Tree

Implement:

leaf nodes
internal nodes
search
insert
split

Stage 10 — Catalog

Implement:

tables
columns
types
indexes

Stage 11 — Query Execution

Implement:

table scan
index scan
filter
projection

Stage 12 — Transactions

Implement:

BEGIN
COMMIT
ROLLBACK

Stage 13 — WAL and Recovery

Implement:

log
checkpoint
recovery

Stage 14 — Concurrency

Eventually:

locks
latches
transactions
isolation

32. Suggested Project Structure

A clean project might eventually look like:

mydb/
│
├── src/
│   ├── main.c
│   ├── repl.c
│   ├── lexer.c
│   ├── parser.c
│   ├── executor.c
│   ├── catalog.c
│   ├── table.c
│   ├── row.c
│   ├── page.c
│   ├── pager.c
│   ├── buffer_pool.c
│   ├── btree.c
│   ├── transaction.c
│   ├── wal.c
│   └── recovery.c
│
├── include/
│   ├── repl.h
│   ├── lexer.h
│   ├── parser.h
│   ├── executor.h
│   ├── catalog.h
│   ├── table.h
│   ├── row.h
│   ├── page.h
│   ├── pager.h
│   ├── buffer_pool.h
│   ├── btree.h
│   ├── transaction.h
│   ├── wal.h
│   └── recovery.h
│
├── tests/
│   ├── test_pager.c
│   ├── test_page.c
│   ├── test_btree.c
│   └── test_sql.c
│
├── Makefile
└── database.db

You don't need all of these files on day one.

Start small and grow the architecture as the database becomes more capable.

33. The Most Important Concept

The biggest lesson from building a database from scratch is this:

A database is not just SQL.

SQL is only the interface.

Underneath SQL are many layers:

SQL
 ↓
Parser
 ↓
Query Planner
 ↓
Executor
 ↓
Indexes
 ↓
Tables
 ↓
Records
 ↓
Pages
 ↓
Buffer Pool
 ↓
Storage Manager
 ↓
Operating System
 ↓
Disk

And underneath all of that:

bytes

Understanding those layers gives you a completely different perspective on databases.

34. What We Should Not Build Initially

A common mistake is trying to implement everything immediately.

Don't start with:

SQL
Transactions
WAL
Concurrency
B-Trees
Joins
Indexes
Networking
Replication

all at once.

Instead:

file
 ↓
pages
 ↓
pager
 ↓
rows
 ↓
table
 ↓
insert/select
 ↓
B-tree
 ↓
SQL
 ↓
transactions
 ↓
WAL

Each stage should work before moving to the next.

35. Final Architecture

Our final educational database could look like this:

                    USER
                     │
                     ▼
              ┌─────────────┐
              │     SQL     │
              └──────┬──────┘
                     ▼
              ┌─────────────┐
              │    Lexer    │
              └──────┬──────┘
                     ▼
              ┌─────────────┐
              │    Parser   │
              └──────┬──────┘
                     ▼
              ┌─────────────┐
              │Query Planner│
              └──────┬──────┘
                     ▼
              ┌─────────────┐
              │   Executor  │
              └──────┬──────┘
                     ▼
           ┌─────────┴─────────┐
           │                   │
           ▼                   ▼
      Table Scan            B-Tree
           │                   │
           └─────────┬─────────┘
                     ▼
              ┌─────────────┐
              │ Buffer Pool │
              └──────┬──────┘
                     ▼
              ┌─────────────┐
              │    Pager    │
              └──────┬──────┘
                     ▼
              ┌─────────────┐
              │ Database DB │
              │    File     │
              └─────────────┘

Conclusion

Building a SQLite-like database from scratch is one of the best projects for learning systems programming.

You will learn far more than SQL.

You'll learn:

C programming
memory management
binary data
file I/O
serialization
page layouts
storage engines
buffer pools
indexing
B-trees
parsing
query execution
transactions
logging
crash recovery
operating-system I/O

The important thing is to build it incrementally.

Don't begin by asking:

"How do I build SQLite?"

Start by asking:

"How do I store one page?"

Then:

"How do I store one row?"

Then:

"How do I find that row?"

Then:

"How do I find millions of rows efficiently?"

Then:

"How do I make the operation safe if the program crashes?"

That's how a database engine grows—from a few thousand bytes of C code into a complete storage system.

And the best part is that every layer you implement gives you a deeper understanding of what databases are actually doing underneath the SQL interface.

GitHub Doesn't Get “Hacked” the Way You Think

Farhad Rahimi Klie — Mon, 10 Aug 2026 03:59:05 +0000

There is a dangerous misconception in software security:

“If someone hacked GitHub, they must have broken through GitHub's login page.”

Usually, that's not how modern attacks work.

The most interesting attacks don't necessarily defeat the strongest lock.

They find a different door.

A stolen OAuth token.

A compromised developer account.

A leaked secret.

A malicious dependency.

A vulnerable production service.

A trusted third-party integration.

A phishing attack.

A forgotten permission.

And once an attacker obtains a legitimate credential, the attack can look like completely normal activity.

That's what makes these attacks dangerous.

GitHub Is a Giant Trust System

Think about what a modern GitHub account can connect to:

Developer
    |
    +---- GitHub account
    |
    +---- Organizations
    |
    +---- Private repositories
    |
    +---- GitHub Actions
    |
    +---- OAuth applications
    |
    +---- Personal access tokens
    |
    +---- SSH keys
    |
    +---- Cloud credentials
    |
    +---- Package registries
    |
    +---- Deployment systems

GitHub isn't isolated.

It sits inside a much larger software ecosystem.

That means an attacker doesn't always need to attack GitHub directly.

They may attack something that already has permission to talk to GitHub.

And that distinction changes everything.

Attack #1: Steal the Key Instead of Breaking the Lock

One of the clearest examples happened in 2022.

GitHub disclosed an attack campaign involving stolen OAuth user tokens issued to third-party integrations, specifically Heroku and Travis CI.

The attacker used those stolen tokens to access GitHub APIs and selectively identify organizations and private repositories.

GitHub said it did not believe the attacker obtained those tokens by compromising GitHub itself.

Think about the architecture:

                 ┌──────────────┐
                 │   GitHub     │
                 └──────┬───────┘
                        │
                  OAuth trust
                        │
             ┌──────────┴──────────┐
             │                     │
        Third-party App       Third-party App
             │                     │
          Heroku              Travis CI

The attacker didn't necessarily need:

GitHub password
        ↓
GitHub login
        ↓
GitHub account

Instead, the attack path was conceptually:

Compromised integration
        ↓
Stolen OAuth token
        ↓
GitHub API authentication
        ↓
Authorized permissions
        ↓
Private repository access

That's a completely different security model.

The server sees a valid credential.

The credential has permission.

The request can therefore look legitimate.

The Most Dangerous Credential Is the One That Looks Legitimate

This is a fundamental security lesson.

Imagine a server receives:

Authorization: valid-token

The server doesn't automatically know:

"An attacker stole this token yesterday."

It sees:

valid credential
+
valid permission
+
valid API request

That is why credential theft can be so powerful.

You don't necessarily need to defeat authentication.

You can sometimes become the authenticated user.

Attack #2: Phishing the Developer

Another attack path is much simpler:

Attacker
   |
   | fake login page
   v
Developer
   |
   | enters credentials
   v
Attacker

GitHub documented a phishing campaign in which attackers created convincing login pages.

The important part was that even some accounts using TOTP-based two-factor authentication could be targeted because the phishing site relayed authentication information in real time.

GitHub noted that hardware security keys were not vulnerable to that particular attack technique.

This demonstrates an important distinction:

Authentication ≠ phishing resistance

A security mechanism can be strong while still being vulnerable to a particular social-engineering technique.

That's one reason phishing-resistant authentication matters.

Attack #3: Steal a Token After Taking the Account

Here's where attacks become interesting.

Suppose an attacker compromises a developer account.

The attacker doesn't necessarily stop there.

They may look for additional ways to maintain access.

GitHub documented attackers attempting to create personal access tokens, authorize OAuth applications, or add SSH keys after obtaining account credentials.

Conceptually:

Account compromise
        |
        +---- Password
        |
        +---- PAT
        |
        +---- OAuth application
        |
        +---- SSH key
        |
        +---- Repository permissions

Why?

Because attackers want persistence.

If the original password is changed, another credential may still provide access.

This is why security teams don't ask only:

“Was the password changed?”

They ask:

“What other credentials or trust relationships were created?”

Attack #4: The Secret You Accidentally Pushed

This is probably one of the most common developer mistakes.

Imagine writing:

const char *api_key =
    "SUPER_SECRET_VALUE";

Then committing:

git add .
git commit -m "add API integration"
git push

Now the secret may exist in Git history.

Deleting the line later doesn't necessarily erase the historical commit.

Conceptually:

Commit 1
   |
   +-- source code

Commit 2
   |
   +-- API_KEY = SECRET

Commit 3
   |
   +-- API_KEY removed

The developer sees:

Current code:
SECRET = gone

But the repository history may still contain:

Commit 2:
SECRET = still present

That's why:

Removing a secret from the latest version is not the same as revoking the secret.

If a real credential is exposed, the important response is generally to revoke/rotate it, then clean up the repository history where appropriate.

The Scale Is Bigger Than Most Developers Realize

GitHub reported that more than 39 million secrets were leaked across GitHub in 2024.

That's an enormous number.

And this explains why secret scanning and push protection exist.

GitHub has also described push protection as a mechanism that can block commits when supported secrets are detected before they enter public repositories.

The lesson isn't:

“GitHub is insecure.”

The lesson is:

Developers are part of the security boundary.

Your repository can be perfectly protected while you accidentally publish a cloud credential.

Attack #5: Attack the Supply Chain

Here's where things become much more complicated.

Your repository might be secure.

Your password might be secure.

Your server might be secure.

But what about your dependencies?

Consider:

Your application
      |
      +---- dependency A
      |
      +---- dependency B
      |
      +---- dependency C

And:

dependency C
      |
      +---- dependency D

Now your application depends on software you didn't write.

This creates a software supply-chain attack surface.

GitHub has specifically documented repo-jacking as a supply-chain risk. A repository that has been renamed or transferred can potentially create problems for projects that reference it incorrectly. GitHub recommends pinning dependencies to specific commit IDs in relevant scenarios.

The important idea is:

Trust
  ↓
Repository
  ↓
Dependency
  ↓
Build system
  ↓
Production

Every link matters.

Attack #6: A Vulnerability in the Platform

Sometimes the target really is the platform itself.

In December 2023, GitHub received a bug-bounty report describing a vulnerability that could allow access to environment variables from a production container.

GitHub patched the issue the same day and said its investigation found no evidence that the vulnerability had previously been discovered or exploited.

And in March 2026, GitHub disclosed a critical remote-code-execution vulnerability affecting multiple GitHub environments.

GitHub said it validated the report, deployed a fix to GitHub.com in under two hours, and concluded its investigation with no evidence of exploitation.

This is a completely different category:

Attacker
   |
   v
Vulnerability
   |
   v
Application
   |
   v
Execution
   |
   v
Potential privilege escalation

This is what people often imagine when they hear:

“GitHub got hacked.”

But finding and exploiting a vulnerability is only one possible attack path.

The Most Important Security Concept: Trust Boundaries

Let's simplify the whole problem.

Imagine GitHub as:

                    INTERNET
                       |
                       v
              ┌─────────────────┐
              │     GitHub      │
              └─────────────────┘
                 /     |      \
                /      |       \
               v       v        v
          Developers  OAuth   Actions
                      Apps

Every arrow represents a trust relationship.

And every trust relationship is an attack surface.

For example:

Developer
   |
   | credentials
   v
GitHub
   |
   | token
   v
OAuth application
   |
   | permissions
   v
Repository

If any link is compromised, the attacker may gain access to the next layer.

This is why modern security engineering focuses heavily on:

least privilege
credential rotation
short-lived credentials
strong authentication
audit logs
secret scanning
dependency pinning
network isolation
continuous monitoring

Why “Just Use 2FA” Isn't the Whole Answer

2FA is important.

But security isn't a single checkbox.

Consider:

Password
    +
2FA
    +
OAuth token
    +
SSH key
    +
GitHub Actions
    +
Cloud credentials

An account can have strong login protection while another credential remains compromised.

Security therefore becomes a lifecycle:

IDENTITY
   ↓
AUTHENTICATION
   ↓
AUTHORIZATION
   ↓
CREDENTIALS
   ↓
ACTIVITY
   ↓
MONITORING
   ↓
REVOCATION

Every stage matters.

Least Privilege Changes the Game

Suppose an application only needs to read one repository.

Bad design:

Application
    |
    +---- full organization access

Better design:

Application
    |
    +---- read-only
    |
    +---- specific repository

If that credential is stolen, the blast radius is smaller.

This is the principle of:

Least privilege

GitHub introduced fine-grained personal access tokens specifically to provide more precise permissions and reduce the risk associated with compromised tokens.

The question shouldn't be:

“Can this application access the repository?”

It should be:

“What is the minimum access this application needs?”

Think Like a Security Engineer

When you build software, don't ask only:

Does it work?

Ask:

What happens if this credential leaks?

What happens if this user is compromised?

What happens if this dependency becomes malicious?

What happens if this OAuth token is stolen?

What happens if this server is compromised?

What happens if an attacker gets read access?

What happens if an attacker gets write access?

How do we detect it?

How do we revoke access?

How do we recover?

Those questions are far more valuable than simply asking:

“Is my application secure?”

A Realistic Attack Chain

Put everything together.

A modern software attack could conceptually look like:

        PHISHING
           |
           v
    Developer account
           |
           v
     OAuth / PAT / SSH
           |
           v
     Private repository
           |
           v
       Secret found
           |
           v
     Cloud environment
           |
           v
     Production system

Notice something important.

The attacker didn't necessarily:

break GitHub

They abused trust.

That's the deeper lesson.

So, Was GitHub “Hacked”?

The answer depends on what you mean by hacked.

There have been:

account-targeting attacks
stolen-token campaigns
phishing campaigns
security vulnerabilities
service incidents
supply-chain risks
credential exposure incidents
attacks against GitHub Enterprise environments

But these are not all the same thing.

For example, in the 2022 OAuth-token incident, GitHub explicitly said it did not believe GitHub itself was compromised in the way people might normally imagine; attackers abused stolen tokens issued by third-party OAuth integrations.

And in the 2026 RCE disclosure, GitHub reported that it fixed the vulnerability and found no evidence of exploitation.

Precision matters.

“GitHub was hacked” can hide the actual security lesson.

The Real Lesson

The most dangerous misconception in cybersecurity is:

“Attackers break systems.”

Often, attackers don't need to.

They abuse what systems already trust.

A stolen credential.

A valid token.

A compromised account.

A vulnerable dependency.

A leaked secret.

An overly powerful service account.

A trusted integration.

That's modern security.

The strongest system isn't necessarily the system with the biggest lock.

It's the system where:

credentials are limited
        +
permissions are limited
        +
secrets are protected
        +
dependencies are controlled
        +
activity is monitored
        +
compromise is detected
        +
access can be revoked
        +
systems can recover

And that's the real reason GitHub security is interesting.

GitHub isn't just a website where developers store code.

It's a massive trust network connecting developers, identities, repositories, CI/CD systems, dependencies, cloud infrastructure, and production environments.

Attack the trust network—

and you may not need to attack the website at all.

Final Thought

The next time you run:

git push

remember:

You're not just uploading code.

You're participating in a security system.

Your repository has identities.

Your identities have permissions.

Your permissions have credentials.

Your credentials have blast radius.

And somewhere in that chain is the thing an attacker is looking for.

Security isn't about making one door impossible to break.

It's about making sure that opening one door doesn't open the entire building.

How to Build Your Own Filesystem From Scratch in C

Farhad Rahimi Klie — Mon, 03 Aug 2026 11:51:09 +0000

Stop treating filesystems as magic. Build one yourself and understand how operating systems actually store data.

Most programmers use a filesystem every day.

FILE *fp = fopen("notes.txt", "r");

int fd = open("file.txt", O_RDONLY);

But very few programmers know what happens after those function calls.

Where is the file actually stored?

How does the operating system know where its data begins?

How does deleting a file free disk space?

How does a filesystem survive a power failure?

These questions are answered by one piece of software:

The filesystem.

In this article, we'll build one from scratch—not a toy with a single array in memory, but a real userspace filesystem stored inside a disk.img file. By the end, you'll understand many of the same concepts used by Linux filesystems like ext2, ext3, and ext4.

Why Build a Filesystem?

Building a filesystem teaches far more than file storage.

You'll learn about:

Disk layouts
Binary file formats
Metadata
Block allocation
Bitmaps
Direct and indirect pointers
File growth
Directory structures
Crash consistency
C programming
Systems programming

It's one of the best projects for becoming a systems programmer.

What Is a Filesystem?

A filesystem is software that organizes raw bytes on a storage device.

Imagine you have a completely empty disk.

+------------------------------------------------+
|                                                |
|             1 GB of Random Bytes               |
|                                                |
+------------------------------------------------+

Without a filesystem, the operating system sees only bytes.

It doesn't know:

where files begin
where files end
which space is free
what filenames exist

The filesystem provides all of that information.

The Basic Idea

Instead of treating the disk as one giant byte array, we divide it into blocks.

Disk

+------+------+------+------+------+------+
|Blk 0 |Blk 1 |Blk 2 |Blk 3 |Blk 4 | ... |
+------+------+------+------+------+------+

A block is the smallest storage unit.

Typical sizes are:

512 bytes
1024 bytes
2048 bytes
4096 bytes

Linux commonly uses 4096-byte blocks.

Our Project

We'll build everything ourselves.

disk.img

+-------------------------+
| Superblock              |
+-------------------------+
| Bitmap                  |
+-------------------------+
| Inode Table             |
+-------------------------+
| Data Blocks             |
+-------------------------+

Every modern filesystem has something similar.

Step 1 — Create a Virtual Disk

Instead of modifying a real hard drive, we'll use a normal file.

disk.img

Think of it as pretending this file is an SSD.

disk.img

+------------------------------------------+
|                                          |
|             Raw Bytes                    |
|                                          |
+------------------------------------------+

We can open it using normal C functions.

FILE *disk = fopen("disk.img", "rb+");

int fd = open("disk.img", O_RDWR);

Every read and write will modify the virtual disk.

Step 2 — Design the Disk Layout

Before writing code, always design the filesystem.

Never start coding first.

Example layout:

Block 0
----------------
Superblock

Blocks 1-8
----------------
Bitmap

Blocks 9-40
----------------
Inode Table

Blocks 41+
----------------
File Data

Everything begins with a good layout.

Step 3 — Superblock

The superblock is the brain of the filesystem.

It stores global information.

Superblock

Magic Number
Version
Block Size
Total Blocks
Free Blocks
Inode Count
Free Inodes
Bitmap Start
Inode Start
Data Start

Whenever the filesystem mounts, it reads the superblock first.

Without it, nothing else can be understood.

Step 4 — Blocks

Instead of storing files continuously, we store them in blocks.

Example:

File

Hello World!

Stored as

Block 90

A larger file:

Block 90
Block 91
Block 92
Block 93

Large files simply occupy more blocks.

Step 5 — Free Space Management

How does the filesystem know which blocks are free?

Using a bitmap.

Example:

Block Number

0 1 2 3 4 5 6 7

Bitmap

1 1 0 0 1 0 0 0

Meaning:

1 = Used
0 = Free

Finding free space becomes easy.

Search bitmap

↓

00100000

↓

Found!

Allocate Block 2

This technique is used in ext2, ext3, ext4, FAT, and many other filesystems.

Step 6 — Inodes

The inode is the heart of every Unix filesystem.

It stores metadata—not the filename.

Example:

inode

File Size

Permissions

Owner

Creation Time

Modified Time

Block Pointers

Notice something missing?

The filename.

Linux stores filenames separately inside directories.

Step 7 — Direct Block Pointers

Small files are easy.

inode

Block 91

Block 92

Block 93

Block 94

Each pointer references one data block.

Reading the file is straightforward.

Read inode

↓

Read block pointers

↓

Read data

Step 8 — File Growth

Eventually a file becomes larger.

Before

inode

91

92

93

94

Now write more data.

Filesystem

↓

Find Free Block

↓

Allocate

↓

Update Bitmap

↓

Update Inode

↓

Increase File Size

Growing a file is simply allocating additional blocks and updating metadata.

Step 9 — Indirect Pointers

Direct pointers eventually run out.

Linux solves this with indirect blocks.

inode

Direct

Direct

Direct

Indirect
        |
        v

+--------------------+
|101|102|103|104|...|
+--------------------+

Instead of pointing to data, the inode points to another block containing many more block numbers.

This allows files to grow into gigabytes or even terabytes.

Step 10 — Directories

A directory is just another file.

Instead of storing text, it stores mappings.

Filename

↓

Inode Number

Example:

notes.txt

↓

inode 15

photo.png

↓

inode 42

movie.mp4

↓

inode 80

The operating system first finds the inode, then reads the file.

Step 11 — Reading a File

The process is surprisingly simple.

Open File

↓

Find Directory Entry

↓

Get Inode Number

↓

Read Inode

↓

Read Block Pointers

↓

Read Data Blocks

↓

Return Bytes

This sequence happens every time you open a file.

Step 12 — Deleting a File

Deleting does not erase the data immediately.

Instead:

Remove Directory Entry

↓

Free Blocks in Bitmap

↓

Free Inode

↓

Mark Space Available

The old bytes often remain until overwritten.

Step 13 — Formatting the Filesystem

Before using the disk, it must be formatted.

Formatting means:

Create the superblock
Initialize the bitmap
Create empty inode table
Reserve metadata blocks
Mark remaining blocks as free

After formatting, the filesystem is ready.

Step 14 — Features to Add Later

Once the core filesystem works, you can implement advanced features.

Symbolic Links

myfile

↓

inode

↓

Target Path

Hard Links

Multiple filenames pointing to the same inode.

fileA

↓

inode 12

↑

fileB

Journaling

Protects against crashes.

Write Journal

↓

Write Real Data

↓

Commit

If the system crashes, unfinished operations can be replayed safely.

Permissions

Store Unix permissions.

rwxr-xr-x

Timestamps

Maintain:

Creation time
Modification time
Access time

Nested Directories

Support structures like:

/

home/

home/user/

home/user/docs/

home/user/docs/file.txt

Suggested Development Order

Don't try to build everything at once.

Follow this roadmap:

Create disk.img
Define block size
Implement disk read/write functions
Create the superblock
Implement bitmap-based free space management
Build the inode table
Create files
Read files
Write files
Delete files
Implement file growth
Add directories
Support nested directories
Add indirect pointers
Add journaling
Add caching
Optimize performance

Each milestone builds on the previous one, making debugging much easier.

Final Thoughts

Building a filesystem is one of the most rewarding systems programming projects you can undertake. It combines low-level C programming, binary data structures, memory management, and operating system concepts into a single, practical project.

You'll stop thinking of files as mysterious objects managed by the OS and start seeing them for what they really are: carefully organized blocks of bytes, tracked by metadata and allocation structures.

If you can build a filesystem from scratch, you'll gain a much deeper understanding of how Linux works internally—and you'll develop the skills needed for advanced areas like kernel development, storage engines, databases, embedded systems, and operating system design.

Every byte on a disk has a purpose. Your job as a filesystem developer is to decide what that purpose should be.

How to Become a System Programmer in 2026

Farhad Rahimi Klie — Sun, 02 Aug 2026 10:57:47 +0000

Stop chasing frameworks. Start understanding the machine.

Most developers spend years learning frameworks, libraries, and APIs. Yet very few understand what actually happens after they press Compile or Run.

System programmers are different.

They build operating systems, databases, compilers, virtual machines, device drivers, networking software, embedded systems, hypervisors, game engines, and high-performance applications. They work closer to the hardware than almost any other software engineer.

In 2026, as AI generates more application code than ever before, developers who understand computers at the lowest levels are becoming increasingly valuable.

This article provides a practical roadmap to becoming a system programmer.

What Is System Programming?

System programming is the art of writing software that interacts directly with the operating system or hardware.

Instead of building websites or mobile apps, system programmers create software such as:

Operating systems
Kernels
Device drivers
File systems
Compilers
Linkers
Assemblers
Database engines
Virtual machines
Hypervisors
Networking software
Embedded firmware
Performance-critical libraries

These programs manage computer resources and provide services that application software depends on.

Why System Programming Matters More Than Ever

Many developers worry that AI will replace programmers.

AI can generate CRUD applications.

AI can build websites.

AI can write boilerplate code.

But AI still struggles with:

Operating system internals
CPU architecture
Memory management
Performance optimization
Lock-free algorithms
Kernel development
Compiler optimization
Hardware communication

These require deep understanding rather than memorization.

The closer you are to the hardware, the harder you are to replace.

Step 1 — Master the C Language

If system programming has a native language, it is C.

Learn:

Variables
Pointers
Arrays
Structures
Memory layout
Bitwise operators
Function pointers
Dynamic memory allocation
Header files
Build systems

Don't just memorize syntax.

Understand what every line becomes in memory.

You should know exactly why this works:

int *ptr = malloc(sizeof(int));

Not just that it works.

Step 2 — Learn Computer Architecture

A system programmer must understand the machine.

Study:

CPU execution
Registers
Cache hierarchy
Virtual memory
Paging
Stack vs Heap
Calling conventions
Assembly language
Interrupts
Pipelines

Books worth reading:

Computer Systems: A Programmer's Perspective
Computer Organization and Design
Modern Operating Systems

Step 3 — Become a Linux Power User

Windows is fine.

Linux is essential.

Spend every day inside Linux.

Learn:

Shell scripting
Bash
File permissions
Processes
Signals
Pipes
Redirection
ELF binaries
Package managers
System services

Use the terminal constantly.

If you can solve a problem without opening a GUI, do it.

Step 4 — Learn POSIX System Calls

Applications eventually communicate with the kernel through system calls.

Start with:

open()
close()
read()
write()
lseek()
mmap()
fork()
execve()
wait()
pipe()
dup()
socket()

Understand:

File descriptors
Buffers
Kernel transitions
User space vs Kernel space

Step 5 — Understand Memory

Memory separates beginner programmers from professionals.

Study:

Stack
Heap
Static memory
Memory alignment
Fragmentation
malloc()
calloc()
realloc()
free()
Memory leaks
Buffer overflows

Tools to master:

Valgrind
AddressSanitizer
GDB

Step 6 — Learn Data Structures From Scratch

Don't rely on library implementations.

Implement yourself:

Dynamic Arrays
Linked Lists
Stacks
Queues
Hash Tables
Binary Trees
AVL Trees
Red-Black Trees
Heaps
Tries
Skip Lists
Graphs

Then optimize them.

Measure their performance.

Step 7 — Study Operating System Internals

Every system programmer should know how an operating system works.

Topics include:

Process scheduling
Context switching
Virtual memory
File systems
Kernel architecture
Synchronization
Deadlocks
IPC
Threads
Scheduling algorithms

Read source code.

Linux is one of the greatest learning resources available.

Step 8 — Learn Networking

Computers rarely work alone.

Study:

TCP/IP
UDP
DNS
HTTP
HTTPS
Routing
Sockets
Epoll
Poll
Select

Build:

HTTP server
Chat server
File server

Step 9 — Learn Debugging

Professional programmers spend less time writing code than debugging it.

Master:

GDB
strace
ltrace
perf
objdump
nm
readelf

Learn to inspect:

Memory
Registers
Stack frames
Assembly
Core dumps

Step 10 — Read Source Code Every Day

The fastest way to improve is reading production-quality code.

Great projects include:

Linux Kernel
Git
SQLite
Redis
musl libc
BusyBox
Vim
Nginx
PostgreSQL

Professional programmers read code more often than they write it.

Step 11 — Build Real Projects

Projects teach lessons tutorials cannot.

Ideas:

Mini Shell
Memory Allocator
Text Editor
HTTP Server
File System
Thread Pool
Skip List Library
JSON Parser
Compiler
Virtual Machine
Toy Operating System
Custom malloc()

Each project exposes new challenges.

Step 12 — Learn Performance Engineering

Fast software wins.

Understand:

Cache locality
Branch prediction
SIMD
Compiler optimization
False sharing
Memory bandwidth
CPU profiling

Benchmark everything.

Never assume.

Measure.

Step 13 — Learn Assembly

You don't need to become an assembly expert.

But you should be able to read it.

Learn:

x86-64
ARM64
Calling conventions
Stack frames
Registers

Compile C programs with:

gcc -S program.c

Then compare your C code with the generated assembly.

Step 14 — Learn How Compilers Work

Compilers transform human-readable code into machine instructions.

Study:

Lexical analysis
Parsing
AST
Semantic analysis
Intermediate Representation (IR)
Optimization
Code generation

Building a tiny compiler will change the way you write code forever.

Step 15 — Never Stop Building

Knowledge without projects fades quickly.

Build something every month.

Examples:

Shell
Database
Cache
Compiler
Kernel module
TCP server
Memory allocator
Scheduler simulator

Experience compounds.

A Recommended Learning Roadmap

Beginner (0–3 Months)

C
Linux
Git
Bash
Makefiles

Intermediate (3–9 Months)

Data Structures
Pointers
Memory
System Calls
Debugging

Advanced (9–18 Months)

Operating Systems
Networking
Compilers
Concurrency
Performance Optimization

Expert (18+ Months)

Kernel Development
Database Internals
Distributed Systems
Virtual Machines
Embedded Systems

Final Thoughts

System programming isn't the easiest path—but it's one of the most rewarding.

It teaches you how computers actually work, not just how to use them. Every layer you master—from pointers and memory management to kernels and compilers—makes you a stronger engineer.

Frameworks will evolve. Languages will rise and fall. AI will continue to automate routine coding.

But developers who understand operating systems, hardware, performance, and low-level software will continue to solve the hardest engineering problems.

Don't aim to become someone who can simply write code.

Aim to become someone who understands the machine.

That's what separates a programmer from a system programmer.

How to Read Linux Man Pages Like a Professional Developer

Farhad Rahimi Klie — Fri, 17 Jul 2026 11:02:29 +0000

Stop searching Google for every Linux command. Learn how to read the official documentation that Linux developers use every day.

If you've ever typed:

man ls

and immediately closed it because it looked confusing...

You're not alone.

Many beginners think Linux man pages are difficult, outdated, or only for advanced developers.

The truth is completely different.

Professional Linux developers, system administrators, DevOps engineers, and C programmers read man pages every single day.

Learning to read them properly is one of the best skills you can develop.

After reading this guide you'll know:

What a man page actually is
Why man pages exist
How they're organized
How to navigate efficiently
How to search inside them
How to understand the syntax
How professionals read documentation quickly

Let's begin.

What Is a Linux Man Page?

Man stands for Manual.

A man page is the official documentation for a Linux command, system call, library function, configuration file, or programming interface.

Instead of searching random websites, Linux provides documentation directly on your computer.

For example:

man cp

opens the complete manual for the cp command.

Think of it as an offline encyclopedia built into Linux.

Why Were Man Pages Created?

Linux contains thousands of commands.

Nobody can remember every option.

Instead of memorizing everything, developers simply read the documentation whenever they need it.

Man pages are:

Official
Accurate
Installed locally
Available without Internet
Updated with software packages

This makes them one of the most reliable documentation sources available.

What Can You Find in Man Pages?

Man pages aren't only for commands.

They also document:

Linux commands
C library functions
System calls
Configuration files
Device files
File formats
Games
Administration commands

Examples:

man ls

Documentation for ls

man printf

Documentation for the shell version of printf

man 3 printf

Documentation for the C library function.

Understanding Man Sections

Linux organizes documentation into sections.

Section	Description
1	User Commands
2	System Calls
3	Library Functions (C)
4	Device Files
5	File Formats
6	Games
7	Miscellaneous
8	System Administration

Example:

man 2 open

Shows the Linux system call.

While

man 3 open

may show a library function if one exists.

This distinction is especially important for C programmers.

Opening a Man Page

Simply type:

man command

Example:

man grep

Linux opens the manual using a pager called less.

The Basic Structure of Every Man Page

Although every page is different, most follow the same structure.

NAME

The command name and a short description.

Example:

grep - print lines matching patterns

Always read this first.

SYNOPSIS

Shows the command syntax.

Example:

grep [OPTION]... PATTERN [FILE]...

This line tells you how to use the command.

Let's decode it.

Square Brackets

[OPTION]

Means optional.

You may include it or not.

Three Dots (...)

[FILE]...

Means multiple values are allowed.

Example:

grep hello file1 file2 file3

Uppercase Words

FILE
PATTERN

These are placeholders.

Replace them with your own values.

Vertical Bar

Sometimes you'll see

A | B

Choose one.

Not both.

DESCRIPTION

This explains what the command actually does.

Don't skip it.

Professionals usually read this section before anything else.

OPTIONS

This is where you'll spend most of your time.

Example:

-i

Ignore case.

-r

Recursive search.

-v

Invert match.

Example:

grep -ri hello project/

Read each option carefully.

EXAMPLES

Some man pages include examples.

Unfortunately many don't.

That's why understanding the syntax is important.

EXIT STATUS

Commands return an exit code.

Usually:

Success.

General failure.

Specific error.

This is very useful when writing shell scripts.

FILES

Shows which files the command uses.

Example:

Configuration files.

Cache files.

Database files.

Runtime files.

ENVIRONMENT

Lists environment variables that affect the command.

Example:

PATH
HOME
LANG

How to Navigate Inside a Man Page

Once opened, use these keys.

Key	Action
Space	Next page
b	Previous page
Enter	Next line
g	Top of document
G	Bottom of document
q	Quit
h	Help

These few shortcuts are enough for daily use.

Searching Inside a Man Page

Searching is one of the most useful features.

Press:

Then type a word.

Example:

/recursive

Press:

Enter

Go to the next match:

Previous match:

This saves a huge amount of time.

Searching for Man Pages

Don't know the command name?

Use:

man -k copy

Output:

cp
install
dd
rsync

Linux searches manual descriptions.

What If Multiple Man Pages Exist?

Use:

man -a printf

Linux will show every available manual page.

Viewing the File Location

Want to know where the documentation lives?

man -w ls

Example output:

/usr/share/man/man1/ls.1.gz

Reading C Programming Documentation

If you're a C programmer, this is one of the most important skills.

Instead of searching online for a function:

malloc()

Read its manual:

man 3 malloc

You'll learn:

Parameters
Return value
Errors
Examples
Standards
Thread safety

Other useful examples:

man 2 read
man 2 write
man 2 open
man 2 close
man 3 fopen
man 3 printf
man 3 pthread_create

A Professional Reading Workflow

Experienced developers rarely read an entire man page from top to bottom.

Instead, they follow a focused workflow:

Read NAME to understand the command's purpose.
Check SYNOPSIS to learn the required syntax.
Read DESCRIPTION for behavior and limitations.
Jump to OPTIONS and review only the flags you need.
Use / to search for keywords related to your task.
Look at SEE ALSO to discover related commands or APIs.

This approach is much faster than reading every section sequentially.

Common Beginner Mistakes

Reading Every Line

Most man pages are reference documents, not tutorials.

Read only the sections relevant to your current task.

Ignoring SYNOPSIS

The syntax line explains how to use the command correctly.

Always study it before trying examples.

Not Using Search

Searching with / is significantly faster than scrolling through long pages.

Ignoring SEE ALSO

Many useful Linux tools are discovered through this section.

Depending Only on Google

Search engines often lead to outdated or incomplete information.

The man page installed on your system matches the software version you're using.

Best Commands to Practice Reading

Start with these commands:

man ls
man cp
man mv
man rm
man cat
man pwd
man cd
man grep
man sed
man awk
man find
man chmod
man chown
man tar
man gzip

If you're learning C on Linux:

man 2 open
man 2 read
man 2 write
man 2 mmap
man 2 fork
man 2 execve
man 3 malloc
man 3 free
man 3 printf
man 3 fopen

Final Thoughts

Learning Linux isn't about memorizing every command or every option. It's about knowing where to find reliable information when you need it.

The man command gives you direct access to the official documentation for your system. Once you're comfortable reading the NAME, SYNOPSIS, DESCRIPTION, and OPTIONS sections—and using search effectively—you'll spend less time hunting for answers online and more time understanding how Linux actually works.

Whether you're a Linux beginner, a system administrator, a DevOps engineer, or a C programmer building low-level software, mastering man pages is a skill that will continue to pay off throughout your career.

50 Most Used Linux Commands for Programmers

Farhad Rahimi Klie — Sun, 05 Jul 2026 03:33:42 +0000

Linux is the backbone of modern development environments—from backend servers to DevOps pipelines and cloud systems. Whether you’re writing code, debugging applications, or managing servers, mastering Linux commands significantly boosts productivity.

Below are 50 essential Linux commands every programmer should know, grouped by purpose for easier learning.

1. File and Directory Navigation

These commands help you move around the filesystem quickly and efficiently.

1. pwd
Prints the current working directory. Useful when you’re lost in nested folders.

2. ls
Lists files and directories. Add -l for detailed view or -a to show hidden files.

3. cd
Changes directory. Example: cd /var/www.

4. tree
Displays directory structure in a tree format (may need installation).

5. find
Searches for files and directories based on conditions like name or type.

2. File Operations

These are used constantly in development workflows.

6. touch
Creates an empty file or updates timestamp.

7. cp
Copies files or directories.

8. mv
Moves or renames files.

9. rm
Deletes files or directories. Use carefully.

10. mkdir
Creates a new directory.

11. rmdir
Removes empty directories.

3. File Viewing and Text Processing

Crucial for reading logs, configs, and code files.

12. cat
Displays file content.

13. less
View large files page by page.

14. head
Shows first 10 lines of a file.

15. tail
Shows last 10 lines (useful for logs).

16. nano
Simple terminal text editor.

17. vim
Powerful advanced text editor widely used by developers.

4. Permissions and Ownership

Important for security and server management.

18. chmod
Changes file permissions.

19. chown
Changes file owner and group.

20. umask
Sets default permissions for new files.

5. Process Management

Used for monitoring and controlling running applications.

21. ps
Displays running processes.

22. top
Real-time system process monitoring.

23. htop
Improved version of top (interactive UI).

24. kill
Terminates a process by PID.

25. pkill
Kills process by name.

26. jobs
Shows background jobs.

27. fg
Brings background job to foreground.

28. bg
Resumes a stopped job in background.

6. Networking Commands

Essential for APIs, servers, and debugging network issues.

29. ping
Checks connectivity to a host.

30. curl
Transfers data from/to servers via HTTP.

31. wget
Downloads files from the web.

32. netstat
Shows network connections and ports.

33. ss
Modern replacement for netstat.

34. ifconfig
Displays network interfaces (deprecated but still used).

35. ip
Modern tool for network configuration.

7. Disk and Storage

For managing space and file systems.

36. df
Shows disk space usage.

37. du
Shows directory size.

38. lsblk
Lists block devices (disks, partitions).

39. mount
Mounts file systems.

40. umount
Unmounts file systems.

8. Compression and Archiving

Useful for backups and deployments.

41. tar
Creates and extracts archives.

42. zip
Compresses files into .zip format.

43. unzip
Extracts zip files.

44. gzip
Compresses files using gzip.

45. gunzip
Decompresses gzip files.

9. System Information

Helpful for understanding system state.

46. uname
Displays system information.

47. uptime
Shows how long system has been running.

48. whoami
Displays current user.

49. history
Shows previously executed commands.

50. alias
Creates shortcuts for long commands.

Final Thoughts

These 50 Linux commands form a strong foundation for any programmer working in Linux environments. You don’t need to memorize everything at once—start with navigation, file operations, and process management, then gradually expand into networking and system tools.

With regular use, these commands become muscle memory and significantly improve your speed, debugging ability, and overall workflow efficiency.

10 Essential C Programming Concepts Every Beginner Should Learn

Farhad Rahimi Klie — Sat, 20 Jun 2026 02:10:03 +0000

When people start learning C, they often get overwhelmed by the large amount of syntax and concepts. The truth is that you don't need to learn everything at once.

If you understand the following 10 concepts well, you'll already have a strong foundation in C programming and be ready to learn more advanced topics later.

1. Variables and Data Types

Variables are used to store information in memory.

int age = 20;
float salary = 5000.5;
char grade = 'A';

Common data types:

int → stores whole numbers
float → stores decimal numbers
double → stores larger decimal numbers with more precision
char → stores a single character

Without variables, a program cannot store or manipulate data.

2. Input and Output

Input allows users to provide data, while output displays information on the screen.

printf("Hello World");

scanf("%d", &age);

Important functions:

printf() → prints output
scanf() → reads user input

These functions allow your program to communicate with users.

3. Conditional Statements (if / else)

Conditional statements allow programs to make decisions.

if(age >= 18)
{
    printf("Adult");
}
else
{
    printf("Child");
}

Programs become useful when they can react differently based on different situations.

4. Loops

Loops execute code repeatedly.

for(int i = 0; i < 5; i++)
{
    printf("%d\n", i);
}

Common loop types:

for
while
do-while

Loops help automate repetitive tasks efficiently.

5. Functions

Functions group related code into reusable blocks.

int add(int a, int b)
{
    return a + b;
}

Usage:

int result = add(5, 3);

Benefits:

Code reuse
Better organization
Easier maintenance

Professional software is built using many functions.

6. Arrays

Arrays store multiple values of the same type in a single variable.

int numbers[5] = {1, 2, 3, 4, 5};

Accessing elements:

numbers[0];
numbers[1];

Arrays are essential for managing collections of data.

7. Strings

A string is a sequence of characters.

char name[] = "John";

In C, strings are actually arrays of characters ending with a special character called the null terminator (\0).

Strings are used everywhere, from usernames to file names and messages.

8. Pointers

Pointers store memory addresses.

int x = 10;

int *ptr = &x;

Accessing the value:

printf("%d", *ptr);

Pointers are one of the most powerful features of C because they allow direct interaction with memory.

Understanding pointers helps you understand how computers actually work behind the scenes.

9. Structures (Structs)

Structures allow you to create custom data types.

struct Student
{
    char name[50];
    int age;
};

Usage:

struct Student s1;
s1.age = 20;

Structs are useful when you need to group related information together.

For example:

Student records
Employee records
Product information

10. Dynamic Memory Allocation

Sometimes you don't know how much memory you need until the program runs.

That's where dynamic memory allocation comes in.

int *numbers = malloc(10 * sizeof(int));

When finished:

free(numbers);

Important functions:

malloc()
calloc()
realloc()
free()

Dynamic memory allocation is heavily used in real-world software, databases, operating systems, and many advanced applications.

Final Thoughts

If you're learning C, focus on mastering these five topics first:

Functions
Arrays
Strings
Pointers
Dynamic Memory Allocation

These concepts form the core of C programming and will make learning advanced topics much easier.

Remember: Great programmers are not the ones who memorize the most syntax. They are the ones who understand how data, memory, and logic work together.

# How to Build Your Own Operating System from Scratch in C

Farhad Rahimi Klie — Wed, 17 Jun 2026 12:27:02 +0000

Building your own Operating System (OS) is one of the most challenging and rewarding projects in computer science. It teaches you how computers really work beneath the applications and frameworks we use every day.

In this article, we'll explore the complete roadmap for creating an operating system from scratch using the C programming language.

What Is an Operating System?

An Operating System is software that manages computer hardware and provides services to applications.

Popular operating systems include:

Linux
Windows
macOS
FreeBSD

An OS is responsible for:

Process management
Memory management
File systems
Device drivers
User interfaces
Hardware abstraction

Without an operating system, applications cannot easily communicate with hardware.

Prerequisites

Before building an operating system, you should understand:

Programming Languages

C

C is the primary language used for kernel development because it provides:

Direct memory access
Low-level control
High performance
Minimal runtime dependencies

Assembly

Assembly is required for:

Bootloader development
CPU initialization
Interrupt handling
Context switching

Computer Science Fundamentals

You should know:

Data Structures

Arrays
Linked Lists
Stacks
Queues
Trees
B-Trees
Hash Tables
Bitmaps

Algorithms

Searching
Sorting
Scheduling algorithms
Memory allocation algorithms

Understanding Computer Architecture

Operating systems interact directly with hardware.

Important topics:

CPU

Learn:

Registers
Instructions
Privilege levels
Interrupts
Exceptions

Memory

Understand:

RAM
Virtual Memory
Paging
Segmentation
Memory Mapping

Storage

Learn about:

Hard Drives
SSDs
File Systems

Development Environment

Install:

Compiler

GCC Cross Compiler

Example:

x86_64-elf-gcc

Using a cross-compiler prevents your host operating system from interfering with kernel compilation.

Assembler

NASM

Used for writing assembly code.

Emulator

QEMU

Allows testing your operating system safely.

Example:

qemu-system-x86_64

Debugger

GDB

Used for debugging kernel code.

Operating System Architecture

A basic operating system consists of:

+----------------+
| Applications   |
+----------------+
| System Calls   |
+----------------+
| Kernel         |
+----------------+
| Drivers        |
+----------------+
| Hardware       |
+----------------+

Step 1: Create a Bootloader

When a computer starts:

BIOS/UEFI executes.
Bootloader loads.
Bootloader loads kernel into memory.
Kernel starts running.

Simple bootloader example:

[BITS 16]
[ORG 0x7C00]

mov ah, 0x0E
mov al, 'H'
int 0x10

jmp $

times 510-($-$$) db 0
dw 0xAA55

This displays the letter H on the screen.

Step 2: Create the Kernel Entry Point

Kernel entry:

void kernel_main()
{
    while (1)
    {
    }
}

This is the first C function executed by the kernel.

Step 3: Display Text on Screen

Using VGA text mode:

#define VGA_MEMORY ((unsigned short*)0xB8000)

void print_char(char c)
{
    VGA_MEMORY[0] = (0x0F << 8) | c;
}

Usage:

print_char('A');

You should now see a character displayed on the screen.

Step 4: Build a Terminal

A terminal allows user interaction.

Features:

Print text
Read keyboard input
Execute commands

Example:

myOS>

Commands:

help
clear
version

Step 5: Keyboard Driver

The keyboard generates interrupts.

Kernel responsibilities:

Read scan codes
Convert to characters
Send input to terminal

Example:

User presses A
↓
Keyboard Interrupt
↓
Kernel Receives Code
↓
Display A

Step 6: Interrupt Handling

Interrupts allow hardware to communicate with the CPU.

Examples:

Keyboard interrupt
Timer interrupt
Disk interrupt

Interrupt Descriptor Table (IDT):

struct idt_entry
{
    unsigned short offset_low;
    unsigned short selector;
    unsigned char zero;
    unsigned char flags;
    unsigned short offset_high;
};

Step 7: Memory Management

Memory management is one of the most important kernel subsystems.

Responsibilities:

Allocate memory
Free memory
Protect memory
Virtual memory mapping

Simple bitmap allocator:

unsigned char bitmap[1024];

Each bit represents a memory page.

Step 8: Physical Memory Manager

Tracks available RAM pages.

Functions:

void* alloc_page();
void free_page(void* ptr);

Step 9: Virtual Memory

Modern operating systems use paging.

Benefits:

Process isolation
Security
Larger address spaces

Virtual address:

0x400000

May map to:

0x1A3000

Physical memory.

Step 10: Process Management

A process is a running program.

Process structure:

struct process
{
    int pid;
    void* stack;
    void* page_directory;
};

Kernel responsibilities:

Create process
Destroy process
Schedule process

Step 11: Task Scheduler

Scheduler decides which process runs next.

Common algorithms:

Round Robin

P1 → P2 → P3 → P1

Priority Scheduling

High Priority First

Step 12: Context Switching

Switching between processes requires saving CPU state.

Save:

Registers
Stack Pointer
Instruction Pointer

Restore next process state.

This creates multitasking.

Step 13: System Calls

Applications communicate with the kernel using system calls.

Example:

write();
read();
open();
close();

Flow:

Application
↓
System Call
↓
Kernel
↓
Hardware

Step 14: File System

A file system stores data permanently.

Examples:

FAT12
FAT16
FAT32
EXT2
EXT4

Beginner recommendation:

FAT12

because it is simple to implement.

Basic operations:

open()
read()
write()
delete()

Step 15: Disk Driver

The kernel must communicate with storage devices.

Responsibilities:

Read sectors
Write sectors
Cache data

Example:

read_sector();
write_sector();

Step 16: User Mode and Kernel Mode

Modern CPUs support privilege levels.

Kernel Mode:

Ring 0

User Mode:

Ring 3

Benefits:

Security
Stability
Isolation

Step 17: ELF Executable Loader

ELF is a common executable format.

The loader:

Reads executable.
Maps memory.
Creates process.
Starts execution.

Step 18: Device Drivers

Drivers communicate with hardware.

Examples:

Keyboard
Mouse
Audio
Network
Graphics

Step 19: Networking

Networking requires implementing:

Ethernet
ARP
IP
ICMP
UDP
TCP

Example stack:

Application
↓
TCP
↓
IP
↓
Ethernet

Step 20: Graphical User Interface

After the kernel is stable:

Build:

Framebuffer driver
Window manager
Fonts
Mouse support

Simple GUI architecture:

Desktop
 ├── Window
 ├── Window
 └── Window

Recommended Project Roadmap

Follow this order:

Bootloader
Kernel Entry
VGA Text Output
Keyboard Driver
Terminal
IDT
Timer
Physical Memory Manager
Paging
Heap Allocator
Processes
Scheduler
System Calls
FAT12 File System
ELF Loader
User Programs
Networking
GUI

Useful Resources

Recommended books:

Operating Systems: Three Easy Pieces
Modern Operating Systems
Operating System Concepts
Computer Systems: A Programmer's Perspective
Intel Software Developer Manual

Recommended websites:

OSDev Wiki
LittleOSBook
BrokenThorn OS Development Series

Final Thoughts

Building an operating system is a long-term project that can take months or even years. Start small. Focus first on booting the machine, printing text, handling the keyboard, and managing memory. Once those fundamentals are working, gradually add multitasking, file systems, networking, and eventually a graphical interface.

The most important advice is simple: build one subsystem at a time. Every modern operating system, from Linux to Windows, started as a small kernel capable of doing only a few basic tasks. With patience and consistency, you can build your own operating system from scratch in C and gain a deep understanding of how computers truly work.

Data Structures Used in Database Development: The Foundations Behind Every Database Engine

Farhad Rahimi Klie — Thu, 04 Jun 2026 04:07:48 +0000

When people think about databases, they usually think about SQL, queries, tables, indexes, and transactions.

But underneath all of those features lies something even more fundamental:

Data Structures.

Every database engine—from PostgreSQL and MySQL to MongoDB and SQLite—is essentially a collection of carefully chosen data structures working together.

If you want to understand how databases really work—or build your own database engine from scratch—you need to understand the data structures that make modern databases possible.

In this article, we'll explore the most important data structures used in database development, why they exist, and where they are used.

Why Databases Need Specialized Data Structures

Imagine a database containing:

1 million rows
100 million rows
1 billion rows

A simple linear search through all records would be far too slow.

Databases must solve several critical problems:

Fast lookups
Efficient inserts
Efficient updates
Fast range queries
Minimal disk I/O
Efficient memory usage
Concurrent access by many users

Different data structures solve different parts of these problems.

There is no single "perfect" data structure.

Instead, database engines combine multiple structures together.

1. Arrays

What is an Array?

An array is a contiguous block of memory containing elements of the same type.

int numbers[5] = {10,20,30,40,50};

Arrays provide:

O(1) random access
Cache-friendly memory layout
Simple implementation

Where Databases Use Arrays

Arrays appear everywhere inside database engines:

Buffer Pools

Databases load disk pages into memory.

Buffer Pool

[Page 1]
[Page 2]
[Page 3]
[Page 4]

The buffer pool is often managed using arrays.

Query Execution

Intermediate query results frequently use arrays.

Example:

SELECT * FROM users;

Rows returned by the executor may temporarily be stored in array-like structures.

Columnar Databases

Column stores often keep values in arrays:

Age Column

20
25
30
40
50

This layout enables efficient analytics.

2. Linked Lists

What is a Linked List?

A linked list stores elements connected through pointers.

[Node] -> [Node] -> [Node]

Each node contains:

struct Node {
    int value;
    struct Node* next;
};

Where Databases Use Linked Lists

Buffer Management

Many databases maintain free pages using linked lists.

Free Page List

Page 5 -> Page 8 -> Page 10

Transaction Management

Active transactions are often tracked through linked structures.

Memory Allocators

Database memory managers frequently organize free blocks using linked lists.

3. Hash Tables

What is a Hash Table?

A hash table maps:

Key -> Value

through a hash function.

Example:

"Ali" -> 102
"Sara" -> 211

Why Databases Love Hash Tables

Hash tables provide nearly:

O(1)

lookup time.

This makes them ideal for exact-match searches.

Where Hash Tables Are Used

Query Execution

Hash Join:

SELECT *
FROM orders
JOIN customers
ON orders.customer_id = customers.id;

Database builds a hash table for one side of the join.

Query Cache

Many engines use hash tables for:

Query -> Result

mapping.

Metadata Lookup

Finding:

tables
indexes
columns
users

is often done through hash structures.

Limitation

Hash tables cannot efficiently perform:

WHERE age BETWEEN 20 AND 30

Range queries require ordered structures.

That's why databases also use trees.

4. Binary Search Trees (BST)

A BST stores values in sorted order.

        50
       /  \
     25    75

Properties:

Left < Root < Right

Why Databases Rarely Use Plain BSTs

A normal BST can become:

Performance degrades to:

O(n)

Therefore databases prefer balanced trees.

5. AVL Trees

AVL Trees automatically balance themselves.

      30
     /  \
   20   40

Height remains controlled.

Database Usage

AVL trees are sometimes used in:

in-memory indexes
metadata structures
cache management

However, they are less common for large disk-based indexes.

6. Red-Black Trees

Red-Black Trees are balanced binary search trees.

Operations:

Search  O(log n)
Insert  O(log n)
Delete  O(log n)

Where Used

Many database internals use Red-Black Trees for:

lock management
transaction tracking
memory management
scheduling structures

7. B-Trees

This is where databases become interesting.

B-Trees are arguably the most important data structure in database history.

The Problem

Disk access is expensive.

Reading one node per disk access would be too slow.

The Solution

Store many keys in one node.

|10|20|30|40|

Each node contains multiple keys.

This dramatically reduces tree height.

Example

Instead of:

Height = 20

you might get:

Height = 3

for millions of records.

Why Databases Use B-Trees

Advantages:

Fast lookup
Fast insertion
Fast deletion
Excellent range queries
Minimal disk reads

Used In

Traditional database indexes:

CREATE INDEX idx_users_name
ON users(name);

Often becomes a B-Tree index internally.

8. B+ Trees

Most modern databases actually use B+ Trees.

Not plain B-Trees.

Structure

Internal nodes:

Only keys

Leaf nodes:

Actual records

Leaf Nodes Are Linked

[Leaf1] <-> [Leaf2] <-> [Leaf3]

This is extremely important.

Why?

Range queries become very fast.

Example:

SELECT *
FROM users
WHERE age BETWEEN 20 AND 40;

Database finds the first record and then scans linked leaf pages.

Used By

MySQL InnoDB
SQLite
Many relational databases

B+ Trees are arguably the king of database indexing.

9. LSM Trees (Log-Structured Merge Trees)

Modern databases face a different challenge:

Massive write workloads.

Problem

Updating a B+ Tree repeatedly causes random disk writes.

Random writes are expensive.

Solution

LSM Trees.

Writes first go to memory.

MemTable

Later they are flushed to disk.

SSTables

Background processes merge files.

Benefits

Excellent write performance.

Ideal for:

Logging systems
Analytics systems
Distributed databases

Used By

10. Skip Lists

A Skip List is a probabilistic alternative to balanced trees.

Level 3 ------
Level 2 ------
Level 1 ------
Level 0 ------

Multiple layers accelerate searching.

Advantages

Simpler implementation
Good performance
Easy concurrent operations

Used By

Redis sorted sets
Some in-memory databases

11. Tries (Prefix Trees)

A Trie stores strings character by character.

Example:

car
cat
can

Shared prefixes are reused.

Database Usage

Useful for:

Full-text search
Autocomplete
Dictionary lookups
Query suggestions

Example

c
|
a
|
+--r
+--t
+--n

12. Heaps (Priority Queues)

A Heap allows quick access to:

Smallest
or
Largest

element.

Database Usage

Query Optimization

Database planners choose execution strategies using priority structures.

Top-K Queries

ORDER BY score DESC
LIMIT 10;

Heaps help efficiently maintain the top results.

13. Bloom Filters

A Bloom Filter is a probabilistic structure.

It answers:

"Possibly exists"
or
"Definitely does not exist"

Why Useful

Avoids unnecessary disk reads.

Used By

Cassandra
RocksDB
BigTable-inspired systems

Benefit

A tiny memory footprint can save huge amounts of I/O.

14. Graph Structures

Graph databases use nodes and edges.

Alice ---- Friend ---- Bob

Used By

Perfect For

Social networks
Recommendation systems
Fraud detection
Knowledge graphs

Importance Ranking for Database Engine Developers

If your goal is to build a database engine from scratch, focus on these first:

Data Structure	Importance
Arrays	⭐⭐⭐⭐⭐
Linked Lists	⭐⭐⭐⭐
Hash Tables	⭐⭐⭐⭐⭐
Binary Search Trees	⭐⭐⭐
AVL Trees	⭐⭐⭐
Red-Black Trees	⭐⭐⭐⭐
B-Trees	⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
B+ Trees	⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
LSM Trees	⭐⭐⭐⭐⭐⭐⭐
Skip Lists	⭐⭐⭐⭐⭐
Tries	⭐⭐⭐⭐
Heaps	⭐⭐⭐
Bloom Filters	⭐⭐⭐⭐⭐
Graph Structures	Depends on DB type

Final Thoughts

Database engines are not magical systems. At their core, they are sophisticated combinations of data structures designed to optimize storage, retrieval, indexing, caching, concurrency, and disk access.

If you want to become a database engineer, your learning path should look roughly like this:

Arrays
Linked Lists
Stacks & Queues
Hash Tables
Trees
AVL Trees
Red-Black Trees
B-Trees
B+ Trees
Heaps
Tries
Bloom Filters
Skip Lists
LSM Trees

Master these structures, and you'll begin to see database engines not as black boxes, but as collections of elegant algorithms and data structures working together to manage data at scale.

How I’d Become a Programmer in 2026 (If I Had to Start From Zero)

Farhad Rahimi Klie — Tue, 26 May 2026 05:30:49 +0000

Imagine this.

You wake up tomorrow and lose everything related to your programming journey.

No degree.
No experience.
No connections.
No audience.
No money.

Just you, a laptop, and internet access.

Could you still become a programmer in 2026?

My answer is yes.

Not because becoming a developer is easy, but because the path today is more accessible than ever before. The problem is not lack of information anymore. The real problem is overload.

Too many tutorials.
Too many opinions.
Too many frameworks.
Too many people telling beginners to learn everything at once.

If I had to restart from zero in 2026, this is exactly how I would do it.

Step 1: Stop Trying to Learn Everything

This is the first mistake almost every beginner makes.

They open YouTube and suddenly see:

“Learn Python”
“Become an AI Engineer”
“Learn Rust”
“Master Kubernetes”
“Become Full Stack in 30 Days”
“Top 10 Frameworks You Need”

And then they panic.

So they start 15 different courses and finish none of them.

Programming is not hard because of coding itself.
Programming is hard because beginners constantly switch directions.

If I started again, I would choose ONE path and ignore everything else for a while.

Focus creates progress.

Step 2: Learn the Fundamentals First

I would start with web development because it has:

low entry barriers
huge job opportunities
freelancing potential
endless learning resources

My beginner stack would look like this:

HTML
CSS
JavaScript
Git
React
Node.js

That’s it.

Not 20 languages.
Not 40 tools.

Just enough to become useful.

A lot of beginners underestimate fundamentals because they look “simple.” But strong fundamentals are what separate good developers from confused developers.

HTML teaches structure.
CSS teaches layout and design thinking.
JavaScript teaches logic and interactivity.

Everything builds on top of these.

Step 3: Forget Advanced Topics for the First Month

If I were a beginner again, I would completely avoid:

AI engineering
blockchain
microservices
DevOps complexity
system architecture

Not because these things are bad, but because they are distractions for beginners.

You do not learn programming by jumping into complexity immediately.

You learn programming by understanding simple things deeply.

Most people quit because they try to sprint through concepts they barely understand.

Your first month should simply focus on:

understanding variables
functions
loops
conditions
DOM manipulation
basic layouts
simple projects

That foundation matters more than people think.

Step 4: Code Every Single Day

This is probably the most important part.

Not motivation.
Not intelligence.
Not talent.

Consistency.

I’ve seen average programmers become amazing simply because they stayed consistent for years.

Meanwhile, talented people disappear because they stop practicing.

If I restarted in 2026, I would code daily even if it was only:

30 minutes
1 hour
2 hours

Small progress compounds massively over time.

Programming is a skill built through repetition.

You cannot watch your way into becoming a developer.

Step 5: Escape Tutorial Addiction Early

Tutorial addiction is one of the biggest hidden problems in tech.

You watch video after video after video and feel productive…

…but the moment you open an empty editor alone, your brain freezes.

Why?

Because watching is passive.
Building is active.

Tutorials should introduce concepts, not replace practice.

If I started again, I’d follow a very simple rule:

Learn something → build something with it immediately.

That single habit changes everything.

Step 6: Build Ugly Projects

This part is important.

Your first projects are supposed to look bad.

Seriously.

Most beginners quit because they compare their first project to applications built by senior engineers with 10 years of experience.

That comparison destroys confidence.

My first projects would probably include:

Calculator App
Todo App
Weather App
Notes App
Portfolio Website

Simple projects matter because they teach:

debugging
structure
persistence
problem-solving
project completion

Finishing projects is a superpower.

A lot of beginners start projects.
Very few finish them.

Step 7: Learn Git and GitHub Properly

In modern programming, coding is only part of the job.

Developers collaborate.
Track changes.
Deploy updates.
Manage versions.

That’s where Git and GitHub become essential.

If I restarted, I would learn:

commits
branches
pull requests
repositories
version control workflows

Because employers love proof.

A strong GitHub profile can sometimes speak louder than certificates.

Your projects become your resume.

Step 8: Learn How to Use AI Correctly

In 2026, AI will absolutely become part of programming workflows.

But there’s something important beginners misunderstand:

AI is a tool, not a replacement for thinking.

Good developers use AI to:

explain concepts
debug errors
optimize code
learn faster
generate ideas

Bad developers copy-paste code without understanding it.

That creates dependency instead of growth.

If I restarted today, I’d treat AI like a mentor — not a shortcut.

Because eventually you must understand what your code actually does.

Step 9: Focus on Problem-Solving

A lot of people think programming is about memorizing syntax.

It’s not.

Syntax is searchable.

The real skill is learning how to think logically.

That means learning how to:

break problems into smaller pieces
debug systematically
analyze behavior
think step-by-step

This is why problem-solving platforms can help beginners improve.

Not because interview questions are magical, but because they train your brain differently.

Programming is applied thinking.

Step 10: Learn Backend Development

Frontend development is a great start.

But backend development is where things begin to feel “real.”

That’s when you learn:

APIs
databases
authentication
servers
requests/responses
application logic

Suddenly you’re not just building interfaces anymore.

You’re building complete systems.

This stage is exciting because you finally understand how modern applications actually work behind the scenes.

Step 11: Learn SQL Early

SQL is massively underrated among beginners.

Many new developers focus only on frontend frameworks while ignoring databases completely.

But almost every serious application needs data storage.

Learning SQL teaches:

structured thinking
data relationships
querying
filtering
optimization

Even basic SQL knowledge makes you more valuable immediately.

And honestly?

SQL is one of the most practical skills in tech.

Step 12: Start Freelancing Before You Feel Ready

One of the best ways to grow fast is working on real problems.

Real clients teach lessons tutorials never can.

When real people use your software:

bugs matter
communication matters
deadlines matter
reliability matters

Your first freelance projects may pay very little.

That’s okay.

At the beginning, experience is more valuable than money.

You are building:

confidence
proof
communication skills
practical understanding

Every small project compounds.

Step 13: Build an Online Presence

This matters much more in 2026 than people realize.

Opportunities often come from visibility.

You do not need millions of followers.

You simply need to show your journey consistently.

I would post:

what I’m learning
projects I’m building
mistakes I fixed
lessons I discovered

Because people hire developers they can SEE.

The internet rewards visible builders.

Step 14: Accept That Progress Feels Slow

This is where many beginners quit.

The first year of programming can feel frustrating.

You forget syntax.
You get strange errors.
Nothing works sometimes.

That is normal.

Programming often feels difficult because your brain is learning an entirely new way of thinking.

But eventually something changes.

Concepts start connecting.
Debugging gets easier.
Projects feel less intimidating.

The confusion slowly becomes clarity.

Step 15: Understand the Real Secret

The biggest secret in programming is this:

Most successful developers are not geniuses.

They simply stayed consistent longer than everyone else.

That’s it.

They kept learning.
Kept building.
Kept failing.
Kept improving.

Programming rewards patience more than talent.

Small daily progress looks invisible at first…

…but after a few years, it completely changes your life.

Final Thoughts

If I had to restart from zero in 2026, I wouldn’t chase shortcuts.

I wouldn’t obsess over becoming “perfect.”

I’d focus on:

consistency
fundamentals
projects
problem-solving
patience

Because becoming a programmer is not one giant breakthrough moment.

It’s thousands of small steps repeated over time.

And eventually, one day, you realize:

The beginner who once struggled to print “Hello World” is now building real software.

That’s how the transformation happens. 🚀

Fastest Programming Languages in 2026: Speed, Performance, and Real-World Use Cases

Farhad Rahimi Klie — Tue, 19 May 2026 07:05:13 +0000

Programming languages are not equally fast.

Some languages are designed for raw hardware-level performance, while others focus on developer productivity, simplicity, safety, portability, or rapid development.

When developers talk about the “fastest programming language,” they are usually talking about:

Execution speed
Memory efficiency
CPU usage
Startup time
Latency
Throughput
Control over hardware
Compiler optimizations

But performance is more complicated than simply asking:

“Which language is the fastest?”

Because different workloads produce different results.

For example:

A language that is extremely fast for operating systems may not be the best for AI.
A language optimized for web applications may not perform best for embedded systems.
Some languages trade raw speed for safety.
Others trade safety for maximum hardware control.

In this article, we will deeply explore the fastest programming languages, how they achieve performance, where they are used, their advantages, disadvantages, and which one should be chosen for different types of projects.

What Makes a Programming Language Fast?

Before comparing languages, we must first understand what affects performance.

A programming language itself is not magically fast or slow.

Performance depends on many layers.

1. Compiler Quality

A good compiler can heavily optimize code.

Examples:

GCC
Clang/LLVM
MSVC
Rust Compiler

Compilers perform optimizations such as:

Dead code elimination
Loop unrolling
Inline expansion
Register allocation
Vectorization
Constant folding

A powerful compiler can dramatically improve performance.

2. Memory Management

Languages handle memory differently.

Manual Memory Management

Examples:

Developer controls memory directly.

Advantages:

Maximum speed
Fine-grained control
Minimal overhead

Disadvantages:

Memory leaks
Dangling pointers
Buffer overflows

Garbage Collection (GC)

Examples:

Java
Go
C#

The runtime automatically frees unused memory.

Advantages:

Easier development
Safer memory handling

Disadvantages:

GC pauses
Extra CPU overhead
Higher memory usage

3. Runtime Overhead

Some languages require heavy runtimes.

Examples:

JVM for Java
CLR for C#
Python Interpreter

Runtime systems add features like:

Memory management
Security
Reflection
Dynamic typing

But these also introduce overhead.

4. Abstraction Level

Higher-level languages usually sacrifice some speed.

Low-level languages provide direct hardware access.

Examples:

Level	Languages
Low-Level	C, C++, Rust
Mid-Level	Go, Java
High-Level	Python, JavaScript

More abstraction usually means:

Easier development
Lower performance

5. JIT vs Ahead-of-Time Compilation

Ahead-of-Time (AOT)

Code compiles before execution.

Examples:

C
C++
Rust

Produces very fast native binaries.

Just-in-Time (JIT)

Code compiles during execution.

Examples:

Java
JavaScript
C#

JIT can become extremely optimized after warm-up.

The Fastest Programming Languages

Now let’s explore the fastest languages in detail.

1. C — The King of Raw Performance

Why C is Fast

C is one of the closest high-level languages to hardware.

It provides:

Direct memory access
Minimal runtime overhead
Manual memory management
Extremely small abstractions
Efficient compiled binaries

C code is translated almost directly into machine instructions.

That is why operating systems, databases, kernels, drivers, and embedded systems heavily use C.

Advantages of C

Extremely Fast

C has near-zero abstraction overhead.

Small Executables

Compiled binaries are compact.

Direct Hardware Access

Perfect for:

Operating systems
Drivers
Embedded devices
Database engines

Portable

C can run almost everywhere.

Disadvantages of C

Unsafe Memory Management

Programmers must manually manage memory.

This can cause:

Memory leaks
Crashes
Security vulnerabilities

Harder Development

C development is more difficult than modern languages.

Real-World Systems Built with C

Linux Kernel
MySQL
PostgreSQL
Redis
SQLite
Git
Nginx

Best Use Cases

C is excellent for:

Operating systems
Database engines
Embedded systems
Game engines
Compilers
Device drivers
Networking systems

2. C++ — High Performance with Abstraction

C++ extends C with advanced programming features.

It remains one of the fastest languages ever created.

Why C++ is Fast

C++ provides:

Native compilation
Zero-cost abstractions
Template metaprogramming
Fine memory control
Powerful optimizations

Modern C++ compilers are incredibly advanced.

Advantages of C++

Near-C Performance

C++ can perform almost as fast as C.

Object-Oriented Programming

Supports:

Classes
Inheritance
Polymorphism

Powerful Standard Library

Includes:

Containers
Algorithms
Smart pointers
Threading

High Flexibility

C++ supports multiple paradigms:

Procedural
Object-oriented
Generic
Functional

Disadvantages of C++

Complexity

C++ is one of the most complex programming languages.

Memory Safety Problems

Still vulnerable to:

Undefined behavior
Pointer bugs
Memory corruption

Real-World Systems Built with C++

Unreal Engine
Chrome Browser
Blender
Adobe Software
AAA Game Engines
High-frequency trading systems

Best Use Cases

C++ is excellent for:

High-performance applications
Game development
Real-time systems
Graphics engines
Simulation software
Financial systems

3. Rust — Fast and Memory Safe

Rust became extremely popular because it combines:

C/C++-level performance
Memory safety
Modern tooling

Rust is often considered the future of systems programming.

Why Rust is Fast

Rust uses:

Native compilation
Zero-cost abstractions
Ownership system
No garbage collector
Aggressive optimizations

Rust achieves safety without GC overhead.

Advantages of Rust

Memory Safety

Rust prevents:

Null pointer bugs
Data races
Use-after-free errors

Excellent Performance

Rust is often comparable to C++.

Concurrency Safety

Rust makes multithreading safer.

Modern Tooling

Cargo package manager is excellent.

Disadvantages of Rust

Steep Learning Curve

Ownership and borrowing are difficult initially.

Longer Compile Times

Rust compilation can be slower.

Real-World Systems Built with Rust

Firefox Components
Cloudflare Systems
Dropbox Infrastructure
Linux Kernel Modules
High-performance networking tools

Best Use Cases

Rust is excellent for:

Systems programming
Networking
Blockchain
Security tools
Databases
Game engines
High-performance APIs

4. Go — Simplicity with Strong Performance

Go was created by Google.

Its goal was:

Simplicity
Fast compilation
Concurrency
Scalable backend systems

Go is not as fast as C or Rust, but it performs extremely well for server-side workloads.

Why Go is Fast

Go uses:

Compiled binaries
Lightweight goroutines
Efficient runtime
Optimized garbage collector

Advantages of Go

Very Fast Compilation

Go compiles extremely quickly.

Excellent Concurrency

Goroutines are lightweight.

Simple Syntax

Easy to learn and maintain.

Strong Backend Performance

Perfect for cloud infrastructure.

Disadvantages of Go

Garbage Collection Overhead

GC still introduces some latency.

Less Low-Level Control

Not as flexible as C or Rust.

Real-World Systems Built with Go

Docker
Kubernetes
Terraform
Prometheus
Many cloud-native systems

Best Use Cases

Go is excellent for:

APIs
Microservices
Cloud infrastructure
Backend systems
Networking servers
DevOps tools

5. Java — High Performance Through JVM

Many developers underestimate Java speed.

Modern Java can be extremely fast because of:

JVM optimizations
JIT compilation
Advanced garbage collectors

Why Java is Fast

The JVM dynamically optimizes hot code paths.

After warm-up, Java performance becomes impressive.

Advantages of Java

Mature Ecosystem

Huge libraries and frameworks.

Strong Performance

Excellent enterprise performance.

Cross-Platform

“Write once, run anywhere.”

Strong Tooling

Excellent IDE support.

Disadvantages of Java

Higher Memory Usage

JVM consumes significant RAM.

Startup Time

Slower startup compared to native binaries.

Real-World Systems Built with Java

Hadoop
Elasticsearch
Enterprise Banking Systems
Android Applications

Best Use Cases

Java is excellent for:

Enterprise applications
Large-scale backend systems
Banking systems
Big data systems

6. C# — Fast Modern Managed Language

C# runs on the .NET runtime.

Modern .NET performance has improved dramatically.

Why C# is Fast

C# uses:

JIT compilation
Runtime optimizations
Efficient garbage collection

Modern .NET is highly optimized.

Advantages of C

Excellent Developer Experience

Very productive language.

Strong Ecosystem

Powerful frameworks and tools.

Good Performance

Very competitive runtime speed.

Great for Games

Unity uses C# heavily.

Disadvantages of C

Runtime Dependency

Requires .NET runtime.

GC Overhead

Still affected by garbage collection.

Real-World Systems Built with C

Unity Games
Enterprise Systems
ASP.NET Applications
Windows Applications

Best Use Cases

C# is excellent for:

Game development
Enterprise software
Desktop apps
APIs
Cross-platform applications

7. Zig — A Rising High-Performance Language

Zig is a modern systems programming language.

It focuses on:

Simplicity
Performance
Manual control
Better C interoperability

Why Zig is Fast

Zig compiles directly to native machine code.

It has:

Minimal runtime
Explicit memory management
Strong compiler optimizations

Advantages of Zig

Very Predictable Performance

Excellent C Interoperability

Simple Language Design

No Hidden Allocations

Disadvantages of Zig

Young Ecosystem

Libraries and tooling are still growing.

Smaller Community

Compared to established languages.

Best Use Cases

Zig is excellent for:

Systems programming
Embedded software
Performance-critical tools
Replacing C in modern projects

Performance Comparison Table

Language	Speed	Memory Efficiency	Safety	Ease of Use	Best For
C	Extremely High	Extremely High	Low	Medium	Kernels, databases
C++	Extremely High	Extremely High	Medium	Hard	Games, engines
Rust	Extremely High	Extremely High	Very High	Hard	Safe systems programming
Go	High	Good	High	Easy	Cloud backends
Java	High	Medium	High	Medium	Enterprise systems
C#	High	Medium	High	Easy	Enterprise + games
Zig	Extremely High	Extremely High	Medium	Medium	Modern low-level software

Which Language is Actually the Fastest?

There is no single universal answer.

But generally:

Raw Native Speed

Usually:

C
C++
Rust
Zig

These languages compile directly into optimized machine code.

Best Performance + Safety Balance

Rust is often considered the strongest balance between:

Performance
Reliability
Modern tooling
Concurrency safety

Best Performance for Backend Development

Go is often preferred because:

Easy concurrency
Fast development
Excellent deployment
Strong scalability

Best Enterprise Performance

Java and C# dominate enterprise software.

Their ecosystems are enormous.

Why Python and JavaScript Are Not in the Fastest List

Python and JavaScript are incredibly popular.

But they are not raw-performance languages.

Python

Python is slower because:

Interpreted execution
Dynamic typing
Heavy runtime overhead

However:

Python dominates:

AI
Machine learning
Data science
Automation

Because development speed matters.

JavaScript

JavaScript engines are highly optimized.

But JavaScript still cannot usually match:

C
C++
Rust

for low-level performance.

However, JavaScript dominates:

Web development
Frontend applications
Node.js backends

Speed vs Productivity

One important truth:

The fastest language is not always the best language.

For example:

A team can build a Python application much faster than a C++ application.
Developer productivity sometimes matters more than CPU speed.
Faster development can save millions of dollars.

That is why companies choose different languages for different goals.

Real-World Engineering Truth

Large systems rarely use only one language.

Example architecture:

Component	Language
Kernel	C
Database Engine	C/C++
Backend APIs	Go/Java
AI Systems	Python
Frontend	JavaScript
High-Performance Modules	Rust/C++

Modern software engineering is multi-language.

Final Ranking (General Purpose Performance)

Tier 1 — Absolute Performance

C
C++
Rust
Zig

Tier 2 — High Performance + Productivity

Go
Java
C#

Tier 3 — Slower but Extremely Productive

Python
JavaScript
Ruby
PHP

Final Thoughts

Performance is not only about benchmarks.

A truly great programming language balances:

Speed
Safety
Maintainability
Ecosystem
Developer productivity
Scalability

If you want:

Maximum hardware control → C
Powerful performance engineering → C++
Modern safe systems programming → Rust
Cloud-native backend development → Go
Enterprise systems → Java/C#

The “best” language depends on your goals.

But in terms of pure raw execution speed, low-level native languages like C, C++, Rust, and Zig continue to dominate the performance world.

What Do You Think?

Which programming language do you think offers the best balance between:

Speed
Safety
Productivity
Simplicity

Share your opinion in the comments.