www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Future of D 2.x as stable/bug fix, and what's next for D 3.x

reply Eljay <eljay.adobe gmail.com> writes:
What is left to do for D 2.x for it to be declared "done" and in 
stable/bugfix mode only?

I haven't seen a Vision/20xxHy for a while.

What features (and breaking changes) are on the horizon for when 
the next generation D 3.x begins?

There are plenty of languages out there that have intriguing 
features that may (or may not) be good candidates to consider for 
D 3.x.

Rust with its type state, which allow for a strong memory 
ownership model for a non-GC language.  Although I think it adds 
considerably to the learning curve struggle to grapple with, at 
least for Rust novices such as myself.

Swift and Kotlin, both of which have syntax similarities aimed at 
preventing certain common categories of bugs.


cousin of the ML family) that embrace functional-first functional 
programming.

C++17 and C++2a, as one of the frontrunner languages that's 
evolving in amazing ways (but sometimes odd ways), and its goal 
of backwards compatibility really has made for some awkward and 
awful syntax.  Take Spirit for example:  that's both 
awe-inspiring combined with an amazing abuse of operator 
overloading.


interesting functionality.  Some just gloss and polish and sugar, 
but some language features are very interesting.

Then there's always Lisp and family.

Thoughts?  Plans?  Roadmap?
Aug 30 2020
next sibling parent Cecil Ward <cecil cecilward.com> writes:
On Sunday, 30 August 2020 at 17:32:32 UTC, Eljay wrote:

 Thoughts?  Plans?  Roadmap?


(I may have mentioned this before, but I can’t find a relevant 
old post. Apologies if I’m repeating myself.)

I would like to see D move ahead in performance terms. Being 
faster than C/C++ is a very tall order since compilers tends to 
use common backend machinery and possibly other bits and pieces - 
I don’t know.

I would like to see ideas for features that support killer 
optimisations and better use of hardware - need ideas for this 
though. For example, D’s SIMD and parallelism support are 
excellent. Pure could be another.

I see hope for this because it seems to me that D possibly has 
more freedom to evolve than say C++ and especially C.
Aug 30 2020
prev sibling next sibling parent reply Ali <test example.com> writes:
On Sunday, 30 August 2020 at 17:32:32 UTC, Eljay wrote:

 Thoughts?  Plans?  Roadmap?



I followed the forum long enough, to understand the community (I 
think)
D is a small community of developers, who cannot afford to grant 
wishes

Other communities, who have a large poll of contributors, and 
large number of users, might be more accommodating for user 
wishes (or grant user wishes, if a specific wish become popular 
enough, like if thousands of users ask for the same features. 
This is not a scenario that could happen in D)

In the D community, if you want something code it, if you cant, 
very little chance someone will grant you your wish

I think, there are some big projects within D, the betterC , 
Ownership and Borrowing  and maybe few others

I think those are the big two at the moment, the future of D or D 
roadmap, is more or less those two projects

Other than that, I think the biggest challenges are making sure 
all features fit and work together nicely and marketing, making D 
more popular grow the community etc ...
Aug 30 2020
parent reply IGotD- <nise nise.com> writes:
On Monday, 31 August 2020 at 05:28:06 UTC, Ali wrote:

 Other than that, I think the biggest challenges are making sure 
 all features fit and work together nicely and marketing, making 
 D more popular grow the community etc ...


I think developers want stability and not a language that chases 
for the next compiler technology trend as soon as it pops up.

Also a good base of nice libraries is just as important as the 
language itself.
Aug 31 2020
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Monday, 31 August 2020 at 14:42:04 UTC, IGotD- wrote:

 On Monday, 31 August 2020 at 05:28:06 UTC, Ali wrote:

 Other than that, I think the biggest challenges are making 
 sure all features fit and work together nicely and marketing, 
 making D more popular grow the community etc ...


 I think developers want stability and not a language that 
 chases for the next compiler technology trend as soon as it 
 pops up.


If it were only a question of figuring out "what developers want" 
and then implementing it, language design would be easy. :)

The messy truth is that different developers want different 
things, and no group of developers ever agrees completely on what 
they do or don't want. I mean, think about how much people argue 
about tabs vs. spaces, or vim vs. emacs. Do you really think 
these same people are going to come to a clear consensus about 
stability vs. innovation?
Aug 31 2020
parent reply IGotD- <nise nise.com> writes:
On Monday, 31 August 2020 at 16:34:00 UTC, Paul Backus wrote:

 Do you really think these same people are going to come to a 
 clear consensus about stability vs. innovation?


That's the impression I get from reading this forum. DIPs that 
are small tweaks that breaks nothing or very little often get 
positive feedback. DIPs that makes big breaking changes or tries 
fork in a new piece of technology often has more controversy 
around it. Now, you would say that this is completely natural but 
still I haven't seen that big enthusiasm regarding the bigger 
changes. That's my observation when it comes to D. When it comes 
to other languages, I don't know but they are often governed in 
some other fashion like C++.
Aug 31 2020
next sibling parent Paul Backus <snarwin gmail.com> writes:
On Monday, 31 August 2020 at 19:11:40 UTC, IGotD- wrote:

 On Monday, 31 August 2020 at 16:34:00 UTC, Paul Backus wrote:

 Do you really think these same people are going to come to a 
 clear consensus about stability vs. innovation?


 That's the impression I get from reading this forum. DIPs that 
 are small tweaks that breaks nothing or very little often get 
 positive feedback. DIPs that makes big breaking changes or 
 tries fork in a new piece of technology often has more 
 controversy around it. Now, you would say that this is 
 completely natural but still I haven't seen that big enthusiasm 
 regarding the bigger changes. That's my observation when it 
 comes to D. When it comes to other languages, I don't know but 
 they are often governed in some other fashion like C++.


 From what I recall, DIP 1028, "Make  safe the Default", which 
proposed perhaps the most significant breaking change of any DIP 
ever, got a lot of positive feedback, *except* for the 
controversial part about extern(C) functions. So it seems to me 
like a substantial portion of the D community is happy to embrace 
breaking changes, as long as they're handled well and bring a 
enough of a benefit.

