This is a blog post that really is about C++, but with a look at how Rust does things. So, this is an interesting C++/Rust comparison for once.

Last week I basically duplicated the serialization code to provide better debug output.... today, I see this pass in my Mastodon feed. 😀 Well... what are the odds... most likely close to 100% according to how the universe seems to operate.

Hi rustaceans! What are you working on this week? Did you discover something new, you want to share?

Kellnr, the crate registry for Rust got an update. The latest version contains bug fixes and dependency updates. If you are interested in hosting private crates that must not be on crates.io, check it out.

A short post on how variable names can leak out of macros if there is a name collision with a constant. I thought this was a delightful read!

Hi. I've been learning Rust for a while, and I want to take on an actual project now to learn even more. I need to be pointed in the right direction for one aspect of the affair, and I hope someone here can help me.

I want to create a deck tracker for Hearthstone that runs natively in Linux. This is, on the back end, a fairly simple matter of parsing a constantly updated file that tracks everything that happens in the game. On the front end, however, I want to create a window that sits on top of the fullscreen Hearthstone window and shows me stuff. The "stuff" doesn't have to be images or anything fancy, I'll take whatever I can get, but I don't know how to get started on this part.

So the task is as follows: Create an overlay on top of the fullscreen Hearthstone client, preferably under Wayland, and update it constantly with new information about cards drawn, cards left in deck, that sort of thing.

How do I tackle this problem? Are there any crates that'll let me create such a window and render stuff to it? How would you approach the problem?

Thanks in advance.

I've always been curious about this. If I were to take a snapshot of a git repo at a particular point in time, who would be the top contributors by active lines of code? And then, what type of files have they contributed the most? So I built this little tool.

I've been wanting to learn rust for quite some time now and this was one of my first projects in it. It was a lot of fun!

It uses git under the hood to obtain the information and it's nothing fancy, but keen to hear what you think.

\#rust analyzer question for #emacs folks In client more I see run and debug But gui emacs I don't .. why pfa

@rust

Hi all.

I want to develop a plugin system within my program, and I have a trait that functions defined by plugins should implement.

Currently, my code gets all the functions in a HashMap and then calls them by their name. Problem is, I have to create that hashmap myself by inserting every function myself.

I would really appreciate it if there was a way to say, suppose, all pub members of mod functions:: that implement this trait PluginFunction call register(hashmap) function. So as I add more functions as mod in functions it'll be automatically added on compile.

Pseudocode:

Files: src/ ├── attrs.rs ├── functions │   ├── attrs.rs │   ├── export.rs │   └── render.rs ├── functions.rs ├── lib.rs

