Yup, this makes sense. I host a Matrix server, and it's equivalent in quality to Discord or anything else. Except that I've had a single unread badge on my account on iOS for at least a year now. It drives me nuts.

yup. https://github.com/element-hq/element-x-ios/issues/3151 is a real wart; we're finally at the point now where the push notification process can synchronise with the main process to get the badge count right. Sorry it's taken so long to fix.

I got so used to taking advantage of this feature in my side projects that my work Kotlin code is now full of “run {}” blocks. Even with a GCed language, it’s very nice to restrict variable lifetimes without needing to split the logic out to its own function.

Making batteries for $80/kWh IS the next gen tech. I’m pretty sure China invented lipo (EDIT: I meant lfp) (at least they’re the only ones making it) and they’re currently pushing ahead on sodium ion. They are also the ones who have pushed lithium ion to the point it is today. My first EV was a Nissan Leaf that cost 40 grand and could drive 80 miles. Now you can buy 300-mile cars for about that. That was all China’s doing and nearly every EV on the road today uses their batteries.

They have done to the battery market exactly what Taiwan did to the chip market. You can buy an EV made anywhere the same way you can buy a laptop made anywhere. But guess where the chips and batteries were made.

They didn't invent LiPo (and you probably don't want those in a car), nor did they invent LFP (LiFePO4) but they did license it when no one else wanted to and turned it into probably the best EV battery tech you can buy today. They didn't innovate a ton on the chemistry but they did on the packaging side, BYD and CATLs structural pack designs exploit the low thermal runaway characteristics in a way that wouldn't be safe for NMC etc to reach near parity on density but with better longevity and cost.

They will be the first to sodium ion and solid state though.

It's kind of ironic that BMW pushed CATL into the EV market [1].

[1] https://cleantechnica.com/2022/06/30/how-herbert-diess-zeng-...

This is why I love how Rust approached this; almost by accident to make borrow checking work. Every reference is either mutable or not, and (with safe code), you can't use an immutable reference to get a mutable reference anywhere down the chain. So you can slowly construct a map through a mutable reference, but then return it out of a function as immutable, and that's the end of it. It's no longer ever mutable, and no key or value is either. There's no need to make a whole new object called FrozenHashMap, and then FrozenList, and FrozenSet, etc. You don't need a StringBuilder because String is mutable, unless you don't want it to be. It's all just part of the language.

Kotlin _kinda_ does this as well, but if you have a reference to an immutable map in Kotlin, you are still free to mutate the values (and even keys!) as much as you like.

Only if you're returning a reference or wrapping it in something that will only ever return a reference. If you return an object by value ('owned'), then you can do what you like with it and 'mut' is just an light guardrail on that particular name for it.

You cannot return an immutable version. You can return it owned (in which case you can assign/reassign it to a mut variable at any point) or you can take a mut reference and return an immutable reference - but whoever is the owner can almost always access it mutably.

Arg, you’re right. Not sure what I was thinking there. I still think my point stands, because you get the benefits of immutability, but yeah, I didn’t explain it well.

I mean, if you return an immutable reference, the owner in fact cannot mutate it until that reference is dropped.

If you in fact return e.g. an Rc::new(thing) or Arc::new(thing), that's forever (though of course you can unwrap the last reference!)

> I mean, if you return an immutable reference, the owner in fact cannot mutate it until that reference is dropped.

Might be worth noting that "dropped" in this context doesn't necessarily correspond to the reference going out of scope:

    fn get_first(v: &Vec<i32>) -> &i32 {
        &v[0]
    }

    fn main() {
        let mut v = vec![0, 1, 2];
        let first = get_first(&v);
        print!("{}", first});
        v.push(3); // Works!
        // print!("{}", first); // Doesn't work
    }

My favorite part of rust is its explicit control over mutability, in the manner you describe.

My guess is that when you measure, an arena is not worth the trouble when you run a generational GC, which essentially uses an arena for the eden space already. And if you have an arena, it's probably very short lived and would otherwise live entirely in eden.

Go's GC is not generational.

It's not, but joining the two comments together sync.Pool is often close to what you want for a subset of cases, and it's sort of a locality biased generational storage (without actually providing you strong long-term guarantees that it is that).

Personally, I don’t like non-standard plurals and take the opportunity of a new word not to carry the mistake through. I prefer “mouses” as well, for the plural of a computer mouse.

mouse => mice

corpus => corpora

thesaurus => thesauri

Emacs => Emacsen

Unix => Unices

Unlike you?

I don't take any antipyretics, nor have I given to my kids, unless the fever is 39-39.5°C and climbing. Otherwise, you're sabotaging your own innate immune system!

