I have chosen Go for now, after having learned Nim and Rust. I also know Ada, FreePascal, Racket, CL and a bunch of other languages fairly well. Python was never an option, because it's too slow and (subjective opinion) a very ugly language. There were clear reasons why Go was the best choice for me:

Pros:
- large infrastructure, many third party libraries
- good tooling
- fast compilation speed
- reasonably fast executables (fast enough)
- (just) good enough GUI bindings - although it almost failed on that one
- automatic garbage collection
Cons:
- lack of generics
- a bit too much verbosity (if err!=nil)
- million dollar mistake

Subjective assessment of the other languages (for me, and my type of projects - remember, a programming language is only a tool for a certain purpose):

- Nim is a great language, but unfortunately seems to be eternally unready for prime time. Lack of complete enough GUI bindings.

- Rust is a convoluted language and has no garbage collection. It is marginally better than Ada at the cost of readability, has a number of minor misfeatures, and an unnecessarily steep learning curve. I predict it to have the same complexity or higher than C++ in ten years from now, with all the disadvantages and security issues this brings. Especially macros are a very, very bad idea. (They also count against Nim in my book.)

- D is a very good language and on my list of things to learn. Reasons for deciding against it were primarily its nearness to C++ and the express intent of the developers to get rid of garbage collection in favour of some convoluted, needlessly complex borrow checking. (Unfortunately, D also has macros, but they are less obtrusive and less needed than in Rust.)

- C: dev time too slow

- C++: dev time too slow, too many pitfalls (even if you use just a subset, at some point you will have to deal with esoteric code and bugs that require 40+ of experience to understand); ugly language.

- Kotlin: Java VM is out of question, the long-term technology support on some platforms is too uncertain.

- Crystal: issues with multithreading (if I remember correctly), lack of a good enough GUI binding.

- Java: out of question - I consider it legacy technology, I've used it in the past and found the frameworks to be horrible (too much OOP); ugly language; future VM support too uncertain on some platforms.

- Julia: very nice language, fast; it lacked a good enough GUI binding last time I checked, but once it has one, it will be on my list of things to test.

- Zig: interesting but too close to C, no garbage collection, only manual memory management.

- FreePascal/Lazarus: probably the best GUI support but mostly manual memory management and felt kind of old; basically, I didn't choose it for fear of accumulating too much technological debt.

- Ada: probably the static language I like the most, has everything I need, but is pretty much dead - not enough third party libraries, single vendor lock-in, only GTK as viable GUI option, fear of accumulating too much technological debt; it's a pity, because I think it's the best language among those mentioned so far.

- Racket: my main language for the past 20 years, I have developed successfully GUI applications with it, large tooling, fast enough, BUT: application startup time too slow, rich text editors too sluggish, GUI slightly too limited, professional deployment can be complicated (by professional I mean with all correct metadata, icons, according to OS guidelines, code signing, sandboxing, etc.), dynamic typing bad.

- CommonLisp: probably a good choice for high-tech long-term, large-scale web-based applications like booking systems or scheduling systems; libraries suffer from lack of documentation, executable sizes and memory consumption fairly large, bindings to C/C++ libraries notoriously incomplete or undocumented; dynamic typing bad.

Okay, that's it. These are all purely subjective evaluations for the purpose of writing fun, fast, compact, mid-size cross-platform GUI end-user applications. I should mention that in a more professional setting I would probably bite into the sour apple and just go with C++/Qt. But that wouldn't imply having fun, which is one of my goals.