MaulingMonkey

If you want -3 -2 -1 0 and +3 +2 +1 0 from the same operation, you'll need something more complicated (either some nonsense to give you a signed stride/step value among other things — or perhaps just writing the damn loop twice instead of getting too clever.)

However, if you just want -1 to not iterate down to `std::numeric_limits<ssize_t>::min()` — and then invoke undefined behavior by signed integer underflow if `i` happens to be `ssize_t` instead of `size_t` — I'll note that the `i --> 0` will terminate immediately, unlike `i --` as otherwise seen. (unless you feed it `min()` exactly. Then it'll underflow a signed integer before the comparison, so that's still undefined behavior.)

I prefer:

    const size_t n = 10;
    for (size_t i = n; i --> 0;) {
        std::cout << i << "\n";
    }

I shelled out for a Steam Machine (SteamOS ≈ Arch Linux.) I do gamedev, and I figured having a test machine was a decent enough excuse for a purchase. It's working suprisingly well for the games I'm actually playing. They're playing better than on my last Windows desktop tower, even, presumably due to a better GPU.

Granted, catalogs vary - anti-cheat and DRM may not play nice, and EvE Online wasn't stable until I switched the renderer from D3D12 to D3D11 (and I haven't tried playing with multiple accounts) - but you might revisit Linux gaming if it's been awhile since you last have.

The enshittification of Windows has finally driven me to the point where Linux compatability is going to start affecting my Steam purchases.

Worktrees share more git state (remotes, blobs, etc.) and don't require hunting down the repository url to feed to git clone, or a network connection to use said url. While you could get the same benefit from cloning your local repository, you're then in the weird state where `origin` is a local non-bare repository.

If you're setting up long-lived checkouts that you reuse, it doesn't help much (except perhaps saving space or bandwidth) vs multiple clones and some once up-front reconfiguration. On the other hand, if you want something more temporary - and perhaps based on your current HEAD without having to hunt down a commit id to feed a subsequent git clone / git checkout command - worktrees save you some boilerplate (re)configuration.

Feature flags are great. Working on a crash / memory corruption in an optional subsystem? Just disable the subsystem to unblock coworkers on the same branch while you track down the cause.

Feature flags are terrible. Working on a crash / memory corruption in an optional subsystem? You disabled it previously for your local build, and you'll lose hours failing to repro despite QA giving excellent repro steps.

(For my own gamedev background, I learned to mute audio by setting volume to 0 instead of by disabling the audio subsystem.)

> If you define another language Rust-Without-Any-Unsafe, then maybe that one is safer than Fil-C.

Just write `#![forbid(unsafe_code)]` at the top of your src/lib.rs, and track crates not using it with `cargo geiger`. You don't need a whole new language, it already provides the tools to wield that hatch shut.

> Rust is less safe because it has a feature for turning off safety

Can I write Fil-C's mmap wrapper in Fil-C?

If no, fair enough, but it's worth noting I can write a safe Rust mmap wrapper in Rust, and I absolutely and frequently need to do that kind of "syscall wrapping" in arenas Fil-C explicitly hasn't handled, by virtue of being explicitly a Linux project.

If yes, that sounds like an escape hatch to Fil-C's memory safety, undermining the claim that Fil-C is fundamentally safer, and you're now at best arguing it's safer as tends to be used.

I adore unsafe, appreciate it as a feature... but it is an escape hatch. One that is sometimes necessary, one that is sometimes not necessary but might still be (ab)used for performance, or initial 1:1 porting of C/C++ code. There are a lot of cases where that escape hatch should probably welded shut though. Fortunately, the Rust ecosystem has tools like `cargo geiger`, and straight out of the box I can also write:

    // src\lib.rs
    #![forbid(unsafe_code)]

> The myth of DNS “propagation” needs to die.

What's the actual issue? Are you being frustrated by people laboring under the assumption that DNS records are being sent by carrier pidgeon or something?

> There is no geographical connection whatsoever.

DNS censorship will presumably be based on geopolitical boundaries, which in turn are bound by geography. And I wouldn't be entirely suprised if poor network connections - including those potentially geographically bound (poor weather / flooding / tornados severing or degrading links or power) had some (minor, infrequent) impact on the rate stale cache entries are evicted in favor of fresh ones.

Granted, none of that means a DNS resolver halfway across the globe from the authoritative servers can't typically get updated results <200ms (≈light speed), which is safely ignorable / won't be visible as records propagating from geographic neighbor to geographic neighbor. And granted further, I'm both too boring to censor, and too smart to be on call for anything that would make me aware of global outage reports - so the map is admittedly useless to me beyond farming that hacker vibe aura.

But I imagine there's at least one or two dudes out there that'll see a red dot in, say, Australia - and that'll save them a few minutes, by giving them a shortcut to determining the root cause of some issue reported in Australia by letting them correctly guess/blame stale DNS records.

> Will programmers write more efficient code during the memory shortage?

Yes. No. Yes.

I've worked in gamedev, helping ship code that ran on consoles. Nice fixed hardware targets. You OOM, you crash. We crashed a lot, and cut and saved and optimized and explicitly invoked the garbage collector twice on level transitions, because a single full scripting language GC doesn't work when finalizers must run to deref C++ objects to unroot script objects, and committed other horrific hacks.

The memory shortage may eventually impact fixed targets like this. Or the minspec publishers will swallow for fuzzier targets like "PC". But it takes awhile for new targets to roll out, and for newly bought PCs to make a significant dent on total percentage of PC ownership. Steam Machine's about to release with 16+8GB and while price and market saturation may be affected by the memory shortage, I'd be suprised if the actual spec changed.

> Maybe there will even be more interest in the invention and use of more advanced algorithms

Not for typical gamedev IMO. There the focus will be more on "reduce the amount of content loaded in memory simultaniously". That means less detail, smaller scale, or less variation. Going from 4096x4096 to 2048x2048 textures quarters your texture memory usage. The surface of meshes also has some square density nonsense going on. Basic animation tends to scale with bone count and keyframes, which are more linear, although shape keys are more per-vertex nonsense.

And of course, reusing the same mesh or texture multiple times doesn't use more memory, just more memory bandwidth.

Audio is more a factor of "how many sound effects (and variants) do we need preloaded just in case there's suddenly an event that triggers them".

These are the big ticket items for memory use and advanced algorithms don't help much. Rather, the algorithms help stretch whatever amount of memory you do have to provide the best amount of quality you can, and the small constant shift in total memory availability doesn't change the calculus for how important that is very much (which depending on the game ranges from "unimportant, everything fits in memory easily" to "critical, we're doing open world streaming and we've got terrabytes of raw data already, 16 vs 64GB of memory doesn't change that much")

> and data structures that use less memory?

Some bit packing type stuff comes up for smaller logical data structures in gamedev, and that can be useful for saving memory bandwidth, but I'm skeptical of how critical it is for total memory usage outside of the occasional Factorio.

C++'s stdlib collection algorithms were basically all mutate-in-place instead of return-a-new-value until C++20 introduced ranges, and I still don't know anyone who actually uses those. By contrast, people actually use the `container.iter().map(...)` etc. in Rust.

C++ also lacks much of the fancy pattern matching features which are frequently associated with functional programming. Such features may not be fundamental to functional programming, but they would fall under "some functional programming features", in the sense that they're common in the languages of that ecosystem.