I do the same. Fever is a feature, unless the infection is so pervasive the fever itself becomes a health hazard (at which point you need to see a doctor ASAP, not lower your fever)

Taking an antipyretic for a regular flu completely defeats the purpose. Let your immune system do its thing, it is pretty good at it.

https://en.wikipedia.org/wiki/Fever#Management

Sabotaging is much too strong a word. The fever is not essential to the immune system. If taking down the fever makes it easier to cook food or do something else that is important to you, go ahead.

We have had fever suppressors for so long now that we know they are not harmful to the immune system in any meaningful way.

A fever should be temporary. If you go several days with 39 C then something is wrong and you should absolutely seek medical help. People used to die from simple bacterial infections before we had antibiotics.

And be mindful of the children! Small children are wired somewhat differently and you should be much more careful with them. 39 C in a newborn can be life threatening.

> The fever is not essential to the immune system

Nonsense. From Wikipedia:

Fever is thought to contribute to host defense, as the reproduction of pathogens with strict temperature requirements can be hindered, and the rates of some important immunological reactions are increased by temperature. Fever has been described in teaching texts as assisting the healing process in various ways, including:

- increased mobility of leukocytes

- enhanced leukocyte phagocytosis

- decreased endotoxin effects

- increased proliferation of T cells

[...]

Studies using warm-blooded vertebrates suggest that they recover more rapidly from infections or critical illness due to fever.

---

Fever makes your immune system work better, and many pathogens don't like the higher temps.

> Fever makes your immune system work better,

Right. But it's not essential to the immune system. The immune system doesn't shut down completely just because you temporarily bring the fever down.

It's one thing to avoid overusing painkillers, and while I personally can appreciate that sentiment, over the counter painkillers are pretty well tested and you should not be afraid to use them, without reasonable limits. Denying children painkillers when they ask for them sounds dangerously close to going a step too far!

There are no studies that indicate you can "harden" your immune system by denying pain killers in the long run. You shouldn't be afraid of painkillers, just as you shouldn't be afraid of having fever.

He is not like the others

I agree - stoicism is almost fully extinct. Modern people are a bunch of whiners.

Whining about "people these days" is very, very ironic.

The problem is that the transit agency doesn't have a lot of agency over its city's homeless population.

The transit agency also doesn't have a lot of agency about the budget they receive from the city either

Not being such a car-dependent society that every single person is forced into a dangerous, personal machine that requires licensing and tracking, to do absolutely any activity outside the house.

cameras can still track you regardless

Facial recognition is a LOT harder. And there aren't laws saying you're not allowed to do anything that would disrupt it. AND the laws regarding taking photos of people are a lot different than the laws around taking photos of cars.

Flock is already doing facial recognition

I'd love to see a world were game devs program to a subset of Win32 that's known to run great on Linux and Windows. Then MSFT can be as hostile as they like, but no one will use it if it means abandoning the (in my fantasy) 10% of Linux gamers.

That's basically already happening with Unity and Unreal's domination of the game engines. They seem dominate 80% of new titles and 60% of sales on Steam [1], so WINE/Valve can just focus on them. Most incompatible titles I come across are rolling their own engine.

[1] PDF: https://app.sensortower.com/vgi/assets/reports/The_Big_Game_...

Same with Godot. I'm writing a desktop app, and I get cross-platform support out-of-the-box. I don't even have to recompile or write platform-specific code, and doesn't even need Win32 APIs.

One aspect I wonder about is the move of graphics API from DX11 (or OpenGL) to DX12/Vulkan, while there have been benefits and it's where the majority of effort is from vendors they are (were?) notoriously harder to use. What strikes me about gaming is how broad it is, and how many could make a competent engine at a lower tech level, but fits their needs well because their requirements are more modest.

I also wonder about the developer availability. If you're capable of handling the more advanced APIs and probably modern hardware and their features, it seems likely you're going to aim at a big studio producing something that big experience, or even an engineer at the big engine makers themselves. If you're using the less demanding tech it will be more approachable for a wider range of developers and manageable in-house.

I believe it's already happening to a minor degree. There is value in getting that "steam deck certified" badge on your store, so devs will tweak their game to get it, if it isn't a big lift.

I am seeing that number increasing soon with The SteamDeck and SteamMachine (and clones/home builds). Even the VR headset although niche, is linux.

The support in this space from Valve has been amazing, I can almost forgive them for not releasing Half Life 3. Almost.

There are strong indications that Half Life 3 (or at least a Half Life game) is coming soon. Of course, Valve might decide to pan the project, but I wouldn't be surprised seeing an announcement for 2026.