🦀 The unexpected productivity boost of #Rust

「 I have found that Rust's strong safety guarantees give me much more confidence when touching the codebase. With that extra confidence I'm much more willing to refactor even critical parts of the app, which has a very positive effect on my productivity, and long-term maintainability 」

https://lubeno.dev/blog/rusts-productivity-curve

RV (something like Python's UV, but for #Ruby) looks pretty cool https://andre.arko.net/2025/08/25/rv-a-new-kind-of-ruby-management-tool/

I liked using UV with Python and I'm guessing the experience with RV would be similar as well. It's a bit said that all such tools have to be rewritten in #Rust (or similar), but nothing's perfect. On the bright side - perhaps that would encourage me to do something meaningful with Rust… (RuboCop in Rust anyone? :D)

To the people using #zed for #rust development: Rust (new) module system uses module_name.rs + module_name/ (directory) for organizing modules and sub-modules, so it would make sense to NOT sort directories first in the project panel, so the file and dir for one module are next to each other and not the dir on top and the file elsewhere bellow. How to you configure it to have the natural sorting for #rust project?

jbz
jbz boosted
  • Software engineer/developer
    - Preference for 3rd shift, but if I can work anywhere, I'll find a place to live to fit your schedule.
    - holistic software development("full stack")
    - References out the wazoo, especially from my most recent position.
    - Any language, but I'm practiced in Java, #cpp , HTML, CSS, like #rust , and have professional exp. in Java, SQL, PL/SQL, and BASH
    - English, #日本語 , #suomi , Français, et Español.

    #getfedihired #nonprofit #opensource

Wanted: a #RustLang tool with 4 panes:
- desired generated code
- an in progress proc-macro being written
- input #Rust code where the proc-macro is being applied
- a live updating view of the actual generated code with diff annotations against what was desired

If you want to go fancier, tie things in the output to the input and provide suggestions on where things are missing pre-expansion for the output to march the expectation. I feel like 90% of this can be accomplished today with tmux+a file watcher+direct rustc invocations using -Zunpretty=expanded, but it'd be lovely to have an actual tool for this.

Wanted: a #RustLang tool with 4 panes:
- desired generated code
- an in progress proc-macro being written
- input #Rust code where the proc-macro is being applied
- a live updating view of the actual generated code with diff annotations against what was desired

If you want to go fancier, tie things in the output to the input and provide suggestions on where things are missing pre-expansion for the output to march the expectation. I feel like 90% of this can be accomplished today with tmux+a file watcher+direct rustc invocations using -Zunpretty=expanded, but it'd be lovely to have an actual tool for this.

The #SumUp card payment terminals seem to be quite popular, also among communities taking donations, e.g. at #FrOSCon.

For @Teckids , I made a small stand-alone POS frontend, so we can take card payments and display QR codes for receipts to customers while avoiding the proprietary Google Play app and not passing on customers' e-mail addresses to SumUp.

It's very basic for now, but find it here:

https://codeberg.org/Natureshadow/pumus

#FOSS#OpenSource#Rust

Crazy thought: what if I added another request handler language to #iocaine? What if it was #Rust?

Not quite sure how it would work, but the request handler would be a crate-type = ["cdylib"] thing. That might be even more performant than Roto, and would allow doing a whole lot of things neither the Roto nor the Lua/Fennel engines can (because they're intentionally locked down, while due to the nature of being a cdylib, Rust wouldn't be).