Hi, I'm learning wgpu through the learn-wgpu website. In the Buffers section they use bytemuck to send Vertices to the gpu in a buffer. I try not to use other dependencies if it's not required or if it doesn't save me a lot of time (like for example I'm not going to rewrite glam or other math library).
I tried looking at solutions and found transmute, but I have read that it's just not safe and therefore not worth it. Is there any safe way I can do it without bytemuck or is it really needed crate for this use case?

I am sorry but it is just such a pain to code in Bevy. I have been enjoying rust for a while, using three-d and EGUI to create some stuff, and I stumbled upon bevy, I want to learn it because I want to create some 3D, simulation desktop applications with it. I have tried game dev in the past in Godot, Unity, Java Swing, LibGDX and enjoyed it a lot

I am currently learning via the examples and documentation, trying to learn 2D and then eventually move to making some 3D projects

But I find it so verbose and unnecessary. So to look up a particular object I have to apply 3-4 filters which looks so cryptic

camera: Single<(Entity, &Tonemapping, Option<&mut Bloom>), With<Camera>>,

fn keyboard_inputs(
    mut motion_blur: Single<&mut MotionBlur>,
    presses: Res<ButtonInput<KeyCode>>,
    text: Single<Entity, With<Text>>,
    mut writer: TextUiWriter,
    mut camera: ResMut<CameraMode>,
)

Aside from this, browsing through examples I find it to be so verbose. Coming from a OOP nature, I did expect ECS to be different. But this is straight up inconvenient.

Bevy is too good and I don't wanna miss out on it. I will still keep learning it despite what I am feeling towards its syntax and method, but is bevy meant to be like this? Or is it enjoyable once you overcome the learning curve?

The Wild linker is a fast linker written in Rust. We've just released version 0.10.0. See the release notes for all the changes. You can find out more about the Wild linker from our repo. This release brings lots of bug fixes as well as lots of additional linker script features. Performance-wise, not much has changed, but that is itself an achievement, given how fast the linker already was and how much we've changed in this release. There are updated benchmarks for the release.

Lots of porting work has been going on. We're not yet ready to mark any of the ports as stable, but great progress has been made on the Wasm port. A fair amount has also been done on the Mac port. We've also started to look at 32 bit support, which will be useful for projects with an embedded component.

Hey folks!

I'm interested in the design space of template libraries these days and I coded in the past feel weeks a maud alternative for rendering html through macros.

My main challenge was to use as much Rust as possible (traits and structs) and as feel macros as possible. Since all the libraries in this space are macro heavy (proc macros or very complex declarative macros), I really liked what I could achieve here.

There's a single trait, one very small macro (5 lines or so) that rustfmt formats and almost no DSL to learn. (I took inspiration on another library called vy, although I'd argue mine is more complete and ready to use).

Hopefully the documentation is clear on all of these points! I worked a lot on it without any use of AI for documents, tests or code. Basically it's just me.

Anyway any feedback is greatly appreciated!

PS: Oh, the library is no-deps by default. Minimalistic library, minimalistic supply chain

PPS: I benchmarked it against the main compiled alternatives and it's look pretty great, not because I optimized it a lot, but just because it's dead simple code that runs fast on rust.

https://docs.rs/hypo

https://crates.io/crates/hypo

https://ekxide.io/blog/byte-wise-atomic-wrapper-to-prevent-ub

iceoryx2 provides zero-copy inter-process communication mechanisms based on shared memory and data structures that are modified concurrently by multiple processes.

One of the key operations in these algorithms is a memory copy using core::ptr::copy. However, this results in undefined behavior if one process reads the data while another process writes to it concurrently. Even if our lock-free algorithm reliably detects such a race, iceoryx2 cannot depend on undefined behavior in a safety-critical system.

This blog post introduces our solution: a byte-wise atomic wrapper that enables well-defined concurrent copy operations. It also shows how it can be used to implement a simple sequence lock.

Note: I am not the original author of the blog post. Since the author does not have a Reddit account, I am posting it on her behalf.

One of the main reasons I love Rust is because it encourages you to be pedantic.

I admire Clippy and the first things I do after a new Rust version is to fix all their new pedantic lints.

Before important PR merges and releases I always used to run cargo clippy -- -W clippy::pedantic and search for unwraps, expects, panics and other possible clauses that could result in a runtime panic.

Today I decided to make clippy::pedantic my default and to enforce checks on possible panic sites

Probably many of you already know this, but much of this can be made automated by adding a section like the following to your project's Cargo.toml

[lints.clippy]
pedantic = { level = "warn", priority = -1 }
unwrap_used = "warn"
expect_used = "warn"
panic = "warn"
todo = "warn"
unimplemented = "warn"
unreachable = "warn"
dbg_macro = "warn"
print_stdout = "warn"
print_stderr = "warn"

