FWIW, almost certainly.
I apologize in advance for ranting on this, but it sure tickles my "favorite FUD about Rust." So here we go!
TL;DR: The linked article confuses engine code for game code.
There are countless examples of games out there (blog posts, GDC presentations, you name it) that document the use of a first class scripting language or a VM for game code. Or more abstractly, represent game code in serialized data as a DSL. Engine code is an interpreter for the data.
ECS has been the tool of choice for treating data as your high-level DSL for as long as I can remember. Though, it's been in constant evolution and details differ depending on who you ask. Take for example these two posts from the same author written in 2007 and 2013, respectively: The Brain Dump: The Nebula3 Application Layer and Entity-Component-System Revisited. ECS isn't "solving the wrong problem." It isn't even improving performance, it's probably hurting perf. It isn't working around the borrow checker any more than handles workaround pointers. ECS does one thing only: managing your data.
Time for me to come clean: None of these links are about Rust! That doesn't mean it's impossible or even less likely to build this kind of architecture in Rust. Of course you can, the language is Turing complete, after all. On the contrary, it just means that I mostly picked references that predate Rust. And yet they support my claim that there is an important distinction between engine code and game code.
So, what about scripting languages? There are many games that use lua. Some of them are mostly lua, not just a few lines of simple glue code or "only for mods". Mods work because they use the same basis as the rest of the game.
Don't forget Python! EVE Online "has at its core the programming language known as Stackless Python." And there are a few others.
Here's a telling screenshot from the Scott Bilas/Gas Powered Games slide deck (2002) linked above:
It's as if you can s#Rust#C/C++#
in that overlong rage quit and it reads like the last 4 decades of game development wisdom. Sometimes you just have to learn the hard way. Wouldn't it be cool if institutional memory was a thing?
I don't know, maybe their point is "making game engines is hard", and they wouldn't be wrong. But the problem is they represent Rust as being unsuitable for writing engine code, then list all the problems they had writing game code. It's frustrating every time that article comes up, because the author got so close to the right conclusion. Now everyone uses it as an example of why Rust is bad for games, but none will also admit that C and C++ are bad for games.
I cannot fix this kind of confusion. But I can point out the history and the state of the art. The motivation for data-driven design does not change just because you are using a new language.
Related: