3 ms·
Read in context it's a pretty reasonable offhand example. > Avoiding global variables is usually considered good practise, and some systems ban them for other
by iudqnolq 4y ago
Read in context it's a pretty reasonable offhand example.
> Avoiding global variables is usually considered good practise, and some systems ban them for other reasons anyway (for example, Rust doesn't allow global mutable state as it wouldn't be able to prevent races accessing it from multiple threads).
Rust does avoid global variables. You will very very rarely see a global mutex in a Rust library, and only occasionally see it in an application. (The most recent time I saw a Rust mutex was to implement string interning in wasm, a platform without atomics. So it's basically free).
- LegionMammal978 4y ago> Rust does avoid global variables. You will very very rarely see a global mutex in a Rust library, and only occasionally see it in an application. (The most recent time I saw a Rust mutex was to implement string interning in wasm, a platform without atomics. So it's basically free). Sure, global mutexes are pretty uncommon. (Although I can spy some in a few of the largest crates, such as log, crossbeam-utils, thread_local, rayon-core, and openssl.) But it's far from uncommon to use global atomic variables. Atomic counters are often used for unique ID generators, e.g., in autocfg, url, tokio, futures-util, uuid, same-file, and gimli. Atomics are also used as mutexes for external data, e.g., in parking_lot and backtrace, as well as direct storage of mutable flags and other data, e.g., in proc-macro2, time, parking_lot_core, tracing-core, and crossbeam-epoch. I just don't want people getting the impression that Rust is among the "systems [that] ban [global variables]". I don't deny that it discourages global mutable state for most situations, but its overall approach is far more pragmatic than a simple ban.