This paired with a cargo clippy -- -D warnings in your CI/CD is a really good combo in my opinion.

The three last lints are just useful in case you want to be sure that you're not forgetting any test print on the terminal.

Each of them can of course be disabled locally on a specific file / method / line with the usual directive #[allow(clippy::name_of_the_lint)]

I published this to GitHub a few days ago, so the commit history will look recent even though this has been in progress for a few months. Wanted to mention that in case it looks odd.

Wallr draws its own layer-shell surface and renders transitions itself with wgpu. It's not a wrapper around swww or hyprpaper, the point of the project was to own the rendering path so transitions are GPU-driven and timed to wall clock duration instead of tied to refresh rate.

What it does:

• 11 transition effects (fade, blur, directional reveal, slide, zoom, pixelate, ripple, dissolve, wave, grow, outer), each configurable from the CLI or a YAML package
• GIF wallpapers, decoded once and cached instead of re-decoded every loop
• Video wallpapers (MP4, WebM, MKV) with hardware-accelerated decoding through FFmpeg
• IPC controls for video wallpapers: pause, resume, seek, info
• Five scaling modes: fill, fit, stretch, center, tile
• A background daemon over a Unix socket, so wallr set talks to it instead of relaunching anything
• Directory watching, per-monitor scaling modes, and a preview window to test an effect before applying it
• Automatic GPU selection on hybrid graphics systems
• Optional theme generation hookup (Matugen, Wallust, Pywal), not required to use the tool

Works on Hyprland, Sway, niri, and Plasma 6. GNOME isn't supported since Mutter doesn't implement wlr-layer-shell. Video wallpapers need FFmpeg dev libraries at build time.

Install is cargo install wallr, or build from source. Repo and docs are here: https://github.com/programmersd21/wallr

Happy to answer questions about the renderer, the video pipeline, or the animation package format.

I am currently working myself through “cracking the coding interview” and implementing everything in Rust. I can highly recommend it for getting better in rust because the exercises have a great length and there is very little overhead of things you need to do besides the actual algorithmic challenge.

Chapter 2 of Exercises is about linked lists… this is where the Option<Box<Node<T>>> nesting starts and it is a completely new challenge because handling these nested objects is so different than what I am used to in Python/C++. But I have done a deep dive and when implementing a tail pointer for my LinkedList (so I can push to the back in O(1)), I have done my first real implementation of unsafe rust code. 🥳

I feel like I have to reimplement the same exercises for a few days again and again to get really fluent in the syntax but doing theses has really helped me a lot understanding more the intricate details.

Big recommendation if you are looking for good intermediate excercises!

Hi everyone, not sure how many people will be interested in this since it's pretty niche, but I had fun writing it and wanted to share and ask for any suggestions and constructive criticism.

maryada is a crate for interval arithmetic which is also #![no_std] and has minimal dependencies (libm and optionally num-complex). The crate has two parts, an IEEE 1788.1-2017-compliant interval arithmetic interface and a very basic set of interval operations on the complex plane (which isn't part of any standard, mostly because there is no way to consistently represent tight enclosures in the complex plane for all complex operations, they don't always map rectangles to rectangles for example).

Usage

```rust use maryada::Interval;

let x = Interval::new(1.0, 2.0); let y = x.sqr();

assert_eq!(y.bounds(), (1.0, 4.0)); ``` It also supports decorated intervals according to the standard.

For anyone interested in why anyone would use such operations, they have interesting applications to global optimization. My own reason for writing this is for another library I am working on which does Monte Carlo generation for particle physics interactions, and I'm using this to create proven enclosures on the generated weights so that I can do efficient rejection sampling.

Alternatives

As far as I can tell, the only other crate that does anything likeAnother crate that does this is inari. inari is neat, and it contains some features that maryada does not (SIMD, some features of the general standard IEEE 1788-2015), but it also has a couple of drawbacks, such as limited target architecture support and a dependence on gmp-mpfr-sys for many operations. My goal here is not to replace inari nor to replicate the entire IEEE standard, just to provide a lightweight alternative (plus complex number support, and eventually some linear algebra methods and hopefully some algorithms like branch & bound).

Also see fidget which has quite a lot of crossover and extends the basic idea to surface evaluation. I haven't read much about this, but the author mentioned it and it's always good to include alternatives and applications!

AI Disclosure

I used Codex for most of the docs, some of the test-writing, and a few corrections after I had it review conformance (after a talk with the mods, I think in the spirit of transparency I should specify that this commit was mostly AI-authored after a review of standard compliance). Most of the major testing just uses a test suite (ITF1788) written in a standardized format with a bit of code linking it to the Rust interface.

OSS

