dlangui VS dcompute

Some months ago i started making a new game engine in Free Pascal[0]. D however was the language i considered the most of all alternatives due to its fast build times (at least for DMD) and metaprogramming and compile time function evaluation and code generation abilities that would help a lot to minimize boilerplate and automate things. In fact i chose FPC less for the language and more for other reasons - as a language i think D would fit better.

The two main reasons i chose Free Pascal are (both of which are important):

1. There is a strong aversion to breaking working code in FPC which to some extent is also part of the overall ecosystem. Code i wrote 20 years ago still compiles because any new features are made so that they don't break existing code. Exceptions exist, like when how string are handled changed, but that was a quick fix (in all of my programs i only had to apply a single line fix twice).

I don't know D's story on that but i've heard that there were updates to the D compiler that broke code (but i don't know how severe that is - FPC also introduced theoretically breaking code almost every version but in practice it is usually extreme edge cases, compiler bugs or very internal things and these latter only change like per decade or so).

In general i want code that i know it worked today to keep working in 10 years from today so i can focus on other things instead of babysitting it (i do copy/paste code i know that works from my existing projects all the time - even the engine i linked above contains a lot of code from older projects, the earliest bits being from 2007 or 2008).

This is even more important if i decide to switch to a new language because i wouldn't be able to use much of my existing code so any new code i write i want it to be valid for years ahead.

2. Lazarus and LCL. Think open source Delphi or Visual Basic with a real framework and a strong language. Lazarus is a "real" IDE in that it isn't just a glorified text editor attached to a compiler but it knows the language and builds a database of the entire project in memory, which allows for it to manipulate the code for you (this avoids a lot of boilerplate that come out of the verbose syntax Free Pascal has). More importantly it provides a WYSIWYG visual editor for GUIs (very important for tools) and a rich application framework (LCL) that is designed around Lazarus - these aren't independent bits someone stuck together with some glue, they are all made with each other in mind, which provides a more coherent experience than if someone stitched things together (if anything most of the issues Lazarus/LCL has is from things outside of their control, like the backend GUI toolkits). I have used a lot of other GUI approaches, Lazarus beats them all hands down.

Sadly D doesn't seem to have a decent GUI story, let alone something like Lazarus and LCL. A promising library was dlangui[1], but that is a 3rd party library that looks like the author decided to abandon[2]. Honestly IMO without something that is adopted by the core D developers (and by extension the rest of the D community) i can't see anything flourishing there - it'll instead be a bunch of independent solo devs making their own half-baked stuff for eternity (btw, yes, Lazarus/LCL are technically a separate project but in practice there is strong overlap between the two projects' developers and they share resources). At best you get bindings to Gtk+ but that has its own share of issues and bindings to other toolkits (e.g. wxWidgets) look abandoned.

I occasionally check out D to see what is the status wrt the above but for years things do not seem to change.

[0] https://i.imgur.com/1Y5hL26.png

[1] https://github.com/buggins/dlangui

[2] https://github.com/buggins/dlangui/issues/608

Shameless plug: LDC (the LLVM based D compiler) can already target CUDA (and OpenCL) and wraps its API and all of the nasty details involved in replicating <<<>>> kernel launches with https://github.com/libmir/dcompute/ with a sane syntax that's type safe. LLVM handles the codegen, and all of the "magic" is done in the library.

As noted elsewhere it seems your experience is somewhat outdated: the releases of the LLVM D Compiler (one of the two compilers worth using for production builds, the other being GDC) are buffered to the bugs introduced in DMD (which is more stable than it used to be although there are still regressions), and there is a fork based GC available for linux, but as the GC will only ever trigger on allocation, don't use it and it won't collect.

> While C++ is not by any means a great meta-language, it's improved considerably since that time.

C++ has also painted itself into a corner multiple times too, which despite being technically an improvement over the status quo are lacking severely in their utility. C++ screwed up "constexpr if" big time by always introducing a scope (which costs you a pair of {}'s in the rare occasion you need one) which means you can't conditionally insert declarations (i.e. variables, structs/classes, functions).

> but beyond the novelty you'd hardly find a mature or reliable codebase written by a team of professionals using hacks like [string manipulation and mixins].

They are a wonderful hack when you need them and nothing else will do what you want. This is not unlike resorting to macros in C++, except that its hygienic, unlike macros.

I'm not claiming the project is mature and I'm only one person, but reliable definitely out there. The most heinous set of string mixins i've ever written[1] has definitely got to be the code for generating wrappers to call the OpenCL object property querying functions (clGetDeviceInfo & friends). You need to pass a size and a void pointer to the address of the return object that you have to call once, twice or more (depending on the type of the queried property) to figure out how much memory you need to allocate to call it again.

The important thing is that the interface[2] you use to drive this code generation is very clean and return on investment for getting the generic case correct is large.

[1]: https://github.com/libmir/dcompute/blob/master/source/dcompu...