>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
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