www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Future of D

reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
https://aberba.com/2020/why-i-still-use-d/

Valid points?
Dec 09 2020
next sibling parent IGotD- <nise nise.com> writes:
On Wednesday, 9 December 2020 at 15:42:15 UTC, Imperatorn wrote:

 https://aberba.com/2020/why-i-still-use-d/

 Valid points?


Yes, I think this is pretty much my impression as well. In order 
to get more contributors, people needs to know what should be 
done.
Dec 11 2020
prev sibling next sibling parent Abdulhaq <alynch4047 gmail.com> writes:
On Wednesday, 9 December 2020 at 15:42:15 UTC, Imperatorn wrote:

 https://aberba.com/2020/why-i-still-use-d/

 Valid points?


Well written article and good points.
Dec 11 2020
prev sibling parent reply data pulverizer <data.pulverizer gmail.com> writes:
On Wednesday, 9 December 2020 at 15:42:15 UTC, Imperatorn wrote:

 https://aberba.com/2020/why-i-still-use-d/

 Valid points?


It's an interesting article. For me I'm not that bothered whether 
D becomes huge as long as it keeps growing, and remains "vital". 
It's more important to me to be able to do funded/paid projects 
with D - that's the cirlce I'm trying to square. Other than that 
I'm more interested in the "quality of the language", whether it 
works well, remains powerful and productive, and feels "good" 
when I write it.

I'm also more interested in the community. One thing that 
initially shocked me about the D language is that random people 
would suddenly turn up and start "dissing" the language and the 
community seemed to take these criticisms in its stride, which I 
really liked. I wouldn't like D community to become toxic, aloof, 
or to drive out criticisms even if they seem unfair. These can 
easily happen in programming language forums/communities. Even if 
it leads to nothing dissent can be healthy.

I think that funded projects in academic departments can be a one 
way of increasing the popularity of D. For example an academic 
keen on D chooses to implement some government funded application 
in D, which other people use and become familiar with the 
language. This is often the way languages become more popular - 
or gain widespread use, e.g. Scala (from Spark) and Julia (from 
many different projects).
Dec 13 2020
next sibling parent reply Max Haughton <maxhaton gmail.com> writes:
On Sunday, 13 December 2020 at 18:47:39 UTC, data pulverizer 
wrote:

 On Wednesday, 9 December 2020 at 15:42:15 UTC, Imperatorn wrote:

 https://aberba.com/2020/why-i-still-use-d/

 Valid points?


 It's an interesting article. For me I'm not that bothered 
 whether D becomes huge as long as it keeps growing, and remains 
 "vital". It's more important to me to be able to do funded/paid 
 projects with D - that's the cirlce I'm trying to square. Other 
 than that I'm more interested in the "quality of the language", 
 whether it works well, remains powerful and productive, and 
 feels "good" when I write it.

 I'm also more interested in the community. One thing that 
 initially shocked me about the D language is that random people 
 would suddenly turn up and start "dissing" the language and the 
 community seemed to take these criticisms in its stride, which 
 I really liked. I wouldn't like D community to become toxic, 
 aloof, or to drive out criticisms even if they seem unfair. 
 These can easily happen in programming language 
 forums/communities. Even if it leads to nothing dissent can be 
 healthy.

 I think that funded projects in academic departments can be a 
 one way of increasing the popularity of D. For example an 
 academic keen on D chooses to implement some government funded 
 application in D, which other people use and become familiar 
 with the language. This is often the way languages become more 
 popular - or gain widespread use, e.g. Scala (from Spark) and 
 Julia (from many different projects).


I really think properly killing the GC would give us a big boost 
in fresh blood to the community. It would still be there, but 
it's a huge turn off to new users. That and a bit of blog-spam, I 
constantly see articles for new languages that are (frankly) a 
bit rubbish compared to various D features but because they are 
post-(new generation of languages) they are "cooler"
Dec 13 2020
next sibling parent Paul Backus <snarwin gmail.com> writes:
On Sunday, 13 December 2020 at 19:33:30 UTC, Max Haughton wrote:

 I really think properly killing the GC would give us a big 
 boost in fresh blood to the community. It would still be there, 
 but it's a huge turn off to new users. That and a bit of 
 blog-spam, I constantly see articles for new languages that are 
 (frankly) a bit rubbish compared to various D features but 
 because they are post-(new generation of languages) they are 
 "cooler"


As far as I know, the major obstacles to making the GC truly 
pay-as-you-go are things like

- stabilization of std.experimental.allocator
- allocator-aware containers in Phobos (à la emsi_containers [1])
-  safe reference counting in Phobos or Druntime (à la automem 
[2])

Unfortunately, to my knowledge, nobody is actively working on 
these, and the D Language Foundation has not made any effort to 
prioritize them. Which is a shame, since so much of the work has 
already been done.

[1] https://code.dlang.org/packages/emsi_containers
[2] https://code.dlang.org/packages/automem
Dec 13 2020
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Dec 13, 2020 at 07:33:30PM +0000, Max Haughton via Digitalmars-d wrote:
[...]

 I really think properly killing the GC would give us a big boost in
 fresh blood to the community. It would still be there, but it's a huge
 turn off to new users.


Honestly, IMNSHO the anti-GC crowd is only a vocal minority.  For most
normal applications the GC is actually a big plus.  (And I say this as
someone coming from a strong C/C++ background who used to hate anything
GC-related.)  It eliminates an entire class of bugs that are extremely
time-consuming to debug and work around, and cleans up your internal
APIs in a significant way that allows clean integration of a lot of
components, without constantly having to fiddle with low-level memory
allocation details at every turn.

And I'm almost 100% certain that if D were to eliminate the GC tomorrow,
we would not see a big increase in users -- the naysayers will merely
move on to the next thing to hate.  Probably the lack of native
refcounting / borrowing support.  Or the state of `shared`.  Or any of
various favorite whipping boys that we love to pick on.


T

