Rust

I dunno if this is appropriate for this community, so mods, please delete if not.

I have been writing a screen clone in rust.

https://github.com/cameroncros/PoorMansScreen/tree/better_screen (The main branch is how I currently use it, not at all screen-like, the better_screen branch is much closer to a screen replacement.)

It all currently works fine, albeit quite simple, and I suspect not following best practices. Please talk shit about my code so I can fix that :D

For my next stage of development, I would like to use some combo of vt100 and ratatui to wrap the shell in a border, or add a menu bar at the top or bottom to make it clear when the user is inside a "screen". Does anyone have any thoughts on how to go about doing that? I am very unskilled at ratatui.

It seems like @burntsushi@programming.dev have added some optimizations to the Jiff date time library... so now it should generally be faster than 'chrono' and 'time'. Jiff is quite impressive, the 0.2.1 version number really doen't reflect its quality.

I've got 64 GB of RAM and would like to force cargo to dump build artifacts into it. So basically the target/ directory should end up there.

Unless I'm mistaken RAM is much faster than SSDs and since I do rebuild quite often, it would save some R/W cycles on my SSD and allow faster file access.

I do jot mind doing a full rebuild every morning

Solution:

These 2 comments gave me the best indication how to do it: cargo ramdisk and build.target-dir config options.

Would be great if cargo had a build.target-dir-prefix though. One could set and env var CARGO_TARGET_DIR_PREFIX and point it at /dev/shm or /tmp if it's a tmpfs and every rust project would have its artefacts end up in RAM.

Jiff is a datetime library for Rust that encourages you to jump into the pit of success. The focus of this library is providing high level datetime primitives that are difficult to misuse and have reasonable performance.

And as a user of Jiff, I must say that it is very nice to use. Well thought out API, making date time handling less of a pain. So, nice work @burntsushi@programming.dev

I wrote up a port of GNU factor that has a slightly nicer UI than the original, and runs in approximately 1/3rd the time for 128-bit integers, on average. This is just a preliminary release and I plan implementing elliptic curve arithmetic and extending it to 192-bit to cover all the small integers that CADO-NFS doesn't support.

The factorization algorithm is provided as a separate crate that provides a C-api, since fast factorisation algorithms are hard to come-by.

Greetings,

sometimes I want to read new comments on a particular post but I don't want to check it every hour to see new comments. It would be nice if I can just say "!remind 5h" so that I get a reminder to checkout a specific post which would have new comments after 5 hour.

I am thinking about making it myself in Rust, but if there is already a bot here and I don't know, please tell me.

I've made a tui clock. Ratatui now is so nice to use compared to 1 year ago!

Inspired by Contex-Generic Programming, I made this macro, that allows you to write those generic implementations easily. This is kinda CGP, but simple and with better errors.

Ever repeat yourself implementing traits? Or wanted to easily swap out parts of your code, with (almost) no need to refactor? That is what this is for.

yeehaw is a TUI framework with a full event routing system and plethora of built in elements.

Highlights:

• Actual Neovim can be used as a text editor element (or any other editor set in the $EDITOR environment variable). Likewise, any other TUI that outputs to the terminal can be integrated into an element.
• The color system includes an alpha channel for transparency. A color can also be set to gradients (position or time-based). Basically a yeehaw color can effectively be a neopet's rainbow paintbrush if you want it too.
• Element ownership at a glance: TUI Elements are organized in a hierarchical manner while each retaining autonomy to change their ordering and position within their immediate parent. Events (keyboard/mouse/custom) are routed top down and responses propagate back upwards along the Element ownership tree. Simple elements are only normally required to have spatial awareness within the confines provided to them.
• The core element Trait allows for customizable event/response types enabling developers to create entirely new sub-classes of elements which can reuse the event routing system.

This project is not yet entirely stable, however it felt necessary to unleash this monstrosity into the wild at this point. Feel free to ask any questions here or on github. Also this is my first rust release, so please forgive (and inform me of) missing idioms. -bogz

I shaved off 10 MiB from my binary in 2 hours!

I made a program using Macroquad, then I built it in release mode, the binary was 63 MiB in size.

So I used cargo vendor to have a better look at Macroquad and one of its dependencies, glam.

I then started to delete code, like, lots and lots of code(about 30_000 lines of code); none of it affected my main project, some of it became 'dead_code' just by removing the pub keyword.

The result is that my project was unaffected and the binary went down to 52 MiB.

Is there a way to automate removal of unneeded elements from dependencies? This is potentially huge.

EDIT: I FIGURED IT OUT!!!

My mistake was measuring the size of "target/release", I discovered that that folder contains many "unnecessary" files, like "deps", which greatly bloat the folder'r size, the actual size of my binary is 864K.

I am so relieved.

cross-posted from: https://lemmy.world/post/24505305

The fist new version of Kellnr in 2025 is released! If you want to self-host rust crates on your own infrastructure, check it out.

I've been coming back to the same project a few times. It's essentially just a program that interacts with an API. Only problem is whenever I get back to it, I realize how annoying it is to debug through all the "too many requests" responses I get back from the API because it has a max of 200 requests per second.

On solution would be to filter out those responses but that just feels like the wrong move, so I'm guessing the better solution would be to put some sort of rate limiter on my program. My two questions are: does that seem like a good solution and if it is, do I embed the rate limiter in my program, i.e. using the ratelimit crate or would a better solution be to run my program in a container and connect it to a reverse proxy(I think) container and control rate limiting from there?

This article very much conveys what I think.