Non ho usato tutte le librerie e i framework GUI del mondo, ma non credo che la maggior parte dei linguaggi faccia le GUI estremamente bene. In termini di supporto e documentazione, non si può davvero sbagliare con C#, Java o Python e i loro rispettivi framework. Potete costruire una GUI funzionante con Python e tkinter se non vi interessa l'aspetto della vostra GUI. Tenete a mente che ci sono degli aggiramenti che potete fare per rendere le applicazioni tkinter più moderne, come usare immagini e icone personalizzate quando possibile, ecc.
I buoni programmi GUI non sono intrinsecamente facili da scrivere, non importa in quale linguaggio siano scritti, quindi potete fondamentalmente dimenticare la parte facile della vostra domanda.
Al giorno d'oggi, probabilmente userete una sorta di editor visuale per ottenere rapidamente i vostri componenti sullo schermo, ma potete codificare voi stessi i layout se siete pronti per la sfida.
Ho deciso di mettere il mio gioco attuale in attesa per ora e ho deciso di costruire un editor di mappe 2D in Java Swing. Non sarà una specie di stupido giocattolo, finirà per essere piuttosto avanzato, con la maggior parte delle caratteristiche di base che vi aspettereste in un editor di mappe 2D. Non ho mai costruito un editor di mappe prima, ma sto usando altri editor di mappe 2D come ispirazione. Perché sto usando Swing? Perché ho intenzione di usarlo per fare livelli di gioco per i giochi che farò in futuro e che faranno parte del mio portfolio e ho pensato che dato che sto già usando Java per i miei giochi di portfolio, potrei anche usarlo per i miei strumenti. Inoltre, Java Swing sembra abbastanza moderno senza essere troppo sofisticato. Proprio quello che voglio.
Dalla mia esperienza finora, Java Swing è una vera spina nel fianco. Cosa lo rende una spina nel fianco? È il fatto che usa così tanti tipi diversi di gestori di layout, e puoi mischiarli e abbinarli. Questa sembra una buona cosa, ma è un po' cattiva perché a seconda del gestore di layout che usi per specifici JPanel e JFrames, alcune funzioni di JComponent o non funzionano o funzionano, ma hanno un comportamento diverso.
Un primo esempio è l'uso di BorderLayout in JPanels e JFrames. BorderLayout sembra permetterti solo di posizionare un componente in 5 posizioni diverse all'interno di un frame e allungherà automaticamente i tuoi componenti per adattarli ai contenitori. Chiamare i metodi di dimensionamento sui widget quando sono all'interno di un contenitore configurato con BorderLayout è spesso inutile, perché il layout ignora semplicemente le vostre richieste di dimensionamento. Java non fornisce nulla in termini di comunicazione che le vostre chiamate ai metodi stiano facendo un cazzo.
Se state usando il BoxLayout, alcuni metodi di dimensionamento dei widget sono presi in considerazione e dimensionano effettivamente i widget correttamente, ma usando gli stessi metodi in BorderLayout non succede nulla. Può essere difficile memorizzare ciò che un certo layout permette e prende in considerazione in termini di metodi JComponent.
Per riassumere, dipende dalle vostre esigenze. La maggior parte dei linguaggi, a parte quelli a livello di sistema, saranno in qualche modo decenti per la programmazione GUI, ma non perfetti. Non credo proprio che sia una buona idea programmare una GUI in C al giorno d'oggi se non avete mai fatto una programmazione GUI prima e non avete davvero un motivo per usarla. Fondamentalmente, è un incubo nella maggior parte dei linguaggi, dovete solo scegliere il vostro veleno. Se scegliete il C per una GUI, probabilmente finirà per essere più un mal di testa di quanto lo sia attualmente per me in Java e, ragazzi, è un mal di testa, mal di culo, mal di palle e tutto ciò che sta in mezzo.
Ho scoperto che combinare BorderLayouts, JPanels e BoxLayouts tende a funzionare molto bene, ma prevedo che incontrerò un sacco di problemi più tardi quando avrò bisogno di componenti e layout più complessi.