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