Hey all, I've been building Nevi for about a year and wanted to share it.

Some background. I love Neovim and used it every day, but my config grew to around 70 plugins, and on big projects it started to hurt. Startup got slow, grep would sometimes freeze, and opening a really large file could lock things up for several seconds. On my setup a 183 MB log took 7 to 10 seconds to show anything. That's my plugins, not Neovim itself, but I didn't want to keep tuning a config to fix it. So I started building the editor I wanted: vim keys, with LSP, tree-sitter, a fuzzy finder and live grep built into the binary, so there's nothing to set up.

The video shows what I mean:

• Starts in the rust-lang/rust repo in under 10ms

• Opens a 183 MB log with 2 million lines in about 0.2s, and G jumps to the last line in about 0.04s

• Live grep across about 18k files, then a normal ci" edit

• A rust-analyzer hover in Nevi's own source (rust-analyzer was already indexed, so that part is the server's speed, not Nevi's)

How it's built, for the Rust folks:

• Buffers are ropes (ropey), and rendering only touches the rows on screen. That's most of why a 2M-line file opens and jumps instantly. Tree-sitter highlighting backs off on very large files instead of trying to parse everything.

• Live grep uses ripgrep's own crates (grep-searcher, grep-regex, ignore), and the fuzzy finder uses nucleo, the matcher from Helix. No external rg or fzf needed.

• The terminal UI is plain crossterm. The floating terminal is portable-pty plus alacritty_terminal, and git signs come from git2.

• All the vim behavior lives in one input state machine, and the parity tests run the same keystrokes through a headless nvim and compare the results.

Where it's at right now:

• 372 keybinds, and 206 of them are checked against real Neovim on every CI run. If Nevi does something different from nvim, the test fails.

• LSP for 14 languages, auto-detected on your PATH, with an install hint if a server is missing.

• File explorer, floating terminal, lazygit, Copilot ghost text and 17 themes.

• macOS and Linux. Windows isn't supported yet.

brew install anthonyamaro15/nevi/nevi
# or
cargo install --git https://github.com/anthonyamaro15/nevi

Repo: https://github.com/anthonyamaro15/nevi

It's still early, so I'd really like to know which vim keys you use that are missing or don't behave right. Open an issue or just tell me here.

[HyperStream] — High-performance 128-thread parallel download accelerator and BitTorrent client for Android, powered by a native Rust core.

* GitHub Repo: https://github.com/djsusmith/hyperstream-android

* Live Showcase & APK: https://djsusmith.github.io/hyperstream-android/

* License: GPL-3.0 (100% Free & Open Source, 0 ads, 0 telemetry)

Tech Stack

* Core Engine: Written in Rust using `tokio`, custom work-stealing segment halving down to 12 KB chunks, and `librqbit` for embedded BitTorrent swarm handling.

* Frontend: Kotlin & Jetpack Compose (Modern Obsidian dark theme, reactive telemetry, Material 3).

* Bridge: Zero-copy JNI / C FFI Native Bridge (`libmdm_android.so`).

Key Features

⚡ Up to 128 Parallel Connections:* Real-time socket shedding and dynamic connection pooling that easily saturates high-speed 5G and Wi-Fi 7 connections.

🧲 Native BitTorrent Swarm:* Magnet links, torrent files, sequential downloading (stream while downloading), DHT, and PEX without any third-party daemon.

🎬 Built-in Media Grabber:* Direct 4K YouTube stream extraction and watermark-free video sniffer with multi-stream audio/video muxing.

🔋 Android Background Resiliency:* Foreground service with partial WakeLock and High-Performance Wi-Fi Lock to prevent system Doze throttling.

📂 Safe File Management:* Integrated Android `FileProvider` with 1-tap open and double-confirmation deletion protection.

Context & Why I Built This

Most existing Android download managers are either abandoned or filled with intrusive full-screen ads, tracking SDKs, and paywalled thread limits. I wanted a clean, blazing-fast, genuinely open-source alternative that runs natively on ARM64 without GC pause jitter.

The project is actively maintained (currently on v0.6.0). I’d love to hear your thoughts, feedback, bug reports, or feature requests! PRs and stars are always welcome.

Say you're moving a service away from a legacy adapter, but one import needs to stay for another PR. Excluding the entire service from architecture checks is a pretty big hole for a small exception.

