However, I believe the first shareware version I had was 1.x (distributed via CD that was packed full of shareware) which was significantly different. I remember mining fuel, which tracks with the above link.
Stars! was one of my very first video game purchases. I remember mailing a money order, and recieving a copy in the mail - I didn't have internet at the time. I'm not sure I even knew the internet existed then, although I would soon after if not.
IDK about "tier 1" but I'll note I've used VS for debugging and profiling Rust binaries. I even wrote a tool to auto-generate a wrapper .sln so I can easily launch from VS: https://github.com/MaulingMonkey/cargo-vs
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.
Only a token test amount so far. The root filesystem is read-only by default, but without the whole Nix ecosystem, which is a little awkward (can't install packages even as root without changing that.) On the other hand, it comes with `distrobox` preinstalled, so it's easy enough to spin up a container and use that (including package installation.)
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.
if it's a my main repo where im regularly doing hotfixes in one folder while i work simultaneously on a feature branch on another I will have multiple long lived checkouts (usually 4).
it makes sense to keep them warm because while cloning a new repo is almost always quick, regenerating the build artefacts from scratch each time is not.
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.
It should be mentioned that rust's type system has a long-standing known bug compromising memory safety, as made famous by cve-rs. It's perhaps not a big issue for most people but if you are someone that wants the assurances of #![forbid(unsafe_code)] that should probably be on your radar.
Certainly, we should build into our threat model the idea that the implementation of Rust will have bugs that compromise safety until proven otherwise (merely fixing that one aforementioned bug won't alter that calculus). And the same applies to Fil-C: we should assume it has bugs that compromise safety until proven otherwise. Until then, in practice, Rust has much more real-world use that convincingly demonstrates its ability to realistically eliminate memory safety risks.
No, that's not how this works. The bug being utilized by cve-rs has such roundabout requirements that it's unlikely that anyone has ever triggered it without trying (to be clear, the Rust devs plan to fix it regardless). Meanwhile, here's a memory safety bug that Fil-C fails to catch, not because of a compiler bug, but by design: https://www.reddit.com/r/cpp/comments/1v4nw0k/filc_garbage_i...
I've encountered a few soundness holes in rust-lang in practice, but they've all been fixed before I managed to shoot myself in the foot with any of them:
• `std::mem::uninitialized()`. It's now deprecated in favor of `MaybeUninit`.
• `#[no_mangle]`. It's now `#[unsafe(no_mangle)]`.
I don't believe I've constructed cvs-rs's hole by accident. cve-rs's code links to https://github.com/rust-lang/rust/issues/25860 , which is admittedly still open after a decade. Progress appears to still be ongoing though! Related:
> Meanwhile, here's a memory safety bug that Fil-C fails to catch, not because of a compiler bug, but by design: [...]
Thanks for sharing a concrete example of Fil-C's limitations! Disappointing - but not unexpected - to see it underperforming existing sanitizers. I was hoping for better.
> I've encountered a few soundness holes in rust-lang in practice
Indeed, I'm trying to be careful not to claim that merely fixing #25860 at long last would make Rust's implementation suddenly beyond reproach. For that, we would need formal verification (which, so far, has at least been done by Ralf Jung's group for proving the correctness of large swathes of the standard library, but I wouldn't expect that to extend to the compiler anytime soon).
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:
I feel like this perpetuates a bad mental model. Unsafe is not an escape hatch. Code within unsafe blocks must uphold the same semantics as code outside it but the compiler cannot guarantee that those semantics are upheld.
If we're using analogies, `unsafe` is like a "hard hat required" sign. There's nothing intrinsically different about the space inside or outside of it, other than that you can't be sure a brick isn't going to fall on your head once you cross over. So it's on you to wear a hard hat. And to not drop any bricks and trust other people to do their best not to drop any bricks.
Yeah, I'd have more sympathy for the "It's an escape hatch" model of this feature if the C++ approaches to this problem didn't keep adding actual escape hatches and waving away concerns as "Rust does this too so it's fine".
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.
Yes, I am constantly needing to disabuse people of their misconception that DNS changes start to apply gradually by geographic distance, instead of applying arbitrarily by pure chance of when each resolver happened to query the record previously.
> 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?
The actual issue is that some people misunderstand how DNS works, and the notion that records propagate doesn't help people understand it better. It propagates a misunderstanding of DNS.
> 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.
However, I believe the first shareware version I had was 1.x (distributed via CD that was packed full of shareware) which was significantly different. I remember mining fuel, which tracks with the above link.
Stars! was one of my very first video game purchases. I remember mailing a money order, and recieving a copy in the mail - I didn't have internet at the time. I'm not sure I even knew the internet existed then, although I would soon after if not.
reply