While I find your point interesting by itself, being a game developer, I feel there are still too many unknowns in your argument to catch the attention of any real studio. In the following, I pose a set of questions that I think you should address in your article for a more solid argument. Bear in mind that I am no Julia user, so I don’t know the answers.

1. Game development is mostly done in Windows. Many promising languages are tied or only properly tooled for Linux/Mac. Would that be an issue for Julia?
2. Game code is almost always divided between the “engine” and the “game”. The “engine” is the part which has all the time consuming routines, like rendering and physics, while the “game” part uses the engine functionality to create the game. Do you mean Julia for both or just the last?
3. Engine code is not just SDL 2 or SFML, it has to go all the way to OpenGL, DirectX and Vulkan to fully utilize modern hardware. Can Julia effectively talk to these C APIs in a decent manner? How hard is to create bindings?
4. Engine/Game code is also run on far more devices than the average software: Windows, Linux, Mac, Android, iOS, Xbox, Playstation, Switch, etc. Could Julia be run on all these architectures? Would it be too hard to port if it doesn’t?
5. Game code is not required to be fast (unlike engine code). That’s why it is often not done in C++. Thus, “Julia is fast” is not really an important point for game code. However, game code can get really huge, thus, maintainability is much more of a concern. How would Julia compare to C# in ease of maintenance and refactor?
6. How is Julia support for linear algebra so far? Is it as good as NumPy (or better)? Engines usually have to implement a lot of vector / matrix / quaternion code by hand. Having it built-in would be nice.

Thanks for the article. Looking forward to hearing a bit more on Julia for game dev. I hope these questions also help you understand a bit more of what game developers expect of a language and what they don’t.