ArchUnitRust, my open-source architecture-testing crate, can scope the exception to one member of a grouped import:

use crate::adapters::{legacy, current}; // archunit: ignore crate::adapters::legacy

Here the legacy import is omitted from the dependency graph. current is still checked. Remove the comment and the legacy dependency is checked again.

There's a useful catch: this doesn't suppress a separate qualified reference later in the file. Add legacy::call() in a function and that path still creates a dependency. The ignored import still establishes the alias needed to resolve it.

Small exception, small scope

So this is a declaration-level escape hatch, not permission to use that adapter anywhere in the file. It's also syntax analysis, not macro expansion or an inventory of everything a particular build executes.

This behavior ships in the archunit 0.0.2 preview on crates.io. MIT licensed: https://github.com/dragonsec-ai/ArchUnitRust

This is cudash; because using Vulkan compute is hard for a lot of people (me) so I started a project to help transition from a Cuda driver like experience like cudarc but built on ash that allows you to:

• run SPIR-V kernels with Vulkan

• run PTX kernels with Cuda

• helps you interoperate in between those

• allows you to caputure them into combined graphs

I hope this helps more people use GPGPU computation on any hardware and with more technologies combined.

Feel free to try it out and/or mark it to stay tuned!

After the Black Forest we released The Scribe, a text editor, also 100% rust. The more we use rust the less we see limits. The next project will be far more complex and push the limits though. Hope you’ll enjoy.

More screenshots are here

check : https://github.com/akrram0/atlas-terminal

i'm working on my project called RUSTLAB, its a terminal app, that teaches you how to program in rust from the basics to advanced (or at least my level lol) its not that revolutionary, but i think it has charm, and i'm trying my best to teach people on how to actually learn rust! Its currently only in português brasil and english, and yeah its open source! Although i admit, it's my first github project, so have a grain of salt, currently the repo is in portuguese, afterall that's my language, just a disclaimer, I DONT CONSIDER MYSELF A PROFESSIONAL so the code might be kinda meh, but i think i'm a pretty good teacher, but thats what you are gonna tell me, after you test my project, hopefully. https://github.com/Honraan/RUSTLAB also the app has a pretty fun mini-ide inside, with support for an ai agent powered by local ollama (or your api lol). currently it only works on Linux.

(ai was used to fix bugs and help translate it to english.)

I built Shaft because I was tired of keeping a terminal tab open for every ngrok tunnel. It lives in the macOS menu bar: type a port, press Enter, and the public URL is on your clipboard. It also has a request inspector with replay.

Why it might be interesting from a Rust angle

• Native UI without Electron or a web view: plain AppKit from Rust through objc2 / objc2-app-kit. Delegates and action targets are defined with define_class!, and Rust closures are wired to buttons through a small target object.

• No ngrok binary: tunnels run in-process with the official ngrok-rust SDK.

• Inspector: a tokio proxy captures exchanges into a bounded store, decodes gzip/brotli, and can replay or edit-and-replay requests and export HAR.

• Workspace split: shaft-core (tunnels), shaft-inspector, shaft-api (ngrok API), shaft-config (Keychain-backed secrets) and shaft-app (UI).

Fiddly bits: AppKit holds targets weakly, so they need explicit ownership. Events from tokio have to be hopped onto the main thread. And switching between menu-bar-only and a regular Dock app depending on whether a window is open took more activation-policy juggling than expected.

Universal binary, signed and notarized, MIT/Apache-2.0. Built with a lot of AI assistance; I’d love feedback on whether the objc2 patterns are idiomatic.

Repo: https://github.com/nnevskij/shaft

A Rust parent declares a child module, and the child uses a type exposed by its parent. If you put every relationship into one cycle graph, module organization can get mixed up with the import policy you actually wanted to check.

I maintain ArchUnitRust. You can choose which dependency kinds belong in a cycle rule:

use archunit::{ImportKind, assert_passes, project_files};

#[test]
fn implementation_imports_stay_cycle_free() {
    let rule = project_files()
        .in_path("src/parent**")
        .should()
        .have_no_cycles()
        .excluding_dependency_kinds([
            ImportKind::Mod,
            ImportKind::PubUse,
        ]);
    assert_passes!(rule);
}

Use a selector matching your actual module. In my fixture, excluding those structural kinds removed the parent/child-only cycle. Adding an ordinary import in the other direction still produced a cycle violation.

