vvanders

From reading the paper most of the concerns are around the write side. LMDB is the primary implementation that I know which leans heavily into mmap but it also comes with a number of constraints there(single writer, read locks can lead to unbounded appending to the WAL, etc). As with any tech choice it's about knowing constraints/trade-offs and making appropriate choices for your domain.

Can you be more specific here? You can totally do that based on OS, environment vars or even direct feature flags in the Cargo.toml. I've got a number of projects that do this and let downstream consumers decide what features they want. At the end of the day it's just a Rust program that runs ahead of the build and can do anything that you would be able to do in a normal command line program.

> ... but when it comes to configuring to use an installed library and passing the right linker flags, this becomes really tricky.

pkg-config[1] does all of that including returning linker flags. I can't think of a single case where I wasn't able to integrate with an existing library.

I'm not saying there are zero issues(I.E. passing some linker flags as a dependent crate gets annoying) but my experience having used C++ across a number of platforms(Win32, Linux, proprietary systems) before CMake existed and after it started getting wider adoption is that CMake has a significantly higher hurdle and is just harder to get things working correctly, especially under cross-compilation configurations.

[1] https://crates.io/crates/pkg-config

I've found that things like this are pretty straightforward with a build.rs and you aren't context switching between a configuration language and your target language since build.rs is just a Rust program that outputs configuration values via println.

> ... very complex applications

That's not always a feature for me, the amount of time it takes me to ramp into a complex CMake configuration vs arbitrary crate is significantly different since the conventions are well established. If you spend any time cross-compiling things the Rust experience(I.E. first-class triple support, cc crate) is miles above anything CMake provides.

"... All of these people will play a role in my ultimate success as a dystopian warlord philosopher. However, the most important person in my gang will be a systems programmer."

It's right there in the intro, truly a classic.

