My choice to pick Go over D ( and Rust ), mostly non-technical

data pulverizer data.pulverizer at gmail.com
Mon Nov 8 09:02:53 UTC 2021


On Sunday, 7 November 2021 at 22:19:13 UTC, Ola Fosheim Grøstad 
wrote:
>
> I don't know if using C (or C++) frameworks will provide an 
> acceptable programming experience. C frameworks tend to be 
> quite distant from what you would expect from a higher level 
> language like D. You would have to modify the C framework's 
> «runtime», like making it create treads using the D runtime, 
> etc.

You're right that C frameworks programming experience is far from 
D. But I think if you are looking to get work done, it is the 
difference between having the tool there and being able to use D 
and perhaps having to use a different language altogether.

Further more I think that `ImportC` is actually an opportunity to 
show off D's meta-programming features, by presenting how lots of 
imported functions with ordered parameter naming can be "lifted" 
into one of D's nicer programming methodologies including showing 
off std.traits, template/string mixins and so on. Julia does 
similar things with their C library backends.

I haven't had to deal with making C frameworks «runtime» 
multithreaded in D, perhaps because the C libraries I tend to 
call are already multi-threaded, or it wasn't an issue for my use 
case. I think C libraries are a valuable resource to "lean on" 
and perhaps "write away" at a later date if they are not 
suitable, and `ImportC` is central to easing that pathway.

Having said that runtimes *might* become an issue in the near 
future since I am working with interop between R and D. Basic 
things like calling R functions from D and D functions from R can 
be straightforward, but I quickly discovered that since R has 
it's own runtime and memory allocation schemes as does D, there 
were some issues. Certain features in D rely on D runtime, which 
you have to negotiate carefully with R's and you have to use R's 
memory allocation if you want the data accessible in R, but I 
think these are secondary issues - they are more about extending 
functionality and will be negotiated in various ways. The basic 
functionality I require is **immediately** available with a fully 
developed `ImportC`.

As someone whose work is centred on data science C libraries are 
basically at the centre or backend of > 95% of what we do (even 
people working with JVM languages still have to call BLAS, 
Lapack, and so on). `ImportC` would make a huge difference there 
and in many other application spheres.




More information about the Digitalmars-d mailing list