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.
> the express intent of the developers to get rid of garbage collection in favour of some convoluted, needlessly complex borrow checking
This is incorrect. Nobody wants to get rid of the GC [1], but to offer the possibility of writing GC-free code or just work around the GC and prevent it from allocating if one wishes to do so. There is a full section on the D website about the GC and how to optimize its behaviour or work around it [2].
Okay, my apologies then. That's pretty cool and IMHO exactly how languages should do it. Give people a good GC and a way to switch it off when needed while keeping it safe. That's perfect!
Like everyone else's who prefers to have a GC. Go's GC is fine for all of my use cases and I'd rather not spend endless times musing about lifetime annotations and how to 'trick' the borrow checker into doing what I want. Technology should serve humans, not vice versa.
nimx and a bunch of others. At that time I didn't know what framework I'd want, only the requirements: Cross-platform, preferably native controls, internal and desktop drag&drop, extended clipboard support, rich text editor fields with possibilities of custom ranges, styles, and serialization, listboxes/grids with images and embedded controls.
I later decided on GTK3, not sure if it's the right idea in the long run. Nim's GTK3 bindings state:
> This package is only tested with 64 bit Linux currently.
Partly Yes. If they are used correctly, then they are fine, but often they are used to create all kinds of hidden side effects - sometimes even global side effects.
The other issue is that macro authors tend to create embedded DSLs. That makes the code hard to understand, unmaintainable and write-only-once in the long run.
Strangely, I find the Scheme and Lisp community to be pretty good at creating reasonable macros. (With exceptions, I'm not a fan of the LOOP macro.) Maybe that's because they use them less for syntactic sugar and more for really expanding the language. Still, there are too many DSLs and you can be lucky if you understand your own CL code ten years later.
Thanks. I have the same feeling about the tendency in Ruby to use magic tricks. Prefer the Python way, although it does have support for meta-programming, etc. People tend to write magic code less in Python, AFAIK.
Currently GTK3, because Qt is too large and bulky. It works, although the Go bindings are missing some essential features, Custom TextBuffer serialization seems to be missing and I hope I will be able to implement it myself or work around it.
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.