-- 
MS Windows: 64-bit rehash of 32-bit extensions and a graphical shell for
a 16-bit patch to an 8-bit operating system originally coded for a 4-bit
microprocessor, written by a 2-bit company that can't stand 1-bit of
competition.
Dec 13 2020
next sibling parent Max Haughton <maxhaton gmail.com> writes:
On Sunday, 13 December 2020 at 20:35:15 UTC, H. S. Teoh wrote:

 On Sun, Dec 13, 2020 at 07:33:30PM +0000, Max Haughton via 
 Digitalmars-d wrote: [...]

 I really think properly killing the GC would give us a big 
 boost in fresh blood to the community. It would still be 
 there, but it's a huge turn off to new users.


 Honestly, IMNSHO the anti-GC crowd is only a vocal minority.  
 For most normal applications the GC is actually a big plus.  
 (And I say this as someone coming from a strong C/C++ 
 background who used to hate anything GC-related.)  It 
 eliminates an entire class of bugs that are extremely 
 time-consuming to debug and work around, and cleans up your 
 internal APIs in a significant way that allows clean 
 integration of a lot of components, without constantly having 
 to fiddle with low-level memory allocation details at every 
 turn.

 And I'm almost 100% certain that if D were to eliminate the GC 
 tomorrow, we would not see a big increase in users -- the 
 naysayers will merely move on to the next thing to hate.  
 Probably the lack of native refcounting / borrowing support.  
 Or the state of `shared`.  Or any of various favorite whipping 
 boys that we love to pick on.


 T


Oh, I agree. Having the GC is mainly a PR problem, but we 
absolutely do need a real alterative. We should aim to be closer 
to Rust than C++. FWIW I would never get rid of it completely but 
I also don't think ours will ever be good enough to really 
challenge RC.

Borrowing is definitely doable,  live is a start but we need to 
be able to (say) invalidate an immutable range when it's data 
changes.

Shared is probably the "easiest" to fix economically, but 
requires very subtle specification work.
Dec 13 2020
prev sibling parent reply Dylan Graham <dylan.graham2000 gmail.com> writes:
On Sunday, 13 December 2020 at 20:35:15 UTC, H. S. Teoh wrote:

 On Sun, Dec 13, 2020 at 07:33:30PM +0000, Max Haughton via 
 Digitalmars-d wrote: [...]

 I really think properly killing the GC would give us a big 
 boost in fresh blood to the community. It would still be 
 there, but it's a huge turn off to new users.


 Honestly, IMNSHO the anti-GC crowd is only a vocal minority.  
 For most normal applications the GC is actually a big plus.



D's biggest problem are those trying to turn it into C++.
Dec 15 2020
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 15 December 2020 at 08:13:31 UTC, Dylan Graham wrote:

 On Sunday, 13 December 2020 at 20:35:15 UTC, H. S. Teoh wrote:

 On Sun, Dec 13, 2020 at 07:33:30PM +0000, Max Haughton via 
 Digitalmars-d wrote: [...]

 I really think properly killing the GC would give us a big 
 boost in fresh blood to the community. It would still be 
 there, but it's a huge turn off to new users.


 Honestly, IMNSHO the anti-GC crowd is only a vocal minority.  
 For most normal applications the GC is actually a big plus.



 D's biggest problem are those trying to turn it into C++.


With the irony that most prominent C++ game engines, and OS 
component frameworks, do use some form of automatic memory 
management.
Dec 15 2020
next sibling parent reply Araq <rumpf_a web.de> writes:
On Tuesday, 15 December 2020 at 09:11:26 UTC, Paulo Pinto wrote:

 With the irony that most prominent C++ game engines, and OS 
 component frameworks, do use some form of automatic memory 
 management.


None of these systems confuses GC'ed with non GC'ed pointers. C++ 
for all its warts doesn't have this flaw.
Dec 15 2020
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 15 December 2020 at 09:31:40 UTC, Araq wrote:

 On Tuesday, 15 December 2020 at 09:11:26 UTC, Paulo Pinto wrote:

 With the irony that most prominent C++ game engines, and OS 
 component frameworks, do use some form of automatic memory 
 management.


 None of these systems confuses GC'ed with non GC'ed pointers. 
 C++ for all its warts doesn't have this flaw.


That I agree, but the problem isn't with the GC, rather the 
implementation thereof.

Probably the easiest way for D not to break (much) code would be 
to keep all pointers as GC pointers by default, and non-GC 
pointers would be the ones marked with  system.

This isn't a novelty, and follows a design similar to other 
system languages with GC support.
Dec 15 2020
parent reply Max Haughton <maxhaton gmail.com> writes:
On Tuesday, 15 December 2020 at 10:33:21 UTC, Paulo Pinto wrote:

 On Tuesday, 15 December 2020 at 09:31:40 UTC, Araq wrote:

 On Tuesday, 15 December 2020 at 09:11:26 UTC, Paulo Pinto 
 wrote:

 With the irony that most prominent C++ game engines, and OS 
 component frameworks, do use some form of automatic memory 
 management.


 None of these systems confuses GC'ed with non GC'ed pointers. 
 C++ for all its warts doesn't have this flaw.


 That I agree, but the problem isn't with the GC, rather the 
 implementation thereof.

 Probably the easiest way for D not to break (much) code would 
 be to keep all pointers as GC pointers by default, and non-GC 
 pointers would be the ones marked with  system.

 This isn't a novelty, and follows a design similar to other 
 system languages with GC support.


It would be more fruitful to annotate non-GC code i.e. it would 
need to be subject to ownership checking, which will require 
annotation to interact with existing D semantics (specifically 
for interprocedural analysis)
Dec 15 2020
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 15 December 2020 at 11:59:46 UTC, Max Haughton wrote:

 It would be more fruitful to annotate non-GC code i.e. it would 
 need to be subject to ownership checking, which will require 
 annotation to interact with existing D semantics (specifically 
 for interprocedural analysis)


There should be a distinction between libraries and application. 
Libraries should type annotate ownership, borrowing and 
deterministic destruction. Then they can be used with or without 
GC and a precise GC would be faster with this in place.

But D has to choose whether it should support high level 
programming or not, that would determine which direction the 
lnguage should go. Right now it is aiming for stagnation. Well, 
that won't last...
Dec 16 2020
prev sibling parent Max Haughton <maxhaton gmail.com> writes:
On Tuesday, 15 December 2020 at 09:11:26 UTC, Paulo Pinto wrote:

 On Tuesday, 15 December 2020 at 08:13:31 UTC, Dylan Graham 
 wrote:

 On Sunday, 13 December 2020 at 20:35:15 UTC, H. S. Teoh wrote:

 On Sun, Dec 13, 2020 at 07:33:30PM +0000, Max Haughton via 
 Digitalmars-d wrote: [...]

 I really think properly killing the GC would give us a big 
 boost in fresh blood to the community. It would still be 
 there, but it's a huge turn off to new users.


 Honestly, IMNSHO the anti-GC crowd is only a vocal minority.  
 For most normal applications the GC is actually a big plus.



 D's biggest problem are those trying to turn it into C++.


 With the irony that most prominent C++ game engines, and OS 
 component frameworks, do use some form of automatic memory 
 management.


