Forem: Malek

overcoming developer’s block: the "already done" trap and why you should build it anyway

Malek — Mon, 29 Dec 2025 08:20:48 +0000

It’s 11:00 PM. You’re three coffees deep, and inspiration finally strikes. You’ve found it, the perfect solution to a problem that’s been bugging you for weeks. You open a fresh terminal, your fingers hovering over the keys, ready to git init your way into tech history.

But then, you do the one thing that kills every great idea: You check if it already exists.

Two minutes later, you’re staring at a GitHub repo with 4.2k stars and a "Last Commit: 2 hours ago" badge. The air leaves the room. You tell yourself, "What’s the point? It’s already been done." You close your laptop, the "Already Done" trap has claimed another victim, and a potentially great piece of software dies before its first commit.

the lie of "solved problems"

We’ve all been there. We treat the existence of a competitor as a "Keep Out" sign. We convince ourselves that the market is "saturated" or that the "problem is solved."

But here’s the reality: Software is never "solved." If software were a finished product, there would be no Version 2.0. There would be no "breaking changes." There would be no 2,000 open issues on that "perfect" repo you just found. When you see a successful project, you aren’t seeing a finished masterpiece; you’re seeing a collection of trade-offs.

why the first mover is actually vulnerable

In physics, the person leading the race faces the most wind resistance. In software, the first mover faces the most "conceptual resistance." They have to spend their time and money proving the idea even works, leaving them exhausted and stuck with the architecture they chose years ago.

real-life cases where the first mover fell behind

OpenAI (the "GPT-3" era vs. the current landscape)

It feels strange to call OpenAI a "vulnerable" mover, but everybody feels it in the current landscape of AI. OpenAI pioneered the LLM craze (still the largest user-base compared to other LLMs), but in doing so, they provided a blueprint for everyone else. By being first, they had to navigate the massive costs of R&D and safety guardrails. Now, "fast followers" like Anthropic (Claude), Google's Gemini, or open-source models like Llama are taking those same concepts and optimizing them. OpenAI is now forced to play a defensive game, constantly shipping features to stay ahead of the very path they cleared for others.

MySpace (the cautionary tale of "good enough")

Before Facebook, there was MySpace. It had the market cornered. However, because they were the first to scale to millions, their codebase became a nightmare of "spaghetti" logic and security holes. They were so busy trying to keep the servers from melting that they couldn't innovate on the user experience. Facebook arrived later, saw the chaos of MySpace’s "custom CSS" profiles, and offered a clean, structured, and reliable alternative. MySpace had the users; Facebook had the better execution.

Kodak (the pioneer who feared their own invention)

The finance people love this tale; Kodak is the ultimate example of the "First Mover's Dilemma." Did you know a Kodak engineer actually invented the first digital camera in 1975? They were the first to arrive at the future. But because they were the kings of film photography, they were terrified that digital would cannibalize their existing business. They sat on the tech to protect their "first mover" status in film. While they hesitated, companies like Sony and Canon, who had nothing to lose, jumped into the digital gap and erased Kodak from the map.

the giants who weren't first

If the "Already Done" rule were true, the tech landscape would be a museum of 1990s software. Most of the tools we use today didn't win because they arrived first; they won because they arrived with a better map of the territory.

real-life cases where the latecomer changed the game

Google (the 15th search engine)

By the time Larry Page and Sergey Brin started working on "BackRub" (the precursor to Google), the search engine war seemed over. AltaVista was the speed king, Yahoo! was the gateway to the web, and Excite was worth billions. To any developer in 1996, building a search engine was the definition of "already done."

But Google didn't try to be another directory. They looked at the existing "first movers" and realized they were all missing one thing: relevance. While others indexed keywords, Google indexed authority via PageRank. They weren't first to the market, but they were the first to make the market useful.

