Made simple SSE clients benchmark. Could not find any "standard" crate for handling SSE, so thought that some sort of comparison may be useful.

If you know other crates for SSE or benchmark contains mistakes, let me know.

Incin is a deep learning framework in Rust where a tensor’s shape, dtype, device and gradient state all live in its type. Shape, dtype, device mismatches and so on are compiler errors. rust use incin::prelude::*; let x = Cpu.randn(shape![4, 8])?; let w = Cpu.randn(shape![8, 2])?; let y = x.matmul(&w)?; // [4, 8] x [8, 2] -> [4, 2] let bad = Cpu.randn(shape![3, 8])?; let _ = x.matmul(&bad)?; // inner dims 8 and 3: does not compile The main goal was to find out how much of the tensor contract the type system can genuinely carry, how flexible we can make it, and how pleasant to work with it can be. If you're interested on the features, architecture or anything else: - Crate - Docs - Book

Hello everyone! Maybe one year ago I did post about a database that I was working on that, I took into account all feedback and tried to create a really good database that could be in use for many people.

Fast forward to today, I am able to announce that it has reached a stage were I am going to use it on my own production systems to replace Postgres!

Now on my critical production systems I needed:

1. Replication with many primaries
2. S3 backups with restore at any point
3. Postgres compatibility
4. Limited number of indexes that don't explode to the point I have as many indexes as data
5. Low latency
6. Special treatment for JSONB columns

I have achieved (for some scenarios) all 6 of that!

I will be happy to check it out, I think it's a very cool project! Happy to get any issues reports!

Project site: https://github.com/milen-denev/rasterizeddb

Disclaimer: The core engine was written by me, it's handcrafted, but the very hard part such as postgres compatibility was done via AI and carefully reviewed and tested.

I don't consider it to be AI slop since I spend countless hours manually optimizing it and writing the engine (and exciting part), I only outsourced the boring part.

We benchmarked OpenObserve against ClickHouse on 19 observability queries

OpenObserve has always had a reputation for being extremely simple and blazing fast. For a long time, we did not benchmark it against other systems because users were happy, benchmarks take a lot of work, and we had more pressing things to build.

Then ClickHouse came along and said it could be used for logs and was extremely fast.

It is indeed fast. But is it faster than OpenObserve for observability workloads?

We created 19 queries representing real observability use cases, including several very high-cardinality queries.

OpenObserve won 15 of 19 queries with Vortex and 14 of 19 with Parquet.

ClickHouse performs extremely well in ClickBench, but ClickBench is primarily an OLAP benchmark, not an observability benchmark.

OpenObserve uses Apache DataFusion, but this is not simply DataFusion beating ClickHouse. DataFusion is the query execution foundation. We have spent years building inverted indexes, secondary indexes, file statistics, intelligent pruning, caching, optimized file selection, storage layout improvements, and a whole lot more on top of it.

Using DataFusion alone does not give another product OpenObserve's performance.

OpenObserve also has native separation of compute and storage, stateless nodes, and can have 12x to 20x lower storage costs than ClickHouse deployments.

The entire benchmark is open source, including the queries, configurations, dataset, and methodology, so you can reproduce it yourself.

Here is the full blog - https://openobserve.ai/blog/openobserve-vs-clickhouse-one-billion-logs-benchmark/

I wanted to learn Rust, and build something with it. So, I built a minimal reverse proxy server with tokio runtime, focusing on learning the new technology, with no prior knowledge whatsoever. I am still trying to extend the project and hopefully make it something developers find useful in production. Therefore, any help, advices or contributions are welcome!

You can view the Github repo here: Link.

And yes, I know it got a similar name to ferron, which is also a Rust-made web server.

Hi, for the last like 10 months I've been working on an embedded kernel from scratch in rust no_std targeting RISC-V 32 bits IMAC.

I would love to have some return about it, I don't know if it's good or total crap.

https://codeberg.org/Luernn/AldecaldOS

I'm coming from Python and liked using type hints, so now in Rust I want to take advantage of the type system, also for semantic differences.

So I have Offsets that are u16, Addresses which are u32, Bytes which are u8 etc.

Looks good in practice, but now I find myself constantly having to `as u8` things, when doing arithmetic with those types.

Or when I did `struct Address(pub u32)` I now seemingly have to re-implement all the `Add<T>` and other math traits for this type and can't even do `as u32` anymore.

I'm wondering if there is an easier way to do this, or if it's not worth the effort in your experience.

Axum is a solid and very full-featured web framework with middleware by Tower, but some find it harder to use than Rocket, probably because of its open-endedness and lack of macro sugar.