But not usually a stop-the-world one like we have.
Dec 15 2020
prev sibling next sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Sunday, 13 December 2020 at 19:33:30 UTC, Max Haughton wrote:

 I really think properly killing the GC


What do you mean by this? What would take its place, and what 
practical steps would need to be taken? And above all, how can 
the language and library features that rely on the GC today be 
replaced by alternatives that are as appealing?


 would give us a big boost in fresh blood to the community. It 
 would still be there, but it's a huge turn off to new users.


I don’t understand, when it’s still there, GCfobics will still 
think there is reason to look elsewhere. There are various ways 
to use D without garbage collection today, so it is important to 
define what this imaginary language will look like.

I don’t think there is a boatload of fresh blood just waiting for 
a different D even if is has a GC that has been killed.

I love the features that are enabled by the GC and I love not 
needing to worry about the problems that manual memory management 
brings.

Above all, I just don’t buy that “it's a huge turn off to new 
users”.

I think D hits the sweet spot with a pluggable, configurable, 
profilable and optional garbage collector!

— Bastiaan.
Dec 13 2020
parent reply Max Haughton <maxhaton gmail.com> writes:
On Sunday, 13 December 2020 at 20:59:10 UTC, Bastiaan Veelo wrote:

 On Sunday, 13 December 2020 at 19:33:30 UTC, Max Haughton wrote:

 I really think properly killing the GC


 What do you mean by this? What would take its place, and what 
 practical steps would need to be taken? And above all, how can 
 the language and library features that rely on the GC today be 
 replaced by alternatives that are as appealing?


 would give us a big boost in fresh blood to the community. It 
 would still be there, but it's a huge turn off to new users.


 I don’t understand, when it’s still there, GCfobics will still 
 think there is reason to look elsewhere. There are various ways 
 to use D without garbage collection today, so it is important 
 to define what this imaginary language will look like.

 I don’t think there is a boatload of fresh blood just waiting 
 for a different D even if is has a GC that has been killed.

 I love the features that are enabled by the GC and I love not 
 needing to worry about the problems that manual memory 
 management brings.

 Above all, I just don’t buy that “it's a huge turn off to new 
 users”.

 I think D hits the sweet spot with a pluggable, configurable, 
 profilable and optional garbage collector!

 — Bastiaan.


The problem with the GC is that it isn't optional. It is, 
technically, but practically if you want to use the standard 
library some things use the GC that really shouldn't.

The solution will have to be better than C++. - passing 
unique_ptr isn't good enough. In effect, this means we need a 
combination of reference counting and borrowing. I understand 
that this is a big task but we're a small but efficient community 
so we should try.

Garbage collection is absolutely a powerful tool but we shouldn't 
lie to ourselves about where it doesn't fit.
Dec 13 2020
next sibling parent reply IGotD- <nise nise.com> writes:
On Sunday, 13 December 2020 at 21:21:12 UTC, Max Haughton wrote:

 The problem with the GC is that it isn't optional. It is, 
 technically, but practically if you want to use the standard 
 library some things use the GC that really shouldn't.

 The solution will have to be better than C++. - passing 
 unique_ptr isn't good enough. In effect, this means we need a 
 combination of reference counting and borrowing. I understand 
 that this is a big task but we're a small but efficient 
 community so we should try.

 Garbage collection is absolutely a powerful tool but we 
 shouldn't lie to ourselves about where it doesn't fit.


D needs to differentiate managed and raw pointers, this has to be 
done in order to get out of the tracing GC swamp. Not a small 
task but I think that the D community can do it. This is the key 
and Nim has already gone through several types of GC in its 
development and keeps on updating them.

Also it would be nice to skip all the "unique_ptr" spamming in 
the source code like C++. A built in identifier would be nice 
like "int^ intPointer = new int;
Dec 13 2020
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Sunday, 13 December 2020 at 22:18:26 UTC, IGotD- wrote:

 D needs to differentiate managed and raw pointers, this has to 
 be done in order to get out of the tracing GC swamp. Not a 
 small task but I think that the D community can do it. This is 
 the key and Nim has already gone through several types of GC in 
 its development and keeps on updating them.


This is never going to happen. It's too big of a breaking change.
Dec 13 2020
parent reply IGotD- <nise nise.com> writes:
On Sunday, 13 December 2020 at 22:26:55 UTC, Paul Backus wrote:

 This is never going to happen. It's too big of a breaking 
 change.


I'm afraid of that. No pain no glory.
Dec 13 2020
parent reply Paul Backus <snarwin gmail.com> writes:
On Sunday, 13 December 2020 at 22:41:36 UTC, IGotD- wrote:

 On Sunday, 13 December 2020 at 22:26:55 UTC, Paul Backus wrote:

 This is never going to happen. It's too big of a breaking 
 change.


 I'm afraid of that. No pain no glory.


It's easy to sit around in our armchairs pontificating about how, 
if only "the D community" (read: someone else) would do X, Y, or 
Z, all of our problems would be solved.

It's harder, but ultimately much more rewarding, to roll up one's 
sleeves and actually make a positive contribution.
Dec 13 2020
next sibling parent reply IGotD- <nise nise.com> writes:
On Sunday, 13 December 2020 at 22:53:31 UTC, Paul Backus wrote:

 It's easy to sit around in our armchairs pontificating about 
 how, if only "the D community" (read: someone else) would do X, 
 Y, or Z, all of our problems would be solved.

 It's harder, but ultimately much more rewarding, to roll up 
 one's sleeves and actually make a positive contribution.


This is not a one man job which someone can make a neat preview 
of. It's a decision that has to be made from the maintainers so 
that several people can start working with such a big task. Also 
documenting what needs to be done. This ties into the original 
post with the blog post, that the D project has problems with 
rallying people towards a common goal (which today is very vague).