Basically, in mod functions I want: impl AllFunctions{ pub fn new() -> Self { let mut functions_map = HashMap::new();[[ register_all!(crate::functions::* implementing PluginFunction, &mut functions_map); Self { function_map } } } Right now I'm doing: impl AllFunctions{ pub fn new() -> Self { let mut functions_map = HashMap::new();[[ crate::functions::attrs::PrintAttr{}.register(&mut functions_map); crate::functions::export::ExportCSV{}.register(&mut functions_map); crate::functions::render::RenderText{}.register(&mut functions_map); // More as I add more functions Self { function_map } } }

Hey all, just sharing a small, single-page site I built using Leptos + TailwindCSS, mainly intended as a demo for an API I built using Axum. Hope someone also finds it interesting!

I'm sharing this site and not the API itself cause I figure it's easier to look at and understand, but if you want to roast some code I would appreciate any feedback you have on the API itself (repo here). Trying to leave the front end developer scene so this is the first API I've tried building, fairly basic but it was fun (I am a big Civ V fan - I hear it's inspired by some niche thing called human history?).

Edit: whoops, looks like the link didn't get set cause I put an image - the site is available here, and the repo for it is here. The live API is available here

In case you haven't seen it, here's a talk regarding Rust's integration into the Linux filesystem that gets completely derailed at The Linux Storage, Filesystem, Memory Management and BPF Summit.

After reading Drew's pitch to the rust community to write our own kernel, I've searched for "linux abi compatible rust kernel" and found "Asterinas". Surprised that it is not mentioned here

Hi rustaceans! What are you working on this week? Did you discover something new, you want to share?

I'd like to know if anyone has succesfully flashed a board using their own FTDI chip and not a commercial debug probe.

I want to get into using Rust and I have these STM-based boards where I put an FTDI chip on them so I get a convenient USB-port for power and debug and flashing. I'd really like to get some Rust-software running but I've just hit walls so far with flashing the boards. They work fine when using platformio/openocd and C++ but nothing has worked so far for using "cargo embed" even though it seems to find the FTDI chip correctly and start flashing but then times out.

I'd love to know if anyone has a similar setup working or can give tips on what I could try.

cross-posted from: https://programming.dev/post/18265389 >Hello again everyone, Dihar here. It's been a while since the last release of treedome, but here you go! This release is all about UI update, emojis, and bug fixes. Please consult this git diff for a more detailed changelog https://codeberg.org/solver-orgz/treedome/compare/0.4.5...0.5.0. These are the highlight of the release. > > ! > > * Add emoji picker for title, will show up in tree! > * Text Editor toolbar is back, now with option to toggle both toolbar and floating menu independently! > * Checkbox is here! Thanks Mantine UI! > * You can check the size of each notes by navigating to Escape Menu -> Configure -> Show Note Sizes! > * Add created/last modified date in notes. Note created before this will not have this field and will set as today's date! > * Create child note can now be done through dropdown instead of only from shortcuts! > * Fix bugs of saving empty tree > * General UI update and more stability for auto scrolling in tree view > * Documentation update

I wrote a quick blog post about a pattern I discovered while building TUI applications in Rust. It's a bit unrefined, and I'm working on package to help make the pattern easier. Let me know what you think!

Another crazy idea I share with this website.

I was developing a game and an engine in Rust, so I was reading many articles, most of which criticize the 'borrow checker'.

I know that Rust is a big agenda language, and the extreme 'borrow checker' shows that, but if it weren't for the checker, Rust would be a straight-up better C++ for Game development, so I thought: "Why not just use unsafe?", but the truth is: unsafe is not ergonomic, and so is Refcell<T> so after thinking for a bit, I came up with this pattern:

let mut enemies = if cfg!(debug_assertions) { // We use `expect()` in debug mode as a layer of safety in order // to detect any possibility of undefined bahavior. enemies.expect("*message*"); } else { // SAFETY: The `if` statement (if self.body.overlaps...) must // run only once, and it is the only thing that can make // `self.enemies == None`. unsafe { enemies.unwrap_unchecked() } };

You can also use the same pattern to create a RefCell<T> clone that only does its checks in 'debug' mode, but I didn't test that; it's too much of an investment until I get feedback for the idea.

This has several benefits:

1 - No performance drawbacks, the compiler optimizes away the if statement if opt-level is 1 or more. (source: Compiler Explorer)

2 - It's as safe as expect() for all practical use cases, since you'll run the game in debug mode 1000s of times, and you'll know it doesn't produce Undefined Behavior If it doesn't crash.

You can also wrap it in a "safe" API for convenience:

``` // The 'U' stands for 'unsafe'. pub trait UnwrapUExt { type Target;

fn unwrap_u(self) -> Self::Target; }

impl<T> UnwrapUExt for Option<T> { type Target = T;

fn unwrap_u(self) -> Self::Target { if cfg!(debug_assertions) { self.unwrap() } else { unsafe { self.unwrap_unchecked() } } } } ```

I imagine you can do many cool things with these probably-safe APIs, an example of which is macroquad's possibly unsound usage of get_context() to acquire a static mut variable.

Game development is a risky business, and while borrow-checking by default is nice, just like immutability-by-default, we shouldn't feel bad about disabling it, as forcing it upon ourselves is like forcing immutability, just like Haskell does, and while it has 100% side-effect safety, you don't use much software that's written in Haskell, do you?

Conclusion: we shouldn't fear unsafe even when it's probably unsafe, and we must remember that we're programming a computer, a machine built upon chaotic mutable state, and that our languages are but an abstraction around assembly.