does D already have too many language features ?

[GreatSam4sure]

On Tuesday, 31 December 2019 at 00:39:01 UTC, H. S. Teoh wrote:
> On Mon, Dec 30, 2019 at 11:59:27PM +0000, GreatSam4sure via 
> Digitalmars-d wrote: [...]
>> [...]
>
> +1, pay-as-you-go.  I've been wanting this for a while now.
>
> Keep in mind, though, that using LDC with --gc-sections *does* 
> in fact trim the fat down significantly.  Only thing is, you 
> need to be careful in how you configure it, and some code may 
> break if they implicitly assume the existence of certain 
> sections that aren't referred to directly (such code should be 
> very rare, though, and whoever would write such code probably 
> already knows not to use --gc-sections so it shouldn't be an 
> actual problem in practice).
>
> I've tried this with dynamic libraries created for Android 
> before, and it works like a charm (~1.3 MB bloated .so --> 400+ 
> KB with --gc-sections and a custom linker configuration file -- 
> and this is *with* a significant amount of Phobos usage, so 
> we're not talking about straitjacketing yourself with -betterC 
> here).
>
>
>> [...]
>
> I find myself wishing the same thing too, esp. when two 
> features, when used together, interact (break :-P) in 
> unexpected ways.  Most recent example: Grapheme[] interacts 
> badly with .map.
>
> OTOH, because D has so many features that have complex 
> interactions, it's almost unavoidable to have some combination 
> of features that nobody has put to use together before, or they 
> haven't used it thoroughly enough to uncover the problem spots.
>  The only thing I can propose here is, please file all such 
> bugs to bugzilla so that they don't get forgotten.  Maybe 
> somebody should come up with a fuzzer specially geared for 
> finding problematic combinations of features (seems hard to do, 
> though, since it's not obvious how a set of randomly-picked 
> features "ought" to interact and what the results should be, so 
> you can't exactly automate such a thing).
>
>
>> [...]
> [...]
>
> Have you seen Adam Ruppe's latest jni.d?  Barring some current 
> limitations, it lets you interoperate D code with Java via JNI 
> almost in a transparent way.  The fact that this is possible at 
> all is absolutely amazing, and a testament to D's awesomeness, 
> and I hope sometime in 2020 Adam will come up with a way to 
> solve the remaining issues so that jni.d can become a general 
> solution to D <-> Java interop.  Just think of the huge amounts 
> of Java class libraries that can be made available to D at the 
> press of a button.  This is HUGE.
>
>
> T

Thanks for your patient and detail explanation for the issue at 
hand.

The feature set of D is thoroughly awesome. I am amazed at how a 
language of these feature sets can be simple to write, precise 
and we'll readable with the raw power of C and C++. I am hoping 
that the D community we know that they have a beautiful language 
in there and maximize it to their language.

D is well ahead of most languages with great publicity out there. 
What D need is through polishing not triming.

I am aware of Adam JNI but I have not really understand how to 
apply it. I have ask for tutorial he is yet to reply