>Heavy reliance on the range interface, without automatic support for common range-like types like arrays, so calling code must be cluttered with wrappers.
But D arrays/slices are already ranges. Is this referring to string autodecoding or something else completely?
I fail to recall any situations where builtin types required wrappers often.
>Insistence on returning things exclusively as ranges, even when a single item is wanted, so calling code must be cluttered with dereferencing. (e.g. std.algorithm.searching.find)
This is mirroring C++ iterator design and IMO the right move though I agree that specifically for ranges it is rather awkward to use in practice.
What would you return instead? A pointer?
What if one wants to find the position of the element and do something after that with that position/subrange.
Even if the decision to close the door on this sucks I think they are correct - this is not a syntax problem. Adding sugar will not fix fundamental issues w/ Go's error handling.
They need to add/fix like 5-6 different parts of the language to even begin addressing this in a meaningful way.
Programming in D after C++ is like the opposite of death by 1000 cuts - its just a constant stream of finding nice little things that simplify your life or avoid footguns. You become accustomed to all the niceties very fast and its hard to justify going back haha.
D is by no means perfect (and over the years it has accumulated lots of warts) but if you know what you are doing it enables amazing productivity and almost never gets in your way. If you have an idea about solving a problem in a particular way there's almost always a path available to do just that without running into "computer says no" situations (stares at Go).
I found D 10 years before and it had the same stale feeling it seems to irradiating today and this is turning people away
The truth is it was good enough for most uses already but people waited out for someone to step up and make things better before they felt it would be worth trying D
D really shines if you do greenfield projects where you have the luxury to reinvent some wheels. Its surprisingly pleasant to see a lot of boilerplate one might expect to accumulate to just not be there because it’s either generated or is just not necessary because the language is flexible enough
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
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)
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.
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.
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.
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.
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:
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.
Standard library doesn’t provide similar functionality but it’s trivial to implement a mixin template that would implement print or hash function for any type
That being said standard formatting function can automatically print most types including user types. This eliminates necessity for automatic formatting implementation in majority of situations
You totally could create static libraries or compile stuff statically inside binaries to create a go style standalone executable but you need to recompile Phobos as a static lib for that
