Rust mutexes would be nice. But I think for me that one thing for me would be its enums.

A water central heating system is a closed loop system that is under pressure. This means the water in it is circulated around and around the system and is cut off from other water supplies under normal operation. Naturally, slow leaks happen and gas can enter the system in various ways so occasionally this needs to be released from the system. Any gas in the system naturally collects at the highest points along the path - which tend to be the radiators.

When you bleed a radiator you are opening the system to the outside and hopefully where the gas has accumulated. Since the system is under pressure it forces the gas out of the system to equalize the pressure with the outside. This will cause the pressure of the system to drop and eventually it will stop.

However there should be a control valve somewhere, typically on/near the boiler that connects the central heating system up to the mains water supply. You can open this valve to cause water to flow into the central heating system and pressurize it and really this should be done every time you bleed the radiator a significant amount.

In apartments though you might find that you are on a building wide circuit, or you might have one isolated for your apartment. If you have a boiler in your apartment then you are likely on a closed system and should be able to equalize the pressure yourself. If it is building wide you need to talk with your building manager.

Note that you should not need to bleed your radiators that often. Once every several years should be more than enough. If you are doing it frequently then you likely have a large leak in your system and likely want to get someone to check that out.

I believe that either gender has a genetic disposition towards the feminine form.

I am not sure you can conclude that. Environmental factors likely play a large role here as well as genetic factors. I feel we tend to idolize and sexualize the female form far more then the male form these days. But if you look back and different cultures that did the same with the male form I suspect you would see an opposite trend to both genders preferring the male form more often.

There is probably a forced arbitration clause and class action waver in the TOS…

They only need it to pass once, we need it to be rejected every single time.

I would say it is more so they can advertise a lower price. But then expect you to get the more expensive ones as the bare minimum is just not enough.

They can write good short bits of code. But they also often produce bad and even incorrect code. I find it more effort to read and debug its code then just writing it myself to begin with the vast majority of the time and find overall it just wastes more of my time overall.

Maybe in a couple of years they might be good enough. But it looks like their growth is starting to flatten off so it is up for debate as to if they will get there in that time.

Huh? Logic is only valid if the assumptions it is made under are also valid. That is how logic works. You cannot draw a conclusion for something based off a faulty assumption. And while I do not know if your is true or not I don’t see good reason to consider it a good assumption to make and can easily see if being a false assumption here. Which makes your arguments hard to rely on without more proof that your assumptions do hold ground.

Your brain is not rigid though - it can collect fluids and swell a tiny bit. Which essentially increases pressure inside it and if happens too much can be fatal. But that means you can squish a little bit more into without replacing mass - at least for a little while. Bones also regrow constantly, and with genital pressure and a lot of time you can reshape them.

I always assume that the microplastic is replacing body mass.

I dont think this is a valid assumption to make. I would see it more as your body working around the microplastics to do what it needs to do as best it can it does not have some limit as to the amount of mass it can use at any one point.

This logic is flawed. If you stand on some scales and pick up a credit card, the scale will measure you are one credit card heavier. You don’t get lighter by adding mass (at least when that mass is also denser then air). And what evidence is there that this plastic in our bodies is additional mass or replaced mass? That is the assumption your logic is based on.

And other browsers can be configured to do the same. Though that is not ublock origin doing anything with the cookies and these settings can be enabled wtihout ublock (though you likely want ublock if you are enabling them).

I don’t think it does anything with cookies directly. It just blocks connections to domains and removes elements from pages that match patterns you give it. Removing the cookies/privacy banners does just that - removes the banner. This SHOULD opt you out of tracking as the laws generally require explicit permission, so not clicking the accept button should be enough. But if the sites follow those laws or not is a completely different matter.

Third party tracking cookies are normally blocked by their domain - when a tracking pixel is on the screen it reaches out to a known tracking domain which logs this visit and drops a cookie for that domain on the page. By blocking that domain the tracking request is never made and thus no cookie is dropped and so there is nothing to track you. Most tracking is done like this so it is quite effective. But it wont stop a first party cookie from being dropped or tracking done through that or any other data you send.

Note that the laws don’t require permission for all cookies. Ones that are essential to the sites function (like a cookie that carries login info) are typically allowed and cannot be opted out of (you can always delete cookies locally though, the laws just cover what sites can use). And not all sites will respect these laws or try to skirt around them so none of this is 100% perfect by any means.

Tldr; their flagship goals are:

2024 edition: (1) supporting -> impl Trait and async fn in traits by aligning capture behavior; (2) permitting (async) generators to be added in the future by reserving the gen keyword; and (3) altering fallback for the ! type.

Async: support for async closures and Send bounds.

Rust in the Linux kernel: focus on the unstable features it uses so it can progress out of the experimental phase.

And highlights other goals:

• Stabilize cargo-script
• Improving Rust’s borrow checker to support conditional returns and other patterns
• Move parallel front end closer to stability
• Ergonomic ref counting
• Implementing “merged doctests”

With a link to a list of 23 other goals

I dont think multiple streaming platforms is a problem. The problem is exclusivity. I dont want to pay for every subscription service to watch popular things. I want to watch any show I want on one platform that I choose. Much like I do for music. But no, with TV shows everyone has their own walled garden of exclusives. Fuck that.

They said on a linked post:

Make fish available on servers that run old LTS distros Making it easy to build and run

Which suggests to me they are using features from newer versions of libraries then exist for older LTS distos. Making it hard to compile and run on them. Most of rust libraries are statically compiled so that is not an big issue for rust. Though this is just speculation on my part.

Rust however… are Arc, Box, Rc, async, etc. fine?

Yes, these are all fine to use. When you should use them depends on what you are doing. Each of these has a usecase and tradeoffs associated with them. Rc is for when you need multiple owners to some heap allocated data in a single threaded only context. Arc is the same, but for multithreaded contexts (it is a bit more expensive than an Rc). Box is for single owner of heap allocated data, async is good for concurrent tasks that largely wait on IO of some sort (like webservers)

match or if/else?

Which ever is more readable for your situation. I believe both are equally powerful, but depeding on what you are doing you might find a simple if let enough, other times a match makes things a lot more succinct and readable. There are also a lot of helper functions on things you often match on - like Result and Option that for specific situations can make a lot more readable code. Just use which ever you find most readable in each situation.

How should errors be handled?

This is a large topic. There is some basic advice in chapter 9 of the book though that is mostly about Result vs panic. There are also quite a few guides out there about error handling in rust in a broader sense.

Typically they suggest using the thiserror crate for errors that happen further from main (where you are more likely to care about individual error variants - ie treating a file not found differently from a permission denied error) and the anyhow crate or eyre crate for errors closer to main (when you are dealing with lots of different error types and don’t care as much about the differences as you typically want to deal with them all in the same way when you are near to main).

Also the fact that there is no inheritance leads to some awkward solutions when there is stuff that is hierarchical or shares attributes (Person -> Employee -> Boss -> … | Animal -> Mammal-Reptile-Insect --> Dog-Snake-Grasshopper).

I have rarly seen a system that maps well to an inheritance based structure. Even the ones you give are full of nuances and cross overs that quickly break apart. The classic animal example for instance falls flat on its face so quickly. Like, how do you organise a bird, a reptile, a dog, a fish and a whale? You can put the whale and dog under mammal, but a whale shares a lot of things with the fish, like its ability to swim. Then think about a penguin? It is a bird that cannot fly, so a common fly method on a bird type does not make any sense as not all birds can fly. But a penguin can swim, as can other birds. Then just look at the platypus… a mammal with poison spurs that swims and lays eggs, where do you put that? Where do you draw the lines? Composition is far easier. You can have a Fly, Swim, Walk etc trait that describe behaviour and each animal can combine these traits as and when they need to. You can get everything that can fly in the type signature, even if it is a bird, a bat, or even an insect. Inheritance just cannot do that with the number of dimensions at play in any real world system.

IMO it is simpler and makes more sense to think in terms of what something can do instead of what something inherits from.

Or do we use an Arc such that our dependent services hold onto an Arc>, allowing concurrent access of the owned resource?

Arc is already heap allocated, there is no need or point in Boxing an Arc. They serve the same purpose except Box is single owner and Arc is multi owner. Box is not the only smart pointer that supports trait objects: Arc is also allowed, same goes for Rc and other smart pointer types.

Though the answer to that question as it stands is: it depends. Both methods they suggest are valid approaches with different tradeoffs. Another is to just forgo trying to share a single field and share the whole object, ie have Arc or &Service instead. Or clone the whole thing between threads, or many other patterns that suite different needs. A lot depends on what this service is and how it needs to be passed around the application and how long it lives for. A lot of frameworks already give you good patterns for this.

For instance axum has a way to pass around state to handlers, generally you pass ownership of the resource to axum and let it clone as required. Typically this means using an Arc> for things that are expensive to clone. Though a lot of types you share this way (like database connections) deal with that internally and so are already cheap to clone in these usecases.

While we could have written this as a service where UserRepo is an injected value, doing so would introduce the complexities we’ve already explored

Does it? OOP style methods are basically just syntactic sugar for the most part. You can largely interchange functions and methods all you want to. Also, pure functions does not mean to most people to what your example is showing. Typically a function is considered not pure if it modifies any of its arguments. So by taking a &mut as an argument you make the function not pure.

Given that I can only assume you mean raw functions vs methods on types. At which point there is not as big a differences as they think. For instance, their example of

async fn handle_session_completed(
    user_repo: &mut impl UserRepo,
    session: &CheckoutSession,
) -> anyhow::Result<()> {

Can easily be written as (well, at least if you ignore the issues around async traits which is a technical limitation that is being worked on, for now the #[async_trait] macro helps a bit, and hopefully soon this will be solved at a language layer)

trait UserRepo {
    async fn handle_session_completed(
        &mut self,
        session: &CheckoutSession,
    ) -> anyhow::Result<()> {

And this form can even be called like a the former:

UserRepo::handle_session_completed(&mut user_repo, &session).await

There is little difference between a method on an type and a function that takes a argument to a type in rust. At least not in terms of how that author talks about them. Though I would lean towards the raw function here due to the async issues with traits. But in a lot of non-async contexts both are equally nice to use and would probably lean more on the trait/type method instead. More and more I just think of methods as type namespaced functions more than anything else, that is basically how you use them 95+% of the time.

But yeah, overall don’t write any language like it is a different language. Same goes for trying to write java like it is C or python like it is rust. Learn the patterns of the language you are using.