For a less controversial example, DIP 1024, "Shared Atomics", 
also introduced breaking changes, and was also received 
positively.
Aug 31 2020
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Aug 31, 2020 at 07:11:40PM +0000, IGotD- via Digitalmars-d wrote:

 On Monday, 31 August 2020 at 16:34:00 UTC, Paul Backus wrote:

 
 Do you really think these same people are going to come to a clear
 consensus about stability vs. innovation?


 
 That's the impression I get from reading this forum. DIPs that are
 small tweaks that breaks nothing or very little often get positive
 feedback. DIPs that makes big breaking changes or tries fork in a new
 piece of technology often has more controversy around it. Now, you
 would say that this is completely natural but still I haven't seen
 that big enthusiasm regarding the bigger changes. That's my
 observation when it comes to D. When it comes to other languages, I
 don't know but they are often governed in some other fashion like C++.



From my POV, the controversies usually involve 3 main factors:


- The desire not to break existing code: this used to be a smaller
  problem, but these days it seems we're treading on eggshells whenever
  something might potentially break code;

- The desire for major new features with breaking changes, to rid the
  language of unwanted baggage and add desirable features that we can't
  currently add because it conflicts with the way things are currently
  done.

- The desire to balance the previous two by making smaller changes --
  but the change gets seen as anemic and not going far enough to be
  actually useful and justify the cost.


I've mentioned before (though I'm not 100% sure how practical it would
be with D) that one way to move forward is to introduce a language
versioning mechanism to D, such that each module declares which language
version it was written in. The compiler would internally have multiple
versioned components that represent selected "frozen" states of the
language, which would be selected by this version directive so that it
retains the old semantics of the language. Ideally, this would allow us
to retain complete backward compatibility (at least up to the point this
versioning system was introduced) while allowing newer language versions
to break things as necessary to implement new features. Since the
versioning will apply by module, one can incrementally upgrade code to
newer language versions without being forced to fix everything all at
once upon installing a newer compiler.

Of course, there's bound to be cases where an older language version is
fundamentally incompatible with a newer version; in such cases perhaps
it can be a compile error if a newer module interacts with an older
module in a way that falls under such incompatibilities. The idea being
to catch this at compile-time instead of breaking stuff at runtime.

IOW, it's what Andrei has been repeating about adding rather than
changing. Add new versions of the language in the same compiler, instead
of changing the meaning of the current version of the language.


T

-- 
Don't get stuck in a closet---wear yourself out.
Aug 31 2020
next sibling parent reply claptrap <clap trap.com> writes:
On Monday, 31 August 2020 at 19:33:45 UTC, H. S. Teoh wrote:

 On Mon, Aug 31, 2020 at 07:11:40PM +0000, IGotD- via 
 Digitalmars-d wrote:

 On Monday, 31 August 2020 at 16:34:00 UTC, Paul Backus wrote:


 IOW, it's what Andrei has been repeating about adding rather 
 than changing. Add new versions of the language in the same 
 compiler, instead of changing the meaning of the current 
 version of the language.


Could you use a compatibility layer? Say you have a module that 
is pre safe by default, you could have a component that annotates 
it so it's safety is explicit and then it can be passed to the 
new safe by default compiler.

Like the error with ints being truncated on assignment (cant 
remember what the proper name for it was), you could have a 
component that just inserts casts where needed, and then it could 
be passed to the newer compiler.

You wouldn't even need compiler versioning, the module could just 
declare the specific feature it's not updated to yet, and that 
would cause it to be run through the compatibility process.. Eg..

version(notSafeByDefault);
Aug 31 2020
parent Paul Backus <snarwin gmail.com> writes:
On Monday, 31 August 2020 at 20:57:02 UTC, claptrap wrote:

 On Monday, 31 August 2020 at 19:33:45 UTC, H. S. Teoh wrote:

 On Mon, Aug 31, 2020 at 07:11:40PM +0000, IGotD- via 
 Digitalmars-d wrote:

 On Monday, 31 August 2020 at 16:34:00 UTC, Paul Backus wrote:


 IOW, it's what Andrei has been repeating about adding rather 
 than changing. Add new versions of the language in the same 
 compiler, instead of changing the meaning of the current 
 version of the language.


 Could you use a compatibility layer? Say you have a module that 
 is pre safe by default, you could have a component that 
 annotates it so it's safety is explicit and then it can be 
 passed to the new safe by default compiler.

 Like the error with ints being truncated on assignment (cant 
 remember what the proper name for it was), you could have a 
 component that just inserts casts where needed, and then it 
 could be passed to the newer compiler.


Yes, this is possible, at least for "normal" code--when you get 
into stuff like mixins and generated code, it becomes more 
complicated. At the very least, it is possible to have the 
compiler print a deprecation warning when it encounters code that 
would have its default changed by the transition. I actually 
implemented a version of this for extern(C) functions [1] and 
used it, along with some Vim macros, to add explicit safety 
annotations to a bunch of declarations in druntime [2].

[1] https://github.com/dlang/dmd/pull/11176
[2] https://github.com/dlang/druntime/pull/3117


 You wouldn't even need compiler versioning, the module could 
 just declare the specific feature it's not updated to yet, and 
 that would cause it to be run through the compatibility 
 process.. Eg..

 version(notSafeByDefault);


This is similar to Adam Ruppe's proposal to have blanket-applied 
attributes change the *default* for a particular scope without 
overriding attribute inference for template/auto functions. It's 
an attractive idea, since it allows code to opt-in to 
 safe-by-default (as well as other attributes like 
nothrow-by-default) without breaking compatibility.

I think the main thing stopping it from happening is that 
nobody's stepped forward to write a DIP for it yet. I expect if 
someone did, it would get a favorable reception.
Aug 31 2020
prev sibling parent James Blachly <james.blachly gmail.com> writes:
On 8/31/20 3:33 PM, H. S. Teoh wrote:

 ... one way to move forward is to introduce a language
 versioning mechanism to D, such that each module declares which language
 version it was written in. The compiler would internally have multiple
 versioned components that represent selected "frozen" states of the
 language, which would be selected by this version directive so that it
 retains the old semantics of the language. Ideally, this would allow us
 to retain complete backward compatibility (at least up to the point this
 versioning system was introduced) while allowing newer language versions
 to break things as necessary to implement new features. Since the
 versioning will apply by module, one can incrementally upgrade code to
 newer language versions without being forced to fix everything all at
 once upon installing a newer compiler.


I like this idea and can really give us room to grow.

**This is precisely like Rust editions:**

https://doc.rust-lang.org/book/appendix-05-editions.html

