named arguments, string interpolation, please stop.

[Don Allen]

On Thursday, 11 January 2024 at 13:07:52 UTC, deadalnix wrote:
> I have been in the D community for a very long time. I have 
> seen D successfully deployed in companies, and the pain points 
> associated with it. I have seen D fails to catch on in 
> companies and why that is has well.
>
> Let me tell you, none of this has anything to do with feature D 
> has or does not have. At large, D has more features than most 
> languages.
>
> D chasing the next feature like a crack addict chase his next 
> dose. With the same level of success.
>
> 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.
>
> These are just simple thing that I have on top of my mind, but 
> there are a ton more. I have seen some of the above cause 
> projects to fail. None of them require any significant language 
> change.
>
> There is nothing features like string interpolations or named 
> argument can bring to the table that could pay for the 
> implementations problem of existing feature. The cost benefit 
> analysis is just a big L for D: the fail to address the main 
> pain points, while causing massive breakage in the tooling 
> ecosystem (syntax highlighting support in 3rd party IDE, code 
> formatter, etc...), and it cost real time and resource to 
> upgrade these, or come at the cost of other quality of life 
> stuff nullifying their benefit (for instance, the quality of 
> syntax highlighting for D has degraded significantly in vim and 
> sublime text over the past few years).
>
> In addition, some recent D features, such as @nogc, has been a 
> productivity disaster int he wild. While the impact might not 
> be felt on smaller codebases, the infectious nature of the 
> feature makes large codebase significantly harder the refactor 
> than they used to be.
>
> Each time we take steps in that direction, D becomes a harder 
> sell.

While I don't have a long history with D or deep knowledge of the 
implementation details, the thrust of this message sounds right 
to me.

The calls I've seen recently for more language features strike me 
as misguided. As the above says, D is already a big language, 
lotsa features. It's also well-documented, compared with what 
I've seen with comparable languages, even Rust, whose 
"affectionately named" (seriously?) Book is simply awful, in my 
opinion.

I think Walter and Co. need to create a plan to address D's real 
weaknesses, e.g., tooling, issues with Phobos, and problems with 
the implementations of existing features. Lack of features is not 
among them, in my opinion.

This should be discussed with this community and we should, in 
turn,  avoid the temptation to derail the Big Picture discussion 
by descending into talk of technical details prematurely. Make 
your best plan first. Then you can talk about how to implement 
it. This may cause an iteration back to the plan, adjusting with 
what you learned by considering implementation problems.

I'm, in effect, supporting Walter's preference for 
specifications, but at an even higher level than a particular 
DIP. I also generally support Walter's tendency to say "no" 
(perhaps improving communication of his reasoning), because it's 
consistent with what I'm advocating here. Make sure what you have 
is at a high professional level before moving on to the next 
great thing.

I don't think D's future lies in trying to be more dazzling than 
the competition. I think being better engineered (Walter's 
strength) and better crafted are the dimensions that suit this 
project. Think about products like Toyotas or Seiko watches. 
While both companies have produced some highly innovative 
products, we mostly know and admire them because their 
main-stream stuff Just Works. I think of D in that category. I 
believe that if the project focuses on this and people start to 
discover that in addition to writing programs in D being a huge 
improvement over wrestling with C or C++, all the tooling is 
there and of good quality (I'm really looking forward to the new 
dfmt), so that the D software-development experience, end-to-end, 
is as problem-free as possible. People don't want to fight with 
their tools; they want to use them to accomplish their goal. 
Serve that and you've got a winner.