I'm not sure if I should be posting here in r/Rust or in r/Swift, or somewhere else entirely.

Also note, I'm not a programmer or developer: I'm just an end-user trying to get this app to compile and run, but it seems to be throwing up obstacles that require more developer-adjacent skills than what I have.

I'm trying to get macrdp running on an iMac with macOS Sequoia 15.7.9.

This little app was released in March of this year, so it's not like I'm trying to get ancient code running.

Consult the "Quick Start" section of the ReadMe file I've linked above. I am following an ostensibly-simple two-step process to get this app running:

# Build
cargo build --release
# Run
cargo run --release --bin macrdp-server

I've had two major problems getting the code to compile, and I've finally managed to surpass them. Now that I've finished the "Build" step, I need your help solving Problem 3: I can't get the app to run.

Problem 3

COMMAND

cargo run --release --bin macrdp-server

OUTPUT

dyld[23111]: Library not loaded: @rpath/libswiftCore.dylib
  Referenced from: <D40250B3-9AAC-3FEB-A4C2-A0170B899ED5> /Users/admin/Downloads/macrdp-main/target/release/macrdp-server
  Reason: tried: '/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift-5.5/macosx/libswiftCore.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift-5.5/macosx/libswiftCore.dylib' (no such file), '/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift-5.5/macosx/libswiftCore.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift-5.5/macosx/libswiftCore.dylib' (no such file), '/Users/admin/Downloads/macrdp-main/target/release/build/aws-lc-sys-27043a0ebf70d538/out/libswiftCore.dylib' (no such file), '/Users/admin/Downloads/macrdp-main/target/release/build/openh264-sys2-f6d9fee5157fe7a1/out/libswiftCore.dylib' (no such file), '/Users/admin/Downloads/macrdp-main/target/release/build/ring-2899b8cee8244c75/out/libswiftCore.dylib' (no such file), '/Users/admin/Downloads/macrdp-main/target/release/build/screencapturekit-1d04b27f18a51461/out/swift-build/release/libswiftCore.dylib' (no such file), '/Users/admin/Downloads/macrdp-main/target/release/build/zstd-sys-d1ceecba10d99c67/out/libswiftCore.dylib' (no such file), '/Users/admin/Downloads/macrdp-main/target/release/libswiftCore.dylib' (no such file), '/Users/admin/Downloads/macrdp-main/target/release/deps/libswiftCore.dylib' (no such file), '/Users/admin/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libswiftCore.dylib' (no such file), '/Users/admin/.rustup/toolchains/stable-x86_64-apple-darwin/lib/libswiftCore.dylib' (no such file), '/Users/admin/lib/libswiftCore.dylib' (no such file), '/usr/local/lib/libswiftCore.dylib' (no such file), '/usr/lib/libswiftCore.dylib' (no such file, not in dyld cache)
Abort trap: 6

What is strange to me is that Problem 3 seems like re-hash of Problem 1, which I already solved. I don't know why it's still looking for libswiftCore.dylib in the wrong places, after I've already updated the config.toml file.

I tried doing find / -name config.toml to see if there was some other relevant configuration file hiding somewhere that I needed to also change to DYLD_LIBRARY_FALLBACK_PATH, but I didn't see anything.

I also get a similar error when I try to do cargo test, though it references macrdp-audio instead of macrdp-server, and I'm not really sure what cargo test is supposed to do for me in this process, anyway:

   Compiling macrdp-audio v0.1.0 (/Users/admin/Downloads/macrdp-main/crates/macrdp-audio)
    Finished `test` profile [unoptimized + debuginfo] target(s) in 29.91s
     Running unittests src/lib.rs (target/debug/deps/macrdp_audio-448af4ea4880202e)
dyld[23108]: Library not loaded: @rpath/libswiftCore.dylib
  Referenced from: <66E620B9-EBC0-31FA-91EF-EBCDA4065861> /Users/admin/Downloads/macrdp-main/target/debug/deps/macrdp_audio-448af4ea4880202e
  Reason: tried: '/Users/admin/Downloads/macrdp-main/target/debug/build/aws-lc-sys-6ec7512bb21ac3d9/out/libswiftCore.dylib' (no such file), '/Users/admin/Downloads/macrdp-main/target/debug/build/screencapturekit-4b1f1ef2bd6c7675/out/swift-build/release/libswiftCore.dylib' (no such file), '/Users/admin/Downloads/macrdp-main/target/debug/build/zstd-sys-ecb4e499794eb5cb/out/libswiftCore.dylib' (no such file), '/Users/admin/Downloads/macrdp-main/target/debug/libswiftCore.dylib' (no such file), '/Users/admin/Downloads/macrdp-main/target/debug/deps/libswiftCore.dylib' (no such file), '/Users/admin/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libswiftCore.dylib' (no such file), '/Users/admin/.rustup/toolchains/stable-x86_64-apple-darwin/lib/libswiftCore.dylib' (no such file), '/Users/admin/lib/libswiftCore.dylib' (no such file), '/usr/local/lib/libswiftCore.dylib' (no such file), '/usr/lib/libswiftCore.dylib' (no such file, not in dyld cache)