"""
Every two or three years, the Rust team produces a new Rust edition. 
Each edition brings together the features that have landed into a clear 
package with fully updated documentation and tooling. New editions ship 
as part of the usual six-week release process.
...
Each project can opt in to an edition other than the default 2015 
edition. Editions can contain incompatible changes, such as including a 
new keyword that conflicts with identifiers in code. However, unless you 
opt in to those changes, your code will continue to compile even as you 
upgrade the Rust compiler version you use.
"""


An entire guide to Rust editions:
https://doc.rust-lang.org/stable/edition-guide/
Aug 31 2020
prev sibling parent James Blachly <james.blachly gmail.com> writes:
On 8/31/20 10:42 AM, IGotD- wrote:

 On Monday, 31 August 2020 at 05:28:06 UTC, Ali wrote:

 Other than that, I think the biggest challenges are making sure all 
 features fit and work together nicely and marketing, making D more 
 popular grow the community etc ...


 
 I think developers want stability and not a language that chases for the 
 next compiler technology trend as soon as it pops up.
 
 Also a good base of nice libraries is just as important as the language 
 itself.


Indeed, I get the impression that a lot of Golang's success especially 
early on was due to the std library
Aug 31 2020
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Aug 30, 2020 at 05:32:32PM +0000, Eljay via Digitalmars-d wrote:

 What is left to do for D 2.x for it to be declared "done" and in
 stable/bugfix mode only?


[...]

Walter & others who make decisions have repeatedly stated that there
will be no D3.  Not in the foreseeable future, anyway.  But I'm not sure
if things have changed since.


T

-- 
Elegant or ugly code as well as fine or rude sentences have something in
common: they don't depend on the language. -- Luca De Vitis
Aug 31 2020
prev sibling next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Sunday, 30 August 2020 at 17:32:32 UTC, Eljay wrote:

 What is left to do for D 2.x for it to be declared "done" and 
 in stable/bugfix mode only?

 [...]


I'm curious to know what EXACTLY CANNOT be done in current D that 
requires doing a new version.
Sep 01 2020
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 1 September 2020 at 13:36:37 UTC, aberba wrote:

 I'm curious to know what EXACTLY CANNOT be done in current D 
 that requires doing a new version.


It is rather obvious at this point that it is very difficult to 
gain momentum with the current design. But you see some of the 
same type of complaints on the Rust forums too (complaints that 
Rust is too constraining, too complicated, weird etc).

Right now, the best language for targeting WASM would have a 
chance. Maybe Zig, maybe Rust, probably not Go, Nim or D. 
Currently C/C++ is perceived as being the best option for WASM, 
AFAIK.
Sep 01 2020
parent reply IGotD- <nise nise.com> writes:
On Tuesday, 1 September 2020 at 14:48:19 UTC, Ola Fosheim Grøstad 
wrote:

 It is rather obvious at this point that it is very difficult to 
 gain momentum with the current design.


I didn't quite understand that sentence. What is the problem with 
the current design that prevents D from gaining momentum?
Sep 01 2020
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 1 September 2020 at 15:23:10 UTC, IGotD- wrote:

 On Tuesday, 1 September 2020 at 14:48:19 UTC, Ola Fosheim 
 Grøstad wrote:

 It is rather obvious at this point that it is very difficult 
 to gain momentum with the current design.


 I didn't quite understand that sentence. What is the problem 
 with the current design that prevents D from gaining momentum?


Assuming that everything is perfect (in terms of the mechanics of 
a language) then it seems that programming languages tend to gain 
momentum when they "appear simple" compared to the alternatives, 
then they accrue complexities as they sustain that momentum.

When C++ emerged it made structuring larger programs simpler than 
with C. Complexities was accrued after gaining momentum.

Basically the threshold for picking up a small language is lower 
if the language does not look like it requires much time 
investment.

Python looks simple, although it actually can be complicated. Go 
looks simple etc. Rust claimed to be simpler than C++ (within the 
explicit memory management paradigme).

D1 had the "looks simple" quality too, but probably aggregated 
complexity at a stage that was too early.
Sep 01 2020
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 1 September 2020 at 15:23:10 UTC, IGotD- wrote:

 I didn't quite understand that sentence. What is the problem 
 with the current design that prevents D from gaining momentum?


And of course memory management, which is constantly brought up 
by ex-D users:

https://www.osnews.com/story/132286/rust-1-46-0-released/#comments

Probably the issue with most impact on adoption.
Sep 01 2020
parent reply Russel Winder <russel winder.org.uk> writes:
On Tue, 2020-09-01 at 18:49 +0000, Ola Fosheim Gr=C3=B8stad via Digitalmars=
-d
wrote:

 On Tuesday, 1 September 2020 at 15:23:10 UTC, IGotD- wrote:

 I didn't quite understand that sentence. What is the problem=20
 with the current design that prevents D from gaining momentum?


=20
 And of course memory management, which is constantly brought up=20
 by ex-D users:
=20
 https://www.osnews.com/story/132286/rust-1-46-0-released/#comments
=20
 Probably the issue with most impact on adoption.


And D without garbage collection would create a pool of ex-D programmers
saying "if only D had stuck to it's guns with garbage collection instead of
being bullied into a position by C++ and Rust lovers who aren't going to us=
e D
anyway."

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Sep 02 2020
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 2 September 2020 at 08:40:27 UTC, Russel Winder 
wrote:

 And D without garbage collection would create a pool of ex-D 
 programmers saying "if only D had stuck to it's guns with 
 garbage collection instead of being bullied into a position by 
 C++ and Rust lovers who aren't going to use D anyway."


Yes.

But there is a difference between 1) having an ecosystem where 
many libraries and frameworks rely on stop-the-world-GC 2) having 
the option of using GC in application code (or maybe just in unit 
tests).

It is possible to market a low-level programming GC strategy, if 
it is geared towards that specific use scenario.

Especially if you consider mixed use, e.g. where the application 
use GC during initialization. But in those cases you might want 
the gaps on the GC heap to be available for malloc, or run 
compaction after initialization.

Or just to have GC available for testing frameworks.
Sep 02 2020
parent Russel Winder <russel winder.org.uk> writes:
On Wed, 2020-09-02 at 09:19 +0000, Ola Fosheim Gr=C3=B8stad via Digitalmars=
-d
wrote:

=20


