[qwytw]

> approachable language like python

Python doesn't really scale though and it's fine only for simple games/scripting (on top of a game mainly built with another language). If you're serious about game development you'll have to switch to C# or C++ eventually.

Also I don't see how C# is not "approachable" (C++ is another manner). If you're serious about programming you'll have to figure out static typing at some point anyway (and types is something you have to understand anyway when working in Python even if you can avoid that for some time).

[toastercat]

> If you're serious about game development you'll have to switch to C# or C++ eventually.

Were the creators of Undertale, Hyper Light Drifter, and Hotline Miami not "serious" because they chose to use GameMaker? I understand the pitfalls of using lightweight scripting languages, but not everyone is trying to create Doom Eternal.

[sarchertech]

For a certain type of game GameMaker is fantastic. If you know that the game you’re making is going to work with it, or if you’re just starting out, it’s a great choice.

However, you will run into limits that have nothing to do with AAA graphics, and most people are going to eventually want to expand beyond those limits. Clearly not everyone, because there are plenty of people who’d be happy making pico8 games till they day they die. But most people in my experience.

[qwytw]

You're right, it depends on the type of the game you want to build. Also I was really only thinking about the "programming" part of game development.

[badsectoracula]

> Python doesn't really scale though and it's fine only for simple games/scripting

IMO GDScript (and any scripting language in games) should be treated exactly as a language only for that (scripting) and anything non-trivial should be done in C++ anyway.

[thelastparadise]

This is often said, but is it really true?

Im thinking of libraries like torch, tensor flow, or pandas.

I'm not sure rewriting torch client code from python to c++ would typically be that much faster as most of the work is already being done on the GPU and is highly optimized (much like a game).

[teamonkey]

Gamedev - at least engine dev - bears some relation to the embedded & performance-critial world. You have this conflict between needing extremely performant code, as close to the metal as practical, but also needing rapid iteration and to represent high-level logic cleanly. This is why you almost always end up with the juxtaposition of a C++ core and an embedded scripting language like Lua.

Python isn't really performant enough, or at least hasn't been in the past. Performance still matters, even for a scripting language.

In general, if your engine does what you want right out of the box with no modifications, you can go a long way to writing a game in the scripting language and - if you're not pushing it hard - not suffer any real performance issues. But as soon as you want to chase framerates, or do something unique or time-critical or computationally difficult, which is often, you 100% need that low-level language.

[jillesvangurp]

It's true right now though there are a lot of people working on different ways to get python to have near native performance. I'd say it could be a fixable problem.

I was listening Lex Friedman's podcast featuring Chris Lattner a few months ago. He's is working on Mojo, which is basically a fast superset of python that can be fast (if you opt in to a few things) and worst case just falls back to being as fast as regular python. The intention is to give people enough means that they can optimize such code to be actually fast or just run it as is.

I'm not much of a python developer myself, even though I do have to deal with it occasionally. I liked the point that he made that, for whatever reason, there are just a lot of people using python and getting access to that community of people is a good way to get traction for your tool or technology. He was talking about machine learning specifically. A lot of the experts in that field are using python. Of course all the difficult bits and bobs are outsourced to native libraries. His vision is that a lot of that stuff should be written in mojo/python and that there are no good reasons why that should be any slower.

Probably removing the gil will help (everything blocking is not cool). And the language could use some better primitives for dealing with things like co-routines. They are kind of nice to have in asynchronous code bases like games or UIs. But those are things that could be fixable and might benefit the rest of the ecosystem.

[qwytw]

> Im thinking of libraries like torch, tensor flow, or pandas.

Well the overhead doesen't really matter that much, who cares if you have to wait 10ms or 100ms etc. So yeah rewriting the Python bits is not worth it.

It's an entirely different use case though. In game dev you need fit your frame into 16ms or 32ms and you calling the methods hundreds or thousands of times every second etc. it all adds up.

[manicennui]

Not everyone wants to create a AAA-level FPS. Most languages are fine for a large number of games.

[chaostheory]

> Also I don't see how C# is not "approachable

C# is powerful and performant. I wouldn’t call it approachable though unless your background is Java or C++

It suffers from the same problem as Java: verbosity with endless choices for syntax. Why is this a problem? The “paradox of choice” is debilitating for most people. Also, since there’s no universal consensus over style, you’re going to inevitably have convention wars.

Python has many problems, but it’s easy to see how it became so popular with its one way to do one thing

[JohnFen]

> you’re going to inevitably have convention wars.

Only if you choose to. Most developers use whatever convention they personally prefer when working on their own code. When you're working on other people's code, you use whatever convention was already in use. If you're working for someone else, you follow the convention of your employer. Simples. No fighting necessary.

[chaostheory]

Yeah, that’s true in an ideal world. Unfortunately, we don’t live in one.

[JohnFen]

My point is that each of us chooses whether or not to participate in arguments. Especially when it comes to programming holy wars, which are rarely of actual importance, we can choose not to.

It takes two to tango. No ideal world is needed.