Why Every SRE Should Learn a Little Rust

I'm not saying rewrite your stack in Rust. I'm saying: learn enough to read it.

Here's why, from someone who dragged their feet for years and finally gave in.

Rust is showing up everywhere in infra

● Observability: Vector, OpenTelemetry collector components, Tempo, Loki's ingesters in some paths
● Proxies: Linkerd's data plane, parts of Istio's future, newer eBPF-based tools
● Databases: TiKV, SurrealDB, and bits of Postgres extensions
● CLIs: Half the infra tools you install now are Rust binaries

If your stack has observability or networking components, you're going to be reading Rust code in an incident sooner or later. Better to be able to follow along.

You don't need to be fluent

You need to:

● Read Rust well enough to follow a function call
● Understand what ownership and borrowing mean (you won't debug them, but you need to read the code)
● Compile a small program
● Read a panic stack trace

That's enough. That's maybe 2 weekends of work.

The side benefit

Rust teaches you to think about state, concurrency, and error handling more carefully. Those skills show up in whatever language you actually write in. I write less broken Python and Go after learning Rust, even though I rarely write Rust.

The starting point

The Rust book (free online) + one small project (I did a log parser). Skip the async stuff for now. Come back to it when you need it.

You're not becoming a Rust engineer. You're becoming an SRE who can read the tools your stack depends on. That's a real edge.

Written by Dr. Samson Tanimawo
BSc · MSc · MBA · PhD
Founder & CEO, Nova AI Ops. https://novaaiops.com

via DEV Community: rust (author: Samson Tanimawo)

Meet QueryDen: The Modern Database Client Built for Developers

As developers, we spend a massive chunk of our day staring at database clients. But let's be honest—many existing tools feel either incredibly bloated, painfully slow, or stuck in the early 2000s UI-wise.

That’s exactly why we built QueryDen.

We wanted a database IDE that is fast, beautiful, and stays out of your way so you can focus on writing queries, analyzing data, and building things.

What is QueryDen?

QueryDen is a lightweight, high-performance desktop database client engineered by the team at OpenIdle. It’s designed from the ground up for modern developer workflows, giving you a smooth, distraction-free environment to manage your data.

Key Features 🚀

● ⚡ Blazing Fast Performance: No more waiting for heavy Java-based wrappers to boot up. QueryDen feels native, lightweight, and incredibly responsive.
● 🎨 Intuitive, Modern UI: A beautifully designed dark/light interface designed to reduce visual clutter and cognitive overload.
● 🛠️ Robust Query Editor: Featuring smart auto-completion, syntax highlighting, and an easy format tool that takes the headache out of writing complex SQL.
● 📂 Effortless Schema Exploration: Quickly navigate tables, views, and relationships without losing your place in your workspace.
● 🔒 Secure & Private: Connect safely to your local and remote databases. Your credentials and data stay where they belong—with you.

Why We're Building This

We believe that developer tools shouldn't just be functional—they should be a joy to use. QueryDen is our take on what a modern, hassle-free database manager should feel like.

We’re actively improving it and would love to get your feedback!

Get Started & Join the Community

QueryDen is currently available for download across platforms. Give it a spin and let us know what you think!

● Download / Website: queryden.openidle.com
● Give us feedback: Drop a comment right here on dev.to or open an issue over on our GitHub discussions!

via DEV Community: rust (author: Keenan)

I built a build tool in Go — and now I'm slowly rewriting pieces in Rust (fz 1.9.0 release)

So I've been solo-building fz — a fast, opinionated build tool for C/ASM projects written in Go. No Makefile hell, no CMake nightmares. Just a single binary that figures out your toolchain and gets out of the way.

Today I shipped 1.9.0 (and a quick 1.9.2 patch). Here's what changed — and why I started poking at Rust.

What's new in 1.9.0

Cross-compilation with -target <triple>

fz -target arm-linux-gnueabihf
fz -target riscv64-linux-gnu
fz -target x86_64-w64-mingw32

fz now auto-selects the right compiler, assembler, and linker for the target triple. ARM, RISC-V, x86_64, i386 — all supported out of the box.

Static libraries: -type static / -lib

fz -type static -lib mylib

Builds .a archives from object files via ar. Previously you had to wire this up yourself. Now it's a one-liner.

LSP support: compile_commands.json

fz -compile-commands

Generates compile_commands.json for clangd and any other LSP client. Finally get autocomplete and go-to-definition in your editor without configuring anything manually.

Other improvements

● fz -shell now handles both single files and full directories
● Fixed a long-standing bug where hello.asm and hello.s would produce conflicting object file names
● Linker test coverage: 17% → 60% 🎉
● Squashed dozens of golangci-lint warnings

1.9.2 patch — the boring-but-important stuff

Cleaned up every errcheck, govet, and ineffassign warning across the codebase:

● Proper error handling for json.Encode, os.Rename, os.Chmod, storeCache
● Error checks in tests: os.Chdir, os.MkdirAll, os.Create, buf.ReadFrom
● Fixed an empty branch in builder_test.go and a wrong printf format
● Updated go.mod / go.sum

Nothing glamorous, but the kind of hygiene that prevents weird bugs six months from now.

The Rust experiment: rustcache

⚠️ This lives in a separate branch and is not part of the release. Yet.

I've been curious about Rust FFI for a while, so I decided to try moving the caching layer — file hashing and copying — into a Rust static library.

Here's what I've built so far in rustcache/:

// SHA256 of a file, returned as a hex string over FFI
#[no_mangle]
pub extern "C" fn rust_hash_file(path: *const c_char) -> *mut c_char { ... }

// Simple file copy via std::fs::copy
#[no_mangle]
pub extern "C" fn rust_copy_file(src: *const c_char, dst: *const c_char) -> i32 { ... }

5 unit tests, all passing. Builds into librustcache.a.

The plan

Once I wire it into Go via cgo and build tags:

//go:build rustcache

// #cgo LDFLAGS: -L./rustcache/target/release -lrustcache
// #include "rustcache.h"
import "C"

...users will be able to opt in with -tags rustcache and I'll benchmark both paths. If the Rust version is meaningfully faster, it becomes the default.

For now: zero impact on existing fz users. The Go cache path is unchanged.

What's next

● [ ] Finish the Rust → Go integration (cgo, build tags, benchmarks)
● [ ] Dynamic library support (.so / .dylib)
● [ ] Colored error and warning output
● [ ] Remote cache (S3 / MinIO) for CI/CD speedups

If you're building C or ASM projects and tired of Makefile archaeology, give fz a try. Issues and PRs welcome — it's a solo project and I read everything.

Docs and install: https://github.com/forgezero-cli/forgezero

via DEV Community: rust (author: Alex Voste)

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

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 — <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.com

Render a local file

rakers page.html

Pipe HTML in

curl -s https://example.com | rakers

Route traffic through Tor

rakers --proxy socks5://127.0.0.1:9050 https://example.com

Filter to a CSS selector

rakers --selector "article.post" https://example.com

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)