[=E2=80=A6]

 But there is a difference between 1) having an ecosystem where=20
 many libraries and frameworks rely on stop-the-world-GC 2) having=20
 the option of using GC in application code (or maybe just in unit=20
 tests).


My belief is that you end up with two runtime systems and standard librarie=
s:
one for GC and the other for non-GC. Certainly doable for a community with
lots of people able to contribute, not so viable for a community with stric=
tly
limited person effort available.


 It is possible to market a low-level programming GC strategy, if=20
 it is geared towards that specific use scenario.
=20
 Especially if you consider mixed use, e.g. where the application=20
 use GC during initialization. But in those cases you might want=20
 the gaps on the GC heap to be available for malloc, or run=20
 compaction after initialization.
=20
 Or just to have GC available for testing frameworks.


I fear that would be the worst of all worlds.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Sep 03 2020
prev sibling parent Ethan <gooberman gmail.com> writes:
On Wednesday, 2 September 2020 at 08:40:27 UTC, Russel Winder 
wrote:

 And D without garbage collection would create a pool of ex-D 
 programmers saying "if only D had stuck to it's guns with 
 garbage collection instead of being bullied into a position by 
 C++ and Rust lovers who aren't going to use D anyway."


Commenting on thread to agree with this.

The only thing I really want as far as GC goes in D is more hooks 
in to pointer acquire and release. From there, I can get the 
task-based async collector going that I have in mind. GC is fine, 
but not when it's unconfigurable for my uses.

(I'm generally against library solutions like refcounted 
templates, this can 100% be solved with runtime hooks)
Sep 03 2020
prev sibling parent reply Eljay <eljay.adobe gmail.com> writes:
On Tuesday, 1 September 2020 at 15:23:10 UTC, IGotD- wrote:

 I didn't quite understand that sentence. What is the problem 
 with the current design that prevents D from gaining momentum?


D does have momentum.

Some obstacles as I see them are:
   * no corporate/government/academic sponsor backing the language
   * garbage collection

How one courts a sponsor, I do not know.

Garbage collection is a good thing for some programs, but a bad 
thing for other kinds of programs.  I think the C, C++, and Rust 
developers see "garbage collection", and don't take a second 
look.  If D was better at being  nogc friendly, out of the box, 
that would help -- but it would take a bit of an awareness 
campaign to spread the word.

The syntax has grown a bit, and somewhat awkwardly.  Maybe 
something to make the syntax less unwieldy.  (I don't think this 
causes acceptance impedance, though.  It's one of those things 
that gets discovered over time. C++ is also suffering from 
ceremonious syntax bloat because the unqualified defaults are 
wrong due to historical evolutionary reasons.)

To borrow what I've seen from another D developer...

private Handle foo_;
public  property inout(Handle) foo() nothrow pure  safe  nogc 
return inout {
    return foo_;
}
Sep 01 2020
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 2 September 2020 at 01:49:23 UTC, Eljay wrote:

 C++ is also suffering from ceremonious syntax bloat because the 
 unqualified defaults are wrong due to historical evolutionary 
 reasons.)


Mastering C++ is also very timeconsuming, it relies on the 
pervasive adoption it has as a framework language + regular 
updates. C++20 and beyond brings large changes that are likely to 
renew interest ( modules, concepts, ranges ). I believe such 
changes work for C++ as compilers give developers the ability to 
work with older language versions and those are being maintained. 
So nobody are forced to upgrade. You can freeze your current 
project on C++14 and adopt C++2a on new projects.

According to github stats, only Go and C++ appears to be growing? 
Rust has been stagnant since 2014 on github?

Most languages seem to hit a plateu or a ceiling after a few 
years. The dominant language in each use scenario appears to take 
the long term growth. So javascript, python, go and c++ appears 
to be the ones with momentum on github.
Sep 01 2020
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 2 September 2020 at 05:50:39 UTC, Ola Fosheim 
Grøstad wrote:

 According to github stats, only Go and C++ appears to be 
 growing? Rust has been stagnant since 2014 on github?


If we look at "stars", then Rust had growth from 2013 through 
2018 and then it might seem to swing at a plateau of 1%. Go has a 
more linear growth from 2012, but might flatten out at 10%. C++ 
has linear growth since 2014, reaching 7%. Too much noise to 
judge smaller languages, but Julia, Crystal and Nim appears to 
quickly attract a small following, but no clear growth after 
that. Sadly D isn't present on this chart.

https://madnight.github.io/githut/#/stars/2020/2

Python is seeing steady growth, reaching 14%. Might be the end of 

has hit a plateau in 2019 at 3.5%. Dart quickly hit a plateau at 
0.75%. Likewise, Swift had a peak in 2016 at 6%, but enthusiasm 
appears to have been lost and it is flattening out at 2%.
Sep 01 2020
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2020-09-02 at 05:50 +0000, Ola Fosheim Gr=C3=B8stad via Digitalmars=
-d
wrote:

=20


[=E2=80=A6]

 According to github stats, only Go and C++ appears to be growing?=20
 Rust has been stagnant since 2014 on github?


Perhaps because GitHub is not the only choice of backup and marketing platf=
orm
for what is a *distributed* version control tool. I can't imagine BitBucket=
 is
a player, but GitLab definitely is.


 Most languages seem to hit a plateu or a ceiling after a few=20
 years. The dominant language in each use scenario appears to take=20
 the long term growth. So javascript, python, go and c++ appears=20
 to be the ones with momentum on github.


Which is fine, and not a problem.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Sep 02 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 2 September 2020 at 08:43:29 UTC, Russel Winder 
wrote:

 Perhaps because GitHub is not the only choice of backup and 
 marketing platform for what is a *distributed* version control 
 tool.


There certainly is a bias towards personal projects on github, 
but then again, that would be an indicator of genuine interest. 
Not sure if the trends would differ significantly if you included 
other repos.

Although, some bias might be peculiar to a specific eco system. 
E.g. Swift users might find that Apple now has enough built in 

are probably underrepresented because of enterprises favouring 
closed source.
Sep 02 2020
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Wednesday, 2 September 2020 at 01:49:23 UTC, Eljay wrote:

 Some obstacles as I see them are:
   * no corporate/government/academic sponsor backing the 
 language
   * garbage collection


The biggest mistakes of D is not that it is garbage collected but 
that it painted itself into a corner requiring a tracing GC which 
prevents it from using other GC methods.