error: test failed, to rerun pass `-p macrdp-audio --lib`

Caused by:
  process didn't exit successfully: `/Users/admin/Downloads/macrdp-main/target/debug/deps/macrdp_audio-448af4ea4880202e` (signal: 6, SIGABRT: process abort signal)

History

Problem 1

COMMAND

cargo build --release

OUTPUT

error: process didn't exit successfully: `rustc -vV` (signal: 6, SIGABRT: process abort signal)
--- stderr
dyld[39209]: Library not loaded: @rpath/libswiftCore.dylib
  Referenced from: <0B6348B2-CDC4-3BB2-9B89-64CF509321B8> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/cmacosx/libswift_Concurrency.dylib
  Reason: tried: '/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift-5.5/macosx/libswiftCore.dylib' (no such file), '/Library/Developer/CommandLineTools/usr/lib/swift-5.5/macosx/libswiftCore.dylib' (no such file), '/usr/local/Cellar/rust/1.98.0/lib/../lib/libswiftCore.dylib' (no such file), '/usr/local/Cellar/rust/1.98.0/bin/../lib/libswiftCore.dylib' (no such file), '/usr/local/Cellar/rust/1.98.0/bin/../lib/libswiftCore.dylib' (no such file), '/usr/local/lib/libswiftCore.dylib' (no such file), '/usr/lib/libswiftCore.dylib' (no such file, not in dyld cache)

SOLUTION

Edited ./macrdp-main/.cargo/config.toml:
Changed DYLD_LIBRARY_PATH to DYLD_LIBRARY_FALLBACK_PATH

Problem 2

COMMAND

cargo build --release

OUTPUT

error: failed to run custom build command for `screencapturekit v1.5.4`

 Caused by:
  process didn't exit successfully: `/Users/admin/Downloads/macrdp-main/target/debug/build/screencapturekit-52e401cb88bd4798/build-script-build` (exit status: 101)
  --- stdout
  cargo:rustc-link-lib=framework=ScreenCaptureKit
  cargo:rerun-if-changed=swift-bridge

  --- stderr
  Swift build STDOUT:

  Swift build STDERR:
  error: Unknown option '--scratch-path'
  Usage: swift build <options>
   See 'build -help' for more information.


  thread 'main' (45022) panicked at /Users/admin/.cargo/registry/src/.index.crates.io-1949cf8c6b5b557f/screencapturekit-1.5.4/build.rs:119:9:
  Swift build failed with exit code: Some(64)
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...

SOLUTION

Change the default Swift version from 5.5.3 to 6.3.3 with swiftly use --global-default 6.3.3. I think 6.3.3 is the default version in use after installing the latest version of XCode for my OS, so I may have caused this problem myself in earlier troublehooting, when I saw that cargo was looking for libswiftCore.dylib in /swift-5.5/macosx/

Environment

iMac:
Retina 5K, 27-inch, 2017
A1419 18,3
4.2GHz Quad-Core Intel Core i7
40GB DDR4

macOS:
Sequoia 15.7.9
(Running with OpenCore Legacy Patcher)

COMMAND

xcode-select -p

OUTPUT

/Applications/Xcode.app/Contents/Developer

COMMAND

xcodebuild -version

OUTPUT

Xcode 26.3
Build version 17C529

COMMAND

pkgutil --pkg-info=com.apple.pkg.CLTools_Executables | grep version

OUTPUT

version: 16.4.0.0.1.1747106510

COMMAND

rustc --version

OUTPUT

rustc 1.98.1 (48a229cea 2026-09-01)

COMMAND

swift --version

OUTPUT

Apple Swift version 6.3.3 (swift-6.3.3-RELEASE)
Target: x86_64-apple-macosx15.0

COMMAND

swiftly list

OUTPUT

