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].
1. https://forum.dlang.org/post/mailman.2288.1523320489.3374.di...
What's your reasoning behind preferring GC to Rust's automatic memory management?
Out of curiosity, which GUI bindings did you try/want?
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.
echo "million dollar mistake" | sed 's/mil/bil' # :)Why? Is it because the code you see is not the code that runs?
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.
Which one(s) do you use?
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.