Readit NewsNo OS should steal focus, Windows absolutely is guilty of it.
I chose what happens after. Can recommend. I wasn't even aware of my privilege.
But this is way too taxing for my linux boxes that are ending stuttering quite badly sometimes. Are you all using macs or something?
This website
1. reacts well to my system preference of a dark theme in my news-reader
2. has a toggle at the top for dark theme
3. works flawlessly with DarkReader in my browser
Until I saw your comment, I didn't even know the website had a light version.
Again: What?
Compared to C the situation is outlandishly, even hellishly impossible to understand. If I can't understand this one thing then I feel there's no point in continuing so I must stay and battle it till I get it or give up completely. I don't think I've ever hit anything like this in any other language I've ever learned.
You can also create a struct, put your "global" variable inside it and then put all the functions that need the variable into an Impl block of that struct. If you then add the parameter `&self` to these functions, you can access the "global"variable any time via `self.global_variable`.
If that is not enough, then you can always make an actual global variable by first wrapping it in a Mutex, to prevent simultaneous access and then wrapping that in an Arc for Atomic Reference Counting. That allows you to pass "copies" of that variable around anywhere, satisfying the borrow-checker (since the variable is now reference-counted in a thread-safe way).
If you need a lot of parallel reading, replacing the Mutex with an RwLock is a good idea, since it allows locking from multiple threads, if you want to read it in most cases.
So you can basically panic anywhere. I understand people have looked at no-panic markers (like C++ noexcept) but the proposals haven't gone anywhere. Consequently, you need to maintain the basic exception safety guarantee [1] at all times. In safe Rust, the compiler enforces this level of safety in most cases on its own, but there are situations in which you can temporarily violate program invariants and panic before being able to restore them. (A classic example is debiting from one bank account before crediting to another. If you panic in the middle, the money is lost.)
If you want that bank code to be robust against panics, you need to use something like https://docs.rs/scopeguard/latest/scopeguard/
In unsafe Rust, you basically have the same burden of exception safety that C++ creates, except your job as an unsafe Rust programmer is harder than a C++ programmer's because Rust doesn't have a noexcept. Without noexcept, it's hard to reason about which calls can panic and which can't, so it's hard to make bulletproof cleanup paths.
Most Rust programmers don't think much about panics, so I assume most Rust programs are full of latent bugs of this sort. That's why I usually recommend panic=abort.
[1] https://en.wikipedia.org/wiki/Exception_safety#Classificatio...
You can easily write code that does not contain any possible panic points, if you want.