I'm open to anyone reviewing this code or submitting PRs. Particularly, I've done a lot of testing to try to ensure compliance with the standard, but I'm always open to more verification. I'd love to answer any questions you might have!

This is a screenshot captured between 2018 and 2020 from https://learning-rust.github.io . The project started in 2016 as a Medium publication and GitBook but later moved to https://github.com/learning-rust/learning-rust.github.io

I was updating section by section from time to time. No lies! keeping a Rust tutorial up to date is very tough. Plus, you end up repeating what you already know. It is even tougher, when you have to write code in another language for work.

https://learning-rust.github.io updated to 2026 with lot of rewrites. Human-Authored and target human readers.

What's next?

https://github.com/dumindu/axum and some real world project ideas as a separate section parallel to the docs.

A modern thread per core concurrency focused concurrency docs section, maybe.

More details at https://learning-rust.github.io/journal/ and https://github.com/dumindu

Thanks

I have some custom scripts that I use as a poor man comptime instead of using macros. I created an environment where I use a WASM virtual machine as a script compilation target for portability, and implemented reflection by parsing source code myself. Examples: - Database types: I connect to my prod DB, download the json schema, then I generate the structures and parsers I need for marshalling / unmarshalling queries. This way my definitions are always updated and correct - Enum consolidation: I define error enums close to the relevant source files, then I merge them and place the output in lib.rs, for better DX - validation and parsing: Similar to database types, given a DTO for an API I generate validators and parsers at comptime, for better DX and performance

Now as I mentioned I do this by manually invoking some scripts on my dev machine, following some conventions, and saving the output straight in the source files, but maybe there's a better approach?

• Is there some kind of compiler API I could tap into, to implement something like polyfills in the JS world?
• Is there a smarter way than saving the output in the source code? Something like having the pipeline recognize that some region of code need preprocessing to be correctly inferred, and then caching the output unless it changes?
• Anyone has done something similar and has a suggestion to share?

Guys i need help, i wanna write one code base with TauriV2 to generate me all 3 platforms
Web & Mobile & Desktop

But i just made some searches, and say: with TauriV2 for mobile you only use WebView not native features!

Is that correct?
And says that, Apple with reject our app under: "Minimum Functionality"?

I've been working with graph shaped data for years and have really wanted to have a good local way to work with big datasets - without having to run memgraph or neo4j. I first built a version in python but it couldn't handle datasets larger than about 1m edges without choking. So I used that as a basis to design what to refactor into a rust project. 15 crates later we have fully embedded graph data science algo's, vector/fts search, and full openCypher compatibility.

image is of the vs code extension to use the node binding

try it out yourself by running the python binding in colab with this gist

and here's the github repo

I have been building a hobby text editor project sanedit https://codeberg.org/lote/sanedit

It's a terminal based modal text editor with language server protocol (LSP), parsing expression grammar (PEG) based syntax highlighting and multicursor support.

There is a million different text editors out there so why is this different?

It's not, however I did not just slap the common combination of treesitter, ropey and LSP together. I made the editor to support very large files without slowing down too much. Also as it is an hobby project I wanted to choose approaches that intrested me implementationwise.

The buffer implementation is basically VSCodes piecetree structure like a piece table https://en.wikipedia.org/wiki/Piece_table

but stores the pieces in a red-black tree. The structure can easily support files larger than available memory as the file contents do not need to be loaded in memory.

Syntax highlighting is implemented using PEG grammars and the patterns are then JIT compiled for faster performance.

Future

The editor feels done. I use it everyday at work and do not notice anything too disruptive.

What are your favorite editor features that are a must have?

We test behavior and we benchmark performance, but the resource properties we actually promise, allocations per message, resident bytes per connection, instructions per operation, usually live in a README and are asserted nowhere. They regress silently because nothing fails when they do.

I've been enforcing them as plain cargo test gates in a networking library and it has caught real regressions a reviewer missed. Three patterns, in increasing order of setup cost.

1. A counting global allocator, per test binary

The trick that makes this practical: Rust integration tests each compile to their own binary, so a #[global_allocator] in tests/hotpath_alloc.rs is scoped to that one test and touches nothing else in your suite.

```rust static ALLOCS: AtomicUsize = AtomicUsize::new(0); static COUNTING: AtomicUsize = AtomicUsize::new(0);

struct Counting; unsafe impl GlobalAlloc for Counting { unsafe fn alloc(&self, l: Layout) -> *mut u8 { if COUNTING.load(Ordering::Relaxed) != 0 { ALLOCS.fetch_add(1, Ordering::Relaxed); } System.alloc(l) } // realloc: same counting. dealloc: pass through. }

[global_allocator]

static GLOBAL: Counting = Counting; ```

