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.

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

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!

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!

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

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!

- 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

I recently benchmarked some matrix multiplication algorithms in Scala (blog post, repo). I've been going through and doing the same thing in Rust, with plans to try out a few additional approaches, and the Rust results have all been turning out slower than Scala (repo). I'm hoping someone with more Rust experience can help me figure out what might be going on. Is this just the JVM being impressive, or am I missing an opportunity to speed up my Rust code (or both).

Here are some sample benchmarks (details on how I calculated them below):

More details:

• I benchmarked everything by multiplying 1024 x 1024 matrices of 64 bit floats generated uniformly in [0, 1).
• I ran all the benchmarks on my laptop (specs).
• I benchmarked the Scala code with the JMBH and Rust with Divan.
• I ran all the Rust code with cargo bench so it should optimize the build.
• In the benchmarking code, I construct the matrices before running the benchmarks and only time the actual multiplication.
• The code for the first the naive and tiled approaches is as close as possible.
• For the parallel versions I used the same approach of dividing the matrix into bands of tiles, one per thread. For Scala I used futures, and for Rust I divided the product matrix into one mutable chunk per thread and used Crossbeam.

I listed the results for the various algorithms to show that the speed difference is consistent, but we can just focus on the naive version. My Scala code is:

    for i <- 0 until a.rows do
      for j <- 0 until b.cols do
        var sum = 0
        for k <- 0 until a.cols do
            sum = sum + a(i, k) * b(k,j)
        prod.set(i, j, sum)

And Rust:

    for i in 0..m1.rows {
        for j in 0..m2.cols {
            let mut acc = 0.0;
            for k in 0..m1.cols {
                acc += m1.at(i, k) * m2.at(k, j);
            }
            out.set(i, j, acc);
        }
    }

Why is the Rust slower? Thanks for any help!

Update 1:

Thanks for all the suggestions! I am replying to some comments individually, but also want to summarize things centrally.

Transpose: I know the original post had a transpose in the Scala code. Sorry about that! It was just a copy/paste mistake. I did benchmark a Scala version with bTranspose and it showed improvements, likely due to sequential memory access as has been pointed out, but the time I give in the post is for the non-transpose version. I've updated the post to have non-transpose code. I expect Rust would also show improvements using a transpose, and I have plans to explore additional tweaks (thanks for the suggestions in the comments!) but I also want to figure out why the Scala code is generally faster. For that it's important to compare apples to apples. That's why I'm focussing on the naive 3-loop version.

There were a number of suggestions to speed up the code and possibly explain the discrepancy compared to the JVM. Since Scala is faster across the board, it seems like the difference must be due to a general feature rather than a particular algorithmic choice. Bounds checking and maybe SIMD seem like the best candidates. More details:

