Andrei's list of barriers to D adoption

[ketmar via Digitalmars-d]

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.