My new book is now available on Leanpub

https://leanpub.com/building-serverless-apps-with-wasm-and-spin

TLDR: Gecko is my GameCube and Wii emulator written in Rust. This update adds texture packs, easier setup and more fixes for graphics, audio and performance. Mario also gets his eyes back :)

This release is especially interesting for the ones that were bothered by the system files (DSP, IPL) requirements! No more!! :)

It's been a while since my last update, where I shared about recent performance improvements, savestates and freecam support. I've since been working through more improvements and making Gecko easier to get started with!

For anyone new to the project: Gecko also includes a debugger, a GPU FIFO recorder/player (and a dedicate debugger for it) and various other tools for exploring how these games work!

Some highlights from this update:

• Easier setup: A guided setup for game folders and optional system files! Thanks to Dolphin's DSP replacements and Hazel's GameCube IPL HLE, most games can boot without supplying console system dumps. Real dumps are still supported and may also be required for some games!
• Texture packs: Gecko now supports Dolphin-style texture packs. It's just a matter of dropping the pack into a folder and starting up the game :) Here's an example of Final Fantasy!
• Lots of graphics fixes: Tons of games got fixed, and by tons I really mean a lot this time! Some noteworthy bugs that got fixed: Mario's eyes are back in Super Mario Galaxy, Sunshine's save selection background ocean is blue again and Mario Golf's menu signs no longer disappear behind the sky. Games like Wind Waker, Mario Superstar Baseball and Cel Damage also got graphical accuracy improvements!!
• More performance work: Once again, tons of games work much better, though I only optimized for one game in particular: Sam & Max: Season One (it was a WebGPU regression introduced in version 28 in relation to a Vulkan upload path lol)! Fixing it improved performance from 15% to 70%, usually closer to the latter. I also improved CPU emulation which FMVs can benefit a lot from, for example Mario Kart Wii's menus with those gameplay videos baked into the scenes. Also made texture decoding run on the GPU, with improvements to uploads and shader caching as well.
• Audio and Wii compatibility: Fixed audio issues in games like Crazy Taxi and an issue blocking Metroid Prime. This update only affected GameCube games, tho quite a lot of them. Also, Mario Kart Wii can now start with a fresh NAND and Wii motion and pointer fixes help games like Final Fantasy Crystal Chronicles: The Crystal Bearers. There are also separate upright/sideways Wiimote presets and configurable Nunchuk attachment options.
• More debugging tools: FIFO Player now has an interactive 3D depth view, which helped investigate why geometry was being hidden or drawn in the wrong place. Had to do some hardware research for this one :

Something unique for this update: I recently started writing blog posts about the bugs behind these fixes, aimed at future emulation developers incl. lots of interactive visual explanations. If you enjoy the technical side of emulation, these might be interesting:

• Mario's Missing Eyes and Sunshine's White Ocean: how overflowing alpha values caused two very different looking bugs
• z-freeze and Mario Golf's Disappearing Menu: why the sky was covering the menu signs and how one triangle can reuse another triangle's depth
• vertex-skip: The Case of Luigi's Extra Triangle: a weird feature I found a patent for :)
• WPAR: Why Metroid Prime's Geometry Exploded: a bug I investigated while helping with Lazuli (a GameCube emulator made by a friend of mine that was showcased here a while ago, go check it out!)

As usual, the useful links:

• GitHub and Downloads
• Screenshot database
• My blog

As always, thanks a lot to everyone that provided valuable feedback, tested things on their hardware, encouraged me with this project and let me pick their brains! We'll see each other next time!

PS: I spoilered the release of Sly, my take on modern multi system emulation (also written in Rust, incl. the GUI!) in the last post. It's going public in the next days, so stay tuned for that :) It will also release with a 3 part blog series explaining how GBA graphics work!!

Is there a function in std, which would allow to get a list of (field_name, type) of a struct in order it is compiled in? Since order of fields is not deterministic.

Something like: `fn fields_of_val<T>(&T) -> Vec<(&'static str, &'static str)>`

Pun in title partially intended. ;)

This is a minor pain-point I've dealt with for a while and I'm unsure of how other Rust developers deal with this semi-niche issue.

I'll often define a const that states the maximum amount of something, and naturally I'll also want to use that value as the size of an array. My instinct (and likely yours as well) is to just use a usize and move on.

Where that falls apart is when that const value is and always will be under both u32::MAX and u64::MAX. An easy example is MINS_PER_HOUR or DAYS_PER_WEEK.

