As someone who has spent years doing game development work, I can say it's a very labor significant mistake to use anything other than C++. You could even use C

As someone who has spent years doing game development work, I can say it's a very labor significant mistake to use anything other than C++. You could even use C, but you will end up needing to interface with C++ at some point, so at the least you'll want to write in C and use a C++ compiler for when you need things like GLM, etc. When you use non-standard languages for industry purposes where everyone else is doing their work, you will end up wanting to eventually use those tools, but not be able to, or have to write bindings for them that don't exist which means you increase your maintenance labor requirements. Worse yet, you may be deluded into thinking you can write something in your target language that will be good enough to replace the desired library--but it will more than 9 times out of 10 never have the same feature set or support or collaboration base. If you're making games, use C++. If you're doing scientific computing, use Python and C++. If you're making macOS native interfaces, use Swift and Objective-C. If you're making Android apps, use Java. I think a lot of inexperienced developers don't get bit by these mistakes until they've spent too much time in one space and even if they're successful in their own merits, they don't understand why other factors don't continue to grow in the ways they do, like: Hey I wrote a game in Ruby, but for some reason I can't find people who want to collaborate with me, I wonder why? It's because comparatively, no one is writing games in Ruby. I wrote this really cool web development library that uses Elm, why don't I have broader adoption? Because no one is using Elm. The combinatorics of every decision you make in software development have eventual consequences that sometimes take years to figure out simply because you don't have the time to ask everyone who might be a potential interactant how they feel about your decision making. If you're making a game you plan on publishing and can insulate your decision making from the output you're trying to generate in, I'll say in less than 5 years, then go for it, but statistics are already working against you in this field, why would you make your life harder on yourself? Almost everything about this craft sets you up for failure. Don't make it harder. Even people who you think know what they're doing and are core maintainers of large projects you probably know of make some really questionable mistakes and sometimes by sheer dumb luck or factors they don't understand do they still stay successful. I can tell you of one core maintainer for a multi-year run open source piece of game software doesn't believe there are significant performance characteristics between programming languages compiled to machine code versus interpreted languages when it comes to game programming. This is a guy who maintains probably the most used scripting language based game software in his niche. I also say this as one of the largest maintainers of Lua-based game software in the space. Lua is one of the if not the top used scripting languages for video games, and we just do not see the adoption we want for our products. It's overwhelmingly because our users want to use C++.