Yeah, these become a lot less relevant with routine.

• Avoiding the main-thread panicking is mostly just a matter of not using .unwrap() and .expect().

• String vs. &str can mostly be solved by generally using owned datatypes (String) for storing in structs and using references (&str) for passing into function parameters. It does still happen that you forget the & at times, but that's then trivial to solve (by just adding the &).

• "temporary value dropped while borrowed" can generally be avoided by not passing references outside of your scope/function. You want to pass the owned value outside. Clone, if you have to.

• "missing lifetime specifier" is also largely solved by not storing references in structs.

The thing with OOP, particularly how it's used in GCed languages, is that it's all about handing references out to wherever and then dealing with the complexity of not knowing who has access to your fields via getters & setters, or by cloning memory whenever it's modified in asynchronous code.

Rust has quite the opposite mindset. It's all about tracking where references go. It pushes your code to be very tree-shaped, i.e. references typically¹ only exist between a function and the functions it calls underneath. This is what allows asynchronous code to be safe in Rust, and I would also argue that the tree shape makes code easier to understand, too.

But yeah, some of the patterns you might know from OOP will not work in Rust for that reason. You will likely need to get into a different mindset over time.

Also just in case: We are talking OOP in the sense of the paradigm, i.e. object-oriented.
Just using objects, i.e. data with associated functions/methods, that works completely normal in Rust.

¹) If you genuinely need references that reach outside the tree shape, which is mostly going to be the case, if you work with multiple threads, then you can do so by wrapping your data structures in Arc<Mutex<_>> or similar. But yeah, when learning, you should try to solve your problems without these. Most programs don't need them.

Yeah, we onboarded some folks into a Rust project last year and a few months in, they were genuinely surprised when I told them that unwrapping is pretty bad. Granted, they probably did read about it at some point and just forgot, but that isn't helped by lots of code using .unwrap() either.

Can still use .is_positive(), though...

What the heck, I thought you were saying you don't want porn games. Flipping the letters like that is a common way of censoring. I was already somewhat confused, since I'm not sure, I've ever seen a porn puzzle game.

Hmm, I'm not getting a compatibility warning on F-Droid. I'm on Android 15, are you already on 16 maybe?

I was also surprised how well it works, but you genuinely just sploosh water with a mild bit of pressure at it and it comes off.

I've been using a hand-operated travel bidet, which is basically just a squeeze bottle with a nozzle, and that still gets me perfectly clean. Definitely much cleaner than with toilet paper.

Does cow milk bubble in some special way? Like, you can make bubbles rise even in water, but I'm guessing, that's not what we're talking about...

The thing is that many people who "like milk" don't think of the taste of freshly milked dairy milk. I grew up with skimmed milk that got treated with ultra-high-temperature processing. The cow taste was hardly there and it wasn't why I liked milk.

I liked milk, because it made cereal edible and because I could put chocolate powder into it. The cow taste rather even felt out of place.

By some definition of "further", sure. Mainly the definition someone with no remorse would have.

Perhaps worth pointing out that audio volume in general is a mess. The only meaningful number is an audio volume of 0. All the others are made up.

You can measure the dB, but only for specific pieces of hardware. And in the end, it's all a matter of perception anyways. Your bass might be thumping at objectively a high number of dB, but the entire audio track still sounds quiet to some listeners, because they listen:

• on a phone speaker.
• with a bunch of background noise.
• with bad hearing.

Yeah, you understood my comment entirely the wrong way around. When I say "dotfiles", I mean the non-Nix way of managing application configurations. Nix Home-Manager happens to write to these dotfiles, but that means I don't have to deal with the dotfiles myself.