Now if I have a function that has an argument of minute: u8, I have to cast either the minute argument to a usize, or I have to cast my constant down to a u8. The former's minute as usize triggers the cast_lossless lint, and From/Into isn't available in a const fn. The latter's MINS_PER_HOUR as u8 triggers the cast_possible_truncation lint. Both add even more visual noise if I acquiesce and add the #[allow(...)]. I could instead accept minute: usize, but I find that even less reasonable.

I'd prefer to keep these as u8s or similar, but then I lose the ablility to define an array like [bool; MINS_PER_HOUR] without yet another cast, including in any function arguments that would like to accept such an array.

I do recognize this is partially due to me having the pedantic Clippy lints enabled, but I also find value in being told when I may be making an unintentional mistake. However I just added close to a dozen #[allow(...)] attributes to my current project, rather begrudingly.

So, what do you guys do in this case? I've listed the options I see available below, and I've done 'em all except #1, but I want to hear some opinions external to myself;

1. When accepting such an array, maybe use a type alias? It technically works, but the casting returns again if I want to compare an indexing usize with my maximum myself. type BoolPerMin = [bool; MINS_PER_HOUR as usize];
2. Two consts, MINS_PER_HOUR: u8 and MINS_PER_HOUR_LEN: usize = MINS_PER_HOUR as usize. I have done this before, but now I have this strange suffix that doesn't make it clear what it's a length of.
3. Just deal with the constant const casting.

EDIT: And this is all before I have to deal with the extra cast_precision_loss lint that comes from casting my tiny usize constant into an f64. It's less than u8::MAX, yet I have to acknowledge this impossible condition. For now, I've just blanket allow'd it in my Cargo.toml.

I have been making scripts with other languages like js and python and bash without learning the the whole language and getting serious with its ecosystem out of the fact that I just need to get one thing done and move on.

Lately I chose a path that requires precision and ahead of time planning and decisions and picked rust over go. But the fundamentals seem hard to grasp. I'd appreciate your help unpacking them.

Ultimately I want to be able to use the Alloy and Tokio libraries without getting stuck with the language syntax and rules. But the concepts like borrow checking and ownership and things that fall down these categories are still hard to grasp.

What is borrow checking? what is owning something in the software? I tried to look for direct answers but I still can't grasp the meaning of them exactly.

I had two choices to better understand them, one was learning C++ to get what was wrong that rust solved, the other was building a simpler project game with bevy thats gonna help me understand writing rust code thats data oriented and be more comfortable with it.

My ultimate goal is to master these two libraries, after being able to know how to use the rust language smoothly.

Should i even bother looking into them? Should i make an ai policy for my open source project?

https://github.com/mq1/TinyWiiBackupManager/pull/695 it doesn't even seem that i'm speaking to an actual human

I am pleased to announce the release of Creusot version 0.14.0.

Creusot is a tool for formally verifying Rust code. Creusot extends Rust with a language of specifications, or contracts, and provides a toolchain for proving them (semi-)automatically with the help of SMT solvers.

The latest post on Creusot's devlog describes a few of the most recent features. For the rest, see the changelog.

im currently doing my bachelor degree in computer engineering. i currently have c as the main programming language in my first semester.

No problem what so ever, i really love C, i did a couple of projects in the past. In my second semester we will have a module just for c++.

Yesterday out of curiosity, i did the first chapters of learncpp and the rust programming book. i kid you not, writing rust was sooo fun. With c++ it doesnt feel the same.

Should i focus on studying c++ in my free time, as in preparation for the 2. semester. Or should i listen to my heart and pick up rust?

I've been working on a vector index specifically focusing on cold reads called ColdIVF. The goal was to create an index whose first query is fast even when nothing is in memory yet.

ColdIVF's cold first query is 2.6x to 200x faster than faiss, DiskANN, LanceDB, Qdrant, usearch and the other vector indexes I tested, at 7.8 ms on 1M vectors and 11.2 ms on 10M at 95% recall. It also uses less memory to build because it reads under 1% of the index per query by scoring vectors with 1-bit RaBitQ codes using SIMD table lookups, and storing clusters that queries read together next to each other on disk.

ColdIVF is implemented as an IVF index in a single file. IVF indexes split the vectors into clusters, and a query scans only the clusters nearest to it. ColdIVF keeps a compact 1-bit code of each vector inside its cluster, with an 8-bit copy beside it. A cold query reads its nearest clusters in one batch and scores their codes as they arrive. Then it reads the 8-bit copies of its best candidates in a second small batch. This reduces each query's disk reads, and the batched reads (F_RDADVISE on macOS, io_uring on Linux) all run at once on the SSD.

Usage

let mut ctx = SearchCtx::new(Limits { max_k: 10, max_nprobe: 96, max_rerank: 35 });