Either a language is garbage collected which means the 
runtime/compiler takes care of the memory management or it has 
manual memory management. Supporting both is in my opinion not 
realistic because designing libraries than can work in any 
environment is too complicated. This is an active choice that the 
library author must take if automatic memory management should be 
used or not.

You could say that in that case all D libraries must change to 
using manual memory management so that it can work in any 
environment. However, this also affects the design of the 
interfaces and without garbage collection it will be prone for 
more memory bugs. Also I'm not sure anybody is up to the task 
rewriting entire runtime/phobos to use manual memory management.

I think that the work towards  nogc is a waste of time.  nogc 
environments are very specialized and there programmers tend to 
use their own special libraries as well for full control. The 
work should be focused towards plug and play GC and reference 
counting.
Sep 02 2020
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2020-09-02 at 09:06 +0000, IGotD- via Digitalmars-d wrote:
[=E2=80=A6]

=20
 I think that the work towards  nogc is a waste of time.  nogc=20
 environments are very specialized and there programmers tend to=20
 use their own special libraries as well for full control. The=20
 work should be focused towards plug and play GC and reference=20
 counting.


If D can move to be both GC and non-GC then fine, but for me D is a GC
language.=20

C, C++, and Rust folk (who are the bulk of the anti-GC community) are alrea=
dy
firmly anti-D =E2=80=93 I suspect no amount of non-GC D is going to change =
their minds
as to what D is as a programming language.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Sep 02 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 2 September 2020 at 09:20:26 UTC, Russel Winder 
wrote:

 C, C++, and Rust folk (who are the bulk of the anti-GC 
 community) are already firmly anti-D – I suspect no amount of 
 non-GC D is going to change their minds as to what D is as a 
 programming language.


I wouldn't expect people who have invested in Rust to give up on 
the borrow checker, but many past and current D programmers have 
one foot in C++ land.

Right now Go is cutting into both C++ and Java for light weight 
servers. Creating a competing runtime is out of scope for most 
languages. And heavy weight servers will not be implemented with 
smaller languages (more likely to go with industry standards). If 
you want to create a lightweight GC server today the most sane 
business choice is Go or node.js.

There are also many small languages out there that are trying to 
be suitable for that space: Crystal, Nim, V... that space is 
getting crowded.

Zig appears to do a better job of distinguishing itself, e.g. 
attract authors of emulators, hobby OSes etc.

(shrugs)
Sep 02 2020
parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2020-09-02 at 10:16 +0000, Ola Fosheim Gr=C3=B8stad via Digitalmars=
-d
wrote:

 On Wednesday, 2 September 2020 at 09:20:26 UTC, Russel Winder=20
 wrote:

 C, C++, and Rust folk (who are the bulk of the anti-GC=20
 community) are already firmly anti-D =E2=80=93 I suspect no amount of=




=20

 non-GC D is going to change their minds as to what D is as a=20
 programming language.


=20
 I wouldn't expect people who have invested in Rust to give up on=20
 the borrow checker, but many past and current D programmers have=20
 one foot in C++ land.


Investing in Rust means investing in the non-GC mind-set. It is easily done=
,
and has many benefits in many areas of software development. In many other
areas accepting a GC mind-set is also a benefit, witness the rise of Go.

My feeling is that C++20 and C++23 are likely to satisfy C++ addicts such t=
hat
any thoughts of using D get washed away.

My belief is that programmers now attribute programming languages as no-GC,
GC-possible, and GC =E2=80=93 with GC-possible being a very small set.

I have no problem iwth D trying to be both GC and non-GC for those D
programmers that feel they need it, but D is very much seen fairly widely a=
s a
GC language, I see no reason to fight that.


 Right now Go is cutting into both C++ and Java for light weight=20
 servers. Creating a competing runtime is out of scope for most=20
 languages. And heavy weight servers will not be implemented with=20
 smaller languages (more likely to go with industry standards). If=20
 you want to create a lightweight GC server today the most sane=20
 business choice is Go or node.js.


I am not sure Go is cutting into C++, but I am a bit out of that arena just
now with no ACCU conferences this last year. Go is certainly taking some of
the old Java stuff, mostly to do with containers, etc.

Do not underestimate Python as a way of developing GC Web servers. Also of
course Web servers are just a small bit of the overall programming milieu.


 There are also many small languages out there that are trying to=20
 be suitable for that space: Crystal, Nim, V... that space is=20
 getting crowded.
=20
 Zig appears to do a better job of distinguishing itself, e.g.=20
 attract authors of emulators, hobby OSes etc.


Obviously the set of mainstream programming languages change, but most
programmers only even think about alternatives to the current set once a ne=
w
one is established. I cannot see any of the set you mention breaking throug=
h.
D on the other hand is already there, just not as used as perhaps it should
be.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Sep 04 2020
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 4 September 2020 at 07:08:40 UTC, Russel Winder wrote:

 Investing in Rust means investing in the non-GC mind-set. It is 
 easily done, and has many benefits in many areas of software 
 development.


I'm sure their approach works well for larger teams, but when you 
look closer at what people do to get beyond tree-like structures 
in Rust they essentially end up using array-indexes as pointers. 
So technically it is memory-safe, but then you are basically back 
to square one in terms of correctness and also pay some 
performance penalty (out-of-bounds checks).


 My feeling is that C++20 and C++23 are likely to satisfy C++ 
 addicts such that any thoughts of using D get washed away.


It does make the languages/standard lib more similar in some 
ways, I guess.


 I have no problem iwth D trying to be both GC and non-GC for 
 those D programmers that feel they need it, but D is very much 
 seen fairly widely as a GC language, I see no reason to fight 
 that.


Well, but the D language semantics does not provide a lot of room 
for optimizing a GC runtime. So being competitive in terms of GC 
capabilities would require a D3.


 I am not sure Go is cutting into C++, but I am a bit out of 
 that arena just now with no ACCU conferences this last year. Go 
 is certainly taking some of the old Java stuff, mostly to do 
 with containers, etc.


You can write a better image-rescaling service in C++ or D, but 
since Cloud infrastructure makes it easier to deploy managed 
languages lik Go, then that makes me more likely to pick Go. E.g. 
you can run Go as a Google Cloud Function, but for C++ you have 
to set up a docker-thingy.