People starting to add and change things randomly and then hoping 
that it will be accepted and be merged isn't really a good way to 
run a project.
Dec 13 2020
parent reply aberba <karabutaworld gmail.com> writes:
On Sunday, 13 December 2020 at 23:08:05 UTC, IGotD- wrote:

 On Sunday, 13 December 2020 at 22:53:31 UTC, Paul Backus wrote:

 It's easy to sit around in our armchairs pontificating about 
 how, if only "the D community" (read: someone else) would do 
 X, Y, or Z, all of our problems would be solved.

 It's harder, but ultimately much more rewarding, to roll up 
 one's sleeves and actually make a positive contribution.


 This is not a one man job which someone can make a neat preview 
 of. It's a decision that has to be made from the maintainers so 
 that several people can start working with such a big task. 
 Also documenting what needs to be done. This ties into the 
 original post with the blog post, that the D project has 
 problems with rallying people towards a common goal (which 
 today is very vague).

 People starting to add and change things randomly and then 
 hoping that it will be accepted and be merged isn't really a 
 good way to run a project.


Very well put.

The main point of my post is that "What needs to be done" isn't 
documented so unless you've spent some time in the community to 
identify the issues out of experience or see them as they pop up 
here in the forum.

Hence D needs a Project Manager in addition to the PR Manager 
(wait what happened to the PR manager?). I know devs don't like 
project managers but the absence of such a person might not speak 
well to certain companies/individuals looking to invest in D 
(even if they like it). Isn't that one of the reasons why we have 
a foundation in the first place? Without knowing the high-level 
roadmap or core language priorities, what's there to invest in? 
What about those looking for interesting problems for their 
thesis? New volunteers?

BeerConf has created room for community members to chat and 
discuss D issues, and some ideas/mobilization has come from that. 
It's a similar thing for why there needs to be a roadmap or (at 
least) a priority list of some kind.

Individualism simply isn't going to cut it.
Dec 14 2020
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Dec 14, 2020 at 07:42:41PM +0000, aberba via Digitalmars-d wrote:
[...]

 Hence D needs a Project Manager in addition to the PR Manager (wait
 what happened to the PR manager?). I know devs don't like project
 managers but the absence of such a person might not speak well to
 certain companies/individuals looking to invest in D (even if they
 like it).


[...]

I've said this before, we coders just aren't good at project management.
We need someone with the right set of skills to give direction to us
coders.  Preferably someone with some dev background who can sympathize
with the dev side of things.  But people don't seem receptive to this
idea.  Oh well.


T

-- 
My program has no bugs! Only unintentional features...
Dec 14 2020
prev sibling next sibling parent Max Haughton <maxhaton gmail.com> writes:
On Monday, 14 December 2020 at 19:42:41 UTC, aberba wrote:

 On Sunday, 13 December 2020 at 23:08:05 UTC, IGotD- wrote:

 [...]


 Very well put.

 The main point of my post is that "What needs to be done" isn't 
 documented so unless you've spent some time in the community to 
 identify the issues out of experience or see them as they pop 
 up here in the forum.

 [...]


The PR manager position is in the process of being filled. It's 
not our money being spent so these things take time.
Dec 14 2020
prev sibling parent German Diago <germandiago1983 gmail.com> writes:
On Monday, 14 December 2020 at 19:42:41 UTC, aberba wrote:

 On Sunday, 13 December 2020 at 23:08:05 UTC, IGotD- wrote:

 On Sunday, 13 December 2020 at 22:53:31 UTC, Paul Backus wrote:

 It's easy to sit around in our armchairs pontificating about 
 how, if only "the D community" (read: someone else) would do 
 X, Y, or Z, all of our problems would be solved.

 It's harder, but ultimately much more rewarding, to roll up 
 one's sleeves and actually make a positive contribution.


 This is not a one man job which someone can make a neat 
 preview of. It's a decision that has to be made from the 
 maintainers so that several people can start working with such 
 a big task. Also documenting what needs to be done. This ties 
 into the original post with the blog post, that the D project 
 has problems with rallying people towards a common goal (which 
 today is very vague).

 People starting to add and change things randomly and then 
 hoping that it will be accepted and be merged isn't really a 
 good way to run a project.


 Very well put.

 The main point of my post is that "What needs to be done" isn't 
 documented so unless you've spent some time in the community to 
 identify the issues out of experience or see them as they pop 
 up here in the forum.

 Hence D needs a Project Manager in addition to the PR Manager 
 (wait what happened to the PR manager?). I know devs don't like 
 project managers but the absence of such a person might not 
 speak well to certain companies/individuals looking to invest 
 in D (even if they like it). Isn't that one of the reasons why 
 we have a foundation in the first place? Without knowing the 
 high-level roadmap or core language priorities, what's there to 
 invest in? What about those looking for interesting problems 
 for their thesis? New volunteers?

 BeerConf has created room for community members to chat and 
 discuss D issues, and some ideas/mobilization has come from 
 that. It's a similar thing for why there needs to be a roadmap 
 or (at least) a priority list of some kind.


The project management stuff is totally true. I have been 
following D for like 15 years (I think) and D seems to have a 
permanent identity crisis. Set the priority and stick to it and 
give confidence. Yes, do it: refuse big stuff that does not 
fullfill thr goal. Do it. Even if someone gets pissed.

  In fact, even if D has a lot of nice things and is technically 