Docker (containerization wasn't born in 2013)

We often talk about Docker as if it invented the container. In reality, the concept of isolating processes dates back to Unix chroot in 1979, followed by FreeBSD Jails (2000) and Solaris Containers (2004).

The technology existed for decades, but it was a nightmare to use. It was "already done," but it wasn't "done for the average dev." Docker’s genius wasn't in the isolation technology itself, but in the Developer Experience (DX). They took a 30-year-old concept and added a simple CLI, a way to share images (Docker Hub), and a "standard" format. They turned a niche system-admin tool into a worldwide developer standard.

Bun and Deno

Node.js has dominated the server-side JavaScript world since 2009. It’s the ultimate first mover. So why did Ryan Dahl (the creator of Node itself) build Deno? And why did Jarred Sumner build Bun?

They built them because being "first" meant Node was stuck with architectural decisions made over a decade ago, decisions like node_modules, lack of native TypeScript support, and a complex build process.

Deno arrived to fix the security and module resolution "regrets."
Bun arrived to solve the "speed" and "tooling bloat" problem.

They didn't see Node.js as a "Solved Problem"; they saw it as a Validated Problem. Node proved that people wanted JS on the server. Deno and Bun simply offered a more modern, faster way to do it.

the economic validation: why "no competition" is a red flag

When we see a project that looks like ours, our instinct is to feel defeated. But in the world of business and startups, "no competition" is often a red flag. It usually means one of two things: the problem isn't worth solving, or nobody is willing to pay to solve it.

the blue ocean strategy myth

Many developers are obsessed with finding a "Blue Ocean", a market space where they are the only ones. We think that if we are the first to arrive, we win by default.

However, serial entrepreneur and eWebinar CEO Melissa Kwanargues that this is a dangerous misunderstanding of how growth works. As she points out in her critique of why the Blue Ocean Strategy isn't always a good thing, having no competition isn't a "win", it’s an "education tax."

When you are the only one in a space:

You have to prove the problem exists: You aren't just selling a tool; you're selling the need for the tool.
Pricing is a guessing game: Without competitors, you have no benchmark for what users are willing to pay.
The lack of competition is a warning: If nobody else is doing it, there’s a high probability that others tried and found that the market wasn't viable.

By entering a "Red Ocean", a market where people are already building and competing, you are getting a massive head start. You aren't guessing if people want the product; you already know they do. Your only job is to do it better, faster, or more specifically for a certain niche.

the "second mouse" advantage

There’s an old business proverb that says: "The early bird gets the worm, but the second mouse gets the cheese." (a nuanced proverb suggesting that the second mouse gets the cheese holds the warning that there is a risk in rushing in). The first mover has to spend their time and resources hacking through the jungle. As the latecomer, you get to walk down the path they already cleared. You don't have to convince people they need a database; you just have to convince them they need your database because it handles their specific pain points better than the "dinosaur" currently leading the market.

why you should build it anyway

At this point, you might realize that the "Already Done" trap isn't just a mental hurdle, it’s an economic fallacy. But let’s set the market aside for a moment. Even if your project never reaches the scale of the original, there is a purely personal reason to hit git init: The transformation of your own skill.

the refining fire of practice

Most developers are "library consumers." They know how to plug things together, but they don't know how the engine actually works. When you choose to build something that "already exists," you are moving from consumer to creator.

As Roy L. Smith famously said:

"Discipline is the refining fire by which talent becomes ability."

Building a "clone" or a competitor requires the discipline to solve problems that others have already solved. It forces you to deal with the "boring" but essential parts of software, state management, edge cases, and performance bottlenecks. That discipline is what turns your raw talent into a professional-grade ability.

preparation for the big win

We often wait for a "truly unique" idea before we give our 100% effort. The problem is that when that unique idea finally comes, we aren't skilled enough to execute it.

As legendary coach Bobby Knight put it:

"The will to win is nothing without the will to prepare to win."

Building "redundant" software is your preparation. It is the training ground where you make your mistakes on a project that "doesn't matter" so that when you finally find your gap in the market, you have the muscle memory to build it right. Every "already done" project you finish is a deposit into your bank of experience.

your portfolio is your proof

A hiring manager doesn't care that your project is "another" Task Manager. They care that you handled authentication, real-time updates, and database indexing. A completed, high-quality version of an existing idea proves you can handle production-level complexity. It shows you have the "will to prepare" that others lack.

conclusion: don't let the "search bar" kill your craft

The next time you have a 2:00 AM idea, don't let a GitHub search results page be the end of the story.

The "Already Done" trap is a ghost. It only has power if you believe that software is a destination. It isn't. Software is a continuous evolution. Google wasn't the first search engine, Docker wasn't the first container, and Bun wasn't the first runtime. They were simply the projects that arrived later, looked at the "First Movers," and decided there was a better way.

Stop looking for an empty ocean and start building a better ship.

Just hit git init and see where it takes you.

Rust Chronicles #3 - immutability, valuing safety over convenience

Malek — Thu, 18 Dec 2025 20:54:32 +0000

Rust treats your code like a helicopter parent treats their kid at a playground. "Don't run!" "You'll fall!" "Use both hands!" It's overprotective by default, values can't change unless you explicitly mark them as mut. That resistance (big word for a simple three-letter keyword) might feel annoying at first, but it's meant to slow you down just enough to make your intent clear, and to hold you accountable for any abuse the compiler throws at you.

the core principle

In Rust, every variable binding is immutable unless explicitly marked mut. This is the opposite of most languages:

let x = 5;        // immutable - cannot be changed
x = 6;            // ERROR: cannot assign twice to immutable variable `x`

let mut y = 5;    // mutable - can be changed
y = 6;            // works

benefits of immutability

1. aggressive optimizations

When the compiler knows with certainty that a value cannot change, it can make assumptions and transformations that would be illegal or unsafe with mutable data. This has real performance implications.

One of which is keeping immutable values in CPU registers instead of the RAM, Rust uses LLVM as the backend engine, the basic Register Allocator implementation can be found at codebrowser

CPU Registers vs RAM

Registers are the fastest storage locations in your CPU:

Tiny (usually 64 bits on modern systems)
Extremely fast access (sub-nanosecond)
Limited quantity (typically 16 general-purpose registers on x86-64)

Memory (RAM) is much slower:

Vast (gigabytes)
Slower access (10-100+ nanoseconds)
Effectively unlimited for practical purposes

This ability to hold values for rapid access in the CPU Register is enabled by the immutability guarantee that Rust enforces.

2. eliminating a large class of race conditions (concurrency)

Multiple threads can safely read the same data simultaneously because Rust's borrow checker ensures no mutable references exist during those reads, eliminating race conditions.

let data = vec![1, 2, 3, 4, 5];

// multiple threads can read simultaneously
// each thread gets an immutable reference (&Vec<i32>)
std::thread::scope(|s| {
    s.spawn(|| println!("Thread 1: {:?}", data));
    s.spawn(|| println!("Thread 2: {:?}", data));
});

Note: data doesn't need to be immutable (no mut) for this to work, it just needs to not be mutated while being read. Even let mut data = vec![...] would work fine here, because the threads only read.

Trying to write from multiple threads requires synchronization:

let mut data = vec![1, 2, 3, 4, 5];

std::thread::scope(|s| {
    s.spawn(|| data.push(6));  // tries to get mutable reference
    s.spawn(|| data.push(7));  // another mutable reference
});

// ERROR: cannot borrow `data` as mutable more than once at a time

The key: it's not about the mut keyword on the binding, it's about whether the closures need mutable access. Multiple readers are fine; multiple writers need synchronization.

3. the immutability guarantee

Once you bind a value, you know it won't change unexpectedly:

let user_id = fetch_user_id();

expensive_operation(&user_id);

// user_id is GUARANTEED to still be the same value
process_user(user_id);

deep dive: what "immutable" actually means

immutability is about the binding, not the data

When a variable is immutable, it means the binding itself cannot be changed, you cannot reassign the variable or directly mutate the data through that binding. However, the actual data in memory might still be modifiable through other means (like through a mutable reference, or via interior mutability patterns like Cell or RefCell).

// example A
let x = String::from("hello");

// x is immutable - you cannot reassign x or mutate through x
x = String::from("world");   // ERROR: cannot mutate immutable variable `x`
x.push_str(" world");   // ERROR: cannot borrow 'x' as mutable

// but the data can be moved to a mutable binding
let mut y = x;   // ownership transferred (mut)
y.push_str(" world");   // now we can mutate the String
println!("{}", y);   // "hello world"

Another thing is that moving the data to an immutable owner keeps the guarantee:

// example B
let x = String::from("hello");

// x is immutable - you cannot reassign x or mutate through x
x = String::from("world");   // ERROR: cannot mutate immutable variable `x`
x.push_str(" world");   // ERROR: cannot borrow 'x' as mutable

let z = x;   // ownership transferred (no mut)
z = String::from("get mutated");   // ERROR: cannot mutate immutable variable `z`
z.push_str(" fool"); // ERROR: cannot borrow `z` as mutable

The key insight: Immutability means "I cannot change this through THIS binding," not "this data can never change."

immutability & ownership interaction

Multiple immutable references (&T) can exist at any given time since none of them can modify the data, this is also true in concurrent systems where multiple threads read from the same source simultaneously:

let data = vec![1, 2, 3];

let ref1 = &data;  // immutable borrow
let ref2 = &data;  // multiple immutable borrows are fine
let ref3 = &data;

println!("{:?} {:?} {:?}", ref1, ref2, ref3);
// all can coexist because none can modify data

But when it comes to mutable references (&mut T), only one mutable reference is allowed at any given time:

let mut data = vec![1, 2, 3];

let ref_mut = &mut data;  // mutable borrow
let ref2 = &data;         // ERROR: cannot borrow `data` as immutable because it is also borrowed as mutable
let ref3 = &mut data;     // ERROR: cannot borrow `data` as mutable more than once at a time

ref_mut.push(4);
// ref_mut goes out of scope here

println!("{:?}", data);   // now we can use data again

The key insight: you can either have one mutable reference or any number of immutable references, but never both at the same time. This prevents data races at compile time.

practical patterns to design around immutability

One thing every new Rust developer needs to accept is that the less you fight the borrow checker, the saner your life will be for the rest of your (short-lived) software career (unless, of course, the AI bubble bursts and suddenly everyone needs software engineers again). This section covers idiomatic Rust patterns that embrace immutability instead of working against it.

pattern 1: shadowing for transformations

When you need to transform a value through multiple steps, use shadowing to create new immutable bindings instead of mutation.

// mutation for transformation
let mut x = 5;     // mut variable
x = x + 1;         // same variable, mutated
x = x * 2;         // same variable, mutated again

// shadowing - each step is immutable
let x = 5;         // immut variable
let x = x + 1;     // new variable created
let x = x * 2;     // new variable created again

println!("{}", x); // 12 - final immutable value

Each intermediate value is immutable, making the code easier to reason about. You can even change types between transformations:

let spaces = "   ";
let spaces = spaces.len();  // now it's a number

Shadowing is particularly useful when you want to apply a series of transformations without keeping the intermediate states mutable.

pattern 2: transform instead of mutate

Instead of mutating data in place, create transformed copies using iterators and functional methods.

// ✘ imperative style - mutation required
let mut numbers = vec![1, 2, 3, 4, 5];
for i in 0..numbers.len() {
    numbers[i] *= 2;
}

// ✔ functional style - no mutation needed
let numbers = vec![1, 2, 3, 4, 5];
let doubled: Vec<i32> = numbers.iter().map(|x| x * 2).collect();

The benefits include: Original data preserved, easily parallelizable, more declarative, no index bounds errors.

pattern 3: rebuild when cheap, mutate when necessary

For small or inexpensive data structures, prefer immutability. For large structures where allocation is costly, use mutation strategically.

// cheap to rebuild - prefer immutability
let name = "John";
let greeting = format!("Hello, {}!", name);  // new string

// expensive to rebuild - use mutation
let mut large_vec = Vec::with_capacity(1_000_000);
for i in 0..1_000_000 {
    large_vec.push(i);  // mutate in place for performance
}

Choose the approach that matches your performance needs.

pattern 4: temporary mutability

Build data structures with mutation in a limited scope, then expose them as immutable to the rest of your code.

// data is immutable
let data = {
    let mut temp = Vec::new();
    temp.push(1);
    temp.push(2);
    temp.push(3);
    temp  // move out as immutable | eqv to: let data = temp;
};

// data is now immutable outside the block
data.push(4);   // ERROR: cannot borrow `data` as mutable
process(data);  // use immutably

This pattern is everywhere in Rust, construct with mutation, use with immutability. It gives you the performance of in-place construction with the safety of immutable data.

End of log. Thanks for reading, see you in the next entry!

Rust chronicles #2 - ownership, the unprecedented memory safety guarantee without a garbage collector

Malek — Wed, 10 Dec 2025 09:19:13 +0000

I have heard about Rust's unique implementation of memory management before, but I have yet to dive deep into its mechanics, as it is the case with anybody who has never worked with Rust before, that's right, Rust's memory management is unique to it, although it combines principles known prior to Rust's development (those being Ownership, Borrowing, and Lifetimes), Rust packaged it into a practical, usable system that is efficient in actual production software.

understanding Rust's ownership system

Rust's ownership system is a compile-time memory management strategy that enforces three fundamental rules:

every value has exactly one owner,
ownership can be transferred (moved) or lent (borrowed) but not duplicated,
when the owner goes out of scope, the value is automatically deallocated.

The compiler analyzes the program's memory usage during compilation and inserts deallocation code at precisely the points where values are no longer accessible. This approach eliminates entire classes of bugs, use-after-free, double-free, and memory leaks, that are synonym with C and C++ programs, while avoiding the runtime overhead and unpredictable pauses of garbage collection. Unlike languages that choose between safety and performance, Rust achieves both by moving memory safety checks from runtime to compile time. When your program compiles, the compiler has proven your memory usage is safe.

The system extends through "borrowing," which allows temporary access to data without transferring ownership. Rust enforces that you can have either unlimited immutable references or exactly one mutable reference at any time, but never both simultaneously. This restriction makes data races impossible, if two threads can't have mutable access to the same memory simultaneously, race conditions cannot occur. The compiler tracks the lifetime of every reference and ensures no reference outlives the data it points to, eliminating dangling pointers entirely. These ownership checks add zero runtime overhead, producing binaries that run as fast as hand-optimized C but without the memory corruption vulnerabilities that have plagued systems software for decades.

"What is this chump yappin' about here?", Do not worry my friend, I have been writing Rust code for a total of TWO DAYS, and I am here to explain it (I am competent enough I swear).

Let's take this simple code block:

fn main() {
    let s1 = String::from("Hello");
    let s2 = s1; // ownership moved to `s2`, `s1` is marked as invalid

    println!("{}", s1): // ERROR: borrow of moved value: `s1`
    println!("{}", s2); // Hello
}

Lets revise the 3 core principles of Rust's ownership system:

1. Each value has exactly one owner

let s1 = String::from("Hello");

s1 owns the heap-allocated string data. It contains a pointer to the heap, length (5), and capacity (5).

2. Ownership can be transferred (moved) or lent (borrowed) but not duplicated

let s2 = s1;  // ownership moves from `s1` to `s2`
// s1 is now invalid - compiler won't let you use it

The pointer is copied to s2, but s1 is marked as moved. Only s2 can access the heap data now.

3. When the owner goes out of scope, the value is automatically deallocated

{
    let s = String::from("Hello");
}  // `s` goes out of scope here, heap memory is freed automatically

The compiler inserts a drop() call that deallocates the heap memory.

copy types

Some types implement the Copy trait, which makes them copy instead of move:

let x = 5;
let y = x;  // `x` is copied, both `x` and `y` are valid

Copy types:

Integers (i32, u64, etc.)
Floats (f32, f64)
Booleans (bool)
Characters (char)
Tuples of Copy types

They're stored entirely on the stack with no heap allocation. Copying them is cheap (just copying bytes), and there's nothing to deallocate, so having multiple owners is safe.

functions can own values too!

fn main() {
    let s1 = String::from("Hello");
    take_ownership(s1); // ownership moves from `s1` to function body
    println!("{}", s1); // ERROR: borrow of moved value: `s1`
}

fn take_ownership(value: String) -> String {
    value // implicit return, having no semicolon is equivalent to
          // return value;
}

s1 cannot be used after 3rd line because the function take_ownership now owns the information about the value Hello, same thing happens if you call take_ownership inside the print function:

fn main() {
    let s1 = String::from("Hello");
    println!("{}", take_ownership(s1)); // Hello
    println!("{}", s1); // ERROR: borrow of moved value: `s1`
}

fn take_ownership(value: String) -> String {
    value // implicit return, having no semicolon is equivalent to 
          // return value;
}

the workaround: returning vs borrowing vs copying (cloning)

The way Rust is designed ensures no overhead or faulty memory exists at compile time, but the developer can opt-in to changing the status quo. When it comes to values, there are 3 ways you can opt-in to preserving the lifetime of your value:

return the data

This happens when the return value of a function is assigned to a variable:

fn main() {
    let s = String::from("Return Me!");

    let result = return_ownership(s); // `result` owns the string: "Return Me!"

    println!("{}", result); // Return Me!
    println!("{}", s); // ERROR: borrow of moved value: `s`
}

fn return_ownership(value: String) -> String {
    value
} // value leaves scope, but ownership was returned to `result`, so nothing is freed here

In this example, the String value Return Me! moved from being owned by s, to the function return_ownership, marking s as invalid from the 4th line onward. But because we assign the returned value to result, ownership transfers to result. When the function goes out of scope (remember, leaving scope = death... or freeing the memory to be less dramatic), the value has already been moved out, so nothing is freed. result now owns the string Return Me!.

borrow the data

Borrowing uses a reference (pointer) to let code look at data without taking ownership. The borrower cannot free the memory because they don't own it:

fn main() {
    let my_string = String::from("Hello");

    print_string(&my_string); // lend it temporarily, the function merely looks at the data

    println!("{}", my_string); // still works, `my_string` is still the owner
}

fn print_string(s: &String) {
    println!("{}", s);
} // borrow ends once the function executes, data still owned by caller

What about here? Is a return happening or a borrowing?:

fn main() {
    let my_string = String::from("Hello");
    let result = return_string(&my_string); 
    println!("{}", result);
    println!("{}", my_string); // works
}

fn return_string(s: &String) -> &String {
    s
}

If you've answered both, then you'd be correct! return_string is borrowing a reference (pointer) to the allocated value Hello that is owned by my_string, then it returns the same borrowed reference to result. This means both my_string and result point to the same exact memory address that holds the string Hello, but only my_string has ownership over it. The data will not be freed until my_string goes out of scope or ownership is moved somewhere else.

copy (clone) the data

For types that don't implement Copy (integers, floats, booleans, characters, tuples of copy types), you can explicitly duplicate data using .clone():

fn main() {
    let s1 = String::from("Hello");
    let s2 = s1.clone(); // explicit copy, duplicates heap data

    println!("{} {}", s1, s2); // both work! Two independent copies
}

For types that implement Copy (like integers), copying happens automatically:

fn main() {
    let x = 5;
    let y = x; // automatic copy, both valid

    println!("{} {}", x, y); // both work!
}

Copying and Cloning produce independent copies that contain the same content, with the same length and capacity, but the memory address is different, which means each copy will be tracked and freed independently, modifying or freeing one does not affect the other:

fn main() {
    let my_string = String::from("Hi");
    let another_string = my_string.clone(); // new independent clone

    println!("{} {}", my_string, another_string); // both work

    take_owndership(my_string); // ownership moved, marking `my_string` as invalid

    println!("{}", another_string); // works, `my_string` was cloned prior to transfer (move)
    println!("{}", my_string); // ERROR: borrow of moved value: `my_string`
}

fn take_ownership(s: String) {
    println!("{}", s)
}

Test yourself, will the last print statement execute correctly?:

fn main() {
    let x = 5;
    let y = x; // integers get automatically copied, no ownership change
    println!("{} {}", x, y); // both work

    take_owndership(x);

    println!("{}", y); // works fine
    println!("{}", x); // QUESTION: will this work?
}

fn take_ownership(v: i32) -> i32 {
    v
}

The answer: YES! It does work. I've included a hint in the 3rd line that might help. Because x is of type i32, it automatically gets copied everywhere the variable x is used, including in the take_ownership function. This means the function isn't actually using the same memory location that x is using, instead, a copy is made that contains the same value as x. The copy exists independently on the stack, so the last print statement works normally since x still holds the value 5 and hasn't gone out of scope yet.

If you got it wrong, that's okay; Why'd you think I included this test? I got confused as to why x was working normally too!

End of log. Thanks for reading, see you in the next entry!

Rust chronicles #1 - the beginning

Malek — Mon, 08 Dec 2025 09:20:53 +0000

Why Rust? Why now? simple, A Hackathon.
There is no deeper reasoning for this or a grandiose of a goal, a Rust-only Hackathon is happening close to where I live, I have never been to one of these events before, the event organizers clarified that there will be buckets based on experience, so beginners, intermediate, and professionals who actually got paid to write Rust code, and on a whim I signed up and got a ticket in the beginner's bucket, the issue is that, technically speaking, I am not even a beginner yet since I have never written a single line of Rust, following that stream of thoughts I arrived at the conclusion that the unavoidable embarrassment of being the most incompetent person there, is... well... unavoidable...

unless...

Hello World

Starting off we need a compiler, heading to rustup.rs we get our hands on the Rust Toolchain Installer, a .exe file (I atone for the gag that W*ndows inflicts on ultra-chad engineers. I shall repent by becoming mildly competent in Rust); Running the Rust toolchain installer with default options installs stable-x86_64-pc-windows-msvc, which includes rustc, Cargo, and Rust's standard libraries. This toolchain uses Microsoft's link.exe linker and the MSVC runtime libraries to link the compiled code into Windows executables.

To check if the installation happened correctly:

rustc --version
# rustc 1.91.1 (ed61e7d7e 2025-11-07)

cargo --version
# cargo 1.91.1 (ea2d97820 2025-10-10)

rustc is the compiler that produces native machine code and .obj files that calls the Microsoft Linker link.exe, together with MSVC's linker, the final .exe or .dll is produced.
cargo is Rust’s official build system and package manager. It is the standard way to build Rust projects using cargo build, cargo run, cargo test and cargo bench.

After a successful installation we head to our editor to create our first Rust project, to do that we utilize cargo:

cargo new hello_rust
cd hello_rust
code . # If your code editor is VS Code

src/main.rs - main entry point of the project:

fn main() {
    println!("Hello, world");
}

Do not be fooled by the exclamation mark; it is but a fleeting glimmer of cheer in a profession otherwise defined by unending torment.

Cargo.toml - a manifest file that tells Rust’s package manager, Cargo, everything your project needs:

[package]
name = "hello_rust"
version = "0.1.0"
edition = "2024"

[dependencies]

You can think of it as Rust’s equivalent of package.json in Node.js, go.mod in Go, or a .csproj file in C# (or pom.xml for Maven projects, or build.gradle / build.gradle.kts for Gradle projects; Java is very much alive and well, this was not added as an afterthought! trust me).

Running the Project

To run the project:

cargo run

The result will be outputted in the terminal:

Compiling hello_rust v0.1.0
error: linker `link.exe` not found | = note: program not found note: the msvc targets depend on the msvc linker but `link.exe` was not found note: please ensure that Visual Studio 2017 or later, or Build Tools for Visual Studio were installed with the Visual C++ option. note: VS Code is a different product, and is not sufficient.

error: could not compile `hello_rust` (bin "hello_rust") due to 1 previous error

I know what you're thinking: "A single line of Rust produced all of that? Truly a marvel of engineering".

Turns out I was missing the critical linker (from Microsoft Visual C++) that produces native Windows executables using the binaries from the rustc compiler. But I am a Software Engineer, and we are not mere mortals; we are problem-solving architects of the digital realm, tamers of logic, warriors against the tyranny of the compiler. It is our solemn calling, our sacred rite, our raison d’être to stare into the abyss of cryptic error messages, to wrest solutions from the clutches of dependency hell, and to emerge triumphant in the dead of night, clutching a freshly linked .exe like Excalibur itself. And so, with nothing but sheer willpower, caffeine, and perhaps a touch of desperation, I set out to conquer this issue.

First step: delete stable-x86_64-pc-windows-msvc:

rustup toolchain uninstall stable-msvc

Second step: install the GNU toolchain and set it as the default toolchain

rustup toolchain install stable-gnu
rustup default stable-gnu

And Viola!

cargo run

Compiling hello_rust v0.1.0
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.06s
     Running `target\debug\hello_rust.exe`

Hello, world

MSVC Toolchain vs GNU Toolchain

There is bound to be tradeoffs between the two toolchains, I have since asked Claude to clarify what the tradeoffs are, and the result? Did not understand a thing he spewed out. in other words, I am not in the required skill bracket to even understand what the tradeoffs mean, so, for now, we are good to go with the lighter, and more portable GNU Toolchain that relies on the MinGW-w64 runtime.

End of log. Thanks for reading, see you in the next entry!

Discover OfficeForge: Enhance Microsoft Office with Open-Source Automation

Malek — Sun, 07 Dec 2025 08:39:46 +0000

For developers automating administrative work inside the Microsoft Office ecosystem, generating contracts from DOCX templates, producing XLSX reports, or assembling PPTX decks, there's usually a messy gap between where the data lives and where the final document needs to be. OfficeForge closes that gap with an open-source, zero-dependency tool that pushes structured data straight into polished Office files while keeping the original formatting without any parameters.

Part I: For Any Developer in Any Language

A Lightweight CLI That Works From Any Language

OfficeForge comes with a CLI tool that lets you automate Microsoft Office documents without touching Go. Whether you code in Python, Node.js, PHP, or Bash, you can generate Word files, fill templates, or batch-process documents, while keeping the formatting intact and without juggling parameters.

Getting started is simple: download the binary for your Windows architecture from the Releases page and you're ready to go.

For example, replace a single keyword in a template:

officeforge docx-single --input template.docx --output output.docx --key "{{NAME}}" --value "John Doe"

Or generate multiple documents from CSV/JSON:

officeforge docx-batch --input template.docx --output ./contracts --data employees.csv

Flexible Naming Patterns

Control how your generated documents are named using patterns:

# Sequential numbering
officeforge docx-batch --input template.docx --output ./output --data employees.csv --pattern "contract_%03d.docx"
# Creates: contract_001.docx, contract_002.docx, contract_003.docx

# Data-based naming (CSV must have NAME column)
officeforge docx-batch --input template.docx --output ./output --data employees.csv --pattern "{NAME}_contract.docx"
# Creates: Alice_contract.docx, Bob_contract.docx

# Multiple fields (CSV has ID and COMPANY columns)
officeforge docx-batch --input template.docx --output ./output --data clients.csv --pattern "{COMPANY}_{ID}_agreement.docx"
# Creates: Acme_001_agreement.docx, TechCorp_002_agreement.docx

# Combine data and index
officeforge docx-batch --input template.docx --output ./output --data employees.csv --pattern "{DEPARTMENT}_report_{INDEX}.docx"
# Creates: Engineering_report_1.docx, Sales_report_2.docx

With zero dependencies, blazing speed, and straightforward commands, this CLI bridges the gap between your data and document automation, letting you focus on logic. It's a portable, language-agnostic way to automate administrative tasks efficiently.

Because OfficeForge is a standalone binary with zero dependencies, you can call it from any language that can run system commands. Here are examples using Node.js, Python, and PHP to run the same docx-batch operation.

Node.js Example (using `child_process`)

import { exec } from "node:child_process";
import { promisify } from "node:util";

const execAsync = promisify(exec);

(async () => {
  try {
    const { stdout, stderr } = await execAsync(
      `officeforge docx-batch --input template.docx --output ./contracts --data employees.csv --pattern "{EMPLOYEE_NAME} Contract.docx`
    );

    if (stderr) console.error("CLI stderr:", stderr);
    console.log("Success:", stdout);
  } catch (err) {
    console.error("Error:", err);
  }
})();

Python Example (using `subprocess`)

import subprocess

cmd = [
    "officeforge",
    "docx-batch",
    "--input", "template.docx",
    "--output", "./contracts",
    "--data", "employees.csv",
    "--pattern", "{EMPLOYEE_NAME} Contract.docx"
]

result = subprocess.run(cmd, capture_output=True, text=True)

if result.returncode != 0:
    print("Error:", result.stderr)
else:
    print("Success:", result.stdout)

PHP Example (using `exec`)

<?php

$cmd = 'officeforge docx-batch --input template.docx --output ./contracts --data employees.csv --pattern "{EMPLOYEE_NAME} Contract.docx"';

exec($cmd . " 2>&1", $output, $returnCode);

if ($returnCode !== 0) {
    echo "Error:\n";
    echo implode("\n", $output);
} else {
    echo "Success:\n";
    echo implode("\n", $output);
}

?>

Whether you're working in Node.js, Python, PHP, Bash, Go, or anything else, OfficeForge’s CLI gives you a language-agnostic way to automate DOCX generation at high speeds.

Part II: For Go Developers Who Want Native Integration

Integrate OfficeForge Directly in Your Go Code

For Go developers, OfficeForge isn't just a CLI, it's a fully programmatic library. You can embed it directly in your apps to fill templates, generate batches, and keep full control over your Microsoft Word documents.

Installation

Grab the latest version:

go get github.com/siliconcatalyst/officeforge@latest

Or install the CLI for mixed usage:

go install github.com/siliconcatalyst/officeforge/cmd/officeforge@latest

Single Keyword Replacement

Quickly replace one keyword:

import "github.com/siliconcatalyst/officeforge/docx"

err := docx.ProcessDocxSingle("template.docx", "output.docx", "{{NAME}}", "John Doe")
if err != nil {
    log.Fatal(err)
}

Perfect for one-off documents or testing replacements.

Multiple Replacements

Fill multiple fields at once:

import "github.com/siliconcatalyst/officeforge/docx"

replacements := map[string]string{
    "{{NAME}}":  "John Doe",
    "{{EMAIL}}": "john@example.com",
    "{{DATE}}":  "2025-12-07",
}

err := docx.ProcessDocxMulti("template.docx", "output.docx", replacements)
if err != nil {
    log.Fatal(err)
}

Ideal for contracts, letters, or forms where several fields need updating.

Batch Document Generation

Generate dozens—or thousands—of documents in one go:

import "github.com/siliconcatalyst/officeforge/docx"

records := []map[string]string{
    {"NAME": "Alice", "EMAIL": "alice@example.com"},
    {"NAME": "Bob", "EMAIL": "bob@example.com"},
}

// Sequential numbering
err := docx.ProcessDocxMultipleRecords("template.docx", "./output", records, "contract_%03d.docx")
// Creates: contract_001.docx, contract_002.docx

// Data-based naming using fields from records
err := docx.ProcessDocxMultipleRecords("template.docx", "./output", records, "{NAME}_contract.docx")
// Creates: Alice_contract.docx, Bob_contract.docx

// Multiple fields
err := docx.ProcessDocxMultipleRecords("template.docx", "./output", records, "{NAME}_{EMAIL}.docx")
// Creates: Alice_alice@example.com.docx, Bob_bob@example.com.docx

// Combine data and index
err := docx.ProcessDocxMultipleRecords("template.docx", "./output", records, "employee_{INDEX}_{NAME}.docx")
// Creates: employee_1_Alice.docx, employee_2_Bob.docx

For advanced naming logic, use ProcessDocxMultipleRecordsWithNames with a custom nameFunc of your own creation:

import "github.com/siliconcatalyst/officeforge/docx"

nameFunc := func(record map[string]string, index int) string {
    // Custom logic based on data
    if record["PRIORITY"] == "high" {
        return fmt.Sprintf("urgent_%s_%d.docx", record["NAME"], index)
    }
    return fmt.Sprintf("standard_%s_%d.docx", record["NAME"], index)
}

err := docx.ProcessDocxMultipleRecordsWithNames("template.docx", "./output", records, nameFunc)
// Creates: urgent_Alice_1.docx, standard_Bob_2.docx (based on PRIORITY field)

Important Note: In your template DOCX file, the placeholders like {{NAME}} or CLIENT_EMAIL should match the map keys exactly: {"{{NAME}}": "Alice"} or use the field names directly {"CLIENT_EMAIL": "alice@acmecorp.com"} depending on your template structure.

Why You Should Consider Using OfficeForge

Pure Go, zero external dependencies
Fast, even with large batches
Full programmatic control
Intelligent naming patterns built-in
Works seamlessly with existing Go projects

Tips

Use clear, unique keywords like {{CLIENT_NAME}} or [[EMAIL]]
Test templates with a single record first
Keep keywords visible in the document for easy verification
Pattern placeholders {FIELD} must match your CSV/JSON column names or record keys
Use {INDEX} in patterns to include the record number
Invalid filename characters in data are automatically sanitized

OfficeForge makes Microsoft Office automation effortless, whether you’re calling it from a CLI in any language or embedding it directly in a Go application. Fast, reliable, and zero-dependency, it bridges your data with DOCX documents so you can focus on building solutions for your team.

Note: As of December 7, 2025, only DOCX manipulation and generation are fully supported. PowerPoint (PPTX) and Excel (XLSX) support are currently in development.

Get started today and see how OfficeForge can simplify document automation in your projects:

Contributions, feedback, and questions are always welcome!

Forem: Malek

overcoming developer’s block: the "already done" trap and why you should build it anyway

the lie of "solved problems"

why the first mover is actually vulnerable

real-life cases where the first mover fell behind

OpenAI (the "GPT-3" era vs. the current landscape)

MySpace (the cautionary tale of "good enough")

Kodak (the pioneer who feared their own invention)

the giants who weren't first

real-life cases where the latecomer changed the game

Google (the 15th search engine)

Docker (containerization wasn't born in 2013)

Bun and Deno

the economic validation: why "no competition" is a red flag

the blue ocean strategy myth

the "second mouse" advantage

why you should build it anyway

the refining fire of practice

preparation for the big win

your portfolio is your proof

conclusion: don't let the "search bar" kill your craft

Rust Chronicles #3 - immutability, valuing safety over convenience

the core principle

benefits of immutability

1. aggressive optimizations

CPU Registers vs RAM

2. eliminating a large class of race conditions (concurrency)

3. the immutability guarantee

deep dive: what "immutable" actually means

immutability is about the binding, not the data

immutability & ownership interaction

practical patterns to design around immutability

pattern 1: shadowing for transformations

pattern 2: transform instead of mutate

pattern 3: rebuild when cheap, mutate when necessary

pattern 4: temporary mutability

Rust chronicles #2 - ownership, the unprecedented memory safety guarantee without a garbage collector

understanding Rust's ownership system

copy types

functions can own values too!

the workaround: returning vs borrowing vs copying (cloning)

return the data

borrow the data

copy (clone) the data

Rust chronicles #1 - the beginning

Hello World

Running the Project

MSVC Toolchain vs GNU Toolchain

Discover OfficeForge: Enhance Microsoft Office with Open-Source Automation

Part I: For Any Developer in Any Language

A Lightweight CLI That Works From Any Language

Flexible Naming Patterns

Node.js Example (using child_process)

Python Example (using subprocess)

PHP Example (using exec)

Part II: For Go Developers Who Want Native Integration

Integrate OfficeForge Directly in Your Go Code

Installation

Single Keyword Replacement

Multiple Replacements

Batch Document Generation

Why You Should Consider Using OfficeForge

Tips

Node.js Example (using `child_process`)

Python Example (using `subprocess`)

PHP Example (using `exec`)