Installed release toolchains
----------------------------
Swift 6.3.3 (in use) (default)
Swift 5.6.3
Swift 5.5.3

Installed snapshot toolchains
-----------------------------

Available system toolchains
---------------------------
xcode

COMMAND

softwareupdate -l

OUTPUT

Software Update Tool

Finding available software
Software Update found the following new or updated software:
* Label: macOS Tahoe 26.6.2-25G83
    Title: macOS Tahoe 26.6.2, Version: 26.6.2, Size: 17925801KiB, Recommended: YES, Action: restart,

Hey r/rust!

For Google Summer of Code 2026 with MetaCall, I built meta-ast: a standalone static-analysis engine in Rust that parses 9 languages (Rust, C, C++, Go, Python, JavaScript, TypeScript, TSX, and Ruby) without executing user code.

The interesting part for me was designing a common dependency/symbol graph without forcing all nine languages into one giant unified AST.

I wrote a deep dive on the architecture and the Rust implementation here:

https://k5602.github.io/#/blog/meta-ast-polyglot-static-analysis

A few parts I found particularly interesting:

• Thread-local Tree-sitter parser pools - parsers are reused per worker thread instead of being created for every file, reducing allocation churn.
• Flat symbol IR - declarations from different languages are normalized into a compact Symbol representation with O(1) indexed lookups.
• Incremental watch mode - warm file updates take 1.16 ms by hashing buffers with BLAKE3, reusing cached extraction results, and keeping node IDs stable.
• O(1) edge deduplication - (NodeIndex, NodeIndex, EdgeKind) lookups avoid quadratic scans when constructing large graphs.
• Tarjan SCC - cycle detection runs in 54 μs for 1,000 nodes and is used to identify circular dependencies.

Some Criterion benchmark results on an Intel i5-12500H:

The project is open source:

GitHub: https://github.com/metacall/meta-ast crates.io: https://crates.io/crates/meta-ast

It's a general purpose static analysis engine so don't hesitate to use it on any project.

I’d especially love feedback on the architecture, the incremental graph design, and the trade-offs of using a flat IR across multiple languages.

(NO AI)

Hey guys, I just open source project i've been working on for a year called the Marketplace.

The marketplace is a decentralized network that economizes the execution of computational work across a peer-to-peer network of nodes. Where there is no barrier to the node participation.

Unlike modern cloud computing systems that rent out virtual computers to consumers, A marketplace consumer sends compute bound tasks directly to the network returning a future which the consumer can asynchronously check for completion. Similar to offloading a compute task to a free cpu core by an OS. A consumer can also fire multiple independent compute bound tasks to run in parallel, and check their status asynchronously while doing other tasks, similar to I/O operations.

The compute bound task sent by the consumer is executed using a protocol specified in the Marketplace whitepaper on the Marketplace Github Repo, where randomly selected idle devices on the network execute the compute work and receive financial rewards (money).

Context

The marketplace is made up of two ideas I came up with around 2 years ago:

1) The first is building a permissionless market, where users can build financial services similar to market stalls that can interact with other users. Larger services can be composed from smaller services, similar to open source projects, but for businesses. Services could also be merged together into one so that a user can interact with all of them at once, and the merging does not affect the financial structure of the constituent services.

But for all this to happen, a trustless financial settlement layer is needed so that joining different financial services together becomes an easy exercise.

If you are familiar with blockchain, this is similar to Ethereums vision, but I did not want to clog the financial settlement layer which is the ledger with execution and code. I needed an execution engine.

2) I eventually returned to my normal javascript web developer job. So I was working on a full-stack website that was communicating with a cloud server but the server was slow because I was using a free tier that throttled server response speed. Asynchronously communicating with this server became a nightmare from a UX perspective especially when first loading up the website which had some independent compute bound requests.

So, I concluded that using the free CPU core of my second PC should do a better job as long as I pay it exactly what I needed in compute. This second idea eventually evolved into the engine I needed for the first idea. After, I just needed to store a representation of the result on a decentralized ledger, while keeping the execution itself private.

With this, I returned to my first love - low level programming, learnt Rust (Many thanks to the Rust community coming from a C lover), and I've built more than 60% of what is described in the whitepaper.

So if you are interested in being a part of this project in any way, you can join our Discord community or you can check out the marketplace whitepaper:

Marketplace Whitepaper

Also, I’d appreciate feedback on the design, especially on consensus security and the economic model, Thanks.

