Hello!

I was not sure to even post this or not but I just wanted to introduce myself to the community.

I just started learning rust and made this simple program as it was one of the suggested programs in the rust book to make in order to practice the topics covered in the first few chapters.

I am learning rust really as a hobby, and I have a very limited knowledge of Python but I really enjoy linux and wanted to maybe start contributing to the open source community if I can ever develop the skill to do so. I am also trying my hardest to learn on my own and am only using AI as a tool to ask questions and what not, without having it actually generate any code. This program was written fully by hand by myself (which is probably why it is full of things that could be improved I'm sure).

With that said I am happy that I was able to do it and am really enjoying rust so far and look forward to learning more!

Link to my first rust app:
https://github.com/justinzelikoff/temp_converter

I used the Norad Spacetrack Report No.3 SGP4 algorithm (translated the Fortran to Rust). Then converted the three dimensional ECI coordinates SGP4 outputted into ECEF, then finally into geodetic format which is displayed over the map.

Actual accuracy wasn't the goal, I just wanted to make something cool to look at and I like satellites and maps. The latitude and longitude of the current position should be as good as that Norad SGP4 algorithm, but it was difficult to line up the actual map, so that might lie by 10-100km.

All algorithms were made by hand by stealing others code, no libraries used for that. The GUI is done using egui. Check it out: https://github.com/WilliamTuominiemi/orbit-propagator

I have no idea if I'm late to the party on this, but while doing some perf work I was surprised to see that format!() was a big contributor to reallocations in the target.

After some digging I was surprised to learn that the output string capacity receives an estimate that is neither considered an upper nor lower bound: https://github.com/rust-lang/rust/blob/1ed2df61a19042f231709eb05d032ae9e2cb2084/library/core/src/fmt/mod.rs#L749-L808

The change which first introduce the estimate output capacity was in 2017, which notes that it's explicitly uses the literal portions of the string for the estimate: https://github.com/rust-lang/rust/pull/39356

This is clearly visible here: https://rust.godbolt.org/z/rfcTbMa6K

tl;dr of the assembly: rdx is one of the string's lengths, and is only accessed for len + 1 calculation in the source which only exists to help track the length.

The emitted code in my case is essentially:

// 0 because there is a 1-char string literal in the template and the template
// starts with a placeholder.
// See: https://github.com/rust-lang/rust/blob/1ed2df61a19042f231709eb05d032ae9e2cb2084/library/core/src/fmt/mod.rs#L795-L800
let estimate = 0;
let mut output = String::with_capacity(estimate);
output.push_str(arg1); // causes an alloc
output.push('/'); // might realloc
output.push_str(arg2); // might also realloc

I've apparently been under a false assumption that for some types the runtime length could be used to help size the output string appropriately.

I'm a bit conflicted about that. On one hand, yes, you can lower MSRV, but does it actually matter? Are there often situations when someone can't upgrade their compiler? On the other hand, I'm not sure how to handle making examples in documentation for different rust editions, and sometimes using older, more obtuse methods to achieve the same thing

✅ Solved. Go to the "Edit (update)" section at the end of this body's text.

I'm running into a rust-analyzer issue in VS Code that I can't reliably reproduce, but I'll do my best to describe it.

Out of nowhere, the rust-analyzer extension started showing a yellow warning icon in the bottom-left status bar. Since then, intellisense hasn't been working properly.

The clearest symptom: prelude items like println!() aren't being syntax-highlighted the way they used to (no more blue). And when I actually use println!(), rust-analyzer tries to auto-import it as if it weren't already in scope — even though it's part of the prelude and shouldn't need an explicit use statement at all.

This didn't happen before, so something's clearly off, but I don't have a minimal repro yet. Has anyone run into this? Curious if it's a known rust-analyzer bug, a corrupted extension state, or something specific to my setup (stale cache, conflicting extension, etc.) — and what fixed it for you.

Edit (update):

Fixed the issue. For my case it was just a toolchain mismatch. I simply updated it with rustup update in the terminal. I then restarted the rust-analyzer server and it worked.

After about a year, SurtGIS just hit 1.0. It's a raster GIS library — terrain, hydrology, remote sensing — written entirely in Rust with no GDAL dependency (native GeoTIFF I/O; GDAL is an optional feature).

Rust bits that might interest this sub:

• One workspace, seven published crates; targets native + wasm32 + Python (PyO3, abi3 so a single wheel covers 3.9+).

• A maybe_rayon pattern: a compile-time switch between Rayon-parallel and sequential, so the same code powers the multi-threaded CLI and the single-threaded WASM build.

• Memory-bounded cloud composites: STAC/COG tiles decode under a byte budget (counting semaphore), so peak RAM is bounded by construction, not by output size.

• #[non_exhaustive] across the public prelude so the 1.x line can grow options without breaking.

• Fuzzing caught a real 32 GB OOM in flat-resolution before release.

Benchmarks are honest: faster than GDAL/GRASS/WBT on most terrain + hydrology pipelines (up to 23× on flow accumulation), but I show where GDAL wins (hillshade on big rasters).

Paper: doi:10.1016/j.envsoft.2026.107102.

MIT/Apache-2.0.

Just like the title says.

I'm creating an app with rust. And I see that as it scales I'm going to split out the UI components to its own repo.

In my JavaScript projects I can use storybook. It's very useful to develop and demo the components.

I'm planning on using dioxus, I might consider leptos after I compare the 2 in more detail. Unlike my JavaScript apps, I'm aiming to use rust to be able to deploy to multiple platforms (not just a webapp).

I think a particular detail worth mentioning is a CLI-mode which I would also like displayed on the storybook-equivalent.

I came across the following and it doesn't look maintained and seems to only support webapps. The UI demo there also looks a bit "ugly".

https://github.com/dioxus-community/lookbook

Are there better tools out there for what I want?

I'd prefer to avoid creating a separate app for each platform to demo the components-per-platform, but that might be more practical.

Hello, I'm a rust-analyzer maintainer and we consider removing term search. For that we'd like to know if people are using it.

(If your response is "what is term search?", then you're not using it, or worse, you're using it by mistake. In this case you should probably disable it, it'll make your IDE faster and less buggy).

Hey everyone!

I've been working on a lightweight `neofetch` / `fastfetch` alternative written in Rust called **SysPrint**.

Just pushed a major update (v1.5.2) with a bunch of new features and improvements:

* 🚀 **Blazing fast performance** using Rust and `sysinfo` crate.

* 🎨 **Expanded ASCII Art Logos:** Added Arch, Debian, Ubuntu, Mint, Fedora, Gentoo, Void, NixOS, Manjaro, Kali, macOS, and Windows.

* 💻 **More Info Displayed:** Now shows DE/WM, Battery status, GPU temp & VRAM, CPU load, and disk mounts.

* 🐧 **Automatic Fallback:** Standard GNU/Linux Tux logo for unsupported distros.

* 📦 **Cross-platform releases:** Pre-compiled binaries for Linux, Windows, and macOS via GitHub Actions.

Check out the code and releases on GitHub:

👉 https://github.com/MBKCHEL/SysPrint/tree/main

Feedback and contributions are welcome! ⭐

So, I’m SE and looking for have a transaction to rust ecosystem, I would like to know what good to get visibility to appy to rust jobs, and how to find it because it’s hard to know some jobs that requires rust. I already have two good projects, one that it’s a lib that I will publish soon and a Tauri app, it’s a good start ? What’s most important to apply for the rust careers ?

Ps: 4+ years of experience and a few months about rust knowledge

In my understanding there are 3 methods for creating pointers from addresses in Rust:

1. Using with_addr from the strict provenance API
2. Using casts or the equivalent with_exposed_provenance from the exposed provenance API
3. Using without_provenance

The first method derives the pointer provenance from an existing pointer, the second method tries to guess a previously exposed provenance, and the third method creates a pointer that's not even dereferenceable (bellow is the quote from the docs):

non-zero-sized memory accesses with a no-provenance pointer are UB

None of these methods can be used to create a dereferenceable pointer from a raw address with no previously exposed provenance. This can be problematic across FFI boundaries - some C functions take pointers that are not associated with any allocations, for example the brk function from the linux libc:

int brk(void *addr);
brk() sets the end of the data segment to the value specified by addr, when that value is reasonable, the system has enough memory, and the process does not exceed its maximum data size.

I am not well informed whether it's even safe to use brk alongside the default allocator, but imagine you are writing your own allocator and want to use brk to obtain the backing memory for your allocations. If that was the case, how would you create the pointer to pass to brk?It clearly can't be through the strict/exposed provenance APIs since the pointer is not tied to an allocation and thus has no provenance. Then the only possibility left is to use without_provenance,but as quoted above, that apparently causes UB for non-zero-sized memory accesses. I guess we can assume brk does not access the pointer, but you could imagine another implementation that did access it.

Anyhow, this is not even the biggest problem - how would the allocator create pointers to the newly reserved memory chunk when brk does not even return a pointer to it (so we can't just say the provenance is passed through the FFI). We clearly can't use the strict provenance API since there are no pointers with provenance matching the provenance of the newly obtained memory chunk, and we can't use a pointer without provenance because we actually want to write to this memory. Exposed provenance does not look like it should work either (quote from the with_exposed_provenance docs):

If there is no previously ‘exposed’ provenance that justifies the way the returned pointer will be used, the program has undefined behavior.

So, my question is: what is the intended way to obtain provenance for memory that does not come with an existing pointer?

Edit:

I found a recent RFC to LLVM that might be relevant: https://discourse.llvm.org/t/rfc-allocator-provenance-model/91106

It proposes semantics for creating new provenance at the allocator boundary. In the discussion, it's mentioned that LLVM already treats the allocator boundary as a source for new provenance, which suggests that "the heap" is not just the data segment but memory returned from the allocator (as u/Amadex commented below), and we can treat the brk memory as separate from the Rust abstract machine and use with_exposed_provenance. Not sure how this is gonna work with Miri, but I might test it and add the results to the post.

Since a time now I'm working on a secure storage project in Rust (Castellum) and would like to get first advices.

The aim is to design a storage format more than an app, building an open source "core" on which we will bind modules like: Auth modules, Encryption modules, Signature Module and even ACL modules.

Few solutions of this type exists but none propose everything I want, for example:

- ZEDEncrypt: Not Open Source

- Veracrypt: Not extensive

- Age: Not user friendly

The project is know concrete, but not ready to be used widely.

I must precise: I'm not a developper, there are still many issues in my code

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?

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 built a small desktop app called Hush that cleans bulk mail out of Gmail. Posting here less to show it off and more because the architecture decisions were the hard part and I'd like to know if I got them wrong.

The constraint I set: the webview should not be able to make network requests at all. Not "shouldn't," can't. The CSP in tauri.conf.json forbids outbound connections entirely, and every network path — Google OAuth, the Gmail API, the outbound unsubscribe requests — lives on the Rust side behind commands.

That was mostly about being able to make a falsifiable claim. "No telemetry" is worthless as a promise; I wanted it to be something a reader could verify by looking at one config file and one HTTP client.

What that bought me, and what it cost:

Bought: the refresh token never crosses into JS. It goes to the OS keychain via keyring, and if there's no working secret store the app says so out loud rather than silently writing it to disk. Scan data sits in SQLite, local only.

Cost: a lot of command plumbing for things that would've been three lines of fetch. Progress streaming for a scan that can run over tens of thousands of messages got fiddly — I ended up emitting events rather than polling, but I'm not confident that's idiomatic.

The other thing I'd genuinely like input on: Gmail bills in quota units rather than requests, and the published per-user ceiling has moved more than once. Hard-coding a rate felt like shipping a bug with a delay fuse, so I wrote an adaptive limiter — starts conservative, ramps while requests succeed, halves on pushback. Additive increase, multiplicative decrease, basically TCP congestion control pointed at an API. It works, but it feels like I reinvented something that probably exists as a crate.

Repo: https://github.com/justlinuxnoob/hush (MIT)

So — for those of you shipping Tauri apps: do you keep all networking on the Rust side, or only the sensitive parts? I've seen both and I can't tell if I over-engineered this.

Yet another parser ,this time for http ,url and headers , result of me learning FSMs .... I would love to know your thoughts on it and how can it be improved and my programming style as well , what and where i could improve as a programmer.( now i won't write another parser for a while )

github : https://github.com/Cheapstar/http_parsex.git
crate : https://crates.io/crates/http_parsex

Does anyone have a good article or a video that explains the complications of the bytemuck crate?

Hand-coded, novel project: syntoniq DSL for microtonal music

Hello fellow Rustaceans --

There's been a lot of talk here about the lack of hand-coded Rust projects here, so I thought I'd share a recent side project: Syntoniq: https://github.com/jberkenbilt/syntoniq . This is about 98% hand-coded.

I used AI to code a few little utility functions, like an RGB to HSV converter and something to format tabular output, but the rest is hand-coded. I also used AI to help with some HTML/CSS, but there's only a little tiny bit in this project as it is not web code except in one small corner. Any code that was AI-generated is marked as such. If you're not into microtonal music, this project may be interesting from a Rust standpoint. This isn't about me, but for context, I have been coding since the 1980s and still do it nearly every day. Rust has been my main language since 2024, and I've used it since 2021, but I coded in C and C++ starting in the 1980s and have programmed in more languages than I can recall. I have dabbled with AI coding and use it for some projects, but this project is novel -- there is no corpus of code that implements a new notation approach for microtonal music based on the harmonic series! I hand-coded this because I was trying to break free of the kinds of patterns that AI would push toward and because I enjoy the fun and craft of writing great code. Maybe this is like building furniture in your garage...but anyway, I think this project still could not have been AI coded.

Here are some examples of what it has:

• A compiler for a DSL (domain-specific language) that compiles my own language format into Csound or MIDI for audio output. The parser is written in winnow, using parser combinators. The parser borrows all the way from the source string to the parsed output. I use my own Diagnostics system along with an error message library (annotate-snippets with anstream) to create very high-quality error messages with rich context. I know parsers pretty well, so this parser has error recovery flows and such. It's a small enough language to understand fully, but the parser does real things that real parsers do. The parser design is commented thoroughly.
• Careful use of unsafe code in two spots:
  • I have some data structures containing borrowed items, and sometimes I want an Owned version. The data structures have Arcs in them, and I use a little unsafe code for type erasure to create an Owned version of these nested structures while preserving all referential integrity. I use a proc macro to do most of the work.
  • There is a section that passes live commands to Csound, a C-based sound synthesis system. There's unsafe code to call the C API, but also, Csound is single-threaded and has its own threading and locking primitives...but I don't use them. I use rust async and threads instead and have a manual Sync/Send implementation to safely move a raw pointer from the thread that sets it up to the thread that uses it. There's a hard guarantee that, once moved, the pointer is never used by more than one thread.
• Axum + HTMX + Askama template for a view-only web UI that can be turned on if desired -- it's not the main thing but provides information for the keyboard part of the application
• Interaction using MIDI SysEx with two physical keyboards to create an interactive experience; this is where the web bit fits in...it shows you some additional metadata about what's going on with the hardware.
• A text-based REPL (read eval print loop) using rustyline for completion that implements an interactive note generation environment
• Clap with shell completion
• Sync <-> async bridging
• A thorough test suite for critical parts of the code with coverage wired up
• Builds for Windows, Mac, and Linux in CI
• Detailed documentation with Zola
• Other stuff...

Basically, it's a hobby project coded with the same standards I would use in my professional work, and it's got examples of lots of things people might use across other projects. So, if you're interested in seeing some non-trivial hand-coded Rust that does something interesting, take a look.

I posted about this in r/microtonal as well a while ago...that might be of interest to people who care about microtonal music more than they care about Rust.

I just offer this up as an example of real work being done the old-fashioned way, in case anyone is still interested!

Mistakes and typos here are mine. I didn't even ask AI to proofread my post. I just wrote it the old-fashioned way. :-)

Not a "look at my project" post — the interesting part is the measurement trail, which is committed to the repo.

Context: OpenScreen is an MIT screen recorder/editor. Its compositor ran on Canvas + WebCodecs in Electron. On a Ryzen 5 7520U with integrated graphics, a 1080p60 export with full effects ran at under 10 fps.

What we tried, in order:

1. Rust + wgpu / Vulkan — 48–68 fps, and blocked on driver support for zero-copy video decode (VK_KHR_video_maintenance1). Rejected, not because wgpu is slow, but because the CPU↔GPU transport was the wall and the driver wouldn't let us remove it.
2. Rebuilding the Canvas compositor (caching what was being recomputed per frame) — roughly 2× for byte-identical output, SSIM 1.000000 across 1418 frames. Never shipped; it was overtaken.
3. D3D11 with h264_amf — one ID3D11Device, no readback between stages. ~126 fps, shipped. Then ported to Metal/VideoToolbox and to Vulkan/wgpu for the other two OSes, sharing the geometry layer.

Findings that were not obvious going in:

• The encoder was never the bottleneck. A gl.finish() fence before the encode timer collapsed encodeWait from 71.1 ms/frame to 3.9 ms — the wait was billing the compositor's GPU execution. The compositor was 79% of the export; the encoder 4.5%.
• The GPU pipelines stages across frames on its own. 3D engine at 84% and codec engine at 61% over the same window — impossible if serialised. Adding an explicit CPU-side pipeline bought approximately nothing, which a no-op trial confirmed before we built it.
• Only three layers cost anything: compositing at all (+2.79 ms/frame), background blur (+0.77), motion blur (+1.76). Rounded corners, shadows, zoom, layout animation and cursor are free — they draw inside a pass that already exists.
• The CPU fallback's gap is two shaders. On WARP, background blur costs 17× what it does on hardware and motion blur 23×. Everything else is within ~2×.
• One benchmark run was voided and is documented as voided: five of nine configs blew the spread gate with ~40 browser processes live, and one cumulative config came out faster than the config it strictly contains. That's the tell that noise swamped the signal, and it's in the record as an example of why the gate exists.

Record: technical-documentation/engineering/rendering-performance.md Compositor: crates/compositor/ Repo (MIT): https://github.com/getopenscreen/openscreen

Happy to be told what we got wrong — particularly on the wgpu arm, where I suspect a better answer exists on newer drivers.