In the end it's all about engines and libraries, and engines usually dictate the language.
1. Learn GDScript
2. Grow frustrated with duck typing
3. Learn that you can switch to C# and still use Godot
Godot 4 having two first class languages is such an odd paradigm.
Unity used to have 3. Boo (Python inspired), UnityScript (JS inspired) and C#. I'd say for a time UnityScript was even the most popular (back in the days they still called Boo and UnityScript Python and Javascript). But over time they've whittled it down to just C# as the audience switched from hobbyists prioritising accessibility to studios prioritising performance and maintainability.
Unreal also used to have UnrealScript, dropped it, but seems to be trying again with Verse.
What a waste of time and effort when there are other categories that game developers care more about.
In terms of C#, they did get funding of $USD24,000 for implementing it: https://godotengine.org/article/introducing-csharp-godot/#ac...
And while I'm no fan of the language I do see the strategic value in potentially providing a migration path from Unity.
> GDScript is a dead end,
Do you mean in terms of it being a "single use" language?
> and they're making their own physics engine?
I think it's significant to note that in both cases--creating a new language & a "new" physics engine--it wasn't necessarily their first choice.
As they've noted[0], they first used Lua & tried Python before creating GDScript.
And for Godot 3.0 they moved to using the 3rd party Bullet Physics engine[1] but decided for 4.0 to move the focus back to the custom physics engine--in part because Bullet had "a shift of focus...away from game development".
And in both cases they're developed the support in a modular fashion so that the defaults can be replaced (e.g. by Rust/Python/Nim and Bullet/Jolt) so everyone can be unhappy...or happy if they replace it by something they like, I guess. :D
FWIW I don't think anyone particularly wants to learn a single use language but the number of comments I've seen that go "Ugh, I didn't want to learn or use GDScript but it turns out I like it" is non-zero.
And, in my case, I can't argue with the results, even in GDScript for 3.0 the differences between Python & GDScript weren't huge & via the Editor integration it's just so easy to write...for the most part. (There's a reason I've spent so much time writing/using GDScript/FFI-bindings for pre-compiled library binaries--cos I'd rather write GDScript than any compiled language. :) )
With the improvements in gradual typing, optimization & quality-of-life features that come with GDScript for 4.0 it's even better. (As languages go I see Rust & GDScript actually make a nice pairing to move between--in part due to the nice `match`-based features in both.)
Also, they did just spend four years developing a Vulkan-based renderer, which does seem like something game developers care about.
Do you have any examples of what categories you see game developers caring more about that 4.0 hasn't improved on?
Godot as an engine & a project is definitely not without its faults but I don't think "futility" and "waste of time and effort" are particularly fair/generous characterizations of the labor allocation.
[0] https://docs.godotengine.org/en/4.0/about/faq.html#what-were...
[1] https://godotengine.org/article/godot-30-switches-bullet-3-p... (See note on page re: 4.0.)
FWIW GDScript has had optional/gradual typing since Godot 3.1[1] with significant improvements implemented for Godot 4.0[2].
Also, I've seen a non-zero number of people who were used to C# comment that to their surprise they actually liked using GDScript. :)
So, you know, maybe it's C# that will be the onboarding path for GDScript developers instead. :D
[1] <https://godotengine.org/article/optional-typing-gdscript/> [2] <https://godotengine.org/article/gdscript-progress-report-fea...>
So, if your ambitions are for shipping mobile apps, Unity is probably the engine for you, that's their biggest audience.
We are in the midst of the beginning of a paradigm shift.
So while you're right, it's hard for a developer right now to make a hard decision given the impending explosion of growth.
As an example, for nearly 20 years, the physics library choices game developers have had has been a small handful, and of those solutions, most use one of two major codebases.
No one is displacing that tomorrow, or next month, or even, I don't know, I'll be bold and guess 5 years from now. If anything, in 5 years, you might have one new entrant that might develop a solution worth considering.
You can absolutely have exponential growth and in major categories make zero impact to the industry.
I'm predicting we won't hit JavaScript levels of diversity (the problem space is just that much harder in gaming then in web) where the diversity itself is a hindrance but given the metrics of interest in rust and it's ease of use compared to C++ it's just a matter of time.
If I'm wrong the only think I think I would be wrong about is when this inflection point occurs. Either we hit in the future or we just passed it.
(there are a couple of externally maintained bindings though)
PS: the most serious case against C++ for game development is probably the widening gap between "modern C++" and the kind of "sane C++" that's used in the game dev world (e.g. modern C++ is moving into a direction where most new features are entirely useless/pointless for game development). That was at least the main reason why I left C++ mostly behind and moved back to C (or realistically: a mix of mostly C and some C++ where needed to talk to libraries), and I keep a very close eye on Zig to eventually replace my use of C.
This is the easiest way we can automate bindings to other programming languages without having to use larger instrumentation like SWIG.
It's definitely not the industry standard recommendation I wrote about above, but internally we have other objectives that make it sensible. And we still get to use C++.
Betting on the status quo is definitely a pretty safe bet--and particularly over the timeframes of AA-AAA game development. And particularly for someone who is wanting to pick up a job in the industry tomorrow.
> for nearly 20 years, the physics library choices game developers have had has been a small handful
Another way of looking at that is that it means there's 20 years of pent-up interest from people who want a physics library that can benefit from the past 20 years of programming language & software development methodology improvements. :)
> If anything, in 5 years, you might have one new entrant that might develop a solution worth considering.
I think it's important not to discount the impact build tooling like cargo can have on adoption of Rust libraries and the potential for developing libraries in Rust but also exposing them via C and/or C++ bindings and gain adoption via that path as well.
And, due to a combination of "starting at the same time" & build tooling, the potential for cross-industry cooperation on development is greater too. (Questions about fields of endeavour aside, I note that Rapier physics-related projects are sponsored by both game companies & a mining-related company[0].)
(And with regard to scientific computing & Python--well how many people know or care whether the "fast" library they use with Python is implemented in Rust or C++ as long as it's stable & reliable?)
> You can absolutely have exponential growth and in major categories make zero impact to the industry.
True. From my limited perspective it all comes down to whether Rust can deliver on the promises it makes & whether it can make the cost of switching compelling enough for teams to move.
But there does seem to be quite a few people who are putting in a lot of work to try make that happen.
Of course, it's entirely possible the games industry decides against such a wholesale change in which case I guess anyone who learned Rust in the interim will just have to take a less underpaid job in a different industry. :)
[0] <https://dimforge.com/blog/2023/01/22/the-year-2022-in-dimfor...>
I guess by someone announcing their confusion they are also announcing the fact that they are NOT part of THAT group of humans. Or they just want to be a smart ass. Pick one.
It's Kotlin these days (your point still stands).
I've been trying to (lazily) make games for years. It's hard.
But, like, it literally doesn't? The fact that it's a different language nowadays (though still the same runtime?) means that there's no One True Language for Thing X. Times change. Today it's FooLang, but in a couple of years, when the stars align just right, it may be LangBar.
Embrace-extend-extinguish is a tried and true strategy to overcome entrenched languages, I suppose.
You're ignoring the very significant codebase in Fortran. I think Fortran might even be the dominant language for supercomputers, but I don't have hard statistics on the language mix.
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++.