Also, setting up a web-service with Go is less hassle, as more is 
available in the standard library/runtime. So even though I might 
prefer to do it in C++/D it would take twice as much effort, and 
require somewhat more maintenance. So even though Go loose on 
performance, it might win on less friction and effort.

Like, with C++/D I will have to figure out which HTTP-server 
library to use, basically more manual labour and things that 
could go wrong.

But apparently has become easier to deploy smaller languages with 
Google Cloud Run. So if someone created a github repo with a 
ready-made "template" for D, then that would make it more likely 
that people would use it.


 Do not underestimate Python as a way of developing GC Web 
 servers.


True, and with the "cloud functions" approach you get to use 
different languages for different requests. So the situation is 
more flexible than it used to be.
Sep 04 2020
prev sibling parent reply IGotD- <nise nise.com> writes:
On Friday, 4 September 2020 at 07:08:40 UTC, Russel Winder wrote:

 My feeling is that C++20 and C++23 are likely to satisfy C++ 
 addicts such that any thoughts of using D get washed away.

 My belief is that programmers now attribute programming 
 languages as no-GC, GC-possible, and GC – with GC-possible 
 being a very small set.

 I have no problem iwth D trying to be both GC and non-GC for 
 those D programmers that feel they need it, but D is very much 
 seen fairly widely as a GC language, I see no reason to fight 
 that.


Modern C++ is the reason I'm to begin with and I'm satisfied with 
C++11. I use C++ often but that is for low level programming and 
that's where C++ has its niche. All the new features of C++ don't 
really target low level programming but tries to become a 
language it is not and that is a high level big hauling language 
(it actually was in the 80-90s). Think server, cloud, micro 
services. This is really Java, Python and others territory and 
C++ has no chance there. C++ in this realm is very unusual unless 
you have strict performance and/or resource footprint 
requirements but more often people use the big haulers like Java 
because of convenience.

D already support manual memory management and you can mix how 
much you want. The question is how the standard libraries should 
written and used. I'd say leave them as it is and people who want 
manual memory management are free to do that but then you have 
create your own libraries (mainly because nobody will port 
druntme/phobos to non-GC). I agree with you that D should be a GC 
language first since that is what most people will be looking for 
when programming D. For those who are not are probably 
programming betterC and there a lot of features are disabled.

We'll see if you are right when it comes to C++23 and so on. I 
believe that C++ will not increase its popularity because of new 
features. What C++ tries to target with the newer standards is 
out of its reach, better alternatives exist. This includes D. One 
funny observation is that C++20 is starting to look like D in 
some aspects (modules), however the name resolution in D is 
superior in my opinion.

I believe that C++23 will not decrease the interest for D, and it 
will be interesting to see what will really happen.


There is another misconception I want to address and that is that 
Rust is non-GC. Rust is partly a garbage collected language. Due 
to the single ownership limitation many algorithms use reference 
counting. Reference counting is a form of GC. Same goes for C++ 
when it uses shared_ptr.
Sep 04 2020
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 4 September 2020 at 21:51:18 UTC, IGotD- wrote:

 programming and that's where C++ has its niche. All the new 
 features of C++ don't really target low level programming but 
 tries to become a language it is not and that is a high level 
 big hauling language (it actually was in the 80-90s).


Some are low level, like aligned allocators, SIMD, punning...


 others territory and C++ has no chance there. C++ in this realm 
 is very unusual unless you have strict performance and/or 
 resource footprint requirements but more often people use the 
 big haulers like Java because of convenience.


Yes, unfortunally, memory can still be precious in cloud 
settings. But it is a matter of pricing vs convinience.


 D already support manual memory management and you can mix how 
 much you want. The question is how the standard libraries 
 should written and used. I'd say leave them as it is and people 
 who want manual memory management are free to do that but then 
 you have create your own libraries (mainly because nobody will 
 port druntme/phobos to non-GC).


Then you will end up with a Phobos/Tango situation. Keep in mind 
that GC apps benefit from nogc libaries as you will get fewer 
collection cycles and less memory waste.


 We'll see if you are right when it comes to C++23 and so on. I 
 believe that C++ will not increase its popularity because of 
 new features.


C++ is one of the few languages where we can see increased 
enthusiasm in terms of awarded stars on github. So there is 
increasing developer enthusiasm, but probably less so with 
managers.
Sep 04 2020
prev sibling parent reply bachmeier <no spam.net> writes:
On Wednesday, 2 September 2020 at 09:06:16 UTC, IGotD- wrote:


 Either a language is garbage collected which means the 
 runtime/compiler takes care of the memory management or it has 
 manual memory management. Supporting both is in my opinion not 
 realistic because designing libraries than can work in any 
 environment is too complicated. This is an active choice that 
 the library author must take if automatic memory management 
 should be used or not.


But we program in these mixed environments all the time. Garbage 
collected languages call into C libraries.

Here's how it can work without being complicated, based roughly 
on my experience with other languages:  nogc library functions 
can call only std.nogc and other library functions marked  nogc. 
Any data passed into a  nogc function is protected from being 
garbage collected. You can use the GC to allocate data in  nogc 
functions, but only if it's returned to a call that was made from 
non- nogc code.

It would require std.nogc but that wouldn't be a monumental task, 
because you don't need to replicate the full functionality of 
Phobos, and big parts are already nogc. You'd just need to insert 
a few restrictions that we already have when doing mixed-language 
programming.
Sep 02 2020
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 2 September 2020 at 14:09:12 UTC, bachmeier wrote:

 being garbage collected. You can use the GC to allocate data in 
  nogc functions, but only if it's returned to a call that was 
 made from non- nogc code.


So you are thinking about context-aware templates, that can query 
the properties of the call-chain? That is an interesting idea for 
static analysis indeed. Many things to consider though, when you 
have concurrency-mechanisms like coroutines.

There are many interesting things can be done to improve memory 
management for most languages, but one has to figure out what 
kind of constraints one are willing to impose on the language! If 
anything should be possible (on the low level) then that can 
inhibit some nice optimizations. For a GC-language you want to 
impose constraints on the language that some might considered 
inappropriate for writing and operating system kernel (most 
people don't write those, so it is not unreasonable to define 
writing kernels as out-of-scope for a language).