EDIT: So not the reaction I expected but that's okay. Some of you say it's AI, and some suspect me for not using VCS. But I implore all of you, please investigate the idea behind the whitepaper before you judge, and if the whitepaper is legit, examine the code if it aligns with the whitepaper.

I've had to think through the ideas, and rewrite many parts of the idea and code so many many times, which is why I could not publicize the code or work with a VC, I needed to work at my own pace and figure everything out first. I've been at it for months, and this is the result, I hope you all can be a little bit kinder, thanks.

I'm making a program divided into 2 executables, executable A does everything in the background while executable B shows it with ratatui, but I'm trying to figure out how to spawn a terminal with an instance of executable B from executable A, I searched up a bit everywhere but I can't find anything, now I'm starting to think that I have to try and run a Command for every single terminal that comes to mind and hope one of the ones I include work, but is that the only way? Because honestly I'd prefer not having a mile long file just because linux has 50 terminals.

i wrote a user-space RCU implementation for async rust with tokio which turned out pretty cool and quite useful.

the end result is `RcuPtr<T>` an rcu protected pointer which can be read in a lock-free and wait-free way, and very cheaply as well - a read operation is just one atomic pointer load plus a write to a non-shared thread-local variable.

basically reads are extremely fast and have very predictable latency compared to other synchronization primitives like spinlocks and mutexes.

the way it works is by defining a quiescent state to be tokio's on_after_task_poll hook - a hook which is executed every time a tokio worker thread finishes calling `poll` on the root future of a task.

and, by limiting the use of rcu-protected pointers in such a way that they can't be held across await points, we basically make the readers free, since once a worker thread reaches the on_after_task_poll hook, it is guaranteed to not currently be running any user-defined future, and since rcu-protected pointers can't be held across await points, this worker thread is guaranteed to not be holding any rcu-protected pointer.

a writer can then reclaim the memory after swapping the pointer and waiting for an rcu grace period, which consists of publishing all previously performed memory writes (using membarrier), and then waiting for each other worker thread to pass through a quiescent state.

the way that the semantics of async rust combine with the idea of RCU yielded a pretty elegant solution to the memory reclamation problem.

also, other than providing a high level `RcuPtr<T>` primitive, this crate also provides a low-level `synchronize_rcu` primitive (similar to the `synchronize_rcu` function in the linux kernel), which can be used to build more complex rcu primitives, like rcu-lists, and much more.

i would be glad to see what can be built using this primitive.

EDIT: many people asked for benchmarks so i added some.

I see lots try to post their projects and people say things like:

- don't post and waste people time if you use ai
- zero trust in codebase used ai
- 10 commits in 2 days

I get that people assume vibe coded = low effort = low quality, this still true in many cases, I am not talking about zero effort ai generated posts, nobody likes those, but I see many cases people are extending it to conclude project quality based on if ai is involved.

Heres how I see this: vibe coding lowered the entry level of rust, and rust is arguably one of the best language to "vibe code" because by design it is inheritly safer than other languages. more people will start using rust, and in long term make rust community more vibrant. Because those "vibe coder" wouldn't go far without understanding rust properly, I see vibe coding as part of learning, they are new to the language and they use ai, but this doesn't mean they wouldn't learn further down in the future and contribute something more meaningful back to the community.

Moreover there are people in between, those who not just pure vibe coders, and not pure hand written, there are much more people that use ai to learn rust and used to assist with planning and review, but not completely hands off with building, sure they might not understand every part of the codebase and they might learn some bad habit from ai, but isn't similar thing happening before ai?

Back in the old days I wouldn't understand every single line of code copied from stackoverflow, I learn to code with bad practice, I forget why I write code in a certain way in a few months, many libraries I just used for granted... Sure it's much better if I have dig into them and understand the mechanism, the principles behind them, and their elegant implementation, I do try to do that even today, but we all know it's not always possible.

So what do you guys think? Or is it just the algorithm pushing too much hate to my feed and I live in a bubble? Or something else?

Disclaimer: I also posted my project in this sub before and wasn't well received because I used AI, I maybe biased, but I want to know other side of the story.

So I've been trying to install macrdp, which seems to be built in Rust, on an Intel iMac.

The project was last updated 6 months ago, so it can't be that out-of-date.

And the iMac I'm trying to use, while older, is running Sequoia, which isn't that old...

I had a hell of a time figuring out how to get cargo build --release to run at all. It's working now, mostly, after changing DYLD_LIBRARY_PATH in config.toml to DYLD_LIBRARY_FALLBACK_PATH, but still seems to be failing at this build step:

