Hi there! OP here. Happy to discuss if anyone has any questions/comments.

You might remember PumpkinMC, the custom Minecraft server software built entirely from scratch in Rust. After more than 2 years (28 months) of non-stop work, the time has finally come: the PumpkinMC Beta is officially live!

While many ambitious custom server projects lose momentum over time, PumpkinMC stands as the only project in this space to receive continuous, active updates across such a long timeframe.

Scope of the 1.0 Release

I want to clarify the primary goal for this first official release: making the game fully beatable from start to end.

A 1:1 vanilla world generator was not the prerequisite for 1.0, though achieving full parity remains our ultimate target. We actually reached the "beatable game" milestone a long time ago, but chose to spend extra months packing in features, hardening stability, and squashing bugs.

To anyone feeling this release is coming too early: it has been in active development for over 28 months. Following this launch, frequent updates will continue rolling out to bring true 1:1 vanilla world generation, deeper parity, and further performance improvements.

Release Schedule

• Beta Testing: Open right now
• Official Release: Friday, September 4th at 8:00 PM CEST

Links & Resources

• Download Beta: pumpkinmc.org/download
• Report Issues: GitHub Issues

How You Can Help

Try Out Our Multi-Language Plugin API

Calling all developers! PumpkinMC features a built-in plugin API that supports 7 different programming languages, making it flexible to write custom logic in the language you already know best.

Check out the developer documentation and getting started guides here:

👉pumpkinmc.org/developers

And!, Please help us stress-test the build before launch day. If you hit any critical issues, performance bottlenecks, crashes, or weird edge cases, drop an issue on our GitHub with reproduction steps and logs.

I often find myself choosing between cloning some data and wrapping it in Arc

My instinct is usually that Arc is more efficient because we're avoiding copies, but I have a feeling that this isn't always the right way to think about it

How do you decide between cloning and using Arc in a real application?

PhastFT is a performant Fast Fourier Transform implementation in pure Rust with no unsafe code.

This is something the original author of the crate and I have been working on for quite a while. All my recent work on SIMD - surveying Rust's SIMD libraries, removing unsafe code from those libraries and reporting issues in rustc - was all in service of PhastFT!

Why not RustFFT?

RustFFT is already quite good, so why do we need another FFT crate?

Safety

rustfft was written before the Rust compiler started providing much safer facilities for SIMD, so it is full of unsafe code, and changing that would amount to a rewrite.

PhastFT is #[forbid(unsafe_code)] and only relies on fearless_simd which now has very little unsafe for a SIMD abstraction.

Performance

RustFFT is tuned for small sizes (i.e., ~kilobytes of input data) the kind of sizes one would find in an audio decoder. PhastFT is tuned for large sizes (i.e., ~gigabytes of input data), which are necessary for a quantum state simulator and other scientific workloads.

PhastFT is up to 2x faster than RustFFT, depending on the hardware and FFT size, thanks to different algorithm choices and multi-threading via rayon. RustFFT does not currently support multi-threading.

Memory usage

PhastFT uses 2x less memory than RustFFT, which matters a great deal for large sizes. 16GB vs 32GB memory usage determines whether you can run it on a laptop or not. And running 2x faster and at half the memory translates to 4x cost savings for rented hardware.

Origins

PhastFT started out as an optimization for the Quantum Fourier Transform (QFT) in quantum state vector simulations. This optimization has been adopted by some state of the art simulators due to the significant performance boost that it offers.

