named arguments, string interpolation, please stop.

jmh530 john.michael.hall at gmail.com
Thu Jan 11 14:34:57 UTC 2024


On Thursday, 11 January 2024 at 13:07:52 UTC, deadalnix wrote:
> [snip]
> The main problem people face with D in the real world are 
> almost exclusively of the implementation kind. The list is 
> endless (and yes, there are many bugs reports about these 
> things). I recently made a post about how the OOP 
> implementation is extremely sub-par vs what people in OOP 
> languages would expect. no change of the language required to 
> fix. See here: 
> https://forum.dlang.org/post/hteuczyclxajakrisxjd@forum.dlang.org
>
> But if you are not convinced, here are a few more example of 
> thing being implemented wrong or existing feature not working 
> right:
>  - D runtime is unable to see thread started manually (for 
> instance with pthread-create) leading to all kind of bizarre 
> behavior.
>  - Template symbols are generated as weak, which prevents 
> inlining (!).
>  - Pretty much no cross module inlining, making helper function 
> absurdly costly.
>  - scope(success) generates exception handling code.
>  - D goes virtual by default for class methods, but LTO is 
> unable to finalize (contrary to every other languages going 
> virtual by default).
>  - The GC implementation is nowhere close to where it needs to 
> be.
>  - in contracts are dynamically bound (and in the callee) 
> instead of statically bounds and in the caller.
>
> 

Discussing new features is kind of the language equivalent of 
bikeshedding. I don't have anywhere near the skills needed to fix 
any of those issues, but I could vaguely form an opinion on 
whether I like new feature X.

I think everyone has their own explanation for why D isn't 
catching on as much as people would hope. These aren't my 
reasons, but I wouldn't be surprised if there are some people who 
are turned away by these issues.

But your list is very much in line with one of Walter's recent 
posts on the other thread where he mentions how much time he 
spends working on things that no one else is working on. Some of 
these issues are undoubtedly hard to fix and not many have the 
expertise to fix them. The response from those sympathetic to the 
fork might be something along the lines that the burden often 
falls on Walter because some contributors leave. Its a tricky 
organizational problem. It's hard to have high quality/standards 
with a lot of contributors.





More information about the Digitalmars-d mailing list