Is it time for D 3.0?

Paulo Pinto pjmlp at progtools.org
Sat Mar 28 08:17:36 UTC 2020


On Friday, 27 March 2020 at 15:56:40 UTC, Steven Schveighoffer 
wrote:
> There have been a lot of this pattern happening:
>
> 1. We need to add feature X, to fix problem Y.
> 2. This will break ALL CODE IN EXISTENCE
> 3. OK, cancel the fix, we'll just live with it.
>
> Having a new branch of the compiler will provide a way to keep 
> D2 development alive while giving a playground to add new 
> mechanisms, fix long-existing design issues, and provide an 
> opt-in for code breakage.
>
> Some issues I can think of:
>
> 1. The safe by default debate
> 2. pure by default
> 3. nothrow by default
> 4. String interpolation DIP
> 5. auto-decoding
> 6. range.save
> 7. virtual by default
> 8. ProtoObject
>
> Other languages evolve much quicker than D, but break things 
> only in major updates. D seems to "sort of" break things, 
> there's always a risk in every release. We try to be 
> conservative, but we have this horrible mix of deciding some 
> features can break things, while others are not allowed to, and 
> there's no clear guide as to which breakage fits in which 
> category.
>
> If we went to a more regular major release schedule, and 
> decided for a roadmap for each major release what features 
> would be included, it would allow much better planning, and 
> much more defensible breakage of code. If you know that your 
> code will only compile with D2.x, and you're fine with that, 
> then great, don't upgrade to D3.x. If you desperately want a 
> feature, you may have to upgrade to D3.x, but once you get 
> there, you know your code is going to build for a while.
>
> We could also not plan for many major releases, but at least 
> move to D3 for some major TLC to the language that is held back 
> to prevent breakage.
>
> I work occasionally with Swift, and they move very fast, and 
> break a lot of stuff, but only in major versions. It's a bit 
> fast for my taste, but it seems to work for them. And they get 
> to fix issues that languages like C++ might have been stuck 
> with forever.
>
> The biggest drawback is that we aren't a huge language, with 
> lots of manpower to keep x branches going at once.
>
> I just wanted to throw it out as a discussion point. We spend 
> an awful lot of newsgroup server bytes debating things that to 
> me seem obvious, but have legitimate downsides for not breaking 
> them in a "stable" language.
>
> -Steve

I think in any case something is required, not sure if D 3.0 
would be it though, D is already known for having had too many 
unfinished features, even if the reality isn't as bad as those 
people portray it.

For me personally, I don't care that much about D's 
metaprogramming capabilities, so D lost me when C# 7 started 
adding features taken from Midori project for low level 
programming, and when GraalVM graduated from Oracle Research labs.

Java and .NET have OS vendors backing, distributed computing, 
game industry support, big data, to sell as "why use X".

Swift, Objective-C have Apple's mighty hand to sell as "why use 
X".

Rust has the message of "security above anything else" and now 
has Apple, Microsoft, Google on boat as well, doing OS features 
in Rust. All of them are hiring Rust developers currently.

Even though those are the same companies that are heavily 
invested in C++ eco-system, and keep doing strong investments 
into ISO C++, compilers and IDE tooling.

NVidia, a strong C++ house is now using Ada as well, for high 
integrity firmware development.

So D 3.0 or not, what D needs is to finally get is act together 
about what story the community wants to sell.

If this doesn't happen, I have the feeling that D will eventually 
die when the core team for whatever reason decides to focus 
elsewhere.

--
Paulo


More information about the Digitalmars-d mailing list