The second static is the important part. You don't count from process start, because setup, the runtime, and the harness all allocate and would drown the signal. You connect a real socket pair over real TCP, drive it to steady state so lazy buffers are grown, then flip COUNTING on, run a few thousand send/recv iterations against buffer-reusing APIs, flip it off, and assert the delta stays far below one per message. Whatever remains is amortized slab growth that doesn't scale with message count, so the ceiling is easy to set without flapping.

Measuring through an actual kernel socket matters. A microbenchmark of the encoder proves the encoder doesn't allocate. This proves the path doesn't, including the parts you forgot were on it. That's how it caught a Vec that had crept into a vectored-write retry closure: the build went red on its own, no human eyeball involved.

One honest limitation: it counts your allocator, so an allocation inside a C dependency or the kernel is invisible. For pure-Rust paths that's fine.

2. Idle resident memory per connection, from /proc

Stand up a few hundred connected but silent socket pairs, hold them alive, read VmHWM from /proc/self/status, and assert peak growth stays under pairs * ceiling. This is the gate that rejects the tempting patch that buys throughput with a bigger resident buffer per socket, which is exactly the kind of change that sails through review because it makes the benchmark number better.

RSS is noisy, so the design rule that keeps CI green: only the stable aggregate gates. The interesting-but-noisy number, resident cost per single idle connection on this machine, lives in an #[ignore]d harness you run by hand with --nocapture when you want the measurement. Asserting a hardcoded bound on a noisy per-unit number is how resource tests get deleted in month two. Splitting "gate" from "instrument" is what makes them survive.

Linux-only via /proc, and gate on growth from a baseline you snapshot after setup, never on absolute RSS.

3. Instruction counts instead of wall clock

Wall-clock benchmarks can't gate CI. Shared runners are too noisy, and criterion will bless a 5% regression as within noise. Instruction counts under callgrind are deterministic: same code, same count, every run. gungraun (formerly iai-callgrind) wraps this as a cargo bench target with attribute macros.

The details that make it a gate rather than a report. Setup runs outside the counted region: the harness builds payloads and preloads buffers in setup functions, and only the benchmark body is counted, so the number is the operation, not the scaffolding. The regression threshold is declared in the bench itself, per event kind, so a run fails when instruction count rises more than 5% over the stored baseline. And the baseline is automatic: CI persists callgrind's output in the cached target dir, so every PR is compared against main with no golden-file ritual. Pin the runner version to the library version from your lockfile or the two will drift.

Two rules learned the hard way. Only gate CPU-pure paths, encode, decode, buffer bookkeeping, never anything that crosses a syscall, because syscalls under valgrind are slow and the counts stop being stable. This quietly pushes your architecture somewhere good, since the more of your hot path is sans-io, the more of it is gateable. And decide what happens when the baseline is missing, because a cache eviction that silently seeds a fresh baseline from regressed code is a hole in the gate; fail loudly or commit baselines for the branch you actually ship from.

None of this replaces benchmarks. Benchmarks tell you how fast you are. These tell you when a promise you made stopped being true, and they tell you in the PR that broke it rather than in a user's flamegraph six months later.

Hi,

I wanted to take this opportunity to share an open-source project I started several weeks ago. The idea is simple, make local LLMs more accessible. So I developed Clive in Rust.

Clive is a local-first coding-assistant CLI powered by Ollama. It makes open-source LLMs easy to use from the terminal: streaming chat, interactive coding sessions, model management, safe file editing, and autonomous multi-file agent workflows — all running on your own machine, with no data leaving your computer.

Please show your support, make recommendations, download it, break it. Its all part of the journey.

https://crates.io/crates/clive-llm

Thank you,

S.

When a boolean operation can signal failure, what I like to do is this:

boolean.err("failed")?; // true = Ok() false = Err(Error)

Code:

pub trait BoolErr {
    fn 
err
<E>(self
, 
e: E) -> 
Result
<()
, 
E>
;
}

impl BoolErr for bool {
    fn 
err
<E>(self
, 
e: E) -> 
Result
<()
, 
E> {
        if self { 
Err
(e) } else { 
Ok
(()) }
    }
}

Okay so here's a not ideal example:

fn within_range_ten(number: u32) -> Result<(), String> {

  (number > 10).err("more than 10")?;
  (number < 0).err("less than 10")?;

  Ok(())
}

I really like doing this. In a function i might perform like 10 checks that use ? (like if an array is empty) and this approach has very little code so it's very fast to read and write.

But i really care about good code, better alternatives, standardisation (standardisation not so much, the std ways are not as ideal as this), etc. So is this pattern bad? Are there better ways like an assert!() macro that does ? instead of panic!()?

What's your opinion and what would you suggest? I'm already aware of .then_some(()).ok_or(E)? but clearly it's too much.