E.g. What happens if someone loads the whole file to GC-memory 
and then retains a pointer to a tiny slice of it. Can the runtime 
know that only that specific slice is "live"? If it can, then it 
can release the unused parts surrounding the slice (the big bulk 
of allocated memory). Can the runtime prove that there is only 
one reference to the slice? Then it can move it (compaction).

But the language semantics has to be hashed out very clearly and 
formally to do neat things like that safely (or to do them 
efficiently).

You basically need a very clear specification of what low level 
actions are defined as creating "undefined behaviour". You 
probably also need to introduce some constraints that some users 
will object to.
Sep 03 2020
parent bachmeier <no spam.net> writes:
On Thursday, 3 September 2020 at 16:36:46 UTC, Ola Fosheim 
Grøstad wrote:


 E.g. What happens if someone loads the whole file to GC-memory 
 and then retains a pointer to a tiny slice of it. Can the 
 runtime know that only that specific slice is "live"? If it 
 can, then it can release the unused parts surrounding the slice 
 (the big bulk of allocated memory). Can the runtime prove that 
 there is only one reference to the slice? Then it can move it 
 (compaction).


My experience is with mixing R and C. When you write code in C, 
you can tell R to allocate an array (or whatever you want) using 
the GC. It tracks the number of times you do those allocations in 
your C code. You then either release the underlying memory back 
to the GC or you return that memory to R as the return value of 
your function. If you missed something, R throws an error and 
tells you that you didn't release everything.

Naturally, you can still do all kinds of crazy things on the C 
side, including stashing pointers to GC-allocated memory. That's 
how it goes if you want to write C code - it's your 
responsibility to make it work. Everything on the R side is 
guaranteed safe.

I'm not saying this is a strategy D should pursue. Just that it's 
easy to use and it's worked well for decades, allowing you to mix 
your safe GC code with unsafe, GC-free, 
complete-control-of-everything code. There's nothing original in 
anything I've written. All you have to do is track GC allocations 
in the unsafe functions, check your bookkeeping when passing data 
between the two types of code, and enforce the usual  nogc 
restrictions on the relevant code.
Sep 04 2020
prev sibling parent reply Laeeth Isharc <laeeth laeeth.com> writes:
On Wednesday, 2 September 2020 at 01:49:23 UTC, Eljay wrote:

 On Tuesday, 1 September 2020 at 15:23:10 UTC, IGotD- wrote:

 I didn't quite understand that sentence. What is the problem 
 with the current design that prevents D from gaining momentum?


 D does have momentum.

 Some obstacles as I see them are:
   * no corporate/government/academic sponsor backing the 
 language
   * garbage collection

 How one courts a sponsor, I do not know.


I think its a mistake to think that a single corporate sponsor is 
the answer.

Companies have their own distinct interests and values and those 
arent going to be identical with those of the language ecosystem 
and community.  Especially for a publicLy-listed company yet 
those tend to be the ones that have the resources to be a 
significant sponsor.

whats the use case for D?  well, look at how its uses by 
organizations that use D today.  it has incredible breadth and 
there is no single industry that pops out.  its about the kind of 
people more I think.

Having a single sponsor is quite dangerous too.  what will happen 
to Rust given the funding problems Mozilla has after their 
chronic mismanagement?  maybe it will be fine but at least the 
link with Mozilla is a source of brittleness.

government funding these days has most uncertain benefits in an 
environment of budgetary constraints and rising geopolitical 
tension.

I think more funding would be better but would be best for D if 
it comes from more than one source.  and I think this will 
naturally happen in time.
Sep 02 2020
parent aberba <karabutaworld gmail.com> writes:
On Thursday, 3 September 2020 at 04:17:58 UTC, Laeeth Isharc 
wrote:

 On Wednesday, 2 September 2020 at 01:49:23 UTC, Eljay wrote:

 On Tuesday, 1 September 2020 at 15:23:10 UTC, IGotD- wrote:

 I didn't quite understand that sentence. What is the problem 
 with the current design that prevents D from gaining momentum?


 D does have momentum.

 Some obstacles as I see them are:
   * no corporate/government/academic sponsor backing the 
 language
   * garbage collection

 How one courts a sponsor, I do not know.


 I think its a mistake to think that a single corporate sponsor 
 is the answer.

 Companies have their own distinct interests and values and 
 those arent going to be identical with those of the language 
 ecosystem and community.  Especially for a publicLy-listed 
 company yet those tend to be the ones that have the resources 
 to be a significant sponsor.

 whats the use case for D?  well, look at how its uses by 
 organizations that use D today.  it has incredible breadth and 
 there is no single industry that pops out.  its about the kind 
 of people more I think.

 Having a single sponsor is quite dangerous too.  what will 
 happen to Rust given the funding problems Mozilla has after 
 their chronic mismanagement?  maybe it will be fine but at 
 least the link with Mozilla is a source of brittleness.

 government funding these days has most uncertain benefits in an 
 environment of budgetary constraints and rising geopolitical 
 tension.

 I think more funding would be better but would be best for D if 
 it comes from more than one source.  and I think this will 
 naturally happen in time.


I couldn't say any better than this. The whole Mozilla-rust is 
clearly an example of cooperate vs community interest.

We need sponsorship as every Open Source initiative at some point 
does. It doesn't really matter where it comes from (we do 
appreciate where it comes from though). The opportant things is 
those sponsors don't influence the direction of the language 
based solely on their cooperate interest... financially or with 
their engineering workforce. Talking about engineering, D also 
need engineers from cooperates...payed or not to contribute to 
open source. That's something not talked about enough but makes 
huge difference. Developers, developers, developers. Isn't that 
part of why we need money?

Unfortunately is very uncommon to get cooperate sponsorship from 
some known companies without their influence in decision making. 
I'd rather have a independent language that a cooperate interest 
driven language.

And D is doing fairly fine and its only getting better. It might 
not be as fast as you might want it but it's moving... which can 
be both good and bad. Yeah good as in careful decision making cus 
some of these decisions Will become a permanent burden if not 
done right.


The idea that other languages are doing well due to GitHub stars 
and popularity contest is unfounded. I doesn't meant much. 
Popular doesn't necessarily mean good or people are ACTUALLY 
using it for production. Example is Rust being the most Loved 
language on stackoverflow even though ONLY 3% or so have actually 
used it. How's that even a statistic? That's what I call hyped. A 
successful language will MOSTLY have to be useful on its own for 
those who try it.


