News for hackers. Stuff that matters.
Re:Specification for the D Programming Language by Neku42 on Wednesday January 08, 2020 @02:59PM (#21995129)
This seems to be an increasingly growing niche where D is gaining popularity. I see more and more people turning to D where they would normally use python or R for adhoc data crunching
Re:Specification for the D Programming Language by chromatin on Wednesday January 08, 2020 @09:25PM (#21997968)
We are using D for high performance computational biology -- I brought a Go dev and a python dev both onboard with minimal learning curve. Even the powerful template metaprogramming seemed really easy for the team to pick up. I believe this is because it really has a nice design (compared with, say, C++, which I would never, ever use in general bioinformatics unless team had specific past expertise)
Re:Specification for the D Programming Language by mochomocha on Wednesday January 08, 2020 @04:19PM (#21995909)
I also use D for data & ML at work (Netflix) when standard python workflow doesn't cut it anymore. There's just so far you can go with the typical "call a popular python lib interfacing with a C++ backend" paradigm before hitting a brick wall.
Re:Specification for the D Programming Language by Demiurge on Wednesday January 08, 2020 @05:27PM (#21996436)
How far is that? What about Cython?
Re:Specification for the D Programming Language by z3c0 on Wednesday January 08, 2020 @04:10PM (#21995832)
As one of those people, I can say the reason is for the C-level processing power with the approachable syntactic sugar. Out of all the languages gaining popularity for their ability to run natively (Rust, Go, D, etc), I've felt that D is the most natural continuation of C/C++, at least syntactically. I haven't touched the language in about a year, but I'm personally rooting for it.
Re:Specification for the D Programming Language by WalterBright on Thursday January 09, 2020 @12:43AM (#21998832)
And with D as Better C, (-betterC switch), it's easy to convert your C project to D, one file at a time, and not require the D runtime library (only the standard C library is required).

The original impetus for this was so I could incrementally convert the D compiler backend itself from "C with Classes" to D.

Re:Specification for the D Programming Language by mhh__ on Wednesday January 08, 2020 @03:35PM (#21995505)
I try to use D for that (difficult because the libraries are fairly low level, I would say sparse but calling into C and C++ is pretty trivial) because, for the same effort I put into bullying python to do what I want, I can write type safe (generic) code that is both actually readable and ready to be reused if needs be. And sometimes orders of magnitude faster.

That and ranges (D/Andrei's preferred model for iteration) are excellent - in my view at least.

Re:Specification for the D Programming Language by jondegenhardt on Thursday January 09, 2020 @03:38AM (#21999502)
eBay's tsv-utils author here. A fair bit of performance benchmarking was done on the tools with the goal of exploring this type of use (data crunching). D did really well (tsv-utils are fast!). There's more info on the benchmarks page in the github repo. Perhaps the best summary is the slides from a talk I did at 2018 DConf. Links:

- tsv-utils repo: https://github.com/eBay/tsv-utils

- Performance studies: https://github.com/eBay/tsv-utils/blob/master/docs/Performan...

- Talk slides: https://github.com/eBay/tsv-utils/blob/master/docs/dconf2018...

Re:Specification for the D Programming Language by bachmeier on Wednesday January 08, 2020 @03:30PM (#21995463)
It doesn't even need to be an alternative to Python or R, since it's really easy to interoperate with both languages. This is in addition to tools like eBay's tsv-utils.

http://code.dlang.org/packages/pyd

https://embedr.netlify.com/

http://code.dlang.org/packages/autowrap

https://github.com/eBay/tsv-utils