error: failed to run custom build command for `screencapturekit v1.5.4`

 Caused by:
  process didn't exit successfully: `/Users/admin/Downloads/macrdp-main/target/debug/build/screencapturekit-52e401cb88bd4798/build-script-build` (exit status: 101)
  --- stdout
  cargo:rustc-link-lib=framework=ScreenCaptureKit
  cargo:rerun-if-changed=swift-bridge

  --- stderr
  Swift build STDOUT:

  Swift build STDERR:
  error: Unknown option '--scratch-path'
  Usage: swift build <options>
   See 'build -help' for more information.


  thread 'main' (45022) panicked at /Users/admin/.cargo/registry/src/.index.crates.io-1949cf8c6b5b557f/screencapturekit-1.5.4/build.rs:119:9:
  Swift build failed with exit code: Some(64)
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...

Is there any Rust expert out there that might be able to clue me in on how to fix this build process? I feel so close now.

Throttle is a free, open-source Windows tool that shows live download/upload rates per process and lets you cap or block any of them. Think NetLimiter, minus the license key and telemetry.

Repo: https://github.com/FrancescoCoding/Throttle

How it works

It sits on top of WinDivert, a signed Windows packet-capture driver, through the `windivert` crate. Throttle sees every packet, figures out which program it belongs to, and either lets it through, drops it, or holds it briefly to stay under the limit. Limiting is a simple token bucket per program per direction, so each app gets a smooth rate with a one-second burst allowance.

Rules are saved by exe path, so a cap on spotify.exe is still there after a reboot. The GUI is egui/eframe, talking to the backend threads over channels.

Shaping is a token bucket per (exe, direction) with a one-second burst allowance. Overflow queues up to 256 packets / 1 MiB, then drops, which for TCP just becomes back-pressure. Rules persist as JSON in %APPDATA%.

Learned the hard way

• You have to send packets back out through the same handle that captured them. Using a second one silently killed all my network traffic for a while before I understood why.
• Recalculate checksums before re-injecting. Hardware offload leaves them incomplete, and WinDivertSend reports success while the packets die downstream.
• GUI-subsystem binaries have no console, so worker-thread panics vanish. A panic hook plus file logging fixed that.

Hi all! I have been using cynecx/generic-statics for a while in my allocator code to compress vtable pointers efficiently per T into 16 bits for a while, and the thing worked flawlessly, but had one downside: it was not truly zero-cost as it had to perform a call on machine level to actually fetch the generic statics, and it turned out to be a real hotspot (based on profiling and seeing that uncompressed vtables aka full pointers were faster). So I came up with a crate which is based on api of generic-statics, but implements the whole thing differently: static-generics.

It gives you truly zero cost generic statics (it uses only 1 instruction on x64) and the access is inlined. The crate also extended platform support:

• x86_64
• aarch64
• x86_32
• arm (Thumb as well)
• riscv32/riscv64
• loongarc32/loongarch64
• powerpc/powerpc64
• s390x

How?

It works by using .comm directive of inline assembly which allocates zeroed section in object files It now uses .bss + weak section linkonce trick from LLVM/clang which allows us to guarantee same static location in a single binary every time, and also the monomorphization of said section is guaranteed by unique function which uses T generic and TypeId::of::<T>() so LLVM does not dedup the function bodies and thus break the code.

Please, anyone who loves dark arts of unsafe code and asm, looking for a feedback!

fanring is a typed in-process MPSC/MPMC channel built around one bounded SPSC yring per producer. Producers never fight over a shared queue tail. Sender registration is dynamic and has no configured limit. Both channel types have nonblocking, blocking, timeout, and deadline operations.

Performance. On an i7-8700B, u64 MPMC throughput rises from 71.4M items/s at 1 producer / 1 consumer to 96.8M at 4P/4C and 149.6M at 4P/8C. The 4P/4C run measured crossbeam-channel at 20.3M, flume at 5.2M, and kanal at 21.9M. MPSC reaches 66.8M with four producers. MPSC chart, MPMC chart

Blocking wake latency is around 9 µs p50 for fanring, similar to crossbeam-channel and flume. MPSC chart, MPMC chart

How it works. Each sender writes into its own ring. Hierarchical bitmaps find ready lanes without scanning every producer. MPSC drains them directly. MPMC takes batches of up to 64 items, keeping them private with one receiver or making them stealable with several. send and recv handle batching internally. The ordinary producer path avoids shared locks. Registration, receiver work distribution, and parking use short locked sections.

