I’m starting a new series on building desktop applications with Rust and GPUI

For the first article, we’re building a Linear-inspired UI Clone

The goal of this series is to understand GPUI properly while documenting the process so you can follow along and build your own applications.

Read the first article: article link

Github source code: repo link

More GPUI projects and deeper concepts are coming in the series.

I’ve started writing a new Rust series and in this we are going to follow the same project building pattern. One project per article but this time, it’ll be very comprehensive and covers a good amount of theory as well.

This is the first article of our new Rust series.

Article: article link

Just published the next article in my Learning Backend series, this one’s about error handling in Axum, built around a practical example: a Pastebin API.

If you’ve ever wondered how to handle errors cleanly in an Axum app instead of littering your code with unwrap(), this one’s for you.

Article link - Learn Axum Error Handling by Building a Pastebin API in Rust

Source code - here

If my writing helped you, you can support it via GitHub Sponsors. It helps me keep writing about Rust, backend, and gamedev.

As always, feedback and thoughts are welcome.

See you soon.

This week starts a new series, Backend Engineering with Axum, and Part 1 is live: building a URL shortener while learning how Axum actually works.

No shared codebase across this series, no capstone at the end. Each article is a standalone project built around one concept, sequenced so each one is easiest to grasp once the last one is in place. Next up: request bodies and proper error handling, building a Pastebin API.

Read it here: article link

Source code: Github source code

If you build the project along with me, hit reply and let me know how it went, or where you got stuck. That feedback shapes what I cover next.

If my writing helped you, you can support it with $1+ via [Ko-fi], or a monthly pledge via [GitHub Sponsors]. It helps me keep writing about Rust, backend, and gamedev.

Thanks, see you soon with another one

New post is up: we’re learning SQL from scratch, no database experience needed, then bringing it into Rust with SQLx.

If you already know SQL, you can skim Part 1, but the schema and patterns there (GROUP BY on genres, subqueries for rankings) carry straight into the project, so it’s worth at least a glance.

Read it here: article link

As always, source code’s on GitHub.

P.S. Next up: designing relational schemas from scratch, going from requirements to a normalized, production-ready design. That’ll build directly on this post’s schema.

Part 11 of the Learning Rust series is live.

This one covers async/await, the part of Rust that trips up a lot of people. We go through futures, the Future trait, how .await actually works, and what the Tokio runtime is doing under the hood (the reactor + executor model).

Then we build a working HTTP/1.1 server from scratch, raw TCP listener, manual request parsing, static file serving, proper content types, concurrent connection handling with tokio::spawn. No frameworks, no magic. Just you, Tokio, and the standard library.

Read it here → article link

Github Source code → here

Next up: SQLx, SQLite, compile-time checked queries, and a Book Library CLI.

See you then.

Read here → click here to read

github → source code here

A new article is live in the Learning Rust series.

This one covers Box, Rc, RefCell, and Weak, the smart pointer family and ties them together with a project: a Git Commit Graph Viewer that reads a real .git directory, parses every commit object, builds a connected DAG and renders the commit history as an ASCII graph in your terminal.

Read it here → article link

Source code: source code

If you found it useful, sharing it with someone learning Rust goes a long way.

Thanks for reading.

Read it here → article link

Source code → https://github.com/MrSheerluck/linter-rust

If you like what you are reading, then please share it on your socials. This would really help me to keep going and deliver these kind of content. Thank you for your immense support.

See you soon

I’m starting something new.

Alongside the Rust series, I’m starting a game dev series. The structure is the same: each article, we build one game and learn concepts along the way. All the games come from the 20 Games Challenge list.

I’m learning Bevy as I write these, so this series is honest by default.

The first one is Pong.

Here’s what we cover:

- What a game engine actually does and why ECS exists

- Setting up a Bevy project and opening a window

- Spawning paddles and a ball as entities with components

- Writing systems for player input and movement

- Implementing AABB collision detection from scratch

- Scoring and updating a live score display

- Compiling to WebAssembly and deploying to Itch.io

The deployed game is live on Itch.io if you want to try it before reading.

Read the full article here → click here

Github repo → source code

If you like what you are reading, then please consider sharing this with your friends and peers. This will really help me a lot. Thank you so much for your consistent support

See you in the next one.

New post is up

This is post 7 in the learning-rust series. If you’ve been following along, you already know ownership, borrowing, structs, enums, error handling, generics, traits, and lifetimes. This one covers the two things that were missing. HashMap<K, V> and the Iterator trait and the project is the most interesting one yet.

Here’s what we build: a program that reads a real .git folder, decompresses loose objects with zlib, parses commits and trees into typed structs, builds a commit graph using a HashMap, and renders git log --oneline output. Less than 200 lines of Rust.

On the way there, we cover:

- How HashMap<K, V> works like insertion, retrieval, and the Entry API for single-lookup insert-or-update