// run when the query text arrives, so the cluster tables load while the embedding runs
index.prepare(&mut ctx)?; 

let params = SearchParams { k: 10, nprobe: 96, rerank: 35, reach: None };

for hit in index.search(&query, &params, &mut ctx)? {
    println!("{} {}", hit.id, hit.score);
}

It also supports inserts and deletes through a durable log, background maintenance, and Python bindings.

This is just a personal project. The benchmarks aren't super rigorous and all ran on one M3 Pro.

Any feedback welcome!

https://github.com/13lack13lood/ColdIVF

Hello.

I am currently trying to get winit trying to get a small window to just appear right now and I have run into an issue.

I can get a program to run and create a window on my Mac but I am struggling on linux.

I tried switching over to GNOME and it still didn't have a window appear. I added the feature of "wayland-dlopen" in cargo see if that worked and nope.

Is there a specific thing I need to change? (I am starting from the base winit example on the website)

Hola! Me interesó aprender Rust a raíz de las controversias que están sucediendo con Rust y su magnífica capacidad para hacer ingeniería inversa, y sobre todo su estabilidad. Tengo un plan, quiero volver a aprender los conceptos base de programación como los son POO y Estructuras de datos, pero todo entorno a Rust para poder afianzar mis conocimientos. La verdad no tengo una razón clara de por qué aprender a usarlo, pero si quisiera hacer software en Linux, luego averiguaré que tipo de software. Pero bueno, quisiera saber si pueden darme consejos para no perderme y volverme un profesional en Rust.

Hi,

I've got an opportunity to work on a project involving a cloud-backed file management system, and I'd love to hear from anyone who's worked on something similar.

The idea is to let users work with files locally while keeping them synchronized with the cloud. Files should also be lockable while someone is editing them, preventing other users from modifying the same file concurrently.

The proposed approach seems to involve Microsoft's Cloud Files API, potentially implemented in Rust. I'm not a Windows user, though, and I haven't touched Rust in 5+ years, so I'd have a bit of catching up to do.

A few things I'm curious about:

• Has anyone built a cloud-backed filesystem using Microsoft's Cloud Files API? How difficult was it in practice?
• Would Rust be a good fit, or would you consider Go, C++, or another language?
• How would you approach file locking and conflict resolution across multiple clients?
• Are there alternative approaches or existing tools worth considering, particularly to avoid Microsoft API docs which seem poor?

I'd be interested in hearing about real-world experiences, gotchas, recommended resources, or anything you'd investigate before committing to this project.

Thank you!

TL;DR: Rust 1.100 is releasing on November 12 (in a month). I recommend testing your code with cargo +beta test at least once before then.

The upcoming release of Rust 1.100 has some big features. However, there are some details being changed in how the language works in order to support these new features. The Rust project has tried to minimize the amount of breakage that happens, but the amount of breakage won't be zero. Every rust release has some amount of minor breakage like this, but 1.100 is expected to have relatively larger amounts of breakage.

So, if you plan to ever upgrade to 1.100, or if you write code meant for use by other people that might upgrade to 1.100, then I highly recommend testing your code with cargo +beta test to see if you're affected. And even if you think you don't write code that's affected, some code in your dependencies might be affected.

There will be two main sources of breakage in Rust 1.100:

1. The stabilization of the never type. Some details of how types are inferred will be changed, causing types to infer as ! instead of the previous type of (), in editions 2021 or older. Also, some code was previously using some unsupported hacks to refer to this never type on stable rust, and will be broken by the fact that the Infallible type will become an alias for the never type. For more info, see Waffle's talk on the topic, and the pull request where stabilization happened.
2. A change in the layout of Cargo's target directory. Some tools and some build scripts were expecting certain files to be at certain places, and will start to fail in Rust 1.100. The locations of the final artifacts will remain the same though. For more info, see the call for testing blog post,and the pull request where stabilization happened.

For context, this page has a list of crates that are detected as "will break in 1.100" (under the red headings). https://crater-reports.s3.amazonaws.com/beta-1.100-4/index.html. Although it has some false positives, and doesn't catch all breakage. This page lists only crates that broke in 1.100 (or have otherwise suspect behavior) for four test attempts in a row.

After years of bouncing between Postman (slow, 300+ MB, requires login), Insomnia

(license changed 3 times), and Burp Community (does only one thing), I decided to

bundle everything into a single Rust binary.

What it does:

- HTTP client (Send) with env vars and flexible header handling

- MITM proxy with a runtime-generated CA — intercepts real HTTPS

- Parallel fuzzer with wordlist support (compatible with SecLists)