The thing about GC vs nogc by default is purely based on what you 
are used to and there's nothing stopping anyone from doing the 
other. And the friction is constantly being improved.

Those who say: if X had B instead of A... I would use it are 
MOSTLY never really interested IMO. Although there's are some 
very rare exceptions.

There's nothing wrong with D2. And popularity doing mean 
anything. Improving the current ecosystem and language is what I 
would consider founded. And there's already lots of people using 
D BTW. Part of why I try to do my fair share of D promotion.
Sep 03 2020
prev sibling parent Bruce Carneal <bcarneal gmail.com> writes:
On Tuesday, 1 September 2020 at 13:36:37 UTC, aberba wrote:

 On Sunday, 30 August 2020 at 17:32:32 UTC, Eljay wrote:

 What is left to do for D 2.x for it to be declared "done" and 
 in stable/bugfix mode only?

 [...]


 I'm curious to know what EXACTLY CANNOT be done in current D 
 that requires doing a new version.


Alternatively, what language evolutions would admit simpler, 
performant code?

I think that adding pure type variables would help, a lot.  Type 
functions, filters, maps, UFCS (typeVar.yourTraitHere), readily 
composable type libraries, ...  All these things *can* be done 
today, sort of, with our ever growing zoo of template magic 
tricks, conventions, and builtins, but there is a simpler and 
better way forward.
Sep 01 2020
prev sibling next sibling parent reply Mathias LANG <geod24 gmail.com> writes:
On Sunday, 30 August 2020 at 17:32:32 UTC, Eljay wrote:

 What is left to do for D 2.x for it to be declared "done" and 
 in stable/bugfix mode only?

 I haven't seen a Vision/20xxHy for a while.

 What features (and breaking changes) are on the horizon for 
 when the next generation D 3.x begins?

 [...]

 Thoughts?  Plans?  Roadmap?


Once again: I don't see D3 happening. There are plenty of bugs to 
fix, and we can do it gradually. We are doing it gradually, in 
fact.

Everyone has their own agenda, but as mentioned by Ali, we need 
people to do the job. So while I don't know what other people 
have in mind, here's my TODO list:

1) `in` parameters: Will be in v2.094.0
I started to adapt libraries so everyone can "just" use it as 
soon as it's released.
If things work fine (no bug), and it has the adoption I hope, 
then I'll push to have it enabled after 10 to 15 releases 
(perhaps more). At a cadence of 1 release / 2 months, that puts 
at release 2.104 in May 2022, or 2.109 in January 2023.

2) `inout`-style attributes for functions accepting delegates: 
Essentially the invert of DIP1032. I strongly believe that we 
need a way to have a non-templated function which attributes are 
dependent on one or more delegate it accepts. This is an 
essential piece to make OOP and attributes work together. It 
would also solve so many pain points with `opApply`. It needs a 
proper DIP and a proper implementation. That's the next language 
change I plan to tackle once `in` parameters are "done" (aka 
don't need my attention, not necessarily enabled by default).

3) Moving from Bugzilla to Github: I started working on this, but 
due to various conflict in schedule / discussions, it was put on 
hold, and is now in a weird lingering stage. I'd like to resume 
this, eventually, but it requires a lot of tedious work, so 
that's not something that will be completed anytime soon 
(unfortunately).

Those are the main 3 big items I see myself working on for the 
foreseeable future, aside from the other maintenance work.

----
I left this as a draft for a while, to see where the conversation 
went. One thing you can check, if you want to see where the 
language is going, are the `-preview` switches. Next release, 
`-preview=markdown` is going to be enabled by default. Someone is 
working on enabling `-preview=dtorfields`. And obviously, the 
elephant in the room, `-preview=dip1000`.
Aside from that, the DIP queue is also a good source of 
informations.
Sep 01 2020
parent Bruce Carneal <bcarneal gmail.com> writes:
On Tuesday, 1 September 2020 at 15:17:03 UTC, Mathias LANG wrote:

 On Sunday, 30 August 2020 at 17:32:32 UTC, Eljay wrote:

 What is left to do for D 2.x for it to be declared "done" and 
 in stable/bugfix mode only?

 I haven't seen a Vision/20xxHy for a while.

 What features (and breaking changes) are on the horizon for 
 when the next generation D 3.x begins?

 [...]

 Thoughts?  Plans?  Roadmap?


 Once again: I don't see D3 happening. There are plenty of bugs 
 to fix, and we can do it gradually. We are doing it gradually, 
 in fact.


Yes.  We're mostly "adding" our way to D3, rather than "changing".


 Everyone has their own agenda, but as mentioned by Ali, we need 
 people to do the job. So while I don't know what other people 
 have in mind, here's my TODO list:

 1) `in` parameters: Will be in v2.094.0
 I started to adapt libraries so everyone can "just" use it as 
 soon as it's released.
 If things work fine (no bug), and it has the adoption I hope, 
 then I'll push to have it enabled after 10 to 15 releases 
 (perhaps more). At a cadence of 1 release / 2 months, that puts 
 at release 2.104 in May 2022, or 2.109 in January 2023.


I think this will have a very large positive impact: widely 
applicable, easily adopted, bug precluding.  Many thanks.


 2) `inout`-style attributes for functions accepting delegates:


...
Improving transparency and control in composition: yes.


 3) Moving from Bugzilla to Github: I started working on this,


...

 Those are the main 3 big items I see myself working on for the 
 foreseeable future, aside from the other maintenance work.


We all benefit from your well targeted work on the near-frontier 
Mathias.  Again, many thanks.
Sep 01 2020
prev sibling parent Martin Tschierschke <mt smartdolphin.de> writes:
On Sunday, 30 August 2020 at 17:32:32 UTC, Eljay wrote:

 What is left to do for D 2.x for it to be declared "done" and 
 in stable/bugfix mode only?

 I haven't seen a Vision/20xxHy for a while.

 What features (and breaking changes) are on the horizon for 
 when the next generation D 3.x begins?

 There are plenty of languages out there that have intriguing 
 features that may (or may not) be good candidates to consider 
 for D 3.x.


I just have found this interesting read about Ruby:

    Ruby Creator Yukihiro Matsumoto on the Challenges of Updating 
a Programming Language[1]

Some general points sound quite familiar.

[1] 
https://thenewstack.io/ruby-creator-yukihiro-matsumoto-on-the-challenges-of-updating-a-programming-language/
Sep 04 2020