- Ownership rules when you move a String into a map

- What the Iterator trait actually is (`next` returning `Option<Self::Item>`)

- The three forms: .iter(), .iter_mut(), .into_iter() and what each produces

- Adapters like map, filter, flat_map, take, skip, zip, chain, filter_map and why they’re lazy

- Chaining adapters and how values flow through the pipeline one at a time

- Git’s object storage model: blobs, trees, commits, and the <type> <size>\0<content> wire format

The flat_map section in particular makes a lot more sense once you see it used to walk a recursive tree structure.

Read it here: article link

Github Source Code: Click here for source code

I hope you like these articles. If you have any request for any particular topic, do let me know.

It would help me a lot if you can share the article with your friends and peers. Thank you so much for supporting

See you in the next one.

Hey,

New article is up.

This one covers lifetimes, the concept that trips up most Rust beginners. We go through what lifetimes actually are, why the compiler needs them, lifetime annotations, the three elision rules, and the `’static` lifetime.

Then we build a generic LRU cache that:

• Is generic over key and value types

• Holds a borrowed config reference with a lifetime annotation

• Returns zero-copy references from `get` using `Option<&V>`

• Is split across `src/cache.rs` and `src/main.rs`

Only used standard library to build this.

Read it here → here

Github Source Code → here

If you like reading this, please subscribe and share this with others. It'll really help me and motivate me to keep publishing more such articles.

See you in the next one.

New article is up on the blog.

Read it here: learn Rust Generics and Traits

Github repo: source code is here

If you like these tutorials, then please share it with others. It would really mean a lot to me if more and more people read and learn from these articles. Thank you again for your consistent support

This one covers generics and traits in Rust. Two concepts that confused me for a while when I was starting out. Instead of going through theory, we build a mini blackjack game that puts both to work.

Here is what the article covers:

• What generics are and why they exist

• The monomorphization model (zero runtime cost)

• What traits are and how to implement them

• Trait bounds, default implementations, the orphan rule

• The derive macro and which traits you get for free

• How to combine generics and traits on structs

• Building a generic Deck and Hand that works with any card type

• Proper error handling with Result, thiserror, and the ? operator throughout

By the end you will have a working command line blackjack game and a generic card engine that can be extended to any card type.

Happy learning,

Sheerluck

3rd post on Rust series is here.

This one is about structs, enums, and pattern matching. Instead of explaining them in the abstract, we build a JSON parser from scratch. No crates. No shortcuts.

Here’s what that means concretely: you write a lexer that walks raw bytes and produces tokens, then a recursive descent parser that turns those tokens into a typed JsonValue enum that can represent any valid JSON objects, arrays, strings, numbers, booleans, null, nested arbitrarily deep.

By the end you have something real: feed it {”scores”: [95, 87, 100], “info”: {”city”: “delhi”, “zip”: null}} and it parses, traverses, and reconstructs it correctly. Unicode escapes, nested structures, negative floats

What the phase covers:

• Structs: fields, impl blocks, all three self forms (&self, &mut self, self), associated functions, field shorthand

• Enums: basic variants, data-carrying variants, recursive variants

• Pattern matching: exhaustiveness, binding, reference patterns, guards, @ bindings, range patterns, wildcards

• if let and while let as syntactic sugar over match

• Destructuring in let bindings and for loops

If you’ve been following along from Phase 1 (Brainfuck interpreter) and Phase 2 (grep clone), this is where things start feeling like real Rust.

Read it here → Build JSON Parser from Scratch in Rust

Github repo → Get the source code here

Next up: a TOML config parser with schema validation and structured error reporting. Zero unwrap calls. That’s where proper error handling comes in.

If you like articles like these, then please share it with your friends and peers. It would help me a lot and keep me motivated to post more such content.

Thank you so much for your support.

The Problem Rust is Solving

Every program needs memory. There is an important question: who is responsible for freeing that memory when you’re done with it?

In C, you call malloc to allocate and free to release. Fast and in control, but you can make mistakes like free memory twice, forget to free it, or use it after freeing. These bugs are hard to reproduce and hard to debug.

In Python, a garbage collector runs in the background, figures out what memory is no longer reachable, and frees it. You basically can’t have dangerous memory bugs but the problem is performance like the GC runs at unpredictable times, pauses your program, and adds overhead.

Rust gives you memory safety without a garbage collector, through three ideas: ownership, borrowing, and slices.

Ownership

In Rust, every piece of data has exactly one variable that “owns” it. When that variable goes out of scope, the data is automatically freed.

// s owns the string
let s = String::from(”hello”);
// s goes out of scope here — Rust frees it automatically

What happens when you do this?

let s1 = String::from(”hello”);
let s2 = s1;

Ownership moves from s1 to s2. After the second line, s1 no longer exists as far as the compiler is concerned:

let s1 = String::from(”hello”);
let s2 = s1;
println!(”{}”, s1); // ERROR: value borrowed here after move

Because String is heap-allocated, if both s1 and s2 owned it, who would free it? By keeping a single owner, Rust keeps it simple. Simple types like integers live on the stack and are just copied instead.

Borrowing

If ownership moves when you pass data around, how do you actually use data in a function? Rust gives you borrowing, instead of giving ownership, you lend a reference to the data.

fn print_it(s: &String) {
    println!(”{}”, s);
}

fn main() {
    let s = String::from(”hello”);
    print_it(&s); // lend a reference, don’t move ownership
    println!(”{}”, s); // still works — s is still the owner
}

The & means “a reference to”. That means You’re passing a pointer to it. The function can read the data but doesn’t own it, so it can’t free it.

This is a shared (immutable) reference. You can read but not modify. You can have as many as you want simultaneously because reading doesn’t conflict with reading.

For mutable access there’s &mut, but with a catch: you can have one mutable reference at a time, and no immutable references at the same time.

You can have either many readers or one writer, never both simultaneously — enforced by the compiler before your code runs.

I can’t put the entire post in this email. So, please read the entire post on web for free using the Read More button below

Read More

In the next post, we are going to build a JSON Parser from scratch in Rust using structs, enums and pattern matching. See you soon

If you like these kinds of post, then please let me know what else would you like to see next.

If you can share this newsletters with your friends and peers that would really help me a lot. Thank you for supporting me

What is Mythos?

Mythos is Anthropic’s next model. It sits in a new tier above Opus, both in capability and cost. Internally they called this tier Capybara.

It is a general-purpose model. But it is strikingly capable at cybersecurity tasks specifically. Where prior Claude models respond to instructions one step at a time, Mythos plans and executes sequences of actions on its own, moving across systems and completing operations without waiting for human input at each stage.

Here are the benchmark numbers from Anthropic’s own evaluation on agentic coding:

These are not small improvements.

What Can It Actually Do

This is where it gets serious.

During testing, Mythos Preview was capable of identifying and exploiting zero-day vulnerabilities in every major operating system and every major web browser. Many of the vulnerabilities it found are ten or twenty years old. The oldest being a 27-year-old bug in OpenBSD.

In one case it wrote a browser exploit that chained together four vulnerabilities, writing a complex JIT heap spray that escaped both the renderer and OS sandboxes. It autonomously obtained local privilege escalation on Linux by exploiting subtle race conditions and KASLR bypasses. It also wrote a remote code execution exploit on FreeBSD’s NFS server that granted full root access to unauthenticated users by splitting a 20-gadget ROP chain over multiple packets.

The numbers make this concrete. Opus 4.6 turned Firefox 147 JavaScript engine vulnerabilities into working shell exploits only 2 times out of several hundred attempts. Mythos Preview developed working exploits 181 times on the same benchmark.

These capabilities were not explicitly trained into Mythos Preview. They emerged as a downstream consequence of general improvements in code, reasoning, and autonomy. The same improvements that make it better at patching vulnerabilities also make it better at exploiting them.

Why It Is Not Public

Mythos Preview can find tens of thousands of vulnerabilities that even an advanced bug hunter would struggle to find, and it can write the exploits to go with them.

It is also extremely compute-intensive and expensive to run at scale. Anthropic has stated it is working on efficiency improvements before any general release.

So it is dangerous and expensive. Both problems they need to solve before shipping it broadly.

What They Did Instead: Project Glasswing

On April 7, Anthropic launched Project Glasswing. More than 40 partner organizations get access to Mythos Preview strictly for defensive security work, scanning their own code and open-source software for vulnerabilities. Partners include Amazon, Apple, Microsoft, Cisco, CrowdStrike, Palo Alto Networks, and the Linux Foundation. Findings will be shared across the industry.

Anthropic is providing up to $100 million in usage credits to participating companies and $4 million to open-source security organizations including OpenSSF, Alpha-Omega, and the Apache Software Foundation.

Over 99% of the vulnerabilities found have not yet been patched, so details cannot be disclosed publicly yet. For findings they cannot discuss, Anthropic is publishing SHA-3 cryptographic commitments as proof they hold the findings. These will be revealed once responsible disclosure is complete.

There is no public release date.

Conclusion

This was a big one. Mythos is real, it is the most capable model Anthropic has built, and it is deliberately locked away until they figure out how to release it safely. Project Glasswing is their attempt to use it for good in the meantime.

Resources

• Anthropic Red Team: Assessing Claude Mythos Preview’s cybersecurity capabilities

• Axios: Anthropic withholds Mythos Preview over hacking concerns

• TechCrunch: Anthropic debuts Mythos preview in new cybersecurity initiative

• Fortune: Anthropic confirms Mythos after data leak

• Bloomberg: Anthropic lets Apple, Amazon test Mythos