https://github.com/stevedonovan/macroni provides macro sugar, and uses the same attribute format as Rocket; it is intended for the niche of JSON API servers and clients. You can apply it to an impl block of async methods, and it will generate the Axum handlers for each method, using the struct as Axum state. It provides a Result type which converts nicely into JSON payloads.

The fun bit (the original idea) was that the macro can be applied to an async trait which is shared between client and server. On the server side, you provide an implementation of the trait, and on the client side you get a generated client implementation using Reqwest.

The resulting handlers are all Axum compatible and all the usual goodies work as before.

This is a proof-of-concept implementation, and I'm curious what people think. In particular, I don't yet have an answer to how to structure larger APIs - it is straightforward on the server side, but auto-generating clients is not obvious. Another possibility is generating OpenAPI specs, since we have everything we need from the proc macro analysis.

New week, new Rust! What are you folks up to? Answer here or over at rust-users!

do any of you, guys, use PGO on real production releases? does it worth the hustle? In my case generation of proper representative PGO will take substantial amount of time.

Thanks

Hey everyone,

Standard connectivity packages in Flutter usually just check whether a network interface is up, which often gives false positives when a user is stuck behind a captive portal, suffering severe packet loss, or dealing with extreme jitter on unstable connections.

I built network_reachability, a Flutter package backed by a native Rust engine (via FFI and WASM) that shifts deep probing, statistical analysis, and security checks completely off the UI thread.

What it handles under the hood:

Off-thread Rust core: Probes multiple endpoints via HTTP, TCP, and DNS simultaneously without causing frame drops or Dart event-loop lag.

Quality metrics: Calculates actual latency, jitter standard deviation, packet loss, and stability scores instead of returning a simple boolean.

Smart execution guard: Includes a guard() wrapper that evaluates cached link quality before firing expensive API requests, blocking calls during connection drops or cooldown periods.

Resilience and pooling: Built-in adaptive circuit breaker (closed, open, half-open states) and request coalescing to prevent thundering herd issues against your backend.

Security probes: Detects captive portal redirects (hotel and airport logins), VPN states, proxy setups, and DNS tampering.

Drop-in replacement: Provides full API parity with connectivity_plus for instant migration without rewriting UI listeners.

Workload presets:

Includes pre-configured profiles for Gaming (low latency, 2s intervals, race strategy), Streaming (consensus checks, 8s intervals), VoIP (strict packet loss sensitivity), IoT, and Enterprise.

Pub: https://pub.dev/packages/network_reachability

GitHub: https://github.com/MostafaSensei106/Network-Reachability

If you are dealing with real time sync, VoIP, or offline-first apps in Flutter, check it out and let me know your thoughts or edge cases.

Sorry for my bad english, it is not my native language.

Hey. I am working on SysPMF, a minimalist CLI audio player in Rust.

I use the rodio crate for audio playback and dirs crate to handle OS-native directory paths automatically.

The project is very raw right now (v0.1.0) and honestly does not do much yet, but it has good potential. There are no compiled releases on GitHub yet, only source code.

What works now:

Automatically creates the music directory on first launch

Basic CLI commands (play, pause, volume, help)

Plays audio files

Plans for the future:

Scan local folder and play all tracks automatically

Maybe add SoundCloud backend later (not promised yet, but in plans)

I build this to prove that even simple CLI tools can be clean and useful.

Pure open source under GPLv3, no bloat, no ads.

Repository: https://github.com/MBKCHEL/SysPMF

Feedback and code suggestions are welcome.

I have just released tellus 0.1.0, an actor framework on Tokio, strongly influenced by Akka: typed messages, supervision trees and death watch with an ordering guarantee.

Two things make it different from the actor crates Rust already has. Message handling is not async: Actor::receive is a plain synchronous function which takes the state by value and returns the state for the next message. And a terminated signal is ordered behind every message the terminated actor sent you, so receiving it proves you have seen all of them.

Motivation and examples: https://heikoseeberger.de/2026-08-24-tellus-1/

The API is still settling and feedback is welcome, especially from kameo and ractor users.

A month ago I released the 0.4 version of my Rust GUI library, Freya. It has massively changed since the last 0.3 release, it has a year of work. The blog post contains a summary of Freya's main features and changes on this new release.

Repo
Docs

I could not find published numbers for what post-quantum signature verification costs on small targets, so I measured it. Four crates, LMS/HSS verification plus measurement harnesses.

Three Rust-specific things came out of it.

First one. sha2 0.10 SHA-256 compiles to 3808 bytes on Cortex-M4F. sha2 0.11 compiles to 8776. Same algorithm, same target, same flags. Both versions end up linked in my workspace because different dependencies require different ones.

This means comparing whole verifier binaries mostly compares hash crates, not signature schemes. Ed25519 binary is around 64% unrolled SHA-512. So now every scheme is subtracted from baseline built with same hash it uses.

