I've wanted to build my own video editor for years, and I finally spent my summer break making one!
It's called Zerium, a free and open-source video editor built with Rust, GPUI, and wgpu.
It's inspired by AviUtl, a popular video editor in Japan. My goal is to make something that's intuitive to use while still being powerful enough for advanced editing and motion graphics.
Some of the features:
GPU-accelerated rendering
Timeline editing with layers, keyframes, and curves
Plugin support
Cross-platform support (Windows, macOS, Linux)
Completely free and open source
I've just released the first beta! It's still a work in progress, so any feedback is welcome!
Hey everyone! I’m working on Dearust, an experimental, incremental Rust migration of Darling, which runs macOS software on Linux.
The motivation is to explore how much of a compatibility layer this large can move into safer Rust while preserving its existing behavior and ABI. It’s also an experiment in how far AI-assisted development can go when the results are checked against real builds, regression tests, and actual application execution.
I’m using OpenAI Codex extensively for implementation, code review, debugging, and test automation, including parallel agents where useful. That involvement is disclosed in the README and new commits. The repository includes safety notes, verification records, and documented limitations so people can inspect the evidence.
So far, the work includes Rust host utilities and runtime slices for synchronization, errno conversion, Mach locksets, process queries, guarded descriptors, and bounded pathname handling. Testing has also uncovered and fixed concrete bugs, including a null-path crash during bsdtar operations.
The latest build passes 108 Rust tests, 29 Python tests, 16 utility workloads, and 29 app checks—with one explicitly documented log normalization. Earlier testing also covered three GUI samples.
This is still experimental and very incomplete. Most runtime and framework code remains C/C++/assembly, and integration currently depends on a matching Darling build. General macOS application compatibility is still a long-term goal.
Full credit to the Darling developers and upstream contributors whose work makes this possible.
I’d welcome feedback, especially on the ABI boundaries, safety assumptions, testing approach, and migration priorities.
TLDR: built my own RSS reader, with built-in features such as YouTube in-line player, configurable keyboard shortcuts, feed display modes, filters and auto-discovery, HLS playback support, folders, webhooks (Discord, Slack and custom template with replaceable variables) and full text search. Not vibe-coded. This is a project I've been putting in a lot of time and energy over the past 6 months. Please kindly check the repo, the code, commits, PR's, CI workflows, etc, before judging.
The demo instance is mostly read-only to prevent abuse. It's also a shared instance, so it's possible everything will be marked as read already, in which case you can toggle "all posts" to see everything.
I'm a software dev with over 10 years of experience who's decided to use my skills and build something for myself after dealing with a difficult burnout phase having worked at AWS for 8 years. I have since left and am in a much better space now :)
This project is a result of that process. The backend is mostly human-coded, but leaned more on LLMs for the frontend as it's not my strongest area. I have, however, designed, reviewed to the best of my knowledge and am confident about everything I've pushed.
The logo was designed by a tattoo artist I know from Brazil. He's credited in the repo's README file.
On the Rust side:
It's a workspace split by layer: routes, api/crud handlers, database, webhook and the RSS fetcher and polling worker. Only the database crate talks to Diesel.
Postgres or sqlite is chosen by a cargo feature, so the different binaries (server and desktop app) build the same crates and only the database engine they need.
API types derive ts_rs::TS, so cargo test regenerates the frontend's types.
One WyrmError type implements actix's ResponseError, so raw database errors never reach a response.
For installation, I provide easy-to-use Docker compose and Kubernetes manifests. The mobile version can be installed as a PWA. There are also builds for Linux, Windows and MacOS.
Feedback welcome, especially on the Rust side or if you're coming from Miniflux or FreshRSS.
Built a desktop app for security analysts: force-directed vendor<->CVE graph, AI-powered mitigation drafting, CISA KEV flagging, persistent chat sessions. Local-first (SQLite on disk, no telemetry).
Why Tauri: Native look, ~15MB binary, ~80MB RAM idle. WebView2 quirks (blob downloads) were manageable with Rust fs fallback.
Key Rust pattern: Thin IPC layer. Rust spawns Python processes for heavy lifting (LLM orchestration, NVD parsing). Chat history goes through stdin to bypass Windows 32KB CLI limit:
let mut child = Command::new(&python_path)
.arg("--chat").arg(&cve_id)
.stdin(Stdio::piped()).spawn()?;
{
let stdin = child.stdin.as_mut().unwrap();
stdin.write_all(messages.as_bytes())?;
}
let output = child.wait_with_output()?;
Would love feedback from folks who've shipped Tauri apps or Rust/Python hybrids. Where do you draw the line between keep it in Rust and delegate to Python?