I Added Real Playable Demo Maps to RPGMapEditor.com

via DEV Community: rust (author: TheXper)

AI Tools Need Contracts, Not Prompts

via DEV Community: rust (author: Don Johnson)

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.

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)

Building Real-Time Trading Systems: Why We Abandoned Go for Rust

via DEV Community: rust (author: speed engineer)

Rust Concepts: Macros, Modules, Testing & Unsafe Rust (Part 3)

via DEV Community: rust (author: mihir mohapatra)

I Built a Next-Gen DNS Diagnostic CLI in Rust That Visualizes DNSSEC Trust Chains

via DEV Community: rust (author: kent-tokyo)

Rust Concepts: Macros, Modules, Testing & Unsafe Rust (Part 3)

via DEV Community: rust (author: mihir mohapatra)

Why CJK Support in Rust Is Hard

via DEV Community: rust (author: kent-tokyo)

I Just Wanted to Reuse Async Functions in Rust. I Ended Up Building a Tiny Task Manager

via DEV Community: rust (author: icsboyx)

Web Developer Travis McCracken on Rate Limiting at the Edge: A Backend Strategy

via DEV Community: rust (author: Travis McCracken Web Developer)

Embedding 685 million texts in 32 minutes

via DEV Community: rust (author: Coach Danis)

Ditching Geo-Restrictions in Crypto Stores is Harder Than It Looks

via DEV Community: rust (author: pretty ncube)

Building a native terminal for AI coding agents in Rust + GPUI

via DEV Community: rust (author: Arthur Jean)

Rust + WebAssembly实战：用Rust编写高性能前端模块

via DEV Community: rust (author: WDSEGA)

The Day Our Payment System Died at 3 AM From a False Positive in a Blacklist

via DEV Community: rust (author: pretty ncube)