What 44 CVEs Tell You About Rust's Safety Boundary

via DEV Community: rust (author: Arthur)

Rust's Borrow Checker: Translating Intent into Memory Safety

When people start learning Rust, they usually run into the same obstacle: the borrow checker.

I’ve been there, and everyone has. But the truth is this: The borrow checker isn’t against you; it simply translates what you meant into what the computer needs. Once you understand that, Rust's borrow checker makes a lot more sense.

Let me show you the moment this made sense for me.

The Classic Problem

Here’s a tiny piece of code that looks harmless:

let mut name = String::from("Alice");
let r = &name;

name.push('!'); // this is an error.
println!("{}", r);

Rust says no. And at first, it's frustrating; it seems like the compiler is being pedantic. But there's a method to this.

Rust’s Two Rules

Rust has two simple rules:

1. You can have one mutable reference
2. OR any number of immutable references

The catch: You can never have both at the same time.

Why? Because if something is being changed, Rust doesn’t want other parts of your code reading a half‑changed value. And that's all there is to it.

The “Two Doors” Analogy

Imagine your data is a room.

● An immutable reference is like giving someone a window into the room.
They can look, but not touch.
● A mutable reference is like giving someone the key to the room.
They can move furniture around.

Rust’s rule is simple: You can’t have the window open while someone is rearranging the furniture.

Fixing the Code the Right Way

Here’s our earlier example, but fixed:

let mut name = String::from("Alice");

name.push('!');  // do the mutation first

let r = &name;   // then borrow immutably
println!("{}", r);

Or, if you really need both at once, you can clone. Cloning is not a crime, especially for beginners:

let mut name = String::from("Alice");
let r = name.clone();

name.push('!');
println!("original: {}", name);
println!("copy: {}", r);

A Trick That Helps Every Beginner

If you're just starting out, follow this habit: If you’re mutating something, finish all your mutations before you borrow it. This one habit eliminates most borrow checker errors you'll see.

Why Rust Does This (And Why It’s a Good Thing)

Languages like Python, Java, and JavaScript let you mutate data while other parts of your code are reading it. Most of the time, it’s totally harmless. But sometimes, it causes:

● sneaky race conditions (which usually only occur during production)
● strange bugs
● inconsistent state
● security issues
● data corruption

Rust prevents all of that, because it's designed to.

If You’re Learning Rust, Here’s My Advice

Don’t fight the borrow checker. Instead:

● Borrow when you only need to read
● Mutate before you borrow
● Clone when you need independence
● Trust the compiler’s hints
● Keep your functions small
● Return owned data when in doubt

Rust rewards those who take the time to understand the mechanics. The borrow checker is just the first step in that shift in perspective.

Want More Beginner‑Friendly Rust Posts?

I’m working on a series covering:

● ownership
● borrowing
● lifetimes
● slices
● structs
● enums
● pattern matching
● error handling
● async basics

If you want me to cover something specific, or if there's a specific concept that hasn't clicked yet, drop it in the comments! I’ll turn the most requested topic into another post.

via DEV Community: rust (author: MournfulCord)

How one bad prompt burned $40 of my Claude budget in 18 minutes

via DEV Community: rust (author: Mukunda Rao Katta)

Web Developer Travis McCracken on Using Async Rust Safely

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

AppleScript Injection and Directory Traversal — Security Bugs I Fixed in My Own Apps

All tests run on an 8-year-old MacBook Air.
All results from shipping 7 Mac apps as a solo developer. No sponsored opinion.
Security review of my own apps found real vulnerabilities. Not theoretical — actual bugs that could affect users.
Here's what I found and how I fixed them.

AppleScript injection via ADB output
HiyokoAutoSync uses ADB to get device information. ADB output is user-controlled — an attacker with physical access to the device can craft device names containing special characters.
If that output is passed to a shell command without sanitization:
rust// Vulnerable
let cmd = format!("osascript -e 'display notification \"{}\"'", device_name);
Command::new("sh").arg("-c").arg(&cmd).spawn();
A device named "; rm -rf ~/Documents; echo " executes arbitrary commands.
Fix: never interpolate external input into shell strings. Use argument arrays:
rust// Safe
Command::new("osascript")
.args(["-e", &format!("display notification \"{}\"",
device_name.replace('"', "\\""))])
.spawn();
Better: avoid shell interpretation entirely. Pass arguments as separate strings, not a single shell command.

Directory traversal in file sync
Sync operations use paths from ADB. A malicious Android app could expose a path like ../../.ssh/id_rsa via MTP.
rust// Vulnerable
let dest = mac_base_dir.join(&android_path); // android_path = "../../.ssh/id_rsa"
// dest is now outside mac_base_dir
Fix: validate that the resolved path stays within the intended directory:
rustfn safe_join(base: &Path, relative: &Path) -> Result {
let joined = base.join(relative);
let canonical = joined.canonicalize()
.unwrap_or(joined.clone());

if !canonical.starts_with(base) {
    return Err(AppError::Security(
        "Path traversal attempt detected".into()
    ));
}

Ok(joined)

}

Symlink attacks
A symlink in the source directory pointing outside the destination could allow writes to arbitrary locations.
rustfn is_safe_path(path: &Path) -> bool {
// Reject symlinks in sync operations
match path.symlink_metadata() {
Ok(meta) => !meta.file_type().is_symlink(),
Err(_) => false,
}
}
Skip symlinks during sync. Document this in the app — users who need symlink handling can request it explicitly.

The lesson
Security review of your own code finds real bugs. Do it before shipping, not after. The attack surface for a desktop app is smaller than a web app, but it's not zero — especially when external data (ADB output, file paths) influences file system operations.

If this was useful, a ❤️ helps more than you'd think — thanks!
Hiyoko PDF Vault → https://hiyokoko.gumroad.com/l/HiyokoPDFVault
X → @hiyoyok

via DEV Community: rust (author: hiyoyo)

I built a programming language to test how well LLM-edited code survives

via DEV Community: rust (author: O6lvl4)

Zed IDE Is 1.0 — and the Electron Era Just Ended

via DEV Community: rust (author: Arthur)

OpenCut: The Future of Open Source Video Editing is Being Rewritten for Developers!

via DEV Community: rust (author: GitHubOpenSource)

Why Bun is Rewriting in Rust (And What It Means for JavaScript Developers)

via DEV Community: rust (author: Tony Spiro)

Swapping Go for Rust: 10x Cheaper K8s Ingress

via DEV Community: rust (author: Syed Ahmer Shah)

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)