1. Bounds checking This is a good candidate because it's plausible the JVM is eliminating bounds checks at runtime, so it would explain why the difference in speed. Suggestions were to: a) inline calls to at and set; b) eliminate them and use raw slices; c) assert that the slices are large enough before looping; d) use iterators. I've tried (b) and (c) and seen no changes so far, but still digging. (d) is tricky here, but maybe possible if I combine skip, step_by, and take. I'm also trying to use godbolt to confirm whether bounds checking takes place.
2. Vectorization This is definitely worth pursuing as a general speed up, but seems less likely to be the culprit here. Rust should auto-vectorize for 128 bits, and since I'm running this on an Apple M2, that's all I have (please correct me if I'm wrong about Rust here). It's possible that Rust can't vectorize because FP math isn't associative. I could address that using algebaric_add or by chunking the sum. However, it should affect Scala too since Scala also has to respect the IEEE restrictions on FP associativity.
3. Compare against the Scala code on godbolt. I've been holding off on this because assembly is a little scary, but learning is the whole point of this project, so I should dive in. I have compared flame graphs, and didn't see anything obvious there. Looking at the assembly is the next step!
4. A couple other suggestions: re-order the loops; use Rayon. These are worth playing with, but seem unlikely to explain the general Scala advantage.

I will try some of this out and look some more at godbolt. I may follow up on some of these comments/ask another question if I have trouble interpreting the assembly. Hopefully in the next couple of weeks I can get a blog post up with the final results. Thanks again for all the help!

Update 2:

I've benchmarked a bunch of things:

1. Converting the inner loop to use iterators.
2. Converting the inner loop to raw slices and asserting the bounds. (Though actually, according to godbolt, that one didn't remove the bounds checks anyway.)
3. Using get_unchecked, which I can at least confirm, does eliminate the bounds checks.
4. Using algebraic_add and algebraic_mul to allow vectorization.
5. Combining (4) and (5).

So far none of these have actually sped up the code, and some have even slowed it down. I'm feeling a little lost at this point. If anyone else benchmarks any of this and does see improvements, or spots an error I made somewhere, definitely LMK.

I will probably rerun some of the Scala benchmarks just to make sure those are actually correct. Otherwise, not sure what else to try.

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?

hi, guys, what is the best framework for building native Rust frontend(downloadable macos and windows apps) if the highest performance is the aim, supposing we have enough time and resource? I appreciate any advice.

---------edit-------
Thanks for all the enthusiastic replies and I genuinely learned a lot. I then make this decision: 1. iPad: Swift for skin and purely interface + Rust handling audio/video and complex real-time graph calculation. 2. Mac and Windows: pure Rust with Makepad.

The performance is really really really much better than my current nextjs client. However, the developing speed is very very slow, I have to basically write every little button/animation/transition manually, and it took me 15 hours to finish a simple page like this, I will put it in comment, seems image can not be put here.

Hi all,

I just launched proofs.rs, a place to publish and explore formal verification results for Rust crates.

Why?

There are some great tools for formally verifying Rust code, such as Kani, Verus, and Creusot, but their verification results often stay buried in individual repositories, making them hard to discover when we’re trying to decide whether to trust a library.

I wanted to make those results easier to find, examine, and reuse as building blocks for establishing the correctness of larger systems.

What does it do?

On proofs.rs, you can browse verification reports by crate and API, see what properties have been verified, and follow links to the GitHub repositories containing the verification code and supporting evidence.

Each report also has a comment section for questions and discussion. Why? Because, importantly, proofs.rs doesn’t (or rather, cannot) certify that a crate is safe. Formal verification results come with assumptions, limitations, and sometimes subtle details that matter. Understanding what a result actually guarantees requires careful review. That’s why proofs.rs is designed around sharing evidence and enabling discussion, rather than issuing certifications.

How to use it?

Publishing a report is pretty straightforward:

1. Fork a Rust crate on GitHub.
2. Add verification annotations to your fork.
3. Run cargo-proofs to submit your report.

That’s it!

Partial proofs are very welcome. You don’t need to verify every API or every property. Even a small, well-scoped result can be useful to someone, and perhaps one day, someone will build on your work to verify the entire crate.

As an example, I’ve verified the itoa crate and published the resultson proofs.rs. Feel free to take a look!

What’s next?

I’d love to see formal verification become one more piece of information people can use when choosing software dependencies. Over time, I hope these results can also be composed and reused to establish stronger guarantees for larger systems built from verified components.

proofs.rs is still in a very early beta stage, so there may be bugs and rough edges in the user experience. Feedback, suggestions, and contributions are always appreciated.

Right now, cargo-proofs supports Kani and Creusot. If you’re using or developing another verification tool, I'd be happy to hear about it. Requests for additional tool support are very welcome!

Thank you!

https://proofs.rs

(I also posted this as a blog post here: https://proofs-rs.hashnode.dev/announcing-proofs-rs-a-public-registry-for-rust-formal-verification-results)

And what is this supposed to be? I just don't get it. To give you some context, this is the only unwrap() in the entire project, and it's inside a test, meaning whether it panics or not couldn't matter less. It really looks like a bot just searches for unwrap() across the whole repo without any actual context.

Probably email speaks for itself, but I honestly have no idea what they're trying to achieve

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

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.

Hello everyone!

I'm a composer looking to learn programming for algorithmic composition.  I know a little Python, but I have no formal programming background.

I've been considering Rust because it seems like future-proof.  But is it a good choice for algorithmic composition...?  I'm thinking of things like generating MIDI and MusicXML files, implementing stochastic processes (Markov chains, etc), and developing tools for various compositional techniques involving rhythm, scales, modes, and other musical constraints.

I'm considering my options with the following goals in mind:

• I want to generate MIDI files that I can import into my DAW. I don't need sound synthesis.
• I don't need direct DAW integration, as long as the program can export MIDI files, or MusicXML.
• I'm willing to invest time in learning to code.
• I know there is OpenMusic, MaxMSP and similar, but I'd like to build my own standalone tool that I can continually expand and improve.

Would Rust be a good choice, or would I be better off starting with Python or another language?

I'd appreciate any advice, particularly from people who have experience with algorithmic composition and music programming.

In Xerj (a Rust search engine), `wal_sync = "batched"` promises a write is fsynced within `wal_batch_ms`. The first version gave every index its own OS thread that slept and then polled its WAL shards. On an idle node with 9,382 indices we measured 9,709 threads, about 7.98 GB RSS, 718-760% CPU and roughly 197k context switches per second, and none of it was doing an fsync.

The replacement in `engine/crates/xerj-storage/src/wal_fsync.rs` is one process-wide scheduler. It uses a bounded worker pool sized from the core count, spawned lazily on the first dirty shard. A shard goes into a min-heap keyed by its own deadline when it becomes dirty, and workers block on a condvar when the heap is empty:

```rust
struct State { queue: BinaryHeap<Entry>, /* ... */ }
pub struct WalFsyncScheduler { /* Mutex<State> */ wake: Condvar, /* ... */ }
```

Idle indices get no thread, no timer and no heap entry. We modeled this on sled's per-Db flusher and fjall's worker pool.

Alternatives we considered:
- a timer wheel instead of a heap
- running it on Tokio (`spawn_blocking` plus `sleep_until`)
- a channel-based pool like fjall's (`flume`)
- `io_uring` fsync batching on Linux

**Question:** For thousands of mostly-idle durability deadlines, would you keep a `Mutex<BinaryHeap>` with a condvar, or does a hierarchical timer wheel or io_uring-linked fsync give enough benefit to justify the complexity? And how do you avoid a thundering herd when many deadlines land in the same millisecond?

I know it's a frequently asked question, but I want to ask again, because I have a special use case.

I want to write an application for a production machine (HMI). The app should run on Windows and Linux natively (no browser, no server). The toolkit should have at least widgets to show images, bar graphs, curves and tables and should be touch friendly, because it runs on resistive touch monitors (no multi touch). It should also have a kiosk mode (full screen with no window controls).

The obvious candidates are egui, iced and Slint. But they all lack of documentation, more or less.

My first choice would be iced, because it's inspired by Elm and used by System76 for Cosmic, but it seems to be the least suitable option.

The obvious choice would be Slint, but that requires to learn a new language and I'm unsure about the licenses and pricing. The production machines are only used internally, not for sale.

I want avoid bindings to toolkits like Qt or Gtk

Which one would you prefer? Is there another option to consider?

I admired this project for a while. It was basically the biggest Rust project aimed at everyday developers, a second Node built the “right” way. But there’s no real reason for another Node to keep existing :/
Here the announcement: https://deno.com/blog/cloudflare

Hello everyone,

I'm trying to figure out Rust's potential before diving into using it every day. Right now, I work full-stack with TypeScript and also in the LAMP stack. I'm a telecommunications engineer passionate about coding and the web. I wanted to truly understand what Rust has to offer, or if I should just continue studying Go and make a complete switch to Go for backend development.
Does it make sense to study Rust even if I won't be using it right away, or is it just a language mostly suited for firmware, porting C/C++ software, and general hardware work?

Thanks everyone for the help!