That last part matters: this doesn't simply delete every edge between those files. Retained import evidence can keep the edge in the check.

It runs as an ordinary Cargo test. The extraction is syntax-based; this is an import policy, not proof about runtime call cycles.

Source: https://github.com/dragonsec-ai/ArchUnitRust

As a producer I hate that Suno exists. But people will use AI for music either way, so I’d rather give them a real tool than a black box.

I made full FL Studio-style DAW but It also has a wave CLI that talks to the running app. Any agent that can run commands to do anything.

This beat was made by agent to show the point. I still make music myself. I mostly ask things like “what’s wrong with my mix?” or “my vocal is mono, fix it”.

The Rust part:

• Audio callback: zero allocations, no locks, no I/O (a benchmark counts allocations on the audio thread).

• 16 synth voices with 7-voice unison plus all effects use ~17% of one core at 48 kHz / 64 samples.

• The engine owns the project and the undo history. The Tauri UI only sends ops.

• VST3 effects, WASAPI/ASIO on Windows, ALSA/JACK on Linux.

AGPL-3.0: https://github.com/miskibin/wave-DAW

I've been working on Aralez, an open-source reverse proxy and load balancer written in Rust, built on top of Cloudflare's Pingora.

The project started as an attempt to build a performant, flexible proxy that could handle more than basic HTTP load balancing. Over time, it has grown into a fairly feature-rich system.

Some of the new features implemented in the latest v0.95.5 release

• Response Caching: With Memory, Hybrid, RESP (Redis family), TiKV storages

• Cluster Mode: Master/worker deployment model.

• Structured logging: Plug-able modules, currently Elasticsearch.

• Acme DNS-01 Challenge: Plugable currently Cloudflare, Route 53, DigitalOcean

• The full list of features are here

I'm particularly interested in feedback from people with experience in Rust networking, asynchronous systems, proxies and high-performance services.

Also would be very thankful for code contribution, especially with Acme DNS-01 providers.

Examples are at the bottom this page.

GitHub: https://github.com/sadoyan/aralez
Documentation: https://aralez.rs/

Hi guys,

I've been working on RWS (Rust WebServer), an experimental, high-performance web server written in Rust.

In one of my benchmarks, RWS handled around 39% more requests per second than Nginx on the same hardware.

It currently supports HTTP/1.1, HTTPS, virtual hosts, PHP-FPM, WebSockets, reverse proxying, and an in-memory static file cache.

It's still an early-stage project, and there's plenty of room for improvement.

I'd love to hear your thoughts, suggestions, or criticism, especially regarding performance, security, and architecture.

GitHub: https://github.com/Cyber-Space-nl/RWS

One of my favorite features on Mac is how seamlessly your Apple Watch unlocks your screen when you sit down at your desk. I really wanted that exact same hands-free experience on Windows 10 and 11, so I built WristKey.

It is a free and 100% open-source desktop app built in Rust and Tauri v2.

What it does

• Hands-free unlock: Sit down at your desk with your watch on, and your PC wakes up and logs in automatically.

• Walk-away lock: Walk away from your desk, and Windows locks immediately based on Bluetooth signal distance.

• On-wrist verification: It parses Apple Continuity packets passively. If you take the watch off or put it on a charger, it immediately revokes access so your PC stays secure.

• Privacy and local security: No cloud, no telemetry, no tracking. Your Windows credentials are encrypted on your local machine using native Windows DPAPI (CryptProtectData).

• Battery friendly: Uses passive Bluetooth Low Energy (BLE) advertisements, so it does not drain your watch battery.

Why I need your help

This started as a personal project, but reverse-engineering Apple Continuity across different devices is getting too big for just one person:

1. I only have one test device: An Apple Watch SE running watchOS 10. I really need testers with watchOS 11, Series 8/9/10, or Apple Watch Ultra to see if detection and distance estimation work properly on newer firmware.

2. Bluetooth hardware: Different Bluetooth chipsets (Intel, Realtek, Qualcomm) handle signal smoothing and address rotation differently.

3. Contributors welcome: If you know Rust, Win32 APIs, Windows Credential Providers, or Tauri, any PRs, code reviews, or issue reports are hugely appreciated!

How to try it

• Download the installer (v0.5.0): GitHub Releases

• GitHub Repository: https://github.com/jorjanion/WristKey