I think my favorite one was one that used yield[1] with the parameters being the number of frames to resume the execution of the coroutine. That was used by a number of our game designers to write AI scripting that felt close to literate programming(I.E. "move x, look for player, yield 30, if found player, go here, etc). You could build a whole AI state machine that fit into one page of code and was very easy to follow.

[1] https://www.lua.org/manual/5.1/manual.html#pdf-coroutine.yie...

When you factor in LuaJIT[1] and the incredible performance/zero-overhead-FFI[2] it really is a neat language.

[1] https://luajit.org/

[2] https://github.com/dyu/ffi-overhead

While this is not wrong it's also missing the fact that EVs use AC VFD motors that don't need to have a closed loop response under traction loss due to the fact that the AC field will slow down the wheel of it tries to over speed just by nature of how the mechanism works. This helps keep the wheels in the static friction region where traction is highest. In trains this and other factors[1] contribute to a 2x increase in traction over DC motors. With an ICE you have all sorts of momentum in the flywheel and drivetrain that are trying to runaway until the system/driver reacts and compensates.

[1] http://www.republiclocomotive.com/ac-traction-vs-dc-traction...

[1] https://en.m.wikipedia.org/wiki/Cell_(processor)#Synergistic...

Yes Unity does better but there's a ton of momentum with established commercial engines that have tens of millions of dollars invested in them. It was only recently that Godot has started making some inroads on the indie side of the engine space.

Rust benefits a bunch from second mover advantage here but cargo is just soooo good in comparison. Sane defaults, descriptive commands and stuff like cross compilation that can be hell-on-earth with CMake/etc I find actually easier in cargo + cc crate + build.rs for small/medium libraries.

If you care about compile/iteration times you can get them down to a reasonable level, Bevy does a good job splitting the heavy lift part into a section that is linked dynamically[1] which leads to pretty reasonable compile times even in something Rust based.

That said most of the high-churn areas I've seen drop to some scripting language(ex: Lua or others) for both hot-reload and avoiding compile times. Usually the heavy compute pieces are out in native with orchestration in scripting or something more flexible.

[1] https://bevyengine.org/learn/book/getting-started/setup/#ena...

You're right in that not running the workload if possible is the best power savings but if you can't do that moving it to more efficient usage is a good way to make large inroads on power usage.

IMO reference counting(be it in C, C++, Swift/ObjC or Rust) is a sign that you have ambiguous lifetimes and strongly correlates with a design that has punted on what components "own" what parts of memory.

Even in my C++ designs I push more strongly toward single owner patterns(member vars, std::unique_ptr) and if an adjacent system needs access usually an opaque handle(that can fail to return a value) is the better than using something like std::shared_ptr.

To the point at hand, I would argue that Rust pushes more towards the single owner model with some sets of escape hatches(Rc/Arc, RefCell, etc) when upstream rigid requirements force some of this ambiguity. I've yet to see a non-GC'd language that does a better job here, and I've found the default Rust guard rails to be quite good, even at scale across developers who may not have the depth of background to understand all of the tradeoffs involved.

C# actually does really well on this front in that it brings in value types front-and-center, although similar types of capabilities exist in Java(either through ByteBuffers or sun.misc.Unsafe) if a bit harder to use.

CVS though, uf da. We had some rough times in gamedev land until we moved over to SVN and then Perforce with proper proxies for a distributed team.

The other approach(and the one most RTS games use) is called lockstep where you have a fully deterministic game simulation and clients send each other's input's to each other and all of them run in "lockstep" with each other. Generally this adds latency but has the benefit of scaling well to a large number of entities. It also requires your game simulation be deterministic which is extra fun when you have crossplay with different CPU architectures/OSes. If you've ever hit a "sync/divergence" error in those types of games that's usually a gamestate checksum that failed and bailed(some games were smart enough to re-sync the gamestate which is similar to host migration in P2P titles).

Rollback is a bit of a hybrid of both where you run closer to dead-reckoning(I.E. clients simulate all entities) but as inputs from other clients come in the simulation is re-wound to that point(I.E. "rolled back") and then re-run with the new inputs + some smoothing. It works really well for reaction based games which is why you see it widely used in fighting games and an early version of that was used in many FPSes for critical things like hit-tests(with fun byproducts of getting "warped" around a corner in high latency situations if getting hit changed things like movespeed).

Networking in games is an absolute blast, you have the fun technical problems outlined above but there's also an aspect of psychology/game design where a lot of what you're doing is "masking" latency in a way that's not visible to the user. A simple example here is playing hit sounds/effects locally but resolving them server-side. The 100-200ms latency isn't noticable if there are things happening client-side. From the game design side you can have games where it's about predicting where an action will happen 200ms-1000ms+ in the future which is much more latency tolerant. It's how games like Subspace[1] back in '99 was able to do 100s of players with 250-500ms latency and still have a high fidelity game since it was all about prediction instead of twitch reaction.

[1] https://en.wikipedia.org/wiki/SubSpace_(video_game)

Also the build loop on Bevy is pretty good from what I've seen, esp if you enable the dynamic linkage flag in development. The ECS system is really well thought out even if the engine is a bit sparse I think it shows a lot of promise to build a highly efficient game loop.

What's interesting is this appears to be driven by Right to Repair legislation that's been making it's way through various states. There's an explicit ask that AFBF not support any Right to Repair legislation:

"AFBF agrees to encourage state Farm Bureau organizations to recognize the commitments made in this MOU and refrain from introducing, promoting, or supporting federal or state "Right to Repair" legislation that imposes obligations beyond the commitments in this MOU. In the event any state or federal legislation or regulation relating to issues covered by this MOU and/or "Right to Repair" is enacted, each of AFBF and Manufacturer reserve the right, upon fifteen (15) days written notice, to withdraw from this MOU."

[1] https://www.bbc.com/news/business-64206913

If you really want to do it, side projects are the way to go. There's a ton of good engines out there and way more resources than when I was in the industry.

The RF nerd in me thinks it could be interesting but the skeptic makes me wonder how forgeable coverage would be and if the overhead of coverage challenges uses more of the limited spectrum than carrying actual data.

One fun thing we did with co-routines was build literate-style scripting for our designers to define AI routines. They could write them in a linear/semi linear way with yield(<number of frames to wait to re-execute>) that allowed them to script all sorts of interesting behaviors without extensive programming knowledge.

We also ran the whole thing inside a 400kb pre-allocated block, it's an incredible powerful, embeddable language.

[1] http://www.mobilinkd.com/

That said I agree 100% with building tiny games in an iterative fashion to understand the engine you're using, or taking a very narrow "vertical slice" to help flush out where the technical or game mechanic issues will be.

There's a wealth of good engines out there today where you're building on in some cases literally decades worth of development that can accelerate a lot of the work involved in building a game(and there is a lot of work there).

With the dynamic link feature it takes about 1s to compile + link and Bevy is very much a nontrivial runtime/library that makes use of lots of Rust features.

In my opinion Bevy may be one of the better ECS implementations I've seen, as ex-gamedev it's just very well thought through. It's never going to supplant Unity or Unreal but that's less of a language issue than just the scope of those codebases.

You're seeing a lot more of it showing up in OSes across Android, Linux and I've seen a fair bit of movement in the windows space as well.

As for IPC, C/C++ doesn't help you their either, that's more of a framework level concern. If anything the threading model helps when you're doing concurrent IPC dispatch(ex: MTA COM or equivalent high throughput IPC) and preventing data races.