mobile? -> Ask someone else, not me.
desktop?
portable?
yes: -> Qt
needs to be fast?
Lots of heavy lifting?
yes: -> Use "simple C++"
no: -> Use Python
no:
linux: -> unless specifically for gnome, Qt.
mac: -> Mac.
windows: -> C# and MS's flavour-of-the-day framework
If you really dislike C# for some reason, Qt.
none of the above: -> probably Qt
embedded? -> Qt.
A "productive" application, something people will work with
for lots of hours and just need to get stuff done.
-> probably Qt Widgets
A "special snowflake fancy" application that should look special
and very distinguished
-> probably Qt Quick. This is going to be more work, if
it's a "productive" application as well.
Embedded or quasi-mobile applications mostly used with a touchscreen
or other limited inputs
-> Qt Quick.I've noticed that even for standalone graphical applications, it's becoming more and more common to use webapps - either served locally and accessed through a browser, or through something like electron.
Qt is very fast and very cross platform and Qt 5 together with Python is coming in a new form:
Can your end-user relink your app with their own version of QT? Yes - fine, use QT.
No? Is it OK to pay for the commercial version of QT? Yes - fine, use QT.
No - look elsewhere.
How about - our dirt cheap embedded product can not bear the cost of the (great BTW) QT library so we have to make do with something else, perhaps our own polished turd.
Or - we could easily afford it except that it's neigh impossible for us on the dev level to get an audience with the powers higher up in the company imbued with the ability to bless payments for software. AKA corporate spend. In times of budget freeze, even a request for such frivolous expenditure can usually not be done without the proper ritual sacrifice of someone in middle management. It's really hard to get volunteers.
Known workarounds are to start developing in QT (or whatever) and postpone the ritual sacrifice of middle management personell until the shit hits the fan AKA release date, or to just use something else. (It's possible a smashing success at release may make it easier to forgive and forget and not look too hard into which middle management drone should take the blame the licensing slip up.) Another workaround is to pretend that LGPL = MIT for all intents and purposes but that is frowned upon in certain corporations priding themselves with such things as ethics and licensing guidelines.
In my experience C is great for low level things (dealing with hardware, writing small low level services etc...). You don't have to deal with too many abstraction layers, memory management is generally straight forward (your average driver won't usually deal with anything more complex than a buffer queue or ring). For the type of application the author is talking about he'll probably have to deal with rather abstract data structure holding the state of the game, "a fluid flow of information coming into the app and going out of the app", concurrency issues etc...
Is it possible to do all that in C? Undoubtedly. If I was tasked to implement something like that would I choose C ? Hell now. I'd probably go with a subset of C++ like I mentioned before, Rust if the dependencies I needed were available (or I didn't mind coding them myself) or maybe even Python if I wanted to reduce development time as much as possible to get a PoC implementation live as fast as possible.