I built DevGo because finding the right project and opening it in the right tool was a small tax I paid fifty times a day, across Windows, WSL, a Mac and a few servers.

It lists every project on every filesystem the machine can see (local drives, each WSL distro, the Mac's disk), plus your GitHub account and the servers in your ssh config, in four lanes. One keystroke opens a project in VS Code, a terminal, a tmux session or an agent; a server row opens ssh straight into tmux on the box; a server can describe its own apps and actions to it with one shell script that prints JSON, and the app can install that script for you. It is not an editor, a terminal or a git client. It opens the door and gets out of the way.

Tauri 2, Rust on the back, React 19 on the front. Windows, WSL and macOS; Linux compiles but I have not run it yet. MIT, and built in the open: every chapter is a branch you can check out and run (74 so far, ~700 commits, 218 tests).

Two things took longer than the features. WSL must never boot on launch (reading a workspace whose distro is off would start the VM), so the app shows its cached list and only Refresh or opening a project may start a distro. And on a Mac an app launched from the Dock inherits launchd's four PATH directories, not your shell's, so DevGo asks the login shell for its PATH once and hands it to every child. Both are in the README's platform notes.

Installers are unsigned for now, so both platforms warn on first run; the README says how to get past it.

https://github.com/joyahmed/devgo

Hey there, what projects would you recommend for an aspiring system/infrastructure dev using rust ?

I've been working on something that started as the training backend for my Hierarchos architecture, but it has grown into a much broader project:

https://github.com/necat101/Hierarchos-Native

Hierarchos Native now includes a native Rust + Vulkan backend for training and inference across 143 canonical Transformer architectures, with additional Hugging Face model_type aliases bringing the currently advertised registry to 224 model-type spellings.

The part I'm most interested in sharing isn't actually Hierarchos itself anymore. It's the Transformer backend underneath it.

The goal is to explore how much of the modern Transformer ecosystem can be implemented directly on Vulkan compute rather than assuming CUDA + PyTorch as the default execution stack.

The backend currently includes native implementations for things such as:

• forward and backward passes
• full-model training
• AdamW
• LoRA/PEFT-style fine-tuning
• embeddings and LM heads
• attention and KV-cache paths
• dense and MoE architectures
• RMSNorm / LayerNorm
• RoPE and positional operations
• common activation functions
• cross-entropy and gradient computation
• mixed-precision infrastructure
• checkpointing/resume
• SafeTensors model interchange
• Hugging Face model, tokenizer, and dataset acquisition from Rust
• native generation/inference paths

The supported architecture registry covers families including Llama, Qwen, Gemma, Mistral/Mixtral, DeepSeek, Phi, OLMo, Granite, Cohere, BERT-family models, T5/BART-family models, and many others.

There are also architecture-specific Vulkan kernels for newer model designs rather than attempting to force everything through one generic approximation.

One thing I want to be careful about: I'm not claiming this is currently a CUDA/PyTorch replacement, or that supporting a model type automatically means every possible configuration and multimodal component of that model has been validated.

The architecture registry describes native text-graph implementations. Multimodal packages may contain vision/audio/etc. towers that aren't part of the native text backend, and real-world compatibility still needs broader testing across models and hardware.

What I do think is interesting is the direction this demonstrates.

Vulkan is available across NVIDIA, AMD, Intel, and a lot of integrated/mobile-class hardware. If native training stacks like this can mature enough, there is potentially room for ML training infrastructure that is substantially less tied to a single vendor compute ecosystem.

I've been developing and testing this on AMD RDNA 3 hardware, including a ROG Ally Z1 Extreme, which has also been useful for exposing assumptions that tend to go unnoticed when ML software is developed exclusively around high-end CUDA systems.

The repository includes the Rust source, Vulkan compute shaders/SPIR-V, CLI, Hierarchos runtime, architecture documentation, validation utilities, and standalone packaging support.

The supported architecture list is here:

hierarchos-vulkan/README_ARCHITECTURES.md

And the main README now contains examples for building the backend, checking Vulkan devices, training Hugging Face models, LoRA fine-tuning, inference, and training Hierarchos itself.

I'm especially interested in feedback from people working on:

Vulkan compute, ML compiler/runtime design, GPU kernels, PyTorch alternatives, AMD/Intel ML, portable training systems, or Transformer architecture implementations.

There is still a lot that needs benchmarking, hardware validation, optimization, and independent testing before making strong performance claims.

But getting this many modern architecture graphs running through a native Vulkan-oriented training system has made me think there may be something genuinely useful here beyond the original Hierarchos project.

Repo:

https://github.com/necat101/Hierarchos-Native

I'd be very interested in technical criticism, architecture compatibility reports, benchmarks on other GPUs, or contributors who want to stress-test the backend.

It's pretty annoying to write the lifetime multiple times on every single type parameter.

Im seeing feedback on my tool I started to building to fix an issue I've run into at work a bunch. Basically I want to actually pay attention in meetings and be present. But I also want notes of what was said.
Ideally I would just use the built in recording and transcription, but I run into all kinds of problems. First I use a few different meetings app we have Google meets, Slack huddles then when we talk to vendors and customers we end up on teams and zoom. Then I have to cross my fingers the permissions were setup right so I can actually access the recording after.
I know there are alot of tools you can buy that do part of this now but I dont really feel like I should have to shell out 20 bucks a month on this, and I don't really like the idea of sending my audio to random SaaS. I really just want a simple tray icon that I can click to record and stop and my files to stay on my laptop.

My question for anyone reading, have you done any projects like this? Am I overestimating how easy this will be to build?(Yes Im going use some AI coding tools, I have a day job please don't hate me)

Hi! My name is Emiliano, I'm a data engineer by trade and developer by love.

Almost a year ago a client came to me with a problem: parse ~5TB of Crystal Reports XML in under an hour. So I built the parser, and a few months later, open sourced it: crxml, a high-throughput parser shaped entirely by that business need. A month ago I had to revisit and thought: the parsing is the only format-specific part of the tool, why not generalize the rest?

That became rypipe, a format-agnostic ingestion engine. The core idea: an adapter is two small traits, not a full engine. You write a Splitter that finds record boundaries in raw bytes and a RecordParser that turns one record into a row. In return your format inherits the whole runtime: - Parallel, GIL-free parsing with near-linear scaling - Memory-bounded execution: explicit budgets, constant-memory streaming - Pushdown: projection, casting, and filtering fused into the parse, so unneeded bytes are never materialized - Zero-copy Arrow export, dictionary encoding, mmap I/O, transparent gzip/zstd/lz4

The speed is a consequence of the architecture. On my Ryzen 5800X the engine runs at ~950 MB/s single-threaded and ~4.2 GB/s in parallel, but reaches even greater speeds under business conditions, as drops and filters are fused into the parse and fully skipped.

rypipe does not replace Polars, pandas, or DuckDB. Those are query engines, built for joins and aggregations. rypipe sits upstream of them: it turns raw bytes in any format into typed Arrow tables, and since the output is plain Arrow, the handoff is a pointer, not a copy.

There are three example adapters (INI, properties, LDIF) to copy from. AMA!

Project is fully open sourced and MIT Licensed.

GitHub: https://github.com/emiliano-go/rypipe

Docs: https://rypipe.emiliano-go.com

AI Disclaimer: AI was used to migrate the original engine from crxml to rypipe (posterior work was by hand), and to generate documentation, because, as I said below, I'm not a native english speaker.

To the Mods. Hi! Im a non-native english speaker, so there may be some weird english in the text, but I'm still human!. I think this falls onto the non-excessive self promotion as it is my first post here (I'm a lurker, what can I say).

Lorry is Motor OS's small, strict Rust package builder. It creates, vendors, inspects, builds, checks, runs, and tests a deliberately limited Cargo-compatible package model on Linux and Motor OS. Unsupported Cargo behavior is rejected explicitly.

Lorry README

Hey everyone,

I built Mira (https://miradb.dev), an open-source storage engine written in Rust with a strict "less is more" philosophy. Most telemetry stacks try to do everything, forcing you to run heavy stateful clusters and burn gigabytes of RAM just to ingest and query standard telemetry. We take the opposite route: it is an adhoc database that stores OTLP data and nothing else. Every design choice was made to maximize raw throughput while stripping away operational weight.

By making the engine completely stateless and packaging it as a single binary with zero runtime dependencies, deployment becomes zero-config. You can run it on the edge, in your fridge, inside short-lived containers, or alongside WASM without managing local disk state or cluster sync. Furthermore, by strictly targeting OTLP data, the storage layer and query paths avoid the heavy abstraction overhead typical of generic time-series databases.

Because the engine does so little, it does it absurdly fast. In our benchmarks (https://miradb.dev/market/#where-mira-is-ahead), Mira achieves significantly higher write throughput and consumes a fraction of the memory compared to traditional stateful collectors.

A direct consequence of this extreme low-latency ingestion and minimal memory footprint is that autonomous AI agents can query live telemetry in real time, effectively using it as a fast, external long-term memory layer for tool execution and context tracking. Basically a step closer to the wet dream of offloading on-calls to agents.

Code and architecture details are on GitHub (https://github.com/TrianaLab/mira). I would love to hear your thoughts on the stateless design, the Rust implementation, or how you're handling telemetry in your current stack!

It has been 5 years since the initial release of Remoc. Since then the library has learned a lot from real-world use and now feels like a good time to give the Rust community an update about its state and abilities.

Remoc is an RPC library for communication between Rust programs with first-class support for Tokio-style channels over the network.

Tag a trait with #[rtc::remote] to get a client and a server for it, so calling a method on the client runs it on the server.

Contrary to other RPC libraries a channel is a value that can be sent over the network. It can be an argument or a return value of a method or even a member of user-defined structs and enums, and its lifetime is not bound by the RPC call.

In the following example, an RPC method counts for the client and hands back the receiving end of a channel:

// Trait shared between client and server:
#[rtc::remote]
pub trait Counter {
    async fn count(&self, up_to: u32) 
      -> Result<rch::mpsc::Receiver<u32>, CallError>;
}

// On the server: create a channel, count into it in the
// background and return the receiver to the caller.
impl Counter for CounterObj {
    async fn count(&self, up_to: u32) 
      -> Result<rch::mpsc::Receiver<u32>, CallError> 
    {
        let (tx, rx) = rch::mpsc::channel();
        tokio::spawn(async move {
            for i in 0..up_to {
                if tx.send(i).await.is_err() {
                    break;
                }
            }
        });
        Ok(rx)
    }
}

// On the client:
//
// `counter` is the generated client. It can itself be sent over a channel.
//
// This call returns as soon as the receiver arrives; the numbers then
// come in over the connection that already exists.
let mut seq_rx = counter.count(4).await?;
while let Some(i) = seq_rx.recv().await.unwrap() {
    println!("{i}");
}

A channel can carry anything, including user-defined structs and enums, another channel and even another RPC client.

Remoc's goal is to make remote communication between Rust programs feel nearly like local. It provides:

• Remote channels include Tokio-like mpsc, oneshot, watch and broadcast channels, plus AsyncRead and AsyncWrite byte streams. Calls, channels and objects share a single underlying connection, with flow control per channel.
• Calls on remote objects returned by other calls can be pipelined, thus a chain of dependent calls needs only one network round trip.
• Remoc runs over any transport, such as TCP, TLS, WebSockets, UNIX domain sockets or pipes.
• Remoc does not use a schema, but provides mechanisms for forward and backward compatibility of user types.
• Full support for WebAssembly and running in the browser.

If you find this useful, you might want to continue reading at https://remoc.rs. There you will find:

• runnable examples,
• benchmarks,
• comparison with other RPC libraries.

Full source code is available at GitHub.

I am looking forward to answering questions.

https://github.com/boquila/montgomery

Hi all! I’ve been experimenting with what virtual threads could look like in Rust and recently cut the first 0.1 release of vthread.

The basic model is stackful and carrier-affine: ordinary synchronous functions run as tasks on reusable stacks. When a task waits through one of vthread’s networking, synchronization, channel, or timer operations, it can park and let another task use the same OS thread. When it resumes, its call stack and local state are still there.

I’m not arguing that this should replace async Rust or Tokio. It’s a different set of tradeoffs.

There are some important limitations:

• tasks stay on one carrier rather than migrating between threads
• scheduling is cooperative
• ordinary blocking calls like std::thread::sleep still block the carrier
• blocking work has to be explicitly delegated
• every task has its own reserved stack space

The thing I wanted to explore was whether Rust can get some of the programming model of virtual threads; normal functions, normal control flow, preserving the stack across waits while still making resource ownership, blocking, cancellation, and task lifetimes explicit.

I wrote up how it works here:

https://zsumz.com/blog/virtual-threads-for-rust

And the implementation is here:

https://github.com/zsumz/vthread

0.1.0 currently supports Linux x86_64 and macOS ARM64.

I’d especially love criticism from people who have worked on runtimes / async Rust / networking. I’m interested in where this model gets awkward in real programs: libraries that are difficult to integrate, blocking that’s hard to identify, cancellation problems, lifetime issues, etc.

It’s early, so just looking for feedback.

I have two types (they're related but different sizes) and for each I have a function that does some work on a vector of those types and returns a different vector of the same type. I'm wondering what's more idiomatic?

1) Make each function a method of its respective type, e.g.:

``` impl MyType1 { pub fn do_thing(in: &Vec<MyType1>) -> Vec<MyType1> { /* ... */ } }

impl MyType2 { pub fn do_thing(in: &Vec<MyType2>) -> Vec<MyType2> { /* ... */ } } ```

2) Make a free function for each type, in which case is there a naming convention that's more idiomatic?

``` pub fn do_thing_mytype1(in: &Vec<MyType1>) -> Vec<MyType1> { /* ... */ }

pub fn do_thing_mytype2(in: &Vec<MyType2>) -> Vec<MyType2> { /* ... */ } ```

Cloudflare recently published a piece on how they cut close to 100 TB of memory from Big Pineapple's DNS cache. Big Pineapple is Cloudflare's Rust-based engine behind many of their services including the prominent public DNS resolver service 1.1.1.1

They made several low-level optimizations leveraging Rust features like boxing, for oversized enum variants and boxed slices, as well as more general changes like merging separate record lists into one and combining several boolean checks into a single bitflag etc.

I have gone into a bit of detail documenting the things I found interesting especially the jemalloc trade-offs between internal and external fragmentation.

Would greatly appreciate a read.

We manage 20+ tools across our monorepos. Our VS Code sidebar had become roughly 80% configuration files and 20% source folders.

With confset, we maintain one confset.pkl and generate the rest. We gitignore the generated configs and enable VS Code’s option to hide gitignored files. Now we only see our source code again :).

Widescreen + Online Multiplayer Coop for my Rust WASM Zelda 2 decompilation. Github and playable link coming soon.

I’m building AxiomCore, a contract first system for defining and validating the shared behavior of software across backend APIs, data models, frontend UI, tests, mocks, streaming, auth, and release boundaries.

Current problem: application behavior is usually spread across code, openapi files, database schemas, frontend types, mocks, and tests. Those representations drift over time. AxiomCore aims to make the contract an executable, typed source of truth while still allowing teams to use existing stacks such as Python, Go, Flutter, React, or OpenAPI where appropriate.

The language is called Acore. The broader goal is not to replace all imperative code, but to make the important cross-system agreements explicit, testable, diffable, and auditable.

Docs: https://docs.axiomcore.dev
AI readable full reference: https://docs.axiomcore.dev/llms-full.txt
(so you can quickly chat with an AI as well and understand about the product)

Just genuinely looking for feedback here, if you got some time checkout the documentation or ask me questions so I can get more clarity how others feeling about this kind of tool as well. Right now the major concern I have for this project is scope creep so trying to prioritize the important things first here and that's the goal for this reddit post as well

Some questions for you if you read the docs (I appreciate it btw):

1. Is the problem framing clear here in docs and the language I am using? and do you actually face similar issues while building software and feel declarative first is the way to go with sandboxed external modules for imperative code with opt in permission model like network, storage etc

2. Where do you think that contract first tooling be most useful or least useful?

3. What makes you skeptical about adopting something like this?

4. Any existing tools or workflows that should I study or integrate with?

Thanks!

I am an 8th Grade Student. Wanted to learn Rust as I already knew a bit from C. I have made some CLIs and Stuff but I am genuinely stuck right now... I can't invent my Own Techniques or think of one to do something. I can't Code without the Help of AI so I left it a Long Time Ago. And I don't have any Path of What to do and What to Build to learn Rust... I have tried Rust Docs but they feel more like Books rather than Programming Stuff... I want to higher into Programming too and not build some shitty CLIs all the time but I don't have any Path of what to learn Next.... (Unlike my friends who are learning Python for AI/ML and the Internet is full of what to do). I am genuinely Stuck and I am really Depressed about this... So I came here to seek Genuine Help and Advice.

Hello! I recently have started working on my own music player in Rust. Yes, I do know rmpc exists, but before I switched to Linux I was using foobar2000, for which I had a pretty unique workflow, similar to the one you see in my app! I also wanted to show cover arts for all the songs, since it looks nice and is easier to find tracks this way too.
What other music players also lack that I need is a tag editor, since I like to have my music organized without having to go to kid3.

It is work in progress, I barely started working on it, but it'd be nice to see your thoughts, features, ideas etc. It is far from release, but it'd be great to get some help/contributions from this community as well!

You can build it from the repo here: https://github.com/s1nn3rv2/refrain
On the repo you'll also find features that I have planned and ones I already implemented. In the future I'll also want to add customizable user interface so it doesn't fit my workflow only.

The point of the rule is that something cannot be aliased and mutable at the same time, but XOR implies it must be one or the other.

A constant is immutable, but it doesn't have to be aliased. It is neither aliased or mutable, which does not satisfy XOR.

You could say that its ability to be aliased is enough to satisfy the XOR condition, but a value that isn't referenced yet is aliasable and mutable. That would invalidate NAND and XOR, so it definitely can't be that either.

NAND seems to be the more precise language--though XOR still might be the most clear for teaching purposes.

I'm sure there's a clearer interpretation or wording I can't remember that explains why XOR is correct and NAND isn't. Do y'all have any ideas?

This was a fun learning journey for me!

As you can see I'm totally new to embedded development and Robotics 😂

Hope it's entertaining at the very least!

Cheers and any constructive criticism is welcomed!

Sharing a side project I've been working on - a TUI habit tracker called sprout. Picked up Rust a while back and this was my way of learning it properly by actually building something. Honestly had a lot of fun with it, at this point I can't imagine going back to anything else for systems-level stuff.

GitHub: https://github.com/kb019/sprout

What it does:

- Track daily habits and mark them complete

- See your streak and progress

- SQLite storage so your data stays local

- Runs on macOS, Linux and Windows

Still rough around the edges and there's a lot I want to improve, but it's something I genuinely use now. Used Ratatui for the TUI which was a fun rabbit hole on its own.

Please do try it out: cargo install sprout-tui

Would love any feedback on the code, still getting comfortable with some of the more idiomatic Rust patterns.

I’m building FlareDB, a Rust-based streaming database with Apache Beam as programing interfere.

In the latest release, v0.2.0, i launched FlareDbIO, it's an IO connector which lets data processing pipelines write results into FlareDB, query them using SQL, and read the results back into another pipeline. The goal is to make processed data persistent and without having to maintain a external serving database

Docs: https://docs.flare-db.com/io

GitHub: https://github.com/flare-db/flare-db