nice, it has a lack of vision. However, what I see here is people 
throwing random ideas as it has always happened. Like this, I 
think D goes nowhere. It is a pitty bc it has potential. But 
discussing and throwing random PRs is not going to cut it. 
Decisions need to be taken. For example (not a proposal at all): 
memory safety with live, RC, optional GC and the superior tool 
for GUI and server-side backend. Once decided, stick to it. Any 
language I have seen that is successful has direction: Go, 
Rust... even Nim looks more convinced of where they are heading. 
This kind of discussions are not going to fix anything. It is a 
let us talk what comes from the top off my head with zero 
direction permanently. Better to get serious surveys (I say this 
because since I started  to follow D, it is a perpetual thing 
that every once in a short while a post liie this arises. Energy 
that couldu probably be spent in setting direction (namely, 
taking decisions) and executing.

I know it is easy to critizice without doing anything but I have 
a severe lack of free time at this point. Just my two cents.


 Individualism simply isn't going to cut it.
Dec 15 2020
prev sibling parent reply Max Haughton <maxhaton gmail.com> writes:
On Sunday, 13 December 2020 at 22:53:31 UTC, Paul Backus wrote:

 On Sunday, 13 December 2020 at 22:41:36 UTC, IGotD- wrote:

 On Sunday, 13 December 2020 at 22:26:55 UTC, Paul Backus wrote:

 This is never going to happen. It's too big of a breaking 
 change.


 I'm afraid of that. No pain no glory.


 It's easy to sit around in our armchairs pontificating about 
 how, if only "the D community" (read: someone else) would do X, 
 Y, or Z, all of our problems would be solved.

 It's harder, but ultimately much more rewarding, to roll up 
 one's sleeves and actually make a positive contribution.


Positive contribution to what? Do we really have a grand strategy 
as a language at the moment? Obviously the language ecosystem can 
always be improved but the language itself is more subtle.

We know what we want (e.g. take memory safety for an example), 
but doing it requires coordination. The DIP system seems to work 
pretty well, but it encourages incremental work which isn't 
necessarily ideal for something big (like borrowing) - this 
doesn't necessarily imply breaking things but it would mean new 
syntax which (speaking for myself personally) I don't really have 
the confidence to try and propose by myself.

FWIW, we might benefit from having working groups a la the C++ 
committee. I'd happily contribute to one on memory safety (I 
would say I'd start one but I dont trust my knowledge of either 
DMD internals or formal proofs of this kind of theory).
Dec 13 2020
next sibling parent Max Haughton <maxhaton gmail.com> writes:
On Sunday, 13 December 2020 at 23:13:24 UTC, Max Haughton wrote:

 On Sunday, 13 December 2020 at 22:53:31 UTC, Paul Backus wrote:

 [...]


 Positive contribution to what? Do we really have a grand 
 strategy as a language at the moment? Obviously the language 
 ecosystem can always be improved but the language itself is 
 more subtle.

 [...]


*the depths of DMD and internals, and similarly with parts of ldc 
I meant to say
Dec 13 2020
prev sibling parent Paul Backus <snarwin gmail.com> writes:
On Sunday, 13 December 2020 at 23:13:24 UTC, Max Haughton wrote:

 FWIW, we might benefit from having working groups a la the C++ 
 committee. I'd happily contribute to one on memory safety (I 
 would say I'd start one but I dont trust my knowledge of either 
 DMD internals or formal proofs of this kind of theory).


There are a lot of people in the D community with deep technical 
knowledge, but weak organizational and interpersonal skills. If 
you (or someone like you) were willing to reach out to these 
people and do the administrative work to organize a working group 
on memory safety, that would be a very valuable contribution.
Dec 13 2020
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Sunday, 13 December 2020 at 22:18:26 UTC, IGotD- wrote:

 D needs to differentiate managed and raw pointers, this has to 
 be done in order to get out of the tracing GC swamp.


I think ` live` without that differentation does the job better. 
It is a relatively cheap solution that does not even try to be 
perfect. The managed-unmanaged pointers are better in theory, as 
they can be more foolproof, but they have many times as much 
complexity. Since most of the code can avoid memory corruption 
simply by using the GC, I doubt whether closing that gap in 
` live` is worth that much.
Dec 14 2020
parent IGotD- <nise nise.com> writes:
On Monday, 14 December 2020 at 13:12:55 UTC, Dukc wrote:

 I think ` live` without that differentation does the job 
 better. It is a relatively cheap solution that does not even 
 try to be perfect. The managed-unmanaged pointers are better in 
 theory, as they can be more foolproof, but they have many times 
 as much complexity. Since most of the code can avoid memory 
 corruption simply by using the GC, I doubt whether closing that 
 gap in ` live` is worth that much.


I would really like to know more about how  live together with 
the supposedly reference counting without fat pointers is 
supposed to work. I haven't seen any comprehensive document that 
explains it. Reference counting without fat pointers is an 
oxymoron as far as I understand. Maybe someone can explain.

I think that is what's missing, what the plan is for this.
Dec 14 2020
prev sibling parent Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Sunday, 13 December 2020 at 21:21:12 UTC, Max Haughton wrote:

 The solution will have to be better than C++. - passing 
 unique_ptr isn't good enough. In effect, this means we need a 
 combination of reference counting and borrowing. I understand 
 that this is a big task but we're a small but efficient 
 community so we should try.


OK, I like this formulation better. The problem I had with your 
previously hyperbolic wording was that I don’t think it does any 
good. It does not make anyone jump into gear and kill the GC to 
please people that aren’t here, and it possibly scares people 
that should not be scared or confirms people’s misbelieves.

The good news is that there is motion. We now have copy 
constructors which is a necessary step for RC, as is proto 
object, iirc.  live is actively being worked on.


 Garbage collection is absolutely a powerful tool but we 
 shouldn't lie to ourselves about where it doesn't fit.


“Fitting” is relative. There may be better options and work is 
being done to please a bigger audience. My point is that most 
complaints about garbage collection I see on these forums are 
hypothetical and theoretical. I don’t think I have seen anyone 
hitting collection related problems in practice that cannot be 
brought within acceptable limits and that would have been better 
off using another language.

— Bastiaan.
Dec 13 2020
prev sibling next sibling parent Dukc <ajieskola gmail.com> writes:
On Sunday, 13 December 2020 at 19:33:30 UTC, Max Haughton wrote:

 I really think properly killing the GC would give us a big 
 boost in fresh blood to the community. It would still be there, 
 but it's a huge turn off to new users. That and a bit of 
 blog-spam, I constantly see articles for new languages that are 
 (frankly) a bit rubbish compared to various D features but 
 because they are post-(new generation of languages) they are 
 "cooler"


Not really. GC tends to be the least-effort way to get your 
average code to work, so it remains a good "default" way to do 
things. We should strive to make life without GC as easy as 
possible, but that does not mean changing the default allocation 
strategy.

For Phobos-like code, the GC may seem old-fashioned -I used to 
think the way too. But for your average application code that 
does not need to be that finished, it's a totally different story.
Dec 13 2020
prev sibling parent reply a11e99z <black80 bk.ru> writes:
On Sunday, 13 December 2020 at 19:33:30 UTC, Max Haughton wrote:

 I really think properly killing the GC would give us a big 
 boost in fresh blood to the community. It would still be there, 
 but it's a huge turn off to new users. That and a bit of 
 blog-spam, I constantly see articles for new languages that are 
 (frankly) a bit rubbish compared to various D features but 
 because they are post-(new generation of languages) they are 
 "cooler"


many langs has GC. nobody complains.
D looks weird.
D is simpler and more difficult than C++ at the same time.
   D-templates, alias, UFCS, ranges makes it simpler.
   life/ref/pure/nogc/trusted/safe, lambdas with no captures by 
