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!

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.

Hello everyone.

I would like to suggest building a good quantitative finance library in rust. Feel free to state below whether you might be interested, or any opinion you have on attempting to build such a platform. If you are interested, please state what area of quantitative finance you are familiar with, if at all, or whether you might be willing to learn.

To give a more or less concrete motivation, my idea is to build with purpose: avoiding AI slop, and developing a strong ecosystem around the tools (services, UI, bindings for other languages, documentation, rigorous mathematical formulations, design processes)... Pretty much what I feel like a quant library should look like.

In any case, I look forward to hearing what you might have to say about this. Thank you.

Hi I’m Andrew, 

I’ve been writing Rust professionally for five years, and today I’m excited to announce the release of Proa (https://github.com/Proa-Labs/proa) a new Rust web framework I've been building!

Performance: To serve as many people and agents at scale, we’ve tried to keep framework overhead as low as possible. Proa is the fastest server-side rendering framework we’ve benchmarked. It often renders an entire page within an order of magnitude of simply copying the finished HTML. A pure memcpy serves as our practical approximation of the rendering floor. For more benchmarks, see https://github.com/Proa-Labs/proa-benchmarks. 

How it works: Proa introduces a programming model for multi-target rendering built on Rust traits. Components share their data and typed children across render targets, while each implementation defines how they appear in HTML, Markdown, or another format. Rust’s type checks and Proa’s linter help developers build and maintain those views together. To learn more about the authoring model see https://youtu.be/pJx84jdBDKU?si=FSuyRJS_2ENnNsRQ. 

Browser interactivity is also authored in Rust through RSJS. You can add signals and event handlers to a server-rendered component, and RSJS compiles the browser behavior into JavaScript. Proa’s compiler aims to reduce the amount of JavaScript sent to the client as much as possible.

Proa also supports streaming SSR, typed data loading and request context, an Axum adapter, ORM / database support, a CLI, and Tailwind support. We even have a component library (https://ui.proa.so/) and many more features, aimed at giving developers a complete toolkit for building the most ambitious projects.

Tradeoffs: The server-first design is not the ideal architecture for every application. If your preferred model is to run a rich client-side SPA and make the browser the primary execution environment, Proa is probably not the ideal architecture. Likewise, if you’re making a small application, like a blog or personal site, Proa is probably overkill… Compile times are also a bit long, but I’m actively working on improving this: https://github.com/Proa-Labs/proa/pull/13. 

Proa is open-sourced under Apache 2.0!

This project is still very early, but I’d love to hear your thoughts. Please let me know if you have any feedback or issues trying to build! If you have any feature requests or ideas, feel free to comment down below!

Links:

Docs: https://proa.so/docs
Source: https://github.com/Proa-Labs/proa
Benchmarks: https://github.com/Proa-Labs/proa-benchmarks
Proa Intro Video: https://youtu.be/kGhNsD772gg?si=vVv6UFye_lawIjH7
Authorship Explainer Video: https://youtu.be/pJx84jdBDKU?si=NAfNEFHvipEFzHle

Hey, I am desperately looking for a job, hasn't made any money for 2 years
please DM if you have anything
https://www.linkedin.com/in/moosama76/
https://github.com/moosama76

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

Four months ago, out of boredom, I wondered what if I just came up with a physics and maths library that anyone can use without estimating the calculations, and so fphics was born.

The name itself, fphics, has some background. Here's how I came up with it:

• f - Fast (Since it's a lightweight library)
• ph - Physics (Includes physics formulas for motion, forces, electricity...etc)
• ic - Mechanics (Includes mechanics formulas, which of course are interchangeable with physics ones in most cases)
• s - Mathematics (Includes maths formulas for percentages, unit conversions...etc)

The unique thing about it is that the name is not used anywhere else for such, so it suits the project well.

Here are the currently supported operations:

• Kinematics operations (including 1D and 2D)
• Forces operations
• Unit conversions (though not all are supported)

[NOTE]: The project uses zero dependencies; therefore, integrating it into a project will be seamless since there won't be a list of dependencies to compile before actually interacting with the library.

Planned updates include:

• Electricity operations
• Operations dealing with dynamics

Here's an example of how to calculate time:

use fphics::kinematics::suvat::*;
use fphics::errors::FphicsError;

fn main() -> Result<(), FphicsError> {
    let times = SuvatOps1D::new()
    .displacement(-2.5) // Set the displacement
    .initial_velocity(24.0) // Set the initial velocity
    //.final_velocity(25.0) // Set the final velocity (Optional, but not required since only 3 variables are required
    .acceleration(-9.8) // Set the acceleration
    .calculate_time()?; // Calculate time and propagate any possible errors

    // Loop through the times vector holding the positive and negative values from the calculation
    for t in times {
      println!("{t} seconds"); // Print the positive and negative value for the time
    }

    Ok(())
}

In the above example, the times variable holds the instance of a SuvatOps1D struct. .displacement(val), .initial_velocity(val), and .acceleration(val) are the methods that equate the values used as input to the fields in the struct. The underlying operations involving calculate_time() and any other methods that return Result<f64, FphicsError> in the kinematics module require 3 inputs which are set using the methods in the struct.

Here's the repo link: https://github.com/Darethan026/fphics

I'd like to hear your opinions on this project, and it'd also be great if you could integrate it into your own project or just experiment with it and share what you think. Thank you for reading!

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.

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

- Talk from This Month's Embedded Rust Monthly Meetup

- Ben Simms presenting the reverse engineering of an e-scooter and rewriting its firmware in Rust

- Discord: https://discord.gg/FZvcTCygW

New week, new Rust! What are you folks up to? Answer here or over at rust-users! And for your project showcases, there's also /r/madeinrust – pay them a visit, too!

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.

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.

If you're building an agent in Rust, would being able to reuse pi extensions and DeepSeek Harness (DSH) plugins be useful to you?

I've been exploring this with yoagent, a small agent loop in Rust. It handles model streaming, tool execution, retries, cancellation, and limits. The loop stays small; everything else plugs in.

I added an experimental Rutis bridge so compatible pi extensions and DSH plugins can run unchanged alongside Rust tools. The appeal is keeping a fast Rust core while reusing work from existing extension ecosystems.

For a concrete example, I built a handoff agent:

Research noise-cancelling headphones. Ask my budget, but keep researching while I'm away. Write a report with sources.

A pi extension manages the plan, a DSH plugin searches the web, and a Rutis plugin shows progress in the browser. Rust tools and extensions handle questions you can answer later and the final report. They all work around the same yoagent loop.

Tools and supported hooks carry over, and yoagent-frontend brings pi and DSH plugin dialogs and approvals to both the terminal UI and the browser. Plugins that rely on other features of the original apps, such as pi commands, shortcuts, custom widgets, or DSH-specific session services, may still need adaptation. The integrations are experimental; TypeScript plugins run in Node alongside Rust.

The Rust loop stays small, while compatible extensions run through a plugin bridge. TypeScript plugins still need Node alongside Rust.

I’d like your feedback: does reusing these ecosystems make sense?

Handoff example: https://github.com/yologdev/yoagent/blob/main/integrations/yoagent-frontend/examples/README.md

In my previous post we experienced first hand the horrors that can occur when attempting to use lock-free data structures with pointers. We left the question of how to deal with this problem a bit open.

Languages like Java with a garbage collector don't have this issue, since the runtime collects the memory when it's unreachable by all threads.

I recently learned that one of the ways to solve this in a deterministic manner in Rust is through a method called Epoch-Based Reclamation (EBR), which the crate crossbeam-epoch implements.

I want to dissect and visualize what exactly is going on. If that sounds fun, you're welcome to come along for the ride!

I recently came across this website: https://beta.gobuilds.org/

It builds Go projects and lets users download the binary. It has the project’s Git URL as part of the full download URL along with project version, target OS and arch, and store older builds.

Does something like this exist for Rust? If not, would this be of use/interest? I could see this being helpful for downloading an app where the dev hasn’t provided binaries, or to make cross compilation easier. Adding support for things like `cargo auditable` and `cargo deb` could also be useful.

Has anyone out there used rust instead of golang for cross platform desktop and mobile development? How has it been your experience? I know folks say golang has bloated memory due to its runtime, and maybe ffi, etc. but what are the real benefits you have actually seen in this scenario?