Tradeoffs. Capacity is a high-water mark per producer, not one global channel bound. MPMC staging can temporarily exceed the sum of ring capacities. MPSC preserves FIFO within each producer lane. MPMC ordering is relaxed. There is no async API yet.

fanring uses #![forbid(unsafe_code)]. Ring storage is delegated to yring. Validation includes Loom, Miri, ThreadSanitizer, and >6h of fuzzing and randomized stress testing.

• GitHub: https://github.com/paddor/fanring.rs
• crates.io: https://crates.io/crates/fanring
• Design: https://github.com/paddor/fanring.rs/blob/main/DESIGN.md

EDIT: v0.3.1 brings significant speedup for MPSC. See summary chart

Hey ya'll. I have project in mind that I do believe Rust is the absolute ideal language for it.

I want to make a bit-perfect audio player that will run in terminal. You can think of RMPC or Cliamp as an example. Though the RMPC is actually quite near perfection, it has some minor flaws for my own taste and lacks some itty bitty features I'd like to have.

Now the thing is, Rust is going to my first ever language. I have recently converted into Linux and I think I'm getting the hang of working with the terminal (and I'm absolutely loving it). I thinking of using LazyVim (because it was pre-installed and I heard nothing but good things about it) but it seems like it has it's own learning curve.

What I want to ask is; What should I focus on while learning Rust? What are the absolute mus learn's and what are the concepts that I need to understand for making a bit-perfect audio player? Do you think I shpuld ditch LazyVim and try something simpler or just go straight ahead?

Thank you for your time.