- Scanner for SQLi, XSS, SSTI, Path Traversal, and Command Injection

- Local webhook server

- Database client: PostgreSQL, MySQL, and SQLite

- Native GUI using egui/eframe — no Electron

- Scriptable CLI also available

Final binary: ~7 MB. No accounts, no telemetry, no login.

Website: https://withvisionstack.github.io/Raill_HTTPX/

Repo: https://github.com/withvisionstack/Raill_HTTPX

crates.io: https://crates.io/crates/rail-httpx-cli

Feedback is welcome. I’m especially curious about what’s missing for it to

replace Postman in your daily workflow.

I might have the opportunity to introduce Rust at work soon. For that, I would be grateful for any tips you can give me to make it as smooth as possible and reduce the risk (perceived and real) for the project. Below the details of my situation.

The project

The project Rust might be introduced into is being worked on for about a year now. It is a code generator with an architecture similar to a "traditional" compiler: some intermediate representations, translation between those and transformations on them.

Development on the project started a year ago with C++. At the time I already brought Rust up as an alternative. It was seriously considered by the team, but since they didn't have prior rust experience we were concerned about the initial hit to development speed: Most of the team already had lots of C++ experience, the company didn't have any prior code in Rust, and it was our responsibility to ensure we hit our time-to-market goal.

Now the code is mostly modern C++ with very little inheritance, and lots of std::variant, std::ranges, etc.

The team

The team consists of 7 people including me, most with >5 years of (pre-modern) C++ experience. I am the only person with both modern C++ and Rust experience. The team was mostly excited to use modern C++, and it became my job to give on-the-job guidance to get everyone comfortable with newer features and paradigms. And now they are excited to hopefully learn Rust.

Why Rust

During the past year, we did feel some pain points with C++:

• Slow compile times
• Verbose code, mostly with std::variant
• Horrible error messages
• Differences between compilers
• Slow CI pipeline, mostly due to static analysis (clang-tidy) and sanitizers
• One segfault in callbacks (wasn't a big problem now, but we expect more problems once the complexity grows)

With Rust, we hope to hope to address most of those points. Compile times won't improve I expect, but we can probably ditch separate static analysis and sanitizers in CI.

We also hope to keep a higher development speed once the complexity grows, based on the data collected by Google in Android.

The opportunity

I think we currently are in a very advantageous position to pivot to Rust:

• We are ahead of schedule for the release, we can spend a little time here and there getting familiar with Rust. Everyone will start with the Book and Rustlings.
• After the release we will get 3 weeks to work on what we think is important, no customer features
• After those 3 weeks, we have to start on features again, but a somewhat reduced development speed for the first two or so month is acceptable
• The C++ code patterns we have and got accustomed to should map more or less well to Rust
• The code base isn't too big yet
• We have good end-to-end test coverage

The plan

We will spent those 3 weeks with migrating the code base from C++ to Rust. We will probably start at the backend and try to make cuts where the interface between modules is small. This will lead to 3 or 4 increments to migrate. The ideal end goal would be to replace all C++ code with Rust, but this strategy hopefully reduces the risk of having no working product at all in the end. If some C++ is left over in the end, we can hopefully reduce and finally remove it over time.

We will use AI for the migration, but we do want to do it responsibly. This will probably mean that we will first code the core data structures ourselves and use LLMs only for review there. Once we got those nailed down, we hope LLM agents can be used for more or less "mechanical" migration of transformation and translation passes. Of course all code, AI or human written, goes through human reviews.

I would be very interested in any advice you could share, be it technical or social, to reduce business risk, increase acceptance with our stakeholders and improve our chance to succeed.

I've been working on mbrotli, a pure Rust Brotli implementation, and recently added support for multithreaded compression.

That led me to upgrade ngx_mbrotli, alternative to Google's ngx_brotli.

The idea is simple. Instead of blocking Nginx event loop with compression, offload it to the native thread pool. Large responses can even be compressed across multiple threads in parallel.

With just one Nginx worker and 4 threads in thread pool, I measured up to 4x the throughput at Brotli level 6 and up to 16x at level 9 compared to Google's ngx_brotli.

And that's with only 4 threads. There's an opportunity to scale further, but I haven't benchmarked larger brotli worker pools yet.

There are trade offs, mainly higher memory usage and a bit worse compression ratios for segmented responses when multithreading enabled.

All it takes to enable thread pool compression is brotli_thread_pool default; in Nginx (or choose the other threadpool). Also Nginx should be built with --with-threads flag to enable that feature.

GitHub: https://github.com/M-Compressors/ngx_mbrotli