IIRC in the modern .NET runtime, System.Random should come from here, which is updated somewhat regularly: https://github.com/dotnet/runtime/commits/main/src/libraries.... Although, whether any of these is a behavioral breaking change isn't immediately clear; most are just API additions.
How do you accurately resimulate if you don't rollback everything to the previous state? E.g. a giant wall moved from point A to B but it was accurately predicted (no rollback). Don't you need to roll the wall back to accurately simulate everything around it?
EDIT: I misunderstood the previous comment, I think you are rolling back everything that changed, and not rolling back objects which were "static" in that timeframe.
Other than the fact that WebGPU sucks compared to modern Vulkan + extensions, there’s nothing stopping you from just using webgpu even in a native-only project, with no further abstraction
You can expose a C interface from many languages (C++, Rust, C# to name a few that I've personally used). Instead of introducing a new language entirely, it's probably better to write the library in one of the languages you already use.
If your goal is to learn Metal, then just start with Metal. It's a significantly better-designed API. On top of that, if you're developing on an Apple device then you'll have a decent debugging experience with Metal, as opposed to OpenGL where you'll get... nothing last I checked (but it's been a while).
Even most technically-minded people still use QWERTY on full-size computer keyboards despite it being a terrible layout for a number of reasons. I really doubt a new, nonstandard keyboard would get much if any traction on phones.
Shattered Pixel Dungeon is incredible, but dangerously addictive. It's the perfect game for a 4-5 hour plane ride -- speaking from experience over the recent holidays.
This is true, but you do have to enroll by day 60 as far as I know. It’s also a royal pain to get hospitals to readjust billing if you retroactively purchase COBRA coverage after receiving care.
The existence of individual vehicles with very high mileage doesn't feel like a good signal for overall reliability or maintenance req's over a lifespan. I did some brief searches and it seems there's a lot of "record-holding" gas vehicles with several million miles on them, some even claiming to be using original engines. Again though, I'm not sure this is a good representation of how reliable the vehicles are in aggregate.
I've used Colemak primarily for the past 5 or so years. However, the benefit is primarily in typing comfort and hand strain, not quite as much in speed, although it is probably marginally faster at its limits. I'm still fluent in QWERTY (I'm typing this message with qwerty to make sure it still works :)), so I can switch if needed, or if I'm using an unfamiliar computer (or a phone, etc). Moving to Colemak completely solved the frequent wrist and hand pain I got while typing using QWERTY. Others have had the same experience.
This is ignoring the fundamentally-different issue that was raised, which is that the service boundary introduces a new failure point that doesn't exist in a function call. What you're describing could just as easily happen in a service call, IN ADDITION to the service just not being reachable.
> For the probably best known example, Unity used to have an IMGUI [1] but they've actively moved away from it. It's still there in vestigial form, the API is not removed, but game developers don't really use it.
It's true that the newer retained mode GUI has supplanted the older IMGUI for "game UI" (e.g. what users interact with when playing an actual game built with Unity). On the other hand, the Unity editor itself is still built entirely with their immediate-mode GUI library, and I haven't heard of any plan to move away from that. Building "editor-like" tools (including custom user tools) is still significantly easier to accomplish using immediate-mode libraries.