(Quick note on Windows SmartScreen: Because this is a free open-source tool without a paid enterprise certificate, Windows Defender might show a blue prompt on first launch. Click "More info" and then "Run anyway". The entire source code is public and inspectable on GitHub).

If you test it out and run into any bugs, please drop an issue on GitHub with your watch model, watchOS version, and the log file located at %LOCALAPPDATA%\WristKey\wristkey.log.

Thank you to anyone willing to test, star the repo, or contribute!

Quilla es un gestor de paquetes experimental escrito en Rust. Combina una instalación sencilla de paquetes con un store inmutable y perfiles basados en generaciones. El proyecto está en desarrollo y, por ahora, se ha probado con los repositorios de Arch Linux en x86_64.

Quilla is an experimental package manager written in Rust. It combines straightforward package installation (Pacman) with an immutable store and generation-based profiles (Nix). The project is under development and has so far been tested with the Arch Linux repositories on x86_64.

Se acepta cualquier Pull Request y cualquier Feedback del proyecto, estoy abierto a escuchar

Any pull requests or feedback for the project are welcome; I am open to hearing them.

https://github.com/nasadmidev/quilla/

In research communities, we often need to extract data from published plots, particularly detector bounds in our area (HEP). So I made an utility to do this properly without having to eyeball it using messy online tools. For vector images it actually extracts the nodes and for raster ones it uses cheap classifiers and transformations to automatically detect plots. It's visual and intuitive, Try it out. Feature requests are welcome. 😄

https://github.com/rajatmo/plotextract

I wanted to always see my wireless headset, mouse, and controller battery right on the taskbar without keeping heavy vendor apps running all day, so I wrote BatteryDock in Rust.

GitHub & Downloads (MIT, free & open source): https://github.com/jorjanion/BatteryDock

What it does

• Lives directly on your Windows 10/11 taskbar: Sits cleanly next to the system tray clock (or far right, left, or anywhere you drag it).

• Smart fullscreen hiding: Automatically disappears during fullscreen games/videos or when an auto-hide taskbar collapses — and stays put when pressing the Win key, opening Start/Search, or clicking the desktop.

• Direct hardware reading (no telemetry, no Electron):

  • Logitech Wireless: Direct HID++ 2.0 + G HUB IPC fallback (headsets, Lightspeed mice, keyboards)

  • Bluetooth & BLE: Windows WinRT + BLE GATT Battery Service (headphones, BT mice/keyboards)

  • Xbox Controllers: XInput (including wired charging state)

  • PlayStation: Sony HID via USB & Bluetooth (DualSense & DualShock 4)

• Live charging state & alerts: Shows a cyan ⚡ badge while charging, plus customizable low/critical thresholds with gentle chimes and Windows notifications (alerts keep working in the background even when the pill hides in fullscreen games).

• Lightweight: ~4 MB native binary (~4.4 MB installer, also available as a portable zip), ~77 MB private memory live on Windows 11.

Note on Windows SmartScreen

Since this is a free side project without a paid EV code-signing certificate yet, Windows SmartScreen will show "Windows protected your PC" on first launch (More info → Run anyway). All release binaries are built cleanly via GitHub Actions (.github/workflows/release.yml), and you can build from source with cargo build --release in under a minute.

If your brand/device isn't supported yet (Razer, Corsair, SteelSeries, Keychron, etc.), feel free to drop the model/VID:PID or open a device request on GitHub!

Waftty aims for a balance of low RAM, high throughput, low latency, low CPU. Maybe not the very best at one, but very good across all - with no reliance on GPU acceleration.

There's also a few new features that feel simple but missing from other terminals. Like "cd recent" - quickly change to other directories you've recently been to. My flow is very open pop open a terminal, and head to one of 5 projects I'm actively working on (or head to Downloads to install a recent download).

I also added private windows/tabs. Ever head to do something dangerous/experimental and not want to pollute your shell history?

Waftty also sports a command palette, "--quick" mode (for a quake style terminal), ligature support, and more.

The stack is Gossamer (mostly Rust), 3 GUI libraries (the core windowing library and gui engine are Rust), and then Gossamer for the API level GUI library + waftty itself. I built Gossamer in Rust to write Rust like code with structured colorless concurrency and no borrow checker - but still have excellent performance and resource usage. Waftty is an example of all of this coming to fruition.

I use AI (Claude and my own harness) to assist and accelerate, but am very much still in the guts myself.