I haven't slept properly in days. I'm building a package manager for C. And I regret nothing.
4 hours of sleep a night for the past few days. ForgeZero went from 1.0 to 1.9.0 in that time. This isn't work anymore. This is obsession.
Let me be real with you. Why would anyone spend their nights fighting linkers, allocators, and milliseconds?
Because I refuse to let C development die.
I'm obsessed with low-level programming. That feeling when it's just you and the bare metal. No fat abstractions. No lazy runtimes holding your hand. No GC randomly deciding now is a great time to pause everything. Just your logic, the CPU, and the truth.
C is an art form. It's honest. It's foundational. And the tooling around it is, frankly, a disaster.
Setting up dependencies in C feels like archaeology. The build systems look like they were designed to punish you. New devs touch it once and run back to npm. I get it. But I think we can fix this.
That's what ForgeZero 2.0: NEXUS is about.
What's coming
📦 A package manager that doesn't suck — fz pm
Just: point at a repo, let ForgeZero do the rest.
🔌 Compiler-agnostic core
Clang, GCC, NASM, FASM — whatever your stack is, ForgeZero wraps it. A couple lines of config and it knows how to talk to your toolchain. Exotic target hardware? Still fine.
🧠 Incremental builds that actually work
Stop rebuilding the entire project because you fixed a typo in a comment. NEXUS does deep header dependency analysis — it sees the full dep tree and only recompiles what actually changed. Your CPU will thank you.
The stack
Go for the core. Rust for the hot paths (yeah, I'm that guy now). Pure C for the parts where I want to feel things.
Is it overengineered? Maybe. Does it rip? Absolutely.
This isn't just a software update. It's a bet that the classics don't go stale — they just needed better tooling.
ForgeZero 2.0. NEXUS. Low-level lives.
Solo dev. All PRs and issues read personally. Come break things with me.
Documentation: https://github.com/forgezero-cli/forgezero
via DEV Community: rust (author: Alex Voste)
4 hours of sleep a night for the past few days. ForgeZero went from 1.0 to 1.9.0 in that time. This isn't work anymore. This is obsession.
Let me be real with you. Why would anyone spend their nights fighting linkers, allocators, and milliseconds?
Because I refuse to let C development die.
I'm obsessed with low-level programming. That feeling when it's just you and the bare metal. No fat abstractions. No lazy runtimes holding your hand. No GC randomly deciding now is a great time to pause everything. Just your logic, the CPU, and the truth.
C is an art form. It's honest. It's foundational. And the tooling around it is, frankly, a disaster.
Setting up dependencies in C feels like archaeology. The build systems look like they were designed to punish you. New devs touch it once and run back to npm. I get it. But I think we can fix this.
That's what ForgeZero 2.0: NEXUS is about.
What's coming
📦 A package manager that doesn't suck — fz pm
fz pm add and you're done. Pull C libraries and ASM modules the same way you'd import anything in a modern language. No more hunting down tarballs. No more copy-pasting compiler flags from Stack Overflow threads from 2009. No more dependency hell.Just: point at a repo, let ForgeZero do the rest.
🔌 Compiler-agnostic core
Clang, GCC, NASM, FASM — whatever your stack is, ForgeZero wraps it. A couple lines of config and it knows how to talk to your toolchain. Exotic target hardware? Still fine.
🧠 Incremental builds that actually work
Stop rebuilding the entire project because you fixed a typo in a comment. NEXUS does deep header dependency analysis — it sees the full dep tree and only recompiles what actually changed. Your CPU will thank you.
The stack
Go for the core. Rust for the hot paths (yeah, I'm that guy now). Pure C for the parts where I want to feel things.
Is it overengineered? Maybe. Does it rip? Absolutely.
This isn't just a software update. It's a bet that the classics don't go stale — they just needed better tooling.
ForgeZero 2.0. NEXUS. Low-level lives.
Solo dev. All PRs and issues read personally. Come break things with me.
Documentation: https://github.com/forgezero-cli/forgezero
via DEV Community: rust (author: Alex Voste)
rakers — a headless JS renderer in Rust
A lot of useful content on the web only exists after JavaScript runs. Server-side rendering has made a comeback, but plenty of sites still ship a near-empty HTML skeleton and populate it entirely client-side. If you want to extract that content — for archiving, testing, or processing — you need to run the JavaScript first.
The standard answer is a headless browser: Playwright, Puppeteer, or a self-hosted Chrome. These work, but they are heavy. Chrome's footprint is around 300 MB, startup takes one to two seconds, and running it in CI requires care. For many use cases the full browser is overkill: you don't need CSS layout, GPU compositing, or WebGL. You just need the DOM to exist after the scripts have run.
rakers is an attempt to find the floor on that problem. It is a single ~10 MB binary that parses HTML, runs the JavaScript, and returns the post-execution HTML.
How it works
The pipeline has three stages:
● Parse — html5ever (Servo's HTML5 parser, published as a standalone crate) turns the input into a DOM tree.
● Execute —
● Serialize — The post-execution DOM is serialized back to HTML and written to stdout (or a file).
The JS engine is QuickJS via the rquickjs crate. QuickJS is ES2023, compact, and embeds cleanly into Rust without much ceremony. For environments without a C compiler there is an optional boa_engine backend, a pure-Rust JS engine with a smaller compatibility surface but zero native dependencies.
The DOM stub
The trickiest part is not the JS engine — it is the fake browser environment. Frameworks like React, Vue, and Svelte expect a fairly complete DOM API. Since rakers has no real layout engine, those APIs are implemented as a JavaScript stub in bootstrap.js that is injected before any page script runs.
The stub covers the most common patterns: element creation and mutation, getElementById, querySelector, querySelectorAll, event listener registration, classList, localStorage, history.pushState, and XHR. XHR is backed by a synchronous Rust fetch (ureq) so frameworks that load templates at runtime via XHR — like RiotJS — actually retrieve them.
Inevitably there are gaps. Anything that requires layout information (offsetWidth, getBoundingClientRect) returns zero. Native ES modules are skipped. The stub is good enough to run 21 of the 23 TodoMVC implementations, which provides a reasonable compatibility benchmark across React, Vue, Angular, Svelte, Preact, Mithril, Elm, Backbone, Ember, Knockout, and others.
Using it
Render a URL
Render a local file
Pipe HTML in
Route traffic through Tor
Filter to a CSS selector
Installation instructions in the README.
What it is not
rakers is not a browser. It has no CSS engine, no layout, no WebGL, no IndexedDB, no service workers. Anything that depends on those will not work. Sites that fingerprint the JS environment or require a real navigator.plugins array will also fail. For those cases a real headless browser is the right tool.
The value proposition is narrow but real: for sites that render via a self-contained JS bundle with no exotic browser dependencies, rakers is faster, smaller, and simpler to deploy than anything that ships a copy of Chromium.
via DEV Community: rust (author: tbxyz)
A lot of useful content on the web only exists after JavaScript runs. Server-side rendering has made a comeback, but plenty of sites still ship a near-empty HTML skeleton and populate it entirely client-side. If you want to extract that content — for archiving, testing, or processing — you need to run the JavaScript first.
The standard answer is a headless browser: Playwright, Puppeteer, or a self-hosted Chrome. These work, but they are heavy. Chrome's footprint is around 300 MB, startup takes one to two seconds, and running it in CI requires care. For many use cases the full browser is overkill: you don't need CSS layout, GPU compositing, or WebGL. You just need the DOM to exist after the scripts have run.
rakers is an attempt to find the floor on that problem. It is a single ~10 MB binary that parses HTML, runs the JavaScript, and returns the post-execution HTML.
How it works
The pipeline has three stages:
● Parse — html5ever (Servo's HTML5 parser, published as a standalone crate) turns the input into a DOM tree.
● Execute —
<script> tags are collected in document order, inline and external alike. External scripts are fetched synchronously. All scripts are evaluated in a sandboxed JS context that exposes a browser-compatible global environment: document, window, console, XMLHttpRequest, localStorage, setTimeout, and more.● Serialize — The post-execution DOM is serialized back to HTML and written to stdout (or a file).
The JS engine is QuickJS via the rquickjs crate. QuickJS is ES2023, compact, and embeds cleanly into Rust without much ceremony. For environments without a C compiler there is an optional boa_engine backend, a pure-Rust JS engine with a smaller compatibility surface but zero native dependencies.
The DOM stub
The trickiest part is not the JS engine — it is the fake browser environment. Frameworks like React, Vue, and Svelte expect a fairly complete DOM API. Since rakers has no real layout engine, those APIs are implemented as a JavaScript stub in bootstrap.js that is injected before any page script runs.
The stub covers the most common patterns: element creation and mutation, getElementById, querySelector, querySelectorAll, event listener registration, classList, localStorage, history.pushState, and XHR. XHR is backed by a synchronous Rust fetch (ureq) so frameworks that load templates at runtime via XHR — like RiotJS — actually retrieve them.
Inevitably there are gaps. Anything that requires layout information (offsetWidth, getBoundingClientRect) returns zero. Native ES modules are skipped. The stub is good enough to run 21 of the 23 TodoMVC implementations, which provides a reasonable compatibility benchmark across React, Vue, Angular, Svelte, Preact, Mithril, Elm, Backbone, Ember, Knockout, and others.
Using it
Render a URL
rakers https://example.comRender a local file
rakers page.htmlPipe HTML in
curl -s https://example.com | rakersRoute traffic through Tor
rakers --proxy socks5://127.0.0.1:9050 https://example.comFilter to a CSS selector
rakers --selector "article.post" https://example.comInstallation instructions in the README.
What it is not
rakers is not a browser. It has no CSS engine, no layout, no WebGL, no IndexedDB, no service workers. Anything that depends on those will not work. Sites that fingerprint the JS environment or require a real navigator.plugins array will also fail. For those cases a real headless browser is the right tool.
The value proposition is narrow but real: for sites that render via a self-contained JS bundle with no exotic browser dependencies, rakers is faster, smaller, and simpler to deploy than anything that ships a copy of Chromium.
via DEV Community: rust (author: tbxyz)
fz 2.0.0 NEXUS — package manager, BLAKE3 cache, and cross-compilation for C/ASM
Yesterday I shipped 1.9.0. Got a solid mix of hate and genuinely useful feedback. Didn't sleep. Took all of it personally. Built 2.0.0 instead.
No point dragging it out — here's everything I promised, shipped right now.
What's new
⚡ BLAKE3 file hashing — 7x faster cache
Dropped SHA256. Switched to BLAKE3 across the board.
Package verification from the catalog uses BLAKE3 too.
📦 Package manager — fz pm
The big one. Dependency management for C/ASM projects that doesn't make you want to quit programming.
Dependencies live in
🔌 Shared library support
New flags:
🎯 Cross-compilation
ARM, RISC-V, x86_64, i386. Compiler, assembler, and linker are selected automatically for the target triple.
🗂 Static libraries
Builds
🧠 LSP support
Generates
Improvements & fixes
● Parallel builds with
● Linker scripts and text section address:
● Fixed object file name collisions (
● All
● Context and timeouts for all network and git operations
● Test coverage: utils 84%, linker 60%, assembler 60%, builder 56%
Install
Links
● Repository: https://github.com/forgezero-cli/ForgeZero
● Package catalog: https://github.com/forgezero-cli/catalog
● Docs: https://github.com/forgezero-cli/ForgeZero#readme
Solo project. All issues and PRs read personally. If something's broken or missing — tell me, I'll probably fix it overnight.
via DEV Community: rust (author: Alex Voste)
Yesterday I shipped 1.9.0. Got a solid mix of hate and genuinely useful feedback. Didn't sleep. Took all of it personally. Built 2.0.0 instead.
No point dragging it out — here's everything I promised, shipped right now.
What's new
⚡ BLAKE3 file hashing — 7x faster cache
Dropped SHA256. Switched to BLAKE3 across the board.
Package verification from the catalog uses BLAKE3 too.
📦 Package manager — fz pm
The big one. Dependency management for C/ASM projects that doesn't make you want to quit programming.
fz pm add <repository>
fz pm remove <package>
fz pm update
fz pm list
fz pm search <query>
fz pm install
fz pm catalog
Dependencies live in
.fz.yaml. Removal cleans up empty parent directories automatically. Backed by a community-driven JSON package catalog.🔌 Shared library support
New flags:
-shared, -cc-flag, -ld-flag. Build .so and .dylib targets without wiring things up by hand.🎯 Cross-compilation
fz -target arm-linux-gnueabihf
fz -target riscv64-linux-gnu
fz -target x86_64-w64-mingw32
ARM, RISC-V, x86_64, i386. Compiler, assembler, and linker are selected automatically for the target triple.
🗂 Static libraries
fz -type static -lib mylib
Builds
.a archives from object files via ar.🧠 LSP support
fz -compile-commands
Generates
compile_commands.json for clangd and any compatible LSP client. Autocomplete and go-to-definition, no manual config.Improvements & fixes
● Parallel builds with
-j N● Linker scripts and text section address:
-T, -Ttext● Fixed object file name collisions (
hello.asm vs hello.s)● All
golangci-lint warnings resolved: errcheck, govet, ineffassign● Context and timeouts for all network and git operations
● Test coverage: utils 84%, linker 60%, assembler 60%, builder 56%
Install
go install github.com/forgezero-cli/ForgeZero/cmd/fz@latest
Links
● Repository: https://github.com/forgezero-cli/ForgeZero
● Package catalog: https://github.com/forgezero-cli/catalog
● Docs: https://github.com/forgezero-cli/ForgeZero#readme
Solo project. All issues and PRs read personally. If something's broken or missing — tell me, I'll probably fix it overnight.
via DEV Community: rust (author: Alex Voste)
Is Gemini 3.5 Flash Actually Better at Coding Than 3.1 Pro? I Tested It with Real Rust Code
via DEV Community: rust (author: hiyoyo)
via DEV Community: rust (author: hiyoyo)
Telegraph
Is Gemini 3.5 Flash Actually Better at Coding Than 3.1 Pro? …
Background Gemini 3.5 Flash launched at Google I/O 2026 with a bold claim: it beats Gemini 3.1 Pro on coding and agentic benchmarks — while running 4x faster. At the same time, X (formerly Twitter) is full of posts saying it hallucinates constantly and doesn't…
Rust Concepts: Macros, Modules, Testing & Unsafe Rust (Part 3)
via DEV Community: rust (author: mihir mohapatra)
via DEV Community: rust (author: mihir mohapatra)
Telegraph
Rust Concepts: Macros, Modules, Testing & Unsafe Rust (Part …
This is Part 3 of the Core Rust Concepts series. Part 1 — Ownership, Borrowing, Lifetimes, Traits, Result/Option, Pattern Matching Part 2 — Closures, Iterators, Generics, Enums, Smart Pointers, Async/Await Table of Contents Macros Modules & the Cargo Ecosystem…
I Built a Next-Gen DNS Diagnostic CLI in Rust That Visualizes DNSSEC Trust Chains
via DEV Community: rust (author: kent-tokyo)
via DEV Community: rust (author: kent-tokyo)
Telegraph
I Built a Next-Gen DNS Diagnostic CLI in Rust That Visualize…
If you've ever tried to debug a DNSSEC misconfiguration using dig, you know the pain. You're staring at a wall of raw text, manually cross-referencing DS records against DNSKEY records, tracing through TLD delegations one query at a time. It works — but it's…
Rust Concepts: Macros, Modules, Testing & Unsafe Rust (Part 3)
via DEV Community: rust (author: mihir mohapatra)
via DEV Community: rust (author: mihir mohapatra)
Telegraph
Rust Concepts: Macros, Modules, Testing & Unsafe Rust (Part …
This is Part 3 of the Core Rust Concepts series. Part 1 — Ownership, Borrowing, Lifetimes, Traits, Result/Option, Pattern Matching Part 2 — Closures, Iterators, Generics, Enums, Smart Pointers, Async/Await Table of Contents Macros Modules & the Cargo Ecosystem…
I Just Wanted to Reuse Async Functions in Rust. I Ended Up Building a Tiny Task Manager
via DEV Community: rust (author: icsboyx)
via DEV Community: rust (author: icsboyx)
Telegraph
I Just Wanted to Reuse Async Functions in Rust. I Ended Up B…
I Just Wanted to Reuse Async Functions in Rust. I Ended Up Building a Tiny Task Manager I am currently studying Rust, and one of the things that kept bothering me was surprisingly simple: How do I reuse an async function more than once in a clean way? At…
Web Developer Travis McCracken on Rate Limiting at the Edge: A Backend Strategy
via DEV Community: rust (author: Travis McCracken Web Developer)
via DEV Community: rust (author: Travis McCracken Web Developer)
Telegraph
Web Developer Travis McCracken on Rate Limiting at the Edge:…
Harnessing Power with Rust and Go: A backend developer's journey Hello, fellow developers! I’m Web Developer Travis McCracken, and today I want to share some insights into my work with backend development, especially with two of the most exciting programming…
Ditching Geo-Restrictions in Crypto Stores is Harder Than It Looks
via DEV Community: rust (author: pretty ncube)
via DEV Community: rust (author: pretty ncube)
Telegraph
Ditching Geo-Restrictions in Crypto Stores is Harder Than It…
The Problem We Were Actually Solving I still remember the day I was tasked with setting up an admin dashboard for our crypto digital store. The catch - we were operating in a country with strict financial regulations, which made it impossible to use conventional…
Building a native terminal for AI coding agents in Rust + GPUI
via DEV Community: rust (author: Arthur Jean)
via DEV Community: rust (author: Arthur Jean)
Telegraph
Building a native terminal for AI coding agents in Rust + GP…
Author: Arthur Jean, solo indie maker. More on paneflow.dev and arthurjean.com.Repo: github.com/ArthurDEV44/paneflow. MIT licensed. I spend my days running Claude Code, Codex, and OpenCode in parallel panes. Different agents on different branches, each with…
The Day Our Payment System Died at 3 AM From a False Positive in a Blacklist
via DEV Community: rust (author: pretty ncube)
via DEV Community: rust (author: pretty ncube)
Telegraph
The Day Our Payment System Died at 3 AM From a False Positiv…
The Problem We Were Actually Solving In 2023 we launched a SaaS tool for performance engineers. Nothing fancy—just a low-latency endpoint profiler that ingests traces and returns flamegraphs with flamegraph.js. We didnt need Stripes UI. We needed a way to…
Claude returned ```json blocks 14% of the time. Here is the Rust crate I wish I had earlier.
via DEV Community: rust (author: Mukunda Rao Katta)
via DEV Community: rust (author: Mukunda Rao Katta)
Telegraph
Claude returned ```json blocks 14% of the time. Here is the …
I had a system prompt that ended with: Reply with only a JSON object. Do not include code fences. Do not include explanation. That should be enough. It is not. Over a week of structured-output calls (12,400 of them, mostly Claude Sonnet 4.5 and 4.7), I logged…
Our retry loop made an outage worse. The circuit breaker stopped the cascade.
via DEV Community: rust (author: Mukunda Rao Katta)
via DEV Community: rust (author: Mukunda Rao Katta)
Telegraph
Our retry loop made an outage worse. The circuit breaker sto…
A few weeks back there was a 22-minute window where Anthropic returned a high rate of 5xx responses. Not a full outage. Degraded. Our agent service had a retry policy that backed off and tried again on 5xx. With six workers and a shared retry budget that…