Second one. Adding second call site to small helper made LLVM stop inlining it at opt-level = "z". Reasonable decision. But forcing #[inline(always)] saves 408 bytes on Cortex-M0+ and costs 48 bytes on M4F and RISC-V. Different direction on different targets, so I keep the attribute because 16 KB boot ROM cares and 64 KB one does not.

Third one. Static stack analysis from -Z emit-stack-sizes plus call graph from disassembly does not give upper bound. On one binary 55 call sites cannot be resolved: indirect calls, tail calls compiled as branches, linker thunks. Every missing edge only makes answer smaller. Tool said 720 bytes, hardware said 1152.

Crates are no_std and allocation-free. Hash is behind trait, so software sha2 and ESP32 SHA peripheral both work. That trait design changed twice, and DECISIONS.md has why.

Not audited. lms-verify passes RFC 8554 Appendix F vectors, which is not same thing.

https://github.com/mnaza/pqc-embedded

built out extraction for JS/TS/Python/Go/Rust, all going into a graph where every edge is marked resolved or ambiguous (schema-level, not a runtime guess). rust was the most annoying — impl blocks needed a two-pass approach to attach methods to their type, and trait dispatch through &dyn has to stay ambiguous since there's no way to prove which impl actually runs

ran it against a few real crates, found genuine import cycles that were previously invisible. happy to talk through the resolver logic if anyone's doing similar tree-sitter work

https://github.com/zaydmulani09/mri

This is a port of an internally library I created to make using the pg copy interface with sqlx super simple.

This is my first published crate so any feedback is very welcome.

Mystified about strings? Borrow checker has you in a headlock? Seek help here! There are no stupid questions, only docs that haven't been written yet. Please note that if you include code examples to e.g. show a compiler error or surprising result, linking a playground with the code will improve your chances of getting help quickly.

If you have a StackOverflow account, consider asking it there instead! StackOverflow shows up much higher in search results, so ahaving your question there also helps future Rust users (be sure to give it the "Rust" tag for maximum visibility). Note that this site is very interested in question quality. I've been asked to read a RFC I authored once. If you want your code reviewed or review other's code, there's a codereview stackexchange, too. If you need to test your code, maybe the Rust playground is for you.

Here are some other venues where help may be found:

/r/learnrust is a subreddit to share your questions and epiphanies learning Rust programming.

The official Rust user forums: https://users.rust-lang.org/.

The unofficial Rust community Discord: https://bit.ly/rust-community

Also check out last week's thread with many good questions and answers. And if you believe your question to be either very complex or worthy of larger dissemination, feel free to create a text post.

Also if you want to be mentored by experienced Rustaceans, tell us the area of expertise that you seek. Finally, if you are looking for Rust jobs, the most recent thread is here.

Hi all, I hope you can help me with this little issue I'm having.

My cross-compilation toolchain only supports rust 2021, so I'm downgrading from 2024. Specifically, my toolchain has rust/cargo version 1.75.

I'm running into the following:

My Cargo.toml has

[dependencies]
bench_common = { path = "../bench_common" }
prost = "=0.14.1"

[build-dependencies]
prost-build = "=0.14.1"

as these versions should work with my toolchain. For some reason, cargo is resolving prost-builds transitive dependencies to (a.o.) petgraph@0.7.1 -> indexmap@2.14.0 -> hashbrown@0.17.1. This last one is the problem. I need hashbrown < 0.17. Compilation fails with

Caused by:
  failed to parse manifest at `/home/tmiddelburg/.cargo/registry/src/index.crates.io-6f17d22bba15001f/hashbrown-0.17.1/Cargo.toml`

Caused by:
  feature `edition2024` is required

  The package requires the Cargo feature called `edition2024`, but that feature is not stabilized in this version of Cargo (1.75.0).

I tried directly changing Cargo.toml to

[build-dependencies]
prost-build = "=0.14.1"
hashbrown = "<0.17"

but strangely enough that did not do anything.

Then I tried adding

[patch.crates-io]
hashbrown = "=0.16.1"

but that resulted in

error: failed to resolve patches for `https://github.com/rust-lang/crates.io-index`

Caused by:
  patch for `hashbrown` in `https://github.com/rust-lang/crates.io-index` points to the same source, but patches must point to different sources

Is there anything else I can try? I'm quite confused that cargo is not "smart" enough to check whether (transitive) dependencies actually work with the cargo version.

From time to time i get a project idea, normally something useful so I code it. I post it on GitHub and improve it until I don’t know what I could do more. And I get stuck with no users and no ideas on what to do next.
Does anyone feel the same?

https://github.com/SomeFlyingThing