On Friday, 10 June 2016 at 08:29:50 UTC, Yura wrote:
something tells me that GC would slow you down because in this field people are fighting for every percent of the performance (many simulations are running for weeks).
yes, GC will have an effect for such things. but then, people fighting for performance will resort to "dirty tricks" in any language, i believe, and in D it is not that hard to avoid GC (i'm doing something like that in my videogame and sound engines). but the great thing — at least for me — that you can easily prototype your solution with GC, debug it, and then gradually replace data structures with other data structures that does manual memory management. this way you can debug your data structures and algorithms independently.
of course, it is possible in C and C++ too, but i found that with D it is somewhat easier.
Another point is to link the libraries, with my poor background in IT, even to link the C library to the C code is a challenge, and something tells me that to link it to D would be even more challenging
i found that D is better here too, it just require some... discipline. thanks to UFCS, one can write D code that *looks* like OOP, but actualy only using structs and free functions. this way you can use `export(C)` on your public API, and still use `myvar.myfunc()` syntax in D, but have C-ready `myfunc(&myvar)` syntax to export. also, with some CTFE magic one can even generate such wrappers in compile time.
Another things where I do almost all my mistakes is: array bounding/calling the memory which was free => the result is undefined behavior. If I remember correctly the D is better with that respect?
yes. with GC, you won't hit "use after free" error. and D does bound checking on array access (this can be turned off once you debugged your code), so you will get a stack trace on RangeError.
Anyway, super easy way to use all C libraries + super active support would clearly help to increase D popularity/adoption.
and as for C libraries... i'm actively using alot of C libs in my D projects, and most of the time i do wrappers for them with sed. ;-) i.e. i'm just taking C header file, run some regular expression replaces on it, and then do some manual cleanup. that is, even without specialized tools one is able to produce a wrapper with very small time and effort investement.
tbh, i even translated some C libraries to D mostly with sed. for example, enet and libotr.