value, pragma(inline) (I have still "WTF?", why nogc/safe is attr 
but inline is foreign-pragma?) - are complicated. Phobos code 
looks almost same as autogenerated STL code.

D dont want try to use
- write-barrier with GC
- move to LLVM as base.
   u dont need f*ck with x86 asm and register allocations, u 
already have half-done interop with many langs that also used 
LLVM, u can generate LLVM-IR, u can add dynamic compilation - 
generating proxies, parsers on the fly, using scripts without 
converting types AStringA<=>BString in same heap..
- tail lambdas that looks pretty in other langs.

nogc/safe.. - imo its context attr not function attr.
and for context pragma is OK.
when u accept this u can add new user contexts and say to 
compiler what is allowed/disallowed. and compiler can say what 
method u cannot to use in this context coz it used/invoke 
->methodB->methodC->thatUseGC for example.
no need to dirty the methods.

with other lang using package-manager is first step that u tried.
for D u can use dub never and u are fine with ur CLI-utilities.

D is language for handmade crafts, not for enterprise.
when u will do lang for bloody-enterprise, than you've get money 
and people.
and betterC/nogc is not for enterprise, its for some thoughts 
about enterprise.

D is already very complicated for newbies.
if u cannot write program (something connect to http/grpc 
service) in a few hours than "f*ck it".
man need 4-12 months for learning D.
Dec 15 2020
next sibling parent a11e99z <black80 bk.ru> writes:
On Tuesday, 15 December 2020 at 17:45:20 UTC, a11e99z wrote:

 On Sunday, 13 December 2020 at 19:33:30 UTC, Max Haughton wrote:

 I really think properly killing the GC would give us a big 
 boost in fresh blood to the community. It would still be 
 there, but it's a huge turn off to new users. That and a bit 
 of blog-spam, I constantly see articles for new languages that 
 are (frankly) a bit rubbish compared to various D features but 
 because they are post-(new generation of languages) they are 
 "cooler"


 my blahbalh


if u see problem in GC u can make
   RC-string,
   RC-array,
   RC-hashtable and
   RC-ptr
that will close 80% ur and newbies (as u think) needs.

string_impl {
    char* ptr; // -4 is RC
    int start, len;
};
u can use it as span too.
GC will left for lambdas only.

2..4 weeks job that will close 12+years talks.
Dec 15 2020
prev sibling parent reply ddcovery <antoniocabreraperez gmail.com> writes:
On Tuesday, 15 December 2020 at 17:45:20 UTC, a11e99z wrote:


 D is already very complicated for newbies.
 if u cannot write program (something connect to http/grpc 
 service) in a few hours than "f*ck it".
 man need 4-12 months for learning D.


 From my personal experience, the complication comes because D 
libraries and compiler itself follows the "convention" over 
"contract" way (similar to the "convention" over "configuration" 
with ruby on rails :-) ).

Example:  Do you need to be equatable... then add an "opEquals" 
method to your class/struct (operator overload)... you don't need 
to implement the "IEquatable" or "IComparable" interface.

A first look to ranges libraries (it is really impressive) 
exposes that it is based on introspection (static/compile time  
code), not on interfaces/contracts.  This makes it difficult for 
newbies to understand how it works because there is not a 
"contract" (an interface) explaining you what it does.   If you 
try to read de comments in the own library, it is oriented to doc 
generation:  it is extensive and thought for post processed 
documentation generation and really impossible (in my case) as a 
guidance to understand the function signature.  The only way to 
read this "comments" is navigating to dlang.org web and reading 
the generated documentation.

This gives the real power and weakness to D:   The missing 
contracts delegates to the compile-time static code the final 
real code generation... you need to compile to know if you are 
developing well, no interfaces/contracts can be used to guide you 
before this phase.  The problem is clean:  functions signature 
doesn't gives you enough information to understand what exactly 
it does and you need 4 or more months to acquire the knowledge 
(the intuition of the typical developer is not enough: you must 
work it to adapt)

It is like beginning with Functional programming:  you need to 
understand what it means before trying to write complex code... 
and D introduces a new paradigm itself for developers that 
usually works in "productive" more known ways.

Of course, when you change your way of thinking, D reveals it's 
real power:  *auto*, *alias*,... the same function can be applied 
to thinks that are not related.  It's magic? not: D doesn't use 
generics, it uses templates and templates are not generics.

Newbies need to understand this two main concepts:
* D is not based in contracts (it can, but it tries not to use):  
Type resolution is more "introspection" based than declaration 
based.
* D has templates, NOT generics...



Final conclusion... look at this:

void main(){
   0.doThis!(n=>assert(n==0));
   assert( 0.doThis!(n=>n) == 0 );
   assert( "hello".doThis!(s=>s) == "hello" );
   assert( "hello".doThis!(s=>s.length) == 5 );
   assert( doThis!(u=>u)(true) );
}
auto doThis(alias f, T)(T value){
   // Nothing in the "alias f" tells you that it must be an unary 
function or
   // witch type must return...
   return f(value);
}


really... wonderful? :-)
Dec 16 2020
next sibling parent reply Max Haughton <maxhaton gmail.com> writes:
On Wednesday, 16 December 2020 at 10:04:03 UTC, ddcovery wrote:

 On Tuesday, 15 December 2020 at 17:45:20 UTC, a11e99z wrote:


 [...]


 From my personal experience, the complication comes because D 
 libraries and compiler itself follows the "convention" over 
 "contract" way (similar to the "convention" over 
 "configuration" with ruby on rails :-) ).

 [...]


Consider that C++ has only just got template constraints 
(concepts), and they have been at the design stage, roughly, 
since I was born on to this earth.

