Personally, I think the main legitimate use of the ticket pattern is when dealing with hardware. In which case your global hidden state is actually the physical world and can't be eliminated.

Otherwise, I think you have a good point.

The rust embedded ecosystem seems to have way too much focus on ownership and safe handling of peripherals. Exactly as you say there's not many of them, you're limited to what's in the hardware. These are not things that you are dynamically spinning up and tearing down dozens of instances all the time but the HALs I've seen all treat them that way. The result is a lot of abstraction that creates a ton of needless boilerplate.

I would rather these things just get out of the way and let me focus on building abstraction in the business logic where it's needed.

Maybe it's time we redefine what success means.

Remember that 10k drones can't just be conjured into the air all at once or act with perfect coordination. There are operational limitations that prevent effectiveness from scaling up past a certain point.

Meanwhile my experience has been that whenever there has been a performance issue severe enough to actually matter, it's often been the result of some kind of performance bug, not so much language, runtime, or even algorithm choices for that matter.

Hence whenever the topic of how to improve performance comes up, I always, always insist that we profile first.