Thanks for this insightful comment. I shall remove my head from my arse (I'm British) for just a moment so that I can see the monitor sufficiently well to type a response.
The article covers a number of areas where scripting languages fall down in practice as a solution for fast iteration in many area of game development. Please see section 15.2.1.
It uses shared libraries (DLLs) to do so, but manages the creation of these for you so you don't have to set it up. Only the required changes are re-compiled and linked into the shared library, which improves turn around times over approachs such as UE4's Hot Reload which recompiles the entire game lib.
I use RCC++ daily as part of my development routine, and although you can introduce problems which mean you need to relaunch the program, the fact that you save having to do so most of the time is a big win for iteration.
Yeah, I'm all for fast iteration, was just musing aloud if there's some extra benefits to using Rust.
For instance your crash protection catches execution failures, but what about data failures? If you've got a write-past on an object nothing is going to be keeping you from destroying the rest of the world(unless all allocations in a hot-reload scenario are constrained to separate pages that you can protect?).
Seems like a lot if things you're trying to avoid by catching crashes are built-in to Rust.
The issues you mention exist in C++ without runtime compilation, so don't pose a particular blocker to using runtime compilation when you want fast iteration in C++. This is all intended for development environments, so 'destroying the world' simply means closing the application and restarting, which without RCC++ is something you have to do every time.
So there may be benefits to using Rust, but the issues you've posed are not ones I've found were my primary concerns when working on code which needs fast development iteration.
Please do comment here, on the blog or via twitter to @dougbinks. I'm on European time so may not get around to replying until tomorrow, but I'll try to reply to any questions that come through asap.
Cilkplus is a valid approach if you are interested in using a task and data parallel language extension available on Intel's compiler, newer variants of gcc and Intel's fork of clang. As mentioned in the article a more comparable library for standard C++ is Intel's Threaded Building Blocks.
I used to work at Intel and was a technical lead for games developer architecture feedback and ran the multicore gaming initiative for a while. The feedback on cilkplus was that it didn't allow sufficient control, and as a non-standard language feature posed issues for porting to some systems. Intel's TBB however has been used by some games developers, and its API has evolved features in response to game developer feedback. Most games developers however prefer to roll their own.
Note that I didn't downvote this, but if you wanted to implement a task scheduler (the subject of the post) using cilkplus wouldn't be an obvious starting point.
The task library enkiTS has a C interface, though this simply wraps the C++ implementation. Writing a C implementation from that interface would be pretty much the same, however the virtual function and inheritance would be replaced by a function pointer and plain struct.