We have template constraints already, we could have nicer 
template constraints as a fairly trivial library solution 
(composing them isn't hard), but ultimately more templates puts a 
lot of pressure on the compiler for not much benefit.
Dec 16 2020
parent reply ddcovery <antoniocabreraperez gmail.com> writes:
On Wednesday, 16 December 2020 at 10:39:38 UTC, Max Haughton 
wrote:

 On Wednesday, 16 December 2020 at 10:04:03 UTC, ddcovery wrote:

 On Tuesday, 15 December 2020 at 17:45:20 UTC, a11e99z wrote:


 [...]


 From my personal experience, the complication comes because D 
 libraries and compiler itself follows the "convention" over 
 "contract" way (similar to the "convention" over 
 "configuration" with ruby on rails :-) ).

 [...]


 Consider that C++ has only just got template constraints 
 (concepts), and they have been at the design stage, roughly, 
 since I was born on to this earth.

 We have template constraints already, we could have nicer 
 template constraints as a fairly trivial library solution 
 (composing them isn't hard), but ultimately more templates puts 
 a lot of pressure on the compiler for not much benefit.


As a good friend told me 20 years ago: "strong typing allows you 
to see an application as a set of gears that fit together 
perfectly"... with templates, you don't know the shape of the 
gears until compiler tries to build them... this opens a lot of 
possibilities and introduces some problems.

Problem with "template constraints" is it tries to give a 
"declarative" vision of something that is solved imperatively  
(if you generate a "isEquatable" constraint... you must generate 
imperative static code to check what "isEquatable" means) and 
this is a barrier for "intelligense" systems like VSCode plugins 
that helps developers to check it's code BEFORE it is compiled.  
The plugin can't determine what "isEquatable" means and can't 
help you saying "Person class is not Equatable"... a template 
constraint is a "custom" blackbox that, semantically, doesn't 
associate language dependent declarative concepts (like 
inheritance or interfaces).  Correct me if I'm in an error... I 
am not really experienced D developer.

If you will work with D, you must be aware about this kind of 
"small" barriers.
Dec 16 2020
next sibling parent Max Haughton <maxhaton gmail.com> writes:
On Wednesday, 16 December 2020 at 12:30:06 UTC, ddcovery wrote:

 On Wednesday, 16 December 2020 at 10:39:38 UTC, Max Haughton 
 wrote:

 [...]


 As a good friend told me 20 years ago: "strong typing allows 
 you to see an application as a set of gears that fit together 
 perfectly"... with templates, you don't know the shape of the 
 gears until compiler tries to build them... this opens a lot of 
 possibilities and introduces some problems.

 Problem with "template constraints" is it tries to give a 
 "declarative" vision of something that is solved imperatively  
 (if you generate a "isEquatable" constraint... you must 
 generate imperative static code to check what "isEquatable" 
 means) and this is a barrier for "intelligense" systems like 
 VSCode plugins that helps developers to check it's code BEFORE 
 it is compiled.  The plugin can't determine what "isEquatable" 
 means and can't help you saying "Person class is not 
 Equatable"... a template constraint is a "custom" blackbox 
 that, semantically, doesn't associate language dependent 
 declarative concepts (like inheritance or interfaces).  Correct 
 me if I'm in an error... I am not really experienced D 
 developer.

 If you will work with D, you must be aware about this kind of 
 "small" barriers.


Any hypothetical IDE could just use dmd to see if the template 
fits or not. You absolutely can equate this that or the other 
because the template constraints will (99% of the time) be a 
fairly shallow tree of decisions if not flat (they are 
technically unbounded but so is everything else).
Dec 16 2020
prev sibling parent Basile B. <b2.temp gmx.com> writes:
On Wednesday, 16 December 2020 at 12:30:06 UTC, ddcovery wrote:

 On Wednesday, 16 December 2020 at 10:39:38 UTC, Max Haughton 
 wrote:

 On Wednesday, 16 December 2020 at 10:04:03 UTC, ddcovery wrote:

 On Tuesday, 15 December 2020 at 17:45:20 UTC, a11e99z wrote:


 [...]


 From my personal experience, the complication comes because D 
 libraries and compiler itself follows the "convention" over 
 "contract" way (similar to the "convention" over 
 "configuration" with ruby on rails :-) ).

 [...]


 Consider that C++ has only just got template constraints 
 (concepts), and they have been at the design stage, roughly, 
 since I was born on to this earth.

 We have template constraints already, we could have nicer 
 template constraints as a fairly trivial library solution 
 (composing them isn't hard), but ultimately more templates 
 puts a lot of pressure on the compiler for not much benefit.


 As a good friend told me 20 years ago: "strong typing allows 
 you to see an application as a set of gears that fit together 
 perfectly"... with templates, you don't know the shape of the 
 gears until compiler tries to build them... this opens a lot of 
 possibilities and introduces some problems.

 Problem with "template constraints" is it tries to give a 
 "declarative" vision of something that is solved imperatively  
 (if you generate a "isEquatable" constraint... you must 
 generate imperative static code to check what "isEquatable" 
 means) and this is a barrier for "intelligense" systems like 
 VSCode plugins that helps developers to check it's code BEFORE 
 it is compiled.  The plugin can't determine what "isEquatable" 
 means and can't help you saying "Person class is not 
 Equatable"... a template constraint is a "custom" blackbox 
 that, semantically, doesn't associate language dependent 
 declarative concepts (like inheritance or interfaces).  Correct 
 me if I'm in an error... I am not really experienced D 
 developer.

 If you will work with D, you must be aware about this kind of 
 "small" barriers.


Yes your analysis is correct. The barrier to a better 
intellisense is clearly that it would have to to check 
expressions semantics and be able to evaluate them statically, 
just like the compiler does.

Static interfaces for example would make intellisense easier (not 
need to rewrite the ASTs !) but would provide a less modular 
subset of what is possible with D (also known as static 
introspection).

Honestly if I was to create a language I would be **very** 
prudent with the adoption of templates (and even generics) and 
would rather choose static interfaces. For intelissense the 
simple contract that class X implements the behavior defined by 
static interface Y and for a specified type is simple enough.

But for D it's too late. You can have a library solution for 
static interfaces but then it will be template-based and that 
don't help.
Dec 16 2020
prev sibling next sibling parent aberba <karabutaworld gmail.com> writes:
On Wednesday, 16 December 2020 at 10:04:03 UTC, ddcovery wrote:

 On Tuesday, 15 December 2020 at 17:45:20 UTC, a11e99z wrote:


 [...]


 From my personal experience, the complication comes because D 
 libraries and compiler itself follows the "convention" over 
 "contract" way (similar to the "convention" over 
 "configuration" with ruby on rails :-) ).

 [...]


