One point I do want to bring up with C++ is that it is an obstacle to many people, like with the UPBGE project, where the main developer is leaving and people are desperately calling “Does anybody know how to program in C++ properly without adding more bugs and performance issues ?”.
You can learn to start coding with Rust in a month, without half of the risks of introducing hard-to-track bugs and undefined behavior. Even if you are not an expert you can start learning and contributing to the project. In a community project, especially one filled with beginners, coming by the C++ experts necessary to contribute meaningfully to the engine is difficult. I’ve also been a part of a couple of other game communities where everyone groans and moans about C++, not that it is a bad language, but it does produce a lot of pain for the coders, especially beginners.
The difficulty of C++ isn’t just for beginners, either. In a blog post by PingCap they said:
The core team members are experienced C++ developer with rich experience in large C++ projects. But the seemingly inevitable problems in large projects like Dangling pointers, memory leak, or data race make them shudder at the thought [of writing a database in C++].
C/C++ used to be a necessary language that filled a use-case that no other language could. Just like we found that Haxe can’t do the manual shared memory that is necessary to support a CPU cloth solver and C++ would solve for that, but with Rust, now, more people can write programs that are just as efficient as C++, without half as much experience. Not that I’m downplaying experience; there is no replacement for experience, but dealing with something that is more difficult than necessary doesn’t help anybody if there is no reason for it.
That’s just my perspective on the C++ instead of Rust deal. I don’t have anything against C++ or using it, but that doesn’t mean that I would ever use it if I didn’t have to. Given a choice, I think Rust is a better route.
I completely agree. I have tried to involve @lubos in this, but he can be hard to get in contact with. I think this is an important subject though that is critical to the future of Armory, or at the very least critical to my future involvement in the project. Its not like I’m saying, “Guys if you don’t write this thing in Rust I’m forking it”, but what is of critical importance to me and my team is whether or not Armory is going to be able to scale to the point of competing with engines like Unreal or Unity. It has to do with the vision of Armory.
At this point, I actually don’t know what the vision of Armory is. Only @lubos can tell us that. Why is he making Armory. What does he want to accomplish. This is maybe the most important component of any project. What is the vision?
If Armory is not event meant to compete in performance with big name game engines, then this is irrelevant. Haxe is sufficient and going through the undeniable pain that a rewrite, even a partial one, would entail would be completely against the vision of Armory and would not support its direction.
On the other hand, if Armory does intend to compete with other major engines, like many enthusiasts on this forum believe that it could, then I don’t believe that it can while being written in Haxe. It will impose a limitation that will be impossible to overcome within the limits of that language. ( And I really like Haxe so this is not me bashing on that language, I heavily considered whether there was any other language target that we could add to Haxe that would make this a non-issue, but I could come up with nothing short of removing Haxe’s dependency on a garbage collector, which is impossible. )
When it comes to Armory, I have to consider what is the best decision for my team and the values that we have as an organization. Having a desire to make large scale games in the future, it would not be wise for me and my team to invest years of development in an engine that will not be able to scale with our organization.
I love this community and I have spent many, many hours investing in it over a period of almost a year, but I must make decisions that support my vision, just as Armory must make decisions that support its vision. Defining what Armory’s vision is is paramount for the project.
I understand that. If we had to make something new that wasn’t Armory, so be it. What would not be a return on investment would be investing years into an engine that fails us when we get the game made.
Summary: This needs @lubos’s input. Without it and an understanding of where Armory is going and what the vision is, all of this is pointless. If we cannot get @lubos’s input on this, then I can’t really bet on Armory for my games, above small demos and POCs. That doesn’t mean that it won’t be 100% suitable for other people’s use-cases, but me and my team’s vision goes beyond having the limits that Armory has today. That was the purpose of my experimentation and investigation for Rust in Armory, to remove the limits that are showstoppers for using Armory in my team.