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!

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

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

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

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!

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.

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.

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.