I understood it as having to do with the lack of packages rather 
than their implementation details. However, with http/grpc, I 
think we already have dub packages for those...the hunt stuff. 
Never used them myself though.
Dec 16 2020
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 16 December 2020 at 10:04:03 UTC, ddcovery wrote:

 On Tuesday, 15 December 2020 at 17:45:20 UTC, a11e99z wrote:


 D is already very complicated for newbies.
 if u cannot write program (something connect to http/grpc 
 service) in a few hours than "f*ck it".
 man need 4-12 months for learning D.


 From my personal experience, the complication comes because D 
 libraries and compiler itself follows the "convention" over 
 "contract" way (similar to the "convention" over 
 "configuration" with ruby on rails :-) ).

 Example:  Do you need to be equatable... then add an "opEquals" 
 method to your class/struct (operator overload)... you don't 
 need to implement the "IEquatable" or "IComparable" interface.

 A first look to ranges libraries (it is really impressive) 
 exposes that it is based on introspection (static/compile time  
 code), not on interfaces/contracts.  This makes it difficult 
 for newbies to understand how it works because there is not a 
 "contract" (an interface) explaining you what it does.   If you 
 try to read de comments in the own library, it is oriented to 
 doc generation:  it is extensive and thought for post processed 
 documentation generation and really impossible (in my case) as 
 a guidance to understand the function signature.  The only way 
 to read this "comments" is navigating to dlang.org web and 
 reading the generated documentation.

 This gives the real power and weakness to D:   The missing 
 contracts delegates to the compile-time static code the final 
 real code generation... you need to compile to know if you are 
 developing well, no interfaces/contracts can be used to guide 
 you before this phase.  The problem is clean:  functions 
 signature doesn't gives you enough information to understand 
 what exactly it does and you need 4 or more months to acquire 
 the knowledge (the intuition of the typical developer is not 
 enough: you must work it to adapt)

 It is like beginning with Functional programming:  you need to 
 understand what it means before trying to write complex code... 
 and D introduces a new paradigm itself for developers that 
 usually works in "productive" more known ways.

 Of course, when you change your way of thinking, D reveals it's 
 real power:  *auto*, *alias*,... the same function can be 
 applied to thinks that are not related.  It's magic? not: D 
 doesn't use generics, it uses templates and templates are not 
 generics.

 Newbies need to understand this two main concepts:
 * D is not based in contracts (it can, but it tries not to 
 use):  Type resolution is more "introspection" based than 
 declaration based.
 * D has templates, NOT generics...



 Final conclusion... look at this:

 void main(){
   0.doThis!(n=>assert(n==0));
   assert( 0.doThis!(n=>n) == 0 );
   assert( "hello".doThis!(s=>s) == "hello" );
   assert( "hello".doThis!(s=>s.length) == 5 );
   assert( doThis!(u=>u)(true) );
 }
 auto doThis(alias f, T)(T value){
   // Nothing in the "alias f" tells you that it must be an 
 unary function or
   // witch type must return...
   return f(value);
 }


 is really... wonderful? :-)


You mean like this, yeah it is a bit more boilerplate, but no I 
didn't suffer an aneurysm

using System;
using System.Linq.Expressions;


public static class Helpers
{
	public static R dothis<T, R>(this T val, Expression<Func<T,R>> f)
	{
		var func = f.Compile();
		return func(val);
	}
	
	public static void dothis<T>(this T val, Expression<Action<T>> f)
	{
		var func = f.Compile();
		func(val);
	}
}

public class Program
{
	public static void Main()
	{
		0.dothis(n => assert(() => n == 0));
		System.Diagnostics.Debug.Assert(0.dothis(n => n) == 0);
		System.Diagnostics.Debug.Assert("hello".dothis(n => n) == 
"hello");
		System.Diagnostics.Debug.Assert(Helpers.dothis(true, n => n));
	}
	
	public static void assert(Expression<Func<bool>> exp) {
		var expc = exp.Compile();
		System.Diagnostics.Debug.Assert(expc());
	}
}
Dec 16 2020
parent ddcovery <antoniocabreraperez gmail.com> writes:
On Wednesday, 16 December 2020 at 13:26:44 UTC, Paulo Pinto wrote:

 On Wednesday, 16 December 2020 at 10:04:03 UTC, ddcovery wrote:

 ...

 Final conclusion... look at this:

 void main(){
   0.doThis!(n=>assert(n==0));
   assert( 0.doThis!(n=>n) == 0 );
   assert( "hello".doThis!(s=>s) == "hello" );
   assert( "hello".doThis!(s=>s.length) == 5 );
   assert( doThis!(u=>u)(true) );
 }
 auto doThis(alias f, T)(T value){
   // Nothing in the "alias f" tells you that it must be an 
 unary function or
   // witch type must return...
   return f(value);
 }


 is really... wonderful? :-)


 You mean like this, yeah it is a bit more boilerplate, but no I 
 didn't suffer an aneurysm

 using System;
 using System.Linq.Expressions;


 public static class Helpers
 {
 	public static R dothis<T, R>(this T val, Expression<Func<T,R>> 
 f)
 	{
 		var func = f.Compile();
 		return func(val);
 	}
 	
 	public static void dothis<T>(this T val, Expression<Action<T>> 
 f)
 	{
 		var func = f.Compile();
 		func(val);
 	}
 }

 public class Program
 {
 	public static void Main()
 	{
 		0.dothis(n => assert(() => n == 0));
 		System.Diagnostics.Debug.Assert(0.dothis(n => n) == 0);
 		System.Diagnostics.Debug.Assert("hello".dothis(n => n) == 
 "hello");
 		System.Diagnostics.Debug.Assert(Helpers.dothis(true, n => n));
 	}
 	
 	public static void assert(Expression<Func<bool>> exp) {
 		var expc = exp.Compile();
 		System.Diagnostics.Debug.Assert(expc());
 	}
 }


Ahhhh... you read the entire post... thanks!!!

You have to recognize that you know D (and you like it)... 
otherwise, first impression could have been "What?"...  methods 
are "extension" methods by default, you can put "auto" as a 
result, you can declare an "alias f" and compiler will do the 
magic inference... it is a lot of work under scenes (impressive 
one)...

I'm curious about how a Java developer will try to solve the same 
problem.
Dec 16 2020
prev sibling parent data pulverizer <data.pulverizer gmail.com> writes:
On Sunday, 13 December 2020 at 18:47:39 UTC, data pulverizer 
wrote:

 On Wednesday, 9 December 2020 at 15:42:15 UTC, Imperatorn wrote:

 https://aberba.com/2020/why-i-still-use-d/

 Valid points?


 It's an interesting article... [SNIP]


p.s. There are great points on documentation, tooling, libraries, 
overall plan, but I think these are getting better with time. I 
am certainly excited with the scheduled changes and upgrades to 
the language. Could things be better? Yes, but I think progress 
is definitely being made.
Dec 13 2020