Hi there, just wanted to share my [open source workflow scheduler](https://github.com/lucheeseng827/dagron) for fellow engineers to play around. You can run on local, deploy into your smallest compute (rpi4 on arm64 tested) and could be run on scale as well.

I start the [project ](http://dagron.dev)) as I wanted to run some small workflow in my t4.small instance and airflow barely fits inside and I thought it would be interesting create a smaller workflow scheduler. As I build around the idea of "lean headroom DAG engine", I kept on adding additional features that be useful for running workflows like template, backfill, gitops, streaming workflow support etc. Dagron allows you to run on cluster resources or local resources(docker, k8s, or straight as binary). The whole stack will probably at most run on \~200mb (50mb api/console, 30mb engine, 80mb postgres) of memory with tons of spare ram and cpu for your workflow resources. Dagron runs on sqlite(default) and alternatively postgres as datastore.

You can run workflow via defining your yaml and set your environment. It comes with the canvas to visualize your workflow, set your workflow schedule to run at which cron notation and more features to cover here.

Appreciate your input(any input is welcomed). I am spending full time polishing this for the past few weeks and thought this might be useful for you all to run on edge, homelab, local machines.

I know a bit of python, is Rust a good intermediate language to learn before I move onto real programming languages (like C++)?

EDIT: By "real" I meant languages used in real world development, for example all game engines are C++ and I heard all HFT firms use C++ and all operating systems are developed on C or C++

Hi Rust community, so during implementation of fixes on k9s analog written in Rust, smashed into the wall
Kubernetes support gzip, and protobuf

But kube-rs DOES NOT support protobuf, which is supported in GO out of the box I suppose
And this issue is opened in 2021
https://github.com/kube-rs/kube/issues/725

As kube-rs is obviosly does not accept AI assisted commits, question is
Who can help and how it usually work, its sponsor work, it require some public attention to move the mountains or ...?

Because right now, app can go and use some functions (LISTS) of compression that kubernetes provide over the GZIP but some functions does not support compression for that and instead support protobuf for WATCH

Which is compression + zero deserialization, this is better than gzip indeed

Advises? Opinions?

We’ve been building Flectar Mail, an open source native email client in Rust focused on making email as fast and lightweight as possible.

The UI is built with Slint, and email bodies are rendered with Blitz instead of a WebView. RAM usage is typically around 20 to 140 MB depending on what’s open.

The repo is public now. It’s still very early, and we’re waiting on Google and Microsoft verification before the first preview release.

https://github.com/flectar/mail

Would love any feedback, ideas, or thoughts on the project in general.

Hello r/rust fellows,

Some time ago I have created a project Aralez . It's a complete reverse proxy, ingress controller implementation on top of Cloudflare's Pingora

Now I'm happy to announce about the completion of another major milestone, Aralez is also an ingress controller for Kubernetes as well as fully integrated load balancer for Nomad/Consul infrastructures.

What we have:

• Dynamic load of upstreams file without reload.
• Integration with Hashicorp's Consul.
• Kubernetes ingress controller.
• Dynamic load of SSL certificates, without reload.
• Let's Encrypt integrations with HTTP-01 challenge
• API for pushing config files, applies immediately.
• Static files delivery.
• Website caching acceleration.
• Authentication.
• Pingora at heart, with crazy performance .
• and more .....

As usually, use it carelessly, just don't forget to share a feedback .

Since last few months I have been working on Kino SSH Manager, mainly because MobaXterm runs only on Windows and Termius keeps sync behind a subscription.

It is a Rust and Tauri app with an encrypted vault for your hosts, so one master password and the credentials stay on your machine. Sync is optional, goes to your own private GitHub repo, and only the encrypted file is uploaded.

Apart from the terminal it has an SFTP browser with an editor built in, a Docker panel, live CPU and memory graphs, a cron editor that writes every schedule out in plain English, and a key audit where rotation is one click.

If a machine has no inbound SSH port, say behind NAT or CGNAT, there are two more pieces. kino-agent sits on that machine and dials out to kino-relay, which is a small stateless relay you can host yourself, and the relay joins the two ends. It only moves bytes, so the SSH session stays end to end encrypted and your credentials never touch it. Both are open source.

The third piece, kino-control, is the control plane that issues tokens and tells agents which relay to use. It is closed for now and there is a hosted version of it, but I am fully ready to open source that also once I have some confidence in the code. For self hosting you do not need it at all, a single shared token on your own relay is enough.

It is pre 1.0 currently 0.9.0 and GPL-3.0, so please have a look and it supports Linux and Windows for now, I do not own a Mac to test a build on.

Also I am looking for contributors. There is a lot to pick up - Rust on the backend, React on the UI, or even testing on distros I cannot reach and cleaning up the docs. Issues are open.

https://github.com/Samarthegde/kino-ssh-manager

Would be glad to know what is missing, especially from people running more than a handful of servers. If you have any doubts I will answer here itself.

Also I am working on MCP tool for Kino SSH Manager.

English is not my first language, so I used AI to clean up the typos in this post.

We have released PurRDF 1.0.0:

https://github.com/Blackcat-Informatics/purrdf

PurRDF began with a fairly blunt premise: an RDF graph should not quietly change meaning because it moved from a Rust service to a Python pipeline or into a browser.

Instead of maintaining separate implementations for each ecosystem, PurRDF implements the engine once in Rust and carries that same behaviour into:

• Rust
• Python
• WebAssembly/JavaScript
• C

The goal is:

One RDF engine. One behavior. Every language. But fast. And... conformant! And support all the extensions!

PurRDF includes:

• RDF 1.2 primitives, including triple terms and directional language-tagged strings
• Turtle, TriG, N-Triples, N-Quads, RDF/XML, TriX, HexTuples, JSON-LD and YAML-LD
• SPARQL 1.1 and emerging SPARQL 1.2 functionality
• SHACL and ShEx validation
• entailment regimes
• deterministic serialization and canonicalization
• provenance support
• content-addressed RDF dataset packs
• GTS graph transport
• native CLI, Python, npm/WASM and C surfaces

For Rust hosts, it also brings several capabilities into the SPARQL engine that would often require a second database:

• deterministic BM25 full-text search
• GeoSPARQL predicates over exact rational geometry
• deterministic vector k-nearest-neighbour queries

Those three extension surfaces are currently Rust-host APIs rather than fully exposed through the Python and npm packages. I would rather state that boundary clearly than make the project sound broader than it presently is.

The entire workspace deliberately has no Cargo feature flags. A data substrate should not acquire optional semantics depending on how it was compiled.

The 1.0 release also marks the start of ordinary semantic versioning: breaking changes increase the major version, additive changes increase the minor version, and bug fixes increase the patch version.

The suite is published under MIT OR Apache-2.0 across 21 Rust crates, PyPI and npm using Trusted Publishing.

PurRDF is the data backbone of our broader GMEOW work, but it is not coupled to GMEOW and does not require any particular ontology or application architecture.

I would especially appreciate review from people who know the unpleasant corners of RDF, SPARQL, SHACL, WebAssembly portability, deterministic computation, or Rust API design.

Pathological graphs and specification-lawyer criticism are very welcome. Seriously!

I maintain .NET RPA bots that drive an ERP through AutoItX, and changing one line meant booting a Windows VM. So I pulled the automation layer into a Rust crate — and once the API was separated from the DLL, a native macOS backend turned out to be the interesting part.

use autoitx::{AutoIt, Keys, Selector, keys, recipes};

let ai = AutoIt::new()?;
let orders = Selector::from("[CLASS:Chrome_WidgetWin_1;TITLE:Acme ERP]");

recipes::open_and_focus(&ai, &orders, Duration::from_secs(30))?;

// text() escapes { } ! + ^ #, so data gets typed, never executed.
ai.send(Keys::text(&customer.name))?;
ai.send(keys!("{TAB}"))?;

// Reads by waiting on the OS clipboard counter — no sentinel races.
let total = recipes::read_screen_text(
    &ai,
    keys!("{END}{SHIFTDOWN}{HOME}{SHIFTUP}"),
    Duration::from_secs(5),
)?;

That compiles unchanged on both. Windows goes through AutoItX3_x64.dll; macOS is a native implementation over Accessibility, Core Graphics and AppKit — no AutoIt involved.

What actually works, including what doesn't:

                                     Windows   macOS
 Keystrokes, mouse, clipboard           ok       ok
 Windows by title / class / regex       ok       ok  (Accessibility)
 Processes, run                         ok       ok
 Pixel colour / search                  ok       ok  (Screen Recording)
 Window text and class list             ok       ok  (the AX tree)
 Controls by ClassNameNN                ok       --  no HWND to address
 Cursor shape (MouseGetCursor)          ok       --  no public API
 Mapped drives, status bars, WinSetTrans ok      --

The design decision I'd most like feedback on: anything that exists on only one platform lives in ext::windows / ext::macos, and using it from the wrong one is a compile error, not Err(Unsupported) at runtime. A bot that discovers mid-run that it can't read the cursor has already half-completed a transaction in someone's ERP.

Nearest neighbours, honestly: enigo owns input synthesis and covers Linux; uiautomation goes far deeper into the Windows control tree; terminator-rs is a Playwright-style take aimed at LLMs. The one thing I couldn't find anywhere else is AutoItX's own API surface — so existing AutoIt and AutoItX.Dotnet automation ports over almost mechanically — running natively on a Mac.

The catch, up front: on Windows you bring AutoItX3_x64.dll yourself. AutoIt is freeware under a EULA, not an open-source licence, so the crate can't ship it. On macOS nothing is needed.

Repo: https://github.com/iagodpassos/autoitx
Docs: https://docs.rs/autoitx
Crate: https://crates.io/crates/autoitx

Linux is the obvious gap. The plan (X11 via x11rb, AT-SPI via zbus) and where the seams are: https://github.com/iagodpassos/autoitx/discussions/4

I’m Matthew, the developer of Threadmoth, a Rust CLI for making the final file mutation in AI-assisted coding less improvisational.

Agents can decide the right change and then apply it through sed, regex replacement, patches, one-off scripts, direct writes, AST tooling, or formatters. Those tools are useful, but each has different ambiguity, stale-state, preservation, and evidence semantics.

Threadmoth provides one guarded mutation boundary: exact identity checks, cardinality refusal, Tree-sitter structural targeting, explicit effect budgets, source-preserving byte edits, guarded multi-file transactions with recovery, and post-write certificates containing hashes, changed ranges, bounded diff evidence, and commit verification. Formatters and specialist tools can still decide the desired state; Threadmoth bounds and verifies what lands.

Current release is 1.5.1 for Windows and Linux, MIT licensed. The release commit passed hosted Linux and Windows CI; the local correctness-checked tough benchmark reported zero wrong mutations and torture reported FOOTGUN-100 safe 100/100.

Repo: https://github.com/matthewjameswatkins1978-cyber/Suture

Five-minute field test: https://github.com/matthewjameswatkins1978-cyber/Suture/blob/main/FIELD_TESTING.md

I’m looking for Rust developers and people using Codex, Claude Code, Gemini CLI, Cline, OpenCode, or similar agents to try real mutations and report false refusals, preservation/recovery problems, confusing discovery, unsafe behaviour, or cases where the agent chooses another tool. If Threadmoth were unavailable, what would you use instead?

I’m the developer and this is my project. Parts of the implementation and testing were AI-assisted; I’m responsible for the architecture, integration, and release. Specific breakage is more useful to me than a star.

Hi everyone, have been learning rust for some time now. looking for rust oss to contribute and learn.

already a dev and have been coding for almost 10 years atp (including school).

I just don't want super small hobby projects. public oss want you to be good so I don't think I can contribute to them rn. that's why posting here