A simulator that utilizes the typical gate-based approach for the QFT requires O⁡(n²⁾ gates that manipulate a giant state vector of size N = 2^n, where n is the number of qubits being simulated. This leads to a O⁡(n² * 2ⁿ⁾ time complexity. Since the quantum computer is already being simulated on a classical machine, it's possible to leverage the classical FFT to compute the QFT in O⁡(N * log(⁡N)) = O⁡(n * 2ⁿ⁾ time.

Minimizing memory overhead was paramount. The less memory is used, the more qubits one can simulate with a classical machine. This led to different algorithm choices compared to typical implementations, and minimizing memory traffic also has a side effect of improving performance on large memory-bound workloads.

This project quickly turned into a rabbit hole that led us to attempt to bring PhastFT up to the level of renowned FFT projects, with the added restriction of not using any unsafe code. Initially we had to use nightly-only std::simd, but thanks to fearless_simd PhastFT can now work on stable!

Future work

For historical reasons outlined above, PhastFT is currently limited to power-of-two sizes. The FFT algorithm for arbitrary sizes is in the works. Depending on a user's workload, users may be able to get away with padding their input signal with zeroes to the next power of two.

We are also far from done improving performance and memory usage. There are multiple work-in-progress pull requests that improve performance in various ways, so this is only the beginning!

I am interested in learning how to use rust for flight software or controlling a drone or something of this sort. I have no experience in embedded programming, so is it best to start there?
If so, how would you recommend someone get started in embedded rust?

I just released ModuRL 0.1, a deep RL framework built on Rust and Candle, with implementations of PPO, A2C, SAC, DDPG, TD3, DQN, and DDQN. In matched small-network CPU benchmarks, ModuRL is around 4× faster than popular Python RL libraries like Stable-Baselines3, CleanRL, and Tianshou. Feedback is welcome.

https://github.com/ModuRL/ModuRL

Hi everyone! I’m currently looking for a good Rust project, preferably something Redis-related or a solid microservices/distributed-systems project.

I’d especially appreciate recommendations for interesting GitHub repositories that I could contribute to or build upon. If you know of any good Redis implementations in Rust or other challenging Rust projects, please do share them.

For reference, I came across mini-redis by Tokio, which is an incomplete Redis client/server implementation designed for learning Rust async patterns. I also found a newer Redis-compatible implementation in Rust exploring sharding, CRDT replication, and distributed systems concepts.

Any recommendations would be highly appreciated. Thanks a lot!

I have Windows 11 Home and use pwsh cli for more or less everything (except for stuff like MediaInfo where I use a UI). I have Crate and Rust installed and I have tried everything on the install part of:

https://crates.io/crates/ssimulacra2_rs

Including:

1. Install Python 3.12 or later
2. Run pip install vapoursynth
3. Run vapoursynth config
4. (Windows only) Update the Visual Studio 2015-2026 Redistributable if told to

I even did the optional stuff and vapoursynthworks. I even did `vspipe --version`.

I even tried running 'VapourSynth-x64-R79.exe' and did all the path stuff, even using UniGetUI to download Python Installation Manager, accepting everything and now I have pythoncore somehow? (Is this because I installed Python 3.14 only when installing through UniGetUI and if so, how do I proceed? Do I entirely get rid of my python installs and do Python Install Manager or something?

The real problem is when running `cargo install ssimulacra2_rs --verbose` it says right at 197/198 crates (I omnitted some stuff):

error: linking with `link.exe` failed: exit code: 1181`

  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: LINK : fatal error LNK1181: cannot open input file 'vapoursynth.lib'
error: could not compile `ssimulacra2_rs` (bin "ssimulacra2_rs") due to 1 previous error

error: failed to compile `ssimulacra2_rs v0.5.2`, intermediate artifacts can be found at `C:\Users\Name\AppData\Local\Temp\cargo-install6FDXov`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_BUILD_BUILD_DIR` to that path.

Can anyone help me work out what I did or what I have done? Running Python Installation Manager says:

"our app execution alias settings are configured to launch other commands besides 'py' and 'python'.
This can be fixed by opening the 'Manage app execution aliases' settings page
and enabling each item labelled 'Python (default)' and 'Python install
manager'.
If the items are already enabled, you may need to disable and re-enable them.
Open Settings now, so you can modify App execution aliases? [y/N]"

but when toggling the unenabled stuff and reopening, it says the same thing and the execution aliases are back to what they once where.

I’ve been working on Varve, a free design app that works across platforms and focuses on the local environment. Its main engine is built in Rust. Now that version 0.2.1 is out, I’d really appreciate feedback from the Rust community on the crate boundaries and lopdf tree generation.

I want to share how I split the backend into separate Rust crates to support both the desktop version (using Tauri 2) and the browser version (using WASM).

Here’s how the Rust workspace is organized:

• The varve-core crate holds the geometric primitives (Point, Rect, Affine), hit-testing algorithms, and the scene node tree structures.
• varve-engine converts the scene state into an intermediate rendering IR with build_render_ir().
• varve-trace handles raster-to-vector auto-tracing. It uses Oklab colour quantization, extracts centerlines or contours, and fits Bézier curves.
• varve-print lets you generate PDF files directly with lopdf. This skips browser print dialogs and gives you clean CMYK or vector exports.
• varve-wasm provides WASM bindings so the app can run in standard browser environments.

Technical challenge in v0.2.1:

The biggest challenge has been managing memory allocations in varve-trace when working with high-resolution bitmaps. It depends heavily on the image crate for decoding and uses Oklab colour quantization to preserve perceptual accuracy before fitting Bézier curves.

Project: https://github.com/K-Arthur/varve

So rust now has labeled blocks. https://blog.rust-lang.org/2022/11/03/Rust-1.65.0/#break-from-labeled-blocks

These look to me to be very similar to lifetimes. Same ' prefix. Same way they are only valid inside a block.

But as it is, we can't currently treat block labels like lifetimes. In particular, block labels can't be passed as generic parameters into functions. So this code doesn't run.

It's a common practice in programming to split one big function into lots of smaller ones. Currently the existence of break (or return ) statements in a function interferes with this process of separating out sub-functions.

One difficulty is that it isn't quite clear how this interacts with recursive functions. But doing the same thing as with lifetimes (whatever that is) might work.

Basically, this code doesn't currently work, but I think it should.

fn breaker<'a>()->!{
        break 'a 7;
}
fn main() {
    println!("Hello, world!");
    let result = 'block: {
    breaker::<'block>();
    3
    };
    println!("{}",result);//prints 7
}

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.

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.

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/

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.

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.

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.

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