Rust works this way, yes. There are escape hatches though, which allow interior mutability.

Yeah, here's an example: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Passive voice deflects responsibility and agency.

Loss happens, firings are a decision.

Ironically, Amazon's document writing culture stresses NOT using passive voice, but it seems acceptable to do so when you need to spin a PR.

No, OSRS is 100 ticks per minute which gives 0.6 second ticks, which rounds to 1.667 ticks per second.

Eve Online probably wins the slowest tickrate award with its whopping 1 tick per second.

IIRC it gets even slower during massive battles where there are hundreds/thousands of players on the same server and area

https://wiki.eveuniversity.org/Time_dilation

I thought EVE was (near?-)tickless but with all interaction subject to substantial cool down timers that limit input frequency into the core?

Yup. As a plugin dev it has its weird quirks but it's quite amazing how the entire time runs at that speed

I'm working on implementing extension types in Polars. Stay tuned.

Aarch64 does indeed have a proper atomic max, but even on x86-64 you can get a wait-free atomic max as long as you only need to support integers up to 64. In that case you can simply do a `lock or` with 1 << i as your maximum. You can even support larger sizes by using multiple registers, e.g. four 64-bit registers for a u8 maximum.

In most cases it's even better to just store a maximum per thread separately and loop over all threads once to compute the current maximum if you really need it.

That’s a neat trick, albeit with limited applicability given the very narrow range. Thanks for sharing!

I take it you never wrote code involving atomic pointers. Regardless of memory usage, a lot of platforms only provide single-word atomics (efficiently), making bitpacking crucial for lockfree algorithms.

> Reliable pointer tagging is not trivial.

It is if you use alignment bits. Not always possible if you don't control the data though.

Yes. But there is no decider for n-state Turing machines that works regardless of n.

I (Orson Peters) am also here if anyone has any questions :)

Orson, what motivated you to tune Rust's out-of-the-box sort in this way?

Well, years back I released an unstable sort called pdqsort in C++. Then stjepang ported it to the Rust standard library. So at first... nothing. Someone else did it.

A couple years later I was doing my PhD and I spent a lot of time optimizing a stable sort called glidesort. Around the same time Lukas Bergdoll started work on their own and started providing candidate PRs to improve the standard library sort. I reached out to him and we agreed to collaborate instead of compete, and it ended up working out nicely I'd say.

Ultimately I like tinkering with things and making them fast. I actually really like reinventing the wheel, find out why it has the shape that it does, and see if there's anything left to improve.

But it feels a bit sad to do all that work only for it to disappear into the void. It makes me the happiest if people actually use the things I build, and there's no broader path to getting things in people's hands than if it powers the standard library.

Every developer I've talked to has had the same experience with compilation caches as me: they're great. Until one day you waste a couple hours of your time chasing a bug caused by a stale cache. From that point on your trust is shattered, and there's always a little voice in the back of your head when debugging something which says "could this be caused by a stale cache?". And you turn it off again for peace of mind.

Don't you just do "flush the cache, rebuild" at the first suspicion? If the bug abruptly goes away, it was stale cache. It usually doesn't.

What kind of compilation caches, something like ccache[1]? Do you use it, or would you? It is for C and C++. Check out the features, they are pretty neat, IMO!

The documentation may come in handy:

1. https://ccache.dev/manual/4.11.3.html#_how_ccache_works

2. https://ccache.dev/manual/4.11.3.html#_cache_statistics

and so forth.

[1] https://ccache.dev (ccache - a fast C/C++ compiler cache)

There are three hard problems in computer science, cache invalidation and naming things.

Or rather: There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.

(source: https://martinfowler.com/bliki/TwoHardThings.html)