www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Plan for D

reply dogman <dogman aaf.com> writes:
Question to the core team. Whats the plan and roadmap for D ?
a. are we planning to keep D just as a hobby language or a real 
contender for industry use. Despite being complex, rust has 
started to get adopted in industries. Whats our plan ?

b. When are we planning to focus on memory safety and use that as 
our strength

c. Will we ever make D as both a GC and non GC language. So that 
it can be used across control plane, data plane, kernel. I know 
betterC, but could we make it more easy and accessible common 
public to able to use phobos. I know people say 95% is done etc.

d. Why there are no working groups for tooling, webframeworks, 
performance, compiler etc so that we can improve on each area.

e. Why is weka not sponsoring ? why are we not advertising that 
the fastest filesystem is made in D ?

f. D has all properties to make it a good language. But needs 
more work and marketing. Why cant we make D as a safe and fast 
extension to C++ & python
May 13 2021
next sibling parent IGotD- <nise nise.com> writes:
On Thursday, 13 May 2021 at 20:57:13 UTC, dogman wrote:

 c. Will we ever make D as both a GC and non GC language. So 
 that it can be used across control plane, data plane, kernel. I 
 know betterC, but could we make it more easy and accessible 
 common public to able to use phobos. I know people say 95% is 
 done etc.


No, because D has painted itself into a corner. Not only between 
GC and manual memory management but also that you cannot swap GC 
types (any type of GC, like Nim can) because D treats all 
pointers the same. That might have some advantages but I would 
say that the disadvantage is huge.

Memory management wise, D is going nowhere as it seems.
May 13 2021
prev sibling next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 13 May 2021 at 20:57:13 UTC, dogman wrote:

 Question to the core team. Whats the plan and roadmap for D ?
 a. are we planning to keep D just as a hobby language or a real 
 contender for industry use. Despite being complex, rust has 
 started to get adopted in industries. Whats our plan ?


D can already be used professionally



 b. When are we planning to focus on memory safety and use that 
 as our strength


How are we not?


 c. Will we ever make D as both a GC and non GC language. So 
 that it can be used across control plane, data plane, kernel. I 
 know betterC, but could we make it more easy and accessible 
 common public to able to use phobos. I know people say 95% is 
 done etc.


Is there any language more flexible than D in this regard? You 
already have *much* choice.


 d. Why there are no working groups for tooling, webframeworks, 
 performance, compiler etc so that we can improve on each area.


This is a valid point but the answer is how would that be done.


 e. Why is weka not sponsoring ? why are we not advertising that 
 the fastest filesystem is made in D ?


Can't answer this. It's a bit weird yes.


 f. D has all properties to make it a good language. But needs 
 more work and marketing. Why cant we make D as a safe and fast 
 extension to C++ & python


You are correct sir, we must market D more. Do your part and 
spread it ☀️
May 13 2021
prev sibling next sibling parent reply drug <drug2004 bk.ru> writes:
13.05.2021 23:57, dogman пишет:

 Question to the core team. Whats the plan and roadmap for D ?
 a. are we planning to keep D just as a hobby language or a real 
 contender for industry use. Despite being complex, rust has started to 
 get adopted in industries. Whats our plan ?
 


I guess that Walter is planning to keep D just as his hobby language (no 
offense). And definitely there is no any plan to get it adopted for 
industries. Even more I wouldn't be surprised if there is no any plan at 
all.


 b. When are we planning to focus on memory safety and use that as our 
 strength
 


See above


 c. Will we ever make D as both a GC and non GC language. So that it can 
 be used across control plane, data plane, kernel. I know betterC, but 
 could we make it more easy and accessible common public to able to use 
 phobos. I know people say 95% is done etc.
 





 d. Why there are no working groups for tooling, webframeworks, 
 performance, compiler etc so that we can improve on each area.
 


The problem is that D has been evolved by a bunch of talented people. 
They were and are really seasoned but communication between them is very 
poor. For example taggedalgebraic has been created by Shonke long before 
sumtype but taggedalgebraic was known to small subset of D developers 
only and now we have sumtype. It's good library and kudos to its author 
but that things create fragmentation in language ecosystem.
We tried to make working group for gui related things but failed because 
everyone had its own opinion and we failed to find common ground. There 
are two ways to solve that - either increase comminity to rise 
probability for developers to find common ground or organize available 
developers to work in coordinated manner. Who is motivated so high to do 
that?


 e. Why is weka not sponsoring ? why are we not advertising that the 
 fastest filesystem is made in D ?
 


They sponsored D several times. But it looks like they shy its using. 
Sometimes I even suppose they could rewrite their code base in other 
language.


 f. D has all properties to make it a good language. But needs more work 
 and marketing. Why cant we make D as a safe and fast extension to C++ & 
 python


Totally agree. D needs the leader(s).

Once again, I'm very much appreciate those giant efforts that language 
authors and developers has taken. They are really tremendous people. I 
just want D takes its appropriate place in the world.
May 14 2021
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 14 May 2021 at 11:31:28 UTC, drug wrote:

 13.05.2021 23:57, dogman пишет:

 Question to the core team. Whats the plan and roadmap for D ?
 a. are we planning to keep D just as a hobby language or a 
 real contender for industry use. Despite being complex, rust 
 has started to get adopted in industries. Whats our plan ?
 


 I guess that Walter is planning to keep D just as his hobby 
 language (no offense). And definitely there is no any plan to 
 get it adopted for industries. Even more I wouldn't be 
 surprised if there is no any plan at all.


My impression last year was that the plan is to provide a 
competitive memory management strategy.

Seems like it isn't moving because there is no willingness to 
accept hard changes and also not a willingness to make unpopular 
decisions, which are necessary.

Right now, it looks like no significant changes are likely, or 
that an alternative language will emerge.
May 14 2021
prev sibling parent reply IGotD- <nise nise.com> writes:
On Friday, 14 May 2021 at 11:31:28 UTC, drug wrote:

 Totally agree. D needs the leader(s).


We have the D maintainers but they aren't really leaders when it 
comes to organization or communication. When I think about 
leader(s) for the D project I think more about CEO material, not 
necessarily a computer language wiz but someone that move D 
forward and work in the interest of the project.
May 14 2021
parent drug <drug2004 bk.ru> writes:
14.05.2021 16:25, IGotD- пишет:

 not necessarily a computer language wiz but someone that move D forward 
 and work in the interest of the project


This
May 14 2021
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
D The biggest problem is that there is no direction.
Moreover, D author never confronts users' questions directly.
D needs to be organized and, at the same time, have a clear goal.
Let users, beginners, know what you're going to do.

However, the D authors and leading developers have never faced 
this problem.
If the user doesn't know what you're trying to accomplish, no 
matter how good the language,
The user had to leave. Because we don't know the solid point of 
your language.
What are you going to do? Are you going to match the user's 
expectations?
Can users see the improvement?
Yes, small progress is everywhere. But what we expect is your 
clear goals and steps.
C + + has 20, 23 and 26,
Rust, many companies are using. Go, even if itaims at junk 
template.
But what's D's goal? Do we have a schedule?

Is it true that we are doing things at random, and whoever has 
good things ,and then we will copy it?
Hope, D writers, wake up and make a schedule.
Let users see hope.
May 14 2021
next sibling parent zjh <fqbqrr 163.com> writes:
Well, suppose I'm the leader of D
0, do a vote, bull force people, important library author, vote 
for 10, ordinary users, vote for 1, first investigate, understand 
the different needs of various users
1. Focus on users' core requirements, such as' better c ', such 
as' memory security', such as' various bugs fix', such as' C 
'compatibility, and' C + + 'compatibility.
2. Gather a group of enthusiasts and experts together to 
understand their respective areas of expertise, and assign 
corresponding tasks in their respective areas. At the same time, 
ask them to give a timetable for completion. Of course, there are 
rewards

3. Allocation of money: 1,50% for publicity. 2,50% for reward for 
accomplishing the above tasks. At present, there are too few 
publicity and too few reward, so efforts must be made in this 
regard. At the same time, money should be allocated according to 
the stage change

4. Action
May 14 2021
prev sibling parent reply zjh <fqbqrr 163.com> writes:
The real enemy of the D language is there is too many people 
misleading.

I kept wondering if they were undercover agents from other 
languages.

Deliberately, to lead D language astray.
May 17 2021
next sibling parent reply dogman <dogman somwhere.com> writes:
On Tuesday, 18 May 2021 at 00:09:19 UTC, zjh wrote:

 The real enemy of the D language is there is too many people 
 misleading.

 I kept wondering if they were undercover agents from other 
 languages.

 Deliberately, to lead D language astray.


In a language group, there will be always two groups. No doubt 
about it. There is no long language which satisfies all.
Question is why D was not considered why GO got successful, is it 
only the google backing with its money and power or something 
missing from the language or community. I might be wrong, for D 
to succeed
it has to be an alternate to rust with safety, option of complete 
no GC(not by default), easily extensible with C/C++ and easy to 
read/write. Despite go's disadvantages, people follow hype and 
will still use it. D should have been where Go is now. I dont 
think this post will bring a big shift or change in strategy. 
Anyways good luck to all. Take care.
May 17 2021
next sibling parent zjh <fqbqrr 163.com> writes:
On Tuesday, 18 May 2021 at 00:54:04 UTC, dogman wrote:

+10086.
May 17 2021
prev sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 18 May 2021 at 00:54:04 UTC, dogman wrote:

 and easy to read/write. Despite go's disadvantages, people 
 follow hype and will still use it. D should have been where Go 
 is now. I dont think this post will bring a big shift or change 
 in strategy. Anyways good luck to all. Take care.


FWIW, I use Go for tiny web services.

Reasons: polished runtime, focused std lib, limited features, but 
somewhat consistent, cloud support.
May 17 2021
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 18 May 2021 at 00:09:19 UTC, zjh wrote:

 The real enemy of the D language is there is too many people 
 misleading.

 I kept wondering if they were undercover agents from other 
 languages.

 Deliberately, to lead D language astray.


I've also thought about this
May 18 2021
prev sibling next sibling parent reply bioinfornatics <bioinfornatics gmail.com> writes:
On Thursday, 13 May 2021 at 20:57:13 UTC, dogman wrote:

 Question to the core team. Whats the plan and roadmap for D ?
 a. are we planning to keep D just as a hobby language or a real 
 contender for industry use. Despite being complex, rust has 
 started to get adopted in industries. Whats our plan ?

 b. When are we planning to focus on memory safety and use that 
 as our strength

 c. Will we ever make D as both a GC and non GC language. So 
 that it can be used across control plane, data plane, kernel. I 
 know betterC, but could we make it more easy and accessible 
 common public to able to use phobos. I know people say 95% is 
 done etc.

 d. Why there are no working groups for tooling, webframeworks, 
 performance, compiler etc so that we can improve on each area.

 e. Why is weka not sponsoring ? why are we not advertising that 
 the fastest filesystem is made in D ?

 f. D has all properties to make it a good language. But needs 
 more work and marketing. Why cant we make D as a safe and fast 
 extension to C++ & python


Do not plan to get an answer
This kind of question is asked every years since at least 10 
years ago.

I am remind that at begining ov dlang v2 it was : it is not our 
faut the War tango vs photos as stdlib just broke our community. 
We need a killer application à la Ruby on rails.
Now it is not 1 killer application but a set of software 
environnements on se, Big data, sécurité, gui, games...
How they Can Do it?
To remember D is bien in 2001 and Rust ...

Instead to add New feature maybe waste dôme Time on one of 
previous topic des robes above in order to get a chance to be 
more heavily used...

I remember a Time to where Facebook use D to replace c++ code but 
now ...
May 14 2021
parent bioinfornatics <bioinfornatics fedoraproject.org> writes:
On Friday, 14 May 2021 at 21:29:59 UTC, bioinfornatics wrote:

 On Thursday, 13 May 2021 at 20:57:13 UTC, dogman wrote:

 Question to the core team. Whats the plan and roadmap for D ?
 a. are we planning to keep D just as a hobby language or a 
 real contender for industry use. Despite being complex, rust 
 has started to get adopted in industries. Whats our plan ?

 b. When are we planning to focus on memory safety and use that 
 as our strength

 c. Will we ever make D as both a GC and non GC language. So 
 that it can be used across control plane, data plane, kernel. 
 I know betterC, but could we make it more easy and accessible 
 common public to able to use phobos. I know people say 95% is 
 done etc.

 d. Why there are no working groups for tooling, webframeworks, 
 performance, compiler etc so that we can improve on each area.

 e. Why is weka not sponsoring ? why are we not advertising 
 that the fastest filesystem is made in D ?

 f. D has all properties to make it a good language. But needs 
 more work and marketing. Why cant we make D as a safe and fast 
 extension to C++ & python


 Do not plan to get an answer
 This kind of question is asked every years since at least 10 
 years ago.

 I am remind that at begining ov dlang v2 it was : it is not our 
 faut the War tango vs photos as stdlib just broke our 
 community. We need a killer application à la Ruby on rails.
 Now it is not 1 killer application but a set of software 
 environnements on se, Big data, sécurité, gui, games...
 How they Can Do it?
 To remember D is bien in 2001 and Rust ...

 Instead to add New feature maybe waste dôme Time on one of 
 previous topic des robes above in order to get a chance to be 
 more heavily used...

 I remember a Time to where Facebook use D to replace c++ code 
 but now ...



Sorry I wrote from my phone and my spellchecker has done some 
weird job.

So I rephrase:

Do not plan to get an answer

This kind of question is asked every years since at least 10
years ago.

I am remind that at beginning of dlang v2 it was :
«it is not our fault, the war tango vs photos as stdlib just 
broke our
community. We need a killer application à la Ruby on rails.»

Now it is not one killer application but a set of software
environments on web, Big data, security, gui, games...
How they Can Do it, in 10 years we didn't get a killer 
application so a set …?

To remember D is born in 2001 and Rust ...

Instead, to add new features … maybe would b a good idea to waste 
some time on one of
previous topic describe above in order to get a chance to be more 
heavily used...

I remember a time to where Facebook use D to replace c++ code
but now ...
May 15 2021
prev sibling next sibling parent Zubair Zash <zubzash gmail.com> writes:
It seems like there is no plan nor roadmap. It's really hard to 
invest your time into something, realizing there is no team that 
works on fixing issues and adding features. Right now it's easier 
to stuck with C++. Maybe it's not fun to use it, but at least 
it's thought out, stable, has a large code base, tooling, and the 
most important, it has a roadmap. D needs dictatorship until it 
gets rid of the most annoying issues. Somebody has to make 
unpopular decisions.
May 14 2021
prev sibling next sibling parent reply SealabJaster <sealabjaster gmail.com> writes:
On Thursday, 13 May 2021 at 20:57:13 UTC, dogman wrote:

 ...


We used to have vision documents[1] but I believe they were 
stopped since they never really led to anything.

I miss them :(

[1] https://wiki.dlang.org/Category:Vision_Statements
May 14 2021
parent Dennis <dkorpel gmail.com> writes:
On Friday, 14 May 2021 at 23:05:38 UTC, SealabJaster wrote:

 We used to have vision documents[1] but I believe they were 
 stopped since they never really led to anything.


The latest of the sort (Still pretty old):
https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/
May 14 2021
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 13 May 2021 at 20:57:13 UTC, dogman wrote:

 Question to the core team. Whats the plan and roadmap for D ?
 a. are we planning to keep D just as a hobby language or a real 
 contender for industry use. Despite being complex, rust has 
 started to get adopted in industries. Whats our plan ?


The plan is for the D community to whine and moan as they wait 
for Walter to improve the VS Code extension or write web 
frameworks.

The only important difference between D and languages like Rust, 
Go, and Python is that those languages developed communities of 
developers that got stuff done, whereas D didn't. Since D's 
community is so ineffective, it's unlikely we'll ever see 
widespread D adoption.
May 15 2021
next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Saturday, 15 May 2021 at 15:05:44 UTC, bachmeier wrote:

 The only important difference between D and languages like 
 Rust, Go, and Python is that those languages developed 
 communities of developers that got stuff done, whereas D didn't.


That's not true. Those languages are very focused in their 
feature set, and have polished their main feature so that that 
feature is objectively "best in class".

D has over time had many sub communities that has created 
significant frameworks (in terms of scope and effort). Some went 
off to create their own language... That is just facts.
May 15 2021
prev sibling parent reply nkm1 <t4nk074 openmailbox.org> writes:
On Saturday, 15 May 2021 at 15:05:44 UTC, bachmeier wrote:


 The only important difference between D and languages like 
 Rust, Go, and Python is that those languages developed 
 communities of developers that got stuff done


This is not true, that is, its not the only difference. More 
important difference is that Python and Go never said "GC is too 
slow and inappropriate in some situations, we should offer 
complete support for some other way of managing memory", while 
Rust never said "Borrow checker is too annoying and GC is really 
convenient in some situations, lets implement memory barriers and 
stuff". They chose their way of dealing with it and just improved 
it over time without changing course.
May 15 2021
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Sunday, 16 May 2021 at 03:01:55 UTC, nkm1 wrote:

 This is not true, that is, its not the only difference. More 
 important difference is that Python and Go never said "GC is 
 too slow and inappropriate in some situations, we should offer 
 complete support for some other way of managing memory", while 
 Rust never said "Borrow checker is too annoying and GC is 
 really convenient in some situations, lets implement memory 
 barriers and stuff". They chose their way of dealing with it 
 and just improved it over time without changing course.


Many people has put a significant effort into the D GC, but where 
D differs is in being C-like (Go is not C-like although they may 
claim it is) which isn't GC friendly.

The fact that dmd does not ship with GC enabled speaks volumes...
May 15 2021
parent reply Mike Parker <aldacron gmail.com> writes:
On Sunday, 16 May 2021 at 03:46:50 UTC, Ola Fosheim Grostad wrote:


 The fact that dmd does not ship with GC enabled speaks 
 volumes...


Hardly. dmd doesn't release memory, either. Does that "speak 
volumes" about free? Neither is suitable for Walter's performance 
goals with dmd. That's precisely why D allows you to disable or 
avoid the GC when you need to.
May 15 2021
next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Sunday, 16 May 2021 at 03:58:15 UTC, Mike Parker wrote:

 On Sunday, 16 May 2021 at 03:46:50 UTC, Ola Fosheim Grostad 
 wrote:


 The fact that dmd does not ship with GC enabled speaks 
 volumes...


 Hardly. dmd doesn't release memory, either. Does that "speak 
 volumes" about free? Neither is suitable for Walter's 
 performance goals with dmd.


A global bump allocator is just another word for a memory leak. 
You dont need a comp sci degree to understand that this is not a 
good "feature".
May 15 2021
parent reply Mike Parker <aldacron gmail.com> writes:
On Sunday, 16 May 2021 at 04:32:31 UTC, Ola Fosheim Grostad wrote:

 On Sunday, 16 May 2021 at 03:58:15 UTC, Mike Parker wrote:



 A global bump allocator is just another word for a memory leak. 
 You dont need a comp sci degree to understand that this is not 
 a good "feature".


In this case, it's not a leak. DMD does its business and exits. 
I'm not sure what your point is.
May 15 2021
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Sunday, 16 May 2021 at 04:37:52 UTC, Mike Parker wrote:

 On Sunday, 16 May 2021 at 04:32:31 UTC, Ola Fosheim Grostad 
 wrote:

 On Sunday, 16 May 2021 at 03:58:15 UTC, Mike Parker wrote:



 A global bump allocator is just another word for a memory 
 leak. You dont need a comp sci degree to understand that this 
 is not a good "feature".


 In this case, it's not a leak. DMD does its business and exits. 
 I'm not sure what your point is.


WTF? All programs exit. Most programs try to play nice so that 
the user can get the most out of his computer.

The main purpose of implementing a language in itself is to force 
the language designers to eat their own pudding. Secondary goal 
is to show case language features.

The proof of the pudding is in the eating. If you yourself refuse 
to eat it, that will be viewed as the pudding not being ready for 
consumption. The first thing a seasoned programmer will look at 
is how the compiler was implemented using the language features.

Memory management in compilers isnt more complicated than for 
other system software and does only take a tiny fraction of 
compilation times.

There are many good reasons to eat your own pudding. If you dont, 
people will assume itsnt edible.
May 15 2021
parent reply Mike Parker <aldacron gmail.com> writes:
On Sunday, 16 May 2021 at 05:35:30 UTC, Ola Fosheim Grostad wrote:


 WTF? All programs exit. Most programs try to play nice so that 
 the user can get the most out of his computer.


Yeah, and...? dmd a very short-running program, and its allocated 
memory is released when it exits.


 There are many good reasons to eat your own pudding. If you 
 dont, people will assume itsnt edible.


You're acting as if D can only be used with the GC. dmd is 
*written* in D, so we are eating our own pudding. Walter is very 
focused on making compiles as fast as possible, and he determined 
that releasing memory and using the GC prevent him from meeting 
that goal. And he can still write his program in D.

The GC is not a panacea. It's not suitable for every use case or 
performance goal. And that's perfectly fine.
May 15 2021
next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Sunday, 16 May 2021 at 05:50:12 UTC, Mike Parker wrote:

 Yeah, and...? dmd a very short-running program, and its 
 allocated memory is released when it exits.


No, it isnt very short-running. And that is not a valid argument 
either, as the user may have other tasks that need the memory.

To keep it short:

Programs that acquire significantly more resources than needed 
are misbehaving. Never met anyone disagreeing with this view.

Memory management is insignificant time wise if you have a 
solution suitable for systemsprogramming.

If D does not have a memory management solution suitable for DMD, 
then D does not have a solution for systems level programming, 
yet...

If this is difficult to accept, then there is no hope of 
improvements.


 The GC is not a panacea. It's not suitable for every use case 
 or performance goal. And that's perfectly fine.


If GC is suitable for anything system level, it would be a batch 
program like a compiler.
May 15 2021
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 16 May 2021 at 06:44:09 UTC, Ola Fosheim Grostad wrote:

 On Sunday, 16 May 2021 at 05:50:12 UTC, Mike Parker wrote:

 Yeah, and...? dmd a very short-running program, and its 
 allocated memory is released when it exits.


 No, it isnt very short-running. And that is not a valid 
 argument either, as the user may have other tasks that need the 
 memory.

 To keep it short:

 Programs that acquire significantly more resources than needed 
 are misbehaving. Never met anyone disagreeing with this view.

 Memory management is insignificant time wise if you have a 
 solution suitable for systemsprogramming.

 If D does not have a memory management solution suitable for 
 DMD, then D does not have a solution for systems level 
 programming, yet...

 If this is difficult to accept, then there is no hope of 
 improvements.


 The GC is not a panacea. It's not suitable for every use case 
 or performance goal. And that's perfectly fine.


 If GC is suitable for anything system level, it would be a 
 batch program like a compiler.


This is the big difference I see here, everyone keeps discussing 
how much GC matters, while other language communities, regardless 
of what others think just keep doing their stuff.

https://www.f-secure.com/en/consulting/foundry/usb-armory

https://tinygo.org/

https://makecode.com/language

https://www.microej.com/

https://www.wildernesslabs.co/

Now you can argue that Go, Python, JavaScript, Java, .NET aren't 
suitable for systems programming, that people are doing a big 
mistake adopting them, that they are just subsets of the actual 
languages, pick your argument against them.

However at the end of the day hardware is being sold, and 
developers are making money with such products, regardless of 
their suitability for systems programming or whatever else.

Meanwhile over here, yet another GC discussion round starts, or 
what features to implement that should be the next great thing, 
and then one wonders why adoption isn't working out.
May 16 2021
next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Sunday, 16 May 2021 at 07:18:54 UTC, Paulo Pinto wrote:

 Now you can argue that Go, Python, JavaScript, Java, .NET 
 aren't suitable for systems programming, that people are doing 
 a big mistake adopting them, that they are just subsets of the 
 actual languages, pick your argument against them


Python is the only language not well suited for implementing a 
compiler. And no, it is not systems level programming, but it is 
the level right before...

This thread is about planning for competitive memory management 
in D, not in other languages.

Is there a plan? No? Will there be a plan? Right now, it does not 
seem likely. People make suggestions all the time, but there is 
no signal of a likely path.
May 16 2021
parent reply SealabJaster <sealabjaster gmail.com> writes:
On Sunday, 16 May 2021 at 09:22:00 UTC, Ola Fosheim Grostad wrote:

 Is there a plan? No? Will there be a plan? Right now, it does 
 not seem likely. People make suggestions all the time, but 
 there is no signal of a likely path.


On the topic of a plan (just in general, not specifically about 
DMD's memory usage):

1. It begs the question of, how is it possible for anyone to even 
organise a cohesive plan coming forward, since it requires 
participation from both the leadership, core team, and also D's 
community (ideally).

2. Even if we can bring a plan forward, how can the people in 
charge ensure that it is executed, especially in a timely manner?

3. One problem I see all the time with discussions on D, we want 
to be everything yet end up as nothing; we want to please every 
single type of programmer, yet that leads to impossible 
situations, and compromise is for some reason always out of the 
question; we want everything to be perfect and work in every 
situation, but this often isn't achievable, and no compromise is 
made.

So with massive hurdles at any part of even getting people 
together to make a plan, let alone *making the actual plan*, what 
could the future look like for D's progression and evolution?

My best guess is: It'll be the same as always. DIPs that get 
rejected for not being completely perfect in every possible 
use-case (and god forbid it use the GC); features that appear out 
of nowhere; "glaring" or "fundamental" issues (for whomever is 
complaining that is) will be ignored and swept to the side with 
"fix it yourself/file an issue"; things just happen when they 
happen with no rhyme or method, and so on...

Even worse is when exciting things like newCTFE are teased for 
years, only to be dropped :(

Or things like DIP 1028(?) where mostly a single point of tension 
(all extern functions being  safe by default) causes all that 
hard work to go to waste.

Without a cohesive direction and a well-defined plan, I'd say it 
definitely increases the risk factor of someone/some entity 
adopting D for a project, due to the large uncertainty and 
confusion about what kind of language D is.

e.g. I wonder what people who keep on eye on D, but only on a 
casual level, would think once they learn about ImportC. I wonder 
if the feeling would be of confusion or excitement (or both!). I 
wonder if they'll get a feeling of an identity crisis of sorts.

e.g. We're a language with both a GC and  nogc, yet we don't 
provide many tools out of the box for  nogc code (containers?); 
we're becoming GC-phobic in regards to features and library 
changes; etc.

Then there's all this hub-bub about a possible Phobos 
v2/v2021/*whatever*, and it's like: will this actually lead 
anywhere, is there any actual intention to go through with this, 
or is this just a theoretical talking point for the next part of 
a decade?

idk, this was kind of just a ramble - I feel D's overall 
direction and management doesn't seem to be "keeping up with the 
times" so to speak. It's kind of like that "This is fine" meme in 
a way, I don't know how to describe it.

Uncertainly. Lack of clarity. Lack of obvious public direction 
and vision. What could happen to try and tackle these things (if 
they're even problems at all and it's not just me having bad 
observations)?
May 16 2021
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Sunday, 16 May 2021 at 09:53:04 UTC, SealabJaster wrote:

 On Sunday, 16 May 2021 at 09:22:00 UTC, Ola Fosheim Grostad 
 wrote:

 Is there a plan? No? Will there be a plan? Right now, it does 
 not seem likely. People make suggestions all the time, but 
 there is no signal of a likely path.


 On the topic of a plan (just in general, not specifically about 
 DMD's memory usage):

 1. It begs the question of, how is it possible for anyone to 
 even organise a cohesive plan coming forward, since it requires 
 participation from both the leadership, core team, and also D's 
 community (ideally).


I dont know, but it is a historic fact that D's feature set is a 
result of evolutionary experimentation more than analytical 
rigour and careful planning.

So, the best option if there is no plan is to make DMD more and 
more idiomatic and use idiomatic MM, then the weak spots will be 
exposed and hopefully fixed?
May 16 2021
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 16 May 2021 at 07:18:54 UTC, Paulo Pinto wrote:

 On Sunday, 16 May 2021 at 06:44:09 UTC, Ola Fosheim Grostad 
 wrote:

 [...]


 This is the big difference I see here, everyone keeps 
 discussing how much GC matters, while other language 
 communities, regardless of what others think just keep doing 
 their stuff.

 [...]


+1
May 16 2021
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Sunday, 16 May 2021 at 06:44:09 UTC, Ola Fosheim Grostad wrote:


 If this is difficult to accept, then there is no hope of 
 improvements.


This has nothing to do with D. The C version of the D compiler 
also did not release memory. He has written in these forums about 
why he made that decision, and it has absolutely nothing to do 
with memory management options in any language. It was a 
conscious decision to pay for faster compile times with increased 
memory usage.

If you think that's a bad decision, fine. But you're flat out 
wrong that it says anything about D.



 If GC is suitable for anything system level, it would be a 
 batch program like a compiler.


And no one says it isn't. That Walter chose not to use the GC 
says nothing at all about its suitability for compilers. Of 
course someone who decided the cost of free is too high would 
choose not to use the GC!

Someone who is not Walter might choose to take the hit on compile 
times to pay for the benefits of the GC. Then, of course, they 
would write their code with that in mind and optimize it for GC 
usage. D gives them the choice to make the right decision for 
their specific use case to meet their specific goals.

You're extrapolating a broad point from a single example based on 
a flawed interpretation.
May 16 2021
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Sunday, 16 May 2021 at 07:25:30 UTC, Mike Parker wrote:

 And no one says it isn't. That Walter chose not to use the GC 
 says nothing at all about its suitability for compilers. Of 
 course someone who decided the cost of free is too high would 
 choose not to use the GC!


Thats not obvious at all. In batch a GC can perform better than 
naive free if it is possible  to give the compiler good 
information about where and when to scan.

But if people who make language decisions dont struggle with 
memory management in their coding practice then there is less 
likely to be significant improvements in this feature set.
May 16 2021
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 16 May 2021 at 06:44:09 UTC, Ola Fosheim Grostad wrote:

 On Sunday, 16 May 2021 at 05:50:12 UTC, Mike Parker wrote:

 Yeah, and...? dmd a very short-running program, and its 
 allocated memory is released when it exits.


 No, it isnt very short-running. And that is not a valid 
 argument either, as the user may have other tasks that need the 
 memory.

 To keep it short:

 Programs that acquire significantly more resources than needed 
 are misbehaving. Never met anyone disagreeing with this view.

 Memory management is insignificant time wise if you have a 
 solution suitable for systemsprogramming.

 If D does not have a memory management solution suitable for 
 DMD, then D does not have a solution for systems level 
 programming, yet...

 If this is difficult to accept, then there is no hope of 
 improvements.


 The GC is not a panacea. It's not suitable for every use case 
 or performance goal. And that's perfectly fine.


 If GC is suitable for anything system level, it would be a 
 batch program like a compiler.


C'mon dude... How can you say with a straight face that dmd isn't 
a short running process?

It's even hard to imagine a better real world example of a case 
where it's ok to not free.

Also, if you want to you can use the lowmem switch?
May 16 2021
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Sunday, 16 May 2021 at 10:22:02 UTC, Imperatorn wrote:

 C'mon dude... How can you say with a straight face that dmd 
 isn't a short running process?

 It's even hard to imagine a better real world example of a case 
 where it's ok to not free.


This is only acceptable in realtime applications or very specific 
FOREGROUND applications. Draining kernel and hardware resources 
is not something a BACKGROUND prosess should do.

If D was popular it would be used in installers and the compiler 
would run for ages, kicking in and out.
May 16 2021
prev sibling parent reply IGotD- <nise nise.com> writes:
On Sunday, 16 May 2021 at 05:50:12 UTC, Mike Parker wrote:

 You're acting as if D can only be used with the GC. dmd is 
 *written* in D, so we are eating our own pudding. Walter is 
 very focused on making compiles as fast as possible, and he 
 determined that releasing memory and using the GC prevent him 
 from meeting that goal. And he can still write his program in D.

 The GC is not a panacea. It's not suitable for every use case 
 or performance goal. And that's perfectly fine.


In practice that's the case, that you cannot avoid GC unless you 
don't use anything from the standard library. As soon you use 
arrays, associative arrays and many other data structures GC will 
be used.

There are two options as I see it. Either make the standard 
library not using any GC (likely manual memory management or some 
other method that is not tracing GC), or introduce fat pointers 
where GC objects are of a special type and the you can recompile 
the standard library to the GC type you want.
May 16 2021
parent reply Mike Parker <aldacron gmail.com> writes:
On Sunday, 16 May 2021 at 09:48:58 UTC, IGotD- wrote:


 In practice that's the case, that you cannot avoid GC unless 
 you don't use anything from the standard library. As soon you 
 use arrays, associative arrays and many other data structures 
 GC will be used.


By definition, avoiding the GC means avoiding features that use 
the GC. And you don't lose everything in the standard library, 
either. A good chunk of it does not require the GC.

Like anything else in programming, it's a tradeoff. Give up the 
GC and you lose the convenience it provides. The question is, do 
you *need* to give up the GC or not? And if so, do you need to 
give it up completely or only in the spots where you absolutely 
cannot trigger an allocation?

I'm not saying there can't be more work done to alleviate any 
pain that arises from going without the GC. But I do believe some 
people reach for  nogc when they don't need to, and I don't think 
that's a demographic we should be aiming for.
May 16 2021
next sibling parent IGotD- <nise nise.com> writes:
On Sunday, 16 May 2021 at 10:15:00 UTC, Mike Parker wrote:

 Like anything else in programming, it's a tradeoff. Give up the 
 GC and you lose the convenience it provides. The question is, 
 do you *need* to give up the GC or not? And if so, do you need 
 to give it up completely or only in the spots where you 
 absolutely cannot trigger an allocation?


Many like GC but it is the type of GC in D that disqualifies the 
language for certain applications, an area where often C++ 
dominates. The key is not giving up GC, but giving people a 
choice of which type of GC they want to use. D is a versatile 
language and giving people the versatility of pick and choose GC 
type is something that would suit an already versatile language. 
D already supports RC, but only by implicitly doing so in the 
code so next step would be transparent RC.
May 16 2021
prev sibling next sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Sunday, 16 May 2021 at 10:15:00 UTC, Mike Parker wrote:

 On Sunday, 16 May 2021 at 09:48:58 UTC, IGotD- wrote:


 [...]


 By definition, avoiding the GC means avoiding features that use 
 the GC. And you don't lose everything in the standard library, 
 either. A good chunk of it does not require the GC.

 Like anything else in programming, it's a tradeoff. Give up the 
 GC and you lose the convenience it provides. The question is, 
 do you *need* to give up the GC or not? And if so, do you need 
 to give it up completely or only in the spots where you 
 absolutely cannot trigger an allocation?

 I'm not saying there can't be more work done to alleviate any 
 pain that arises from going without the GC. But I do believe 
 some people reach for  nogc when they don't need to, and I 
 don't think that's a demographic we should be aiming for.


Yes, POOP is what made C++ so unappealing (POOP permeates C++ 
froma A to Z) and we should avoid to fall in that same trap in D.

POOP = Premature Optimization Oriented Programming.
May 16 2021
prev sibling parent nkm1 <t4nk074 openmailbox.org> writes:
On Sunday, 16 May 2021 at 10:15:00 UTC, Mike Parker wrote:


 I'm not saying there can't be more work done to alleviate any 
 pain that arises from going without the GC. But I do believe 
 some people reach for  nogc when they don't need to, and I 
 don't think that's a demographic we should be aiming for.


But the trouble is that D's GC is just not a very good one! There 
are much better GCs out there. Why doesn't D have one of those 
better GCs?

It's pretty obvious that the decision to offer full support for 
 nogc is the source of real technical trouble with memory 
management in D. The language was designed to work with GC and 
relies on it. Thus, the path of least resistance (technical 
resistance, that is) would be to improve the GC - for example, by 
implementing memory barriers, perhaps restricting the language 
itself in some respects and doing other such things which should 
make it possible to use some better GC. People who cry about 
automated memory management too much could then be told to just 
go somewhere else and use C++ or Rust or whatever (which is what 
they do anyway).
Instead what happened is stuff like dip1000... does that even 
work already? Juding by the thread "dip1000 + pure is a DEADLY 
COMBO", not really. There were also some ideas about refcounting 
- looks like that also went nowhere?

Supporting both GC and  nogc is just way too difficult, that's 
all there is to it. Other programming languages don't do it (e.g. 
its possible to bolt a GC onto C or C++, but they don't offer any 
special support for it). Instead, D is stuck with subpar GC, 
which seems no better than what's possible with C++, and also 
with dip1000, which doesn't seem all that great either.

All other problems with D aren't a big deal, but the memory 
management thing is real trouble, and that's because the 
developers go against the original design of the language.
May 16 2021
prev sibling next sibling parent reply Johan Engelen <j j.nl> writes:
On Sunday, 16 May 2021 at 03:58:15 UTC, Mike Parker wrote:

 On Sunday, 16 May 2021 at 03:46:50 UTC, Ola Fosheim Grostad 
 wrote:


 The fact that dmd does not ship with GC enabled speaks 
 volumes...


 Hardly. dmd doesn't release memory, either. Does that "speak 
 volumes" about free? Neither is suitable for Walter's 
 performance goals with dmd. That's precisely why D allows you 
 to disable or avoid the GC when you need to.


Hi Mike,
   I have to agree with Ola on this point.
I too find it jarring that for something as simple (really) as a 
compiler, that a very simple bump-the-pointer memory allocation 
strategy without any freeing of memory is considered superior to 
the language's GC.

I do not buy the performance argument. The high memory 
consumption of the D compiler is a real issue, and it does hurt 
compilation performance. The amount of memory used frequently 
passes the available physical memory and paging isn't cheap. Or 
worse, the memory used exceeds the pagefile limit, and the 
compile just fails.
Speeding up a build by parallel compilation is not possible with 
a compiler that has such high memory demands.

Let's simply acknowledge the issue and move on. Ignoring it will 
just spawn more forum posts about it and drain our energy.

cheers,
   Johan
May 16 2021
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Sunday, 16 May 2021 at 10:50:38 UTC, Johan Engelen wrote:

 I do not buy the performance argument.


Indeed. When this bad decision was made, the blame went to free. 
Walter's decision was to never call free... but someone here just 
replaced the free call with the jemalloc library and saw the same 
performance improvement.

Walter's decision was, even known at the time, the wrong one.



order cuz at least in theory, you can buy more ram lol).
May 16 2021
prev sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Sunday, 16 May 2021 at 10:50:38 UTC, Johan Engelen wrote:

 On Sunday, 16 May 2021 at 03:58:15 UTC, Mike Parker wrote:

 On Sunday, 16 May 2021 at 03:46:50 UTC, Ola Fosheim Grostad 
 wrote:


 The fact that dmd does not ship with GC enabled speaks 
 volumes...


 Hardly. dmd doesn't release memory, either. Does that "speak 
 volumes" about free? Neither is suitable for Walter's 
 performance goals with dmd. That's precisely why D allows you 
 to disable or avoid the GC when you need to.


 Hi Mike,
   I have to agree with Ola on this point.


I have trouble following an argument between people that I feel 
should know better than me that the premise is false.

Ola's statement that


 dmd does not ship with GC enabled


is false, given the 
[-lowmem](https://dlang.org/dmd-windows.html#switch-lowmem) 
compiler option:

 -lowmem
    Enable the garbage collector for the compiler, reducing the 
 compiler memory requirements but increasing compile times.


So dmd *as shipped* can be used with and without the GC, the 
default being fast. You've got to have a default.

So before taking this further, I'd suggest arguing about the 
effectiveness of -lowmem, and whether the GC at all can be blamed.

1. Usually the prime argument against a GC is speed. So, if one 
wants to prove that the GC leads to unacceptable delays then 
demonstrate that compile times with -lowmem take considerably 
more time than compilers that use manual memory management. Try 
to come up with a comparable case, like C-like betterC and C. If 
the argument is that important, it shouldn't be hard to make an 
indisputable case.
2. A secondary argument is that the GC claims more memory than 
when memory is released by hand. We know that memory usage can be 
very high even with -lowmem, but that is much more likely to be 
due to template instantiations and ctfe than due to uncollected 
memory. Again, it shouldn't be hard to demonstrate whether the GC 
can be blamed substantially or not.

Until i see this demonstrated, the argument goes on the 
GC-whiners pile for me...

-- Bastiaan.
May 16 2021
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Sunday, 16 May 2021 at 12:42:44 UTC, Bastiaan Veelo wrote:

 On Sunday, 16 May 2021 at 10:50:38 UTC, Johan Engelen wrote:

 On Sunday, 16 May 2021 at 03:58:15 UTC, Mike Parker wrote:

 On Sunday, 16 May 2021 at 03:46:50 UTC, Ola Fosheim Grostad 
 wrote:




 Ola's statement that


 dmd does not ship with GC enabled


 is false, given the 
 [-lowmem](https://dlang.org/dmd-windows.html#switch-lowmem) 
 compiler option:

 -lowmem
    Enable the garbage collector for the compiler, reducing the 
 compiler memory requirements but increasing compile times.


 So dmd *as shipped* can be used with and without the GC, the 
 default being fast. You've got to have a default.


So, you just confirmed that my statement was true.

My MAIN POINT was however that D does not have a system level 
management option if it does not have an option that deemed good 
enough for DMD. And that would be the default.

Calling free manually isnt it, because that is manual management 
that nobody wants to do, and not calling free is even worse.

Whatever the default is, it should be a memory management 
solution that can be recommended and pointed to as a feature, by 
being the default that solution would be given priority.

Simple language development strategy to ensure improved quality 
over time.
May 16 2021
next sibling parent reply dogman <dogman someone.com> writes:
Folks, I think the forum is discussing whether to do GC or not 
which IMHO is a wrong thinking. We need both. I think GC is good 
enough for most of the use cases whether its web services, user 
tools, business logic etc. Do you really think Go/Rust without 
google/mozilla support and money and constant promotion could 
have reached this popularity. no way. My request to the community 
is let D be good at both. With a switch of GC=off, people should 
be able to use manual memory management and also able to use 
stdlib and lot of libraries. Not sure if its technically 
possible. Most people will use D with GC on. I know we can turn 
off GC and mix manual memory management. But not sure we are able 
to understand the developer community. So lets make it more clear 
with a black and white approach. Instead we gave them options 
with lot of ifs and buts.
We should get their feedback(please initiate a survey). Lets 
create small groups to improve specific areas, lets do 
benchmarks, lets create a plan, improve our documentation. If you 
create a plan and divide into smaller milestones people can help 
their part. I think we have all the ammunition its just that we 
need to clean, improve and show case better. I guess industry 
wants a simple, secure language which can be easily interop with 
billions of existing C/C++ codebases. Instead of hundreds of 
features, lets focus on tooling, bootstrap, strengths etc. We 
need a reincarnation.
May 16 2021
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 16 May 2021 at 18:24:11 UTC, dogman wrote:

 [...]


There are "GC off" switches.

 nogc, GC.disable and betterC
May 16 2021
parent reply dogman <dogman somehwere.com> writes:
On Sunday, 16 May 2021 at 19:46:06 UTC, Imperatorn wrote:

 On Sunday, 16 May 2021 at 18:24:11 UTC, dogman wrote:

 [...]


 There are "GC off" switches.

  nogc, GC.disable and betterC


But then we dont know if all standard library and other modules 
can be used. We dont even have associate arrays etc. What we want 
is a pluggable framework where people can use the default GC or 
their GC or manual memory management by registering 
malloc/free's(like zig). Code is same. I am not sure technically 
if its possible as I am not an expert in compiler.
May 16 2021
next sibling parent reply dogman <dogman somehwere.com> writes:
On Sunday, 16 May 2021 at 20:33:12 UTC, dogman wrote:

 On Sunday, 16 May 2021 at 19:46:06 UTC, Imperatorn wrote:

 On Sunday, 16 May 2021 at 18:24:11 UTC, dogman wrote:

 [...]


 There are "GC off" switches.

  nogc, GC.disable and betterC


 But then we dont know if all standard library and other modules 
 can be used. We dont even have associate arrays etc. What we 
 want is a pluggable framework where people can use the default 
 GC or their GC or manual memory management by registering 
 malloc/free's(like zig). Code is same. I am not sure 
 technically if its possible as I am not an expert in compiler.


Rust says "Rewrite", D will say "Extend" which means extend your 
code and rewrite slowly with a safe and simple language. 
Companies can start writing D and use their existing c/c++ code. 
I have been working in c/c++ for last 10-15 years still I couldnt 
follow rust easily. Went through the rust book 2 times. I do like 
some part of it but any big code base looks horribly complex. I 
doubted if its my problem or is language is complex and bad to 
read.
May 16 2021
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 16 May 2021 at 20:36:41 UTC, dogman wrote:

 On Sunday, 16 May 2021 at 20:33:12 UTC, dogman wrote:

 On Sunday, 16 May 2021 at 19:46:06 UTC, Imperatorn wrote:

 On Sunday, 16 May 2021 at 18:24:11 UTC, dogman wrote:

 [...]


 There are "GC off" switches.

  nogc, GC.disable and betterC


 But then we dont know if all standard library and other 
 modules can be used. We dont even have associate arrays etc. 
 What we want is a pluggable framework where people can use the 
 default GC or their GC or manual memory management by 
 registering malloc/free's(like zig). Code is same. I am not 
 sure technically if its possible as I am not an expert in 
 compiler.


 Rust says "Rewrite", D will say "Extend" which means extend 
 your code and rewrite slowly with a safe and simple language. 
 Companies can start writing D and use their existing c/c++ 
 code. I have been working in c/c++ for last 10-15 years still I 
 couldnt follow rust easily. Went through the rust book 2 times. 
 I do like some part of it but any big code base looks horribly 
 complex. I doubted if its my problem or is language is complex 
 and bad to read.


Let me put it this way, a couple of years ago Facebook played 
with D, now they have this to tell about Rust.

https://engineering.fb.com/2021/04/29/developer-tools/rust/


is on

https://developer.android.com/games/develop/build-in-unity


https://dotnet.microsoft.com/learn/games

https://stadia.dev/intl/fr_fr/blog/unity-support-for-stadia:heres-what-you-need-to-know/

https://developer.nintendo.com/tools

https://unity.com/our-company/newsroom/sony-computer-entertainment-and-unity-technologies-form-strategic-partnership

Why? Because they have had plan and stuck to it, regardless of 
what others keep saying about their suitability.
May 16 2021
parent reply dogman <dogman somehwere.com> writes:
On Sunday, 16 May 2021 at 21:24:40 UTC, Paulo Pinto wrote:

 Let me put it this way, a couple of years ago Facebook played 
 with D, now they have this to tell about Rust.


I disagree with this. Facebook chose it because they want to run 
a safe stable language for their mercurial clone. There are lot 
of thoughts, support, ads by mozilla folks for this. Why didnt 
facebook chose Go for this ? For their case GC was no go. For 
Remedy did we analyse what went wrong ? Do we know why facebook 
didnt D after Andrei left ? Did we ask what programming community 
want. Definitely we cant satisfy everyone for all the feature but 
atleast we should play with  some of our  strengths.
Why would someone use D for any with GC.
Go - has GC, easy, good libraries, google backing
Rust - safety, mozilla backing
swift - apple backing, easy

Lets not be in own echo chamber. I feel D can push itself as a 
simple way of doing memory safety and extension to C/C++/python 
instead of a rewrite. Let advertize as a language which can be 
simple like python and fast as C. C++ rust interop doesnt see 
easy.
a. Safe language
b. Good tooling
c. Good interop with C/C++
d. Flexible to use GC/no GC.
May 16 2021
next sibling parent reply dogman <dogman somehwere.com> writes:
On Sunday, 16 May 2021 at 21:38:51 UTC, dogman wrote:

 On Sunday, 16 May 2021 at 21:24:40 UTC, Paulo Pinto wrote:

 Let me put it this way, a couple of years ago Facebook played 
 with D, now they have this to tell about Rust.


 I disagree with this. Facebook chose it because they want to 
 run a safe stable language for their mercurial clone. There are 
 lot of thoughts, support, ads by mozilla folks for this. Why 
 didnt facebook chose Go for this ? For their case GC was no go. 
 For Remedy did we analyse what went wrong ? Do we know why 
 facebook didnt D after Andrei left ? Did we ask what 
 programming community want. Definitely we cant satisfy everyone 
 for all the feature but atleast we should play with  some of 
 our  strengths.
 Why would someone use D for any with GC.
 Go - has GC, easy, good libraries, google backing
 Rust - safety, mozilla backing
 swift - apple backing, easy

 Lets not be in own echo chamber. I feel D can push itself as a 
 simple way of doing memory safety and extension to C/C++/python 
 instead of a rewrite. Let advertize as a language which can be 
 simple like python and fast as C. C++ rust interop doesnt see 
 easy.
 a. Safe language
 b. Good tooling
 c. Good interop with C/C++
 d. Flexible to use GC/no GC.


To the community, sorry am not trying to a$$hole. I just want 
this language and community to grow and flourish. I wish Andrei, 
Walter come up with Q&A to do a postmortem of the issues they 
faced and what we can do for it. I wish to help on small tasks 
whatever I can. I used to do lot of c++ and python and thought of 
a language somewhat like D. Then I saw D and always wished, if I 
could write in D daily. D on android, D on linux kernel/EBPF, D 
with WASM.
May 16 2021
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 16 May 2021 at 21:42:32 UTC, dogman wrote:

 On Sunday, 16 May 2021 at 21:38:51 UTC, dogman wrote:

 [...]


 To the community, sorry am not trying to a$$hole. I just want 
 this language and community to grow and flourish. I wish 
 Andrei, Walter come up with Q&A to do a postmortem of the 
 issues they faced and what we can do for it. I wish to help on 
 small tasks whatever I can. I used to do lot of c++ and python 
 and thought of a language somewhat like D. Then I saw D and 
 always wished, if I could write in D daily. D on android, D on 
 linux kernel/EBPF, D with WASM.


Men too, I also want more D on embedded
May 17 2021
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 16 May 2021 at 21:38:51 UTC, dogman wrote:

 On Sunday, 16 May 2021 at 21:24:40 UTC, Paulo Pinto wrote:

 Let me put it this way, a couple of years ago Facebook played 
 with D, now they have this to tell about Rust.


 I disagree with this. Facebook chose it because they want to 
 run a safe stable language for their mercurial clone. There are 
 lot of thoughts, support, ads by mozilla folks for this. Why 
 didnt facebook chose Go for this ? For their case GC was no go. 
 For Remedy did we analyse what went wrong ? Do we know why 
 facebook didnt D after Andrei left ? Did we ask what 
 programming community want. Definitely we cant satisfy everyone 
 for all the feature but atleast we should play with  some of 
 our  strengths.
 Why would someone use D for any with GC.
 Go - has GC, easy, good libraries, google backing
 Rust - safety, mozilla backing
 swift - apple backing, easy

 Lets not be in own echo chamber. I feel D can push itself as a 
 simple way of doing memory safety and extension to C/C++/python 
 instead of a rewrite. Let advertize as a language which can be 
 simple like python and fast as C. C++ rust interop doesnt see 
 easy.
 a. Safe language
 b. Good tooling
 c. Good interop with C/C++
 d. Flexible to use GC/no GC.


In what concerns Facebook, their GC cases are already covered by 
Haskell, OCaml and Java based languages, no need for the anemic 
Go.

Python JITs are enjoying a revival most likely thanks to Julia, 
now at Pycon 2021 it became official why Guido left his early 
retirement and went to work for Microsoft.

https://us.pycon.org/2021/schedule/presentation/52/

Instagram is also doing a JIT attempt based on their workloads,

https://us.pycon.org/2021/schedule/presentation/76/

Then there is already Cython, good enough to write NES emulators 
in Pyhon,

https://us.pycon.org/2021/schedule/presentation/66/

And the endless set of hardware being supported by CircuitPython 
as the modern BASIC,

https://us.pycon.org/2021/schedule/presentation/69/

Being a glue language for Python isn't any killer application 
worth pursuing, by the time it finally reaches it, Python won't 
need it any longer.
May 16 2021
prev sibling next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 16 May 2021 at 20:33:12 UTC, dogman wrote:

 On Sunday, 16 May 2021 at 19:46:06 UTC, Imperatorn wrote:

 On Sunday, 16 May 2021 at 18:24:11 UTC, dogman wrote:

 [...]


 There are "GC off" switches.

  nogc, GC.disable and betterC


 But then we dont know if all standard library and other modules 
 can be used. We dont even have associate arrays etc. What we 
 want is a pluggable framework where people can use the default 
 GC or their GC or manual memory management by registering 
 malloc/free's(like zig). Code is same. I am not sure 
 technically if its possible as I am not an expert in compiler.


Yeah, I see what you mean
May 16 2021
prev sibling parent sighoya <sighoya gmail.com> writes:
On Sunday, 16 May 2021 at 20:33:12 UTC, dogman wrote:

 On Sunday, 16 May 2021 at 19:46:06 UTC, Imperatorn wrote:

 On Sunday, 16 May 2021 at 18:24:11 UTC, dogman wrote:

 [...]


 There are "GC off" switches.

  nogc, GC.disable and betterC


 But then we dont know if all standard library and other modules 
 can be used. We dont even have associate arrays etc. What we 
 want is a pluggable framework where people can use the default 
 GC or their GC


Definitely + for this, providing a set of GCs for different 
situations is a good thing as severally proven in Java.


 or manual memory management by registering malloc/free's(like 
 zig). Code is same. I am not sure technically if its possible 
 as I am not an expert in compiler.


I think that's what  russhy also wanted to propose. Providing 
support for other memory containers/allocators in stdlib.
As much as I like it, I think "the same" code for all kinds of MM 
is just too beautiful to become true.
Different memory containers will work better for different code 
or even require code to be rewritten which is often the case with 
the ownership system in Rust.
Then we are left to overload over any MM container increasing the 
risk for a state space explosion.
May 16 2021
prev sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Sunday, 16 May 2021 at 18:24:11 UTC, dogman wrote:

 community is let D be good at both. With a switch of GC=off, 
 people should be able to use manual memory management and also 
 able to use stdlib and lot of libraries. Not sure if its 
 technically possible. Most people will use D with GC on. I know 
 we can turn off GC and mix manual memory management.


It takes discipline to mix. Libraries would need to:
1. Be written for RC, transition to GC becomes free.
2. Written for finalizers, getting basic cleanup
3. Test for various mixes of RC/GC... How?
But you also need a fully precise GC to get proper finalzation...

Probably not worth it, easier to have GC only libs...

I am arguing in favour of task bound GC, which can b extended to 
task-group GC. The latter should roughly cover existing code 
bases that dont do anything fancy...

The key point however is that DMD ought to use the recommened 
sytem programming MM idiom (whatever it ends up being), then it 
is possible to argue pro et contra with some level of objectivity.

With no common ground, nothing will move...
May 16 2021
parent reply SealabJaster <sealabjaster gmail.com> writes:
On Sunday, 16 May 2021 at 22:02:29 UTC, Ola Fosheim Grostad wrote:

 On Sunday, 16 May 2021 at 18:24:11 UTC, dogman wrote:

 community is let D be good at both. With a switch of GC=off, 
 people should be able to use manual memory management and also 
 able to use stdlib and lot of libraries. Not sure if its 
 technically possible. Most people will use D with GC on. I 
 know we can turn off GC and mix manual memory management.


 It takes discipline to mix. Libraries would need to:
 1. Be written for RC, transition to GC becomes free.
 2. Written for finalizers, getting basic cleanup
 3. Test for various mixes of RC/GC... How?
 But you also need a fully precise GC to get proper 
 finalzation...
 ...
 With no common ground, nothing will move...


This is what I was going on about in terms of "We want to be 
everything yet end up as nothing" and "We expect everything to be 
perfect in every possible use case, but ends up in impossible 
situations where nothing happens since no one will compromise".

Ultimately the fate of this thread is that everything posted here 
will just turn to dust overtime, as no one with the power to move 
things forward will even take things into consideration.
May 16 2021
next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Sunday, 16 May 2021 at 22:11:23 UTC, SealabJaster wrote:

 On Sunday, 16 May 2021 at 22:02:29 UTC, Ola Fosheim Grostad 
 wrote:
 This is what I was going on about in terms of "We want to be 
 everything yet end up as nothing" and "We expect everything to 
 be perfect in every possible use case, but ends up in 
 impossible situations where nothing happens since no one will 
 compromise".


I think it is more a matter of "we know what we have, but not 
what we get", which tend to lead to stagnation or long tail decay.


 Ultimately the fate of this thread is that everything posted 
 here will just turn to dust overtime, as no one with the power 
 to move things forward will even take things into consideration.


Most likely. It is a bit more dysfunctional than that as people 
are willing to put in effort to move things themselves if they 
knew that the time they put in is a move in a direction that 
wouldnt be rejected. The real blocker is that there is no format 
for creating a task force (working group).
May 16 2021
prev sibling parent reply norm <norm.rowtree gmail.com> writes:
On Sunday, 16 May 2021 at 22:11:23 UTC, SealabJaster wrote:

 On Sunday, 16 May 2021 at 22:02:29 UTC, Ola Fosheim Grostad 
 wrote:

 On Sunday, 16 May 2021 at 18:24:11 UTC, dogman wrote:

 community is let D be good at both. With a switch of GC=off, 
 people should be able to use manual memory management and 
 also able to use stdlib and lot of libraries. Not sure if its 
 technically possible. Most people will use D with GC on. I 
 know we can turn off GC and mix manual memory management.


 It takes discipline to mix. Libraries would need to:
 1. Be written for RC, transition to GC becomes free.
 2. Written for finalizers, getting basic cleanup
 3. Test for various mixes of RC/GC... How?
 But you also need a fully precise GC to get proper 
 finalzation...
 ...
 With no common ground, nothing will move...


 This is what I was going on about in terms of "We want to be 
 everything yet end up as nothing" and "We expect everything to 
 be perfect in every possible use case, but ends up in 
 impossible situations where nothing happens since no one will 
 compromise".

 Ultimately the fate of this thread is that everything posted 
 here will just turn to dust overtime, as no one with the power 
 to move things forward will even take things into consideration.


You do have power, but like anything that involves other people 
if you have a valid idea for where D should go you need to 
convince others first. But while trying to do that remember, 
those others will have to do the actual work to implement and 
maintain whatever it is you want. So bitching for your pet 
features is nothing without putting in the work to either a) 
convince others it is worth doing and where possible b) doing the 
work, either implementation, writing a DIP etc.

So everyone here has power to do something, just most can't be 
bothered once the work kicks in. If you have written several 
books or a compiler or contributed PRs and proven your skills 
then your power will grow, i.e. you ability to influence the core 
D devs.
May 16 2021
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Monday, 17 May 2021 at 01:55:14 UTC, norm wrote:

 So everyone here has power to do something, just most can't be 
 bothered once the work kicks in.


Only on the microscopic level. People who have veto power need to 
set up working groups, guide them and give them a mandate.

Most cant be bothered to do work that is likely to be binned, 
because that is extremely wasteful (expensive) and people have a 
life to attend to.
May 17 2021
parent reply sighoya <sighoya gmail.com> writes:
Just a question, is anything about the GC part of the language 
spec of D?
Is it possible to introduce a task local GC to D in another 
compiler without to touch the D language?
May 17 2021
next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Monday, 17 May 2021 at 08:32:16 UTC, sighoya wrote:

 Just a question, is anything about the GC part of the language 
 spec of D?
 Is it possible to introduce a task local GC to D in another 
 compiler without to touch the D language?


I think so. At least if we drop memory safety.
May 17 2021
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Monday, 17 May 2021 at 09:02:52 UTC, Ola Fosheim Grostad wrote:

 On Monday, 17 May 2021 at 08:32:16 UTC, sighoya wrote:

 Just a question, is anything about the GC part of the language 
 spec of D?
 Is it possible to introduce a task local GC to D in another 
 compiler without to touch the D language?


 I think so. At least if we drop memory safety.


Maybe not that even, but the meaning of shared is the issue, I 
think. Shared ought to refer to between tasks and not threads....
May 17 2021
prev sibling next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 17/05/2021 8:32 PM, sighoya wrote:

 Just a question, is anything about the GC part of the language spec of D?
 Is it possible to introduce a task local GC to D in another compiler 
 without to touch the D language?


It has nothing to do with the compiler.

You can implement it fully in your own code base if you want and select 
it at runtime.

https://github.com/dlang/druntime/blob/master/src/core/gc/registry.d
https://github.com/dlang/druntime/blob/master/src/core/gc/config.d#L53
May 17 2021
next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Monday, 17 May 2021 at 10:39:39 UTC, rikki cattermole wrote:

 On 17/05/2021 8:32 PM, sighoya wrote:

 Just a question, is anything about the GC part of the language 
 spec of D?
 Is it possible to introduce a task local GC to D in another 
 compiler without to touch the D language?


 It has nothing to do with the compiler.


The stack meta info, suspension points and some other details are 
compilerdependant.
May 17 2021
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Monday, 17 May 2021 at 11:09:00 UTC, Ola Fosheim Grostad wrote:

 On Monday, 17 May 2021 at 10:39:39 UTC, rikki cattermole wrote:

 On 17/05/2021 8:32 PM, sighoya wrote:

 Just a question, is anything about the GC part of the 
 language spec of D?
 Is it possible to introduce a task local GC to D in another 
 compiler without to touch the D language?


 It has nothing to do with the compiler.


 The stack meta info, suspension points and some other details 
 are compilerdependant.


That is, if one wants to avoid a clunky library version. Trying 
to be generic underutilizes the features of the backend. The goal 
should be best if breed, whch makes it backend specific.
May 17 2021
prev sibling parent reply IGotD- <nise nise.com> writes:
On Monday, 17 May 2021 at 10:39:39 UTC, rikki cattermole wrote:

 It has nothing to do with the compiler.

 You can implement it fully in your own code base if you want 
 and select it at runtime.

 https://github.com/dlang/druntime/blob/master/src/core/gc/registry.d
 https://github.com/dlang/druntime/blob/master/src/core/gc/config.d#L53


There have been a few tracing GC algorithms but still D is forced 
to used traced GC.

Unfortunately D ends up in the pit as usual, it is chess mate. 
Walter do not want to implement reference types/fat pointers 
types which makes RC impossible by standard. Moving 
druntime/phobos away from GC is also a too big of task which 
might also break something.
May 17 2021
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Monday, 17 May 2021 at 16:47:36 UTC, IGotD- wrote:

 On Monday, 17 May 2021 at 10:39:39 UTC, rikki cattermole wrote:

 It has nothing to do with the compiler.

 You can implement it fully in your own code base if you want 
 and select it at runtime.

 https://github.com/dlang/druntime/blob/master/src/core/gc/registry.d
 https://github.com/dlang/druntime/blob/master/src/core/gc/config.d#L53


 There have been a few tracing GC algorithms but still D is 
 forced to used traced GC.


Yes, the GC runtime interface is not good enough, task based 
should be stackless at suspension points, but use system stack 
for suspension-free functions. That way you can have a massive 
amount of suspended tasks. Another feature that is needed is 
merging GC heaps, so that you can join tasks that has been split 
to maximise parallelism. Etc.


 Unfortunately D ends up in the pit as usual, it is chess mate. 
 Walter do not want to implement reference types/fat pointers 
 types which makes RC impossible by standard.


Not impossible, you can do like C++, use smart pointers, but 
unlike C++ inject a new IR before LLVM IR that does ARC. Also, 
let the smart pointers use compiler intrinsics for ARC.
May 17 2021
parent reply IGotD- <nise nise.com> writes:
On Monday, 17 May 2021 at 16:56:37 UTC, Ola Fosheim Grostad wrote:

 Not impossible, you can do like C++, use smart pointers, but 
 unlike C++ inject a new IR before LLVM IR that does ARC. Also, 
 let the smart pointers use compiler intrinsics for ARC.


That's a possibility, however badging the code similar to 
unique_ptr and shared_ptr like in C++ is not something I want to 
do. What if I want to change the GC algorithm suddenly? One 
possibility is just to have a generic name for the GC type, like 
GcRef which is an alias for the actual GC type and then you can 
change it.

Anyone can do this today but still there is the default GC in 
phobos/druntime. Then we have to go through the entire library 
and change to the versatile GC alias.
May 17 2021
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Monday, 17 May 2021 at 19:10:09 UTC, IGotD- wrote:

 That's a possibility, however badging the code similar to 
 unique_ptr and shared_ptr like in C++ is not something I want 
 to do. What if I want to change the GC algorithm suddenly? One 
 possibility is just to have a generic name for the GC type, 
 like GcRef which is an alias for the actual GC type and then 
 you can change it.


Yes, fix type unification first, then do something like that... 
But you need to deal with finalization issues too. Btw, another 
advantage with task bound GC is that it could call all missed 
finalizers at completion, so the impact of not having a fully 
precise GC would be less also in terms of finalization.


 Then we have to go through the entire library and change to the 
 versatile GC alias.


I guess Phobos alone is not a big issue, we could just fork it. 
The real issue is when you want to use third party libraries that 
assume Phobos...
May 17 2021
prev sibling parent Dukc <ajieskola gmail.com> writes:
On Monday, 17 May 2021 at 08:32:16 UTC, sighoya wrote:

 Just a question, is anything about the GC part of the language 
 spec of D?
 Is it possible to introduce a task local GC to D in another 
 compiler without to touch the D language?


The spec assumes GC exists if you use some features - `new`, 
`arr1 ~ arr2` or associative arrays.

However, the GC is implemented in DRuntime. At least in theory, 
you could take another garbage collector and recompile DRuntime 
so it uses the foreign collector instead.

However, if write barriers are needed, you probably need to use 
some sort of bytecode tool to insert them to an already compiled 
object file, and that means `malloc`ed memory access also gets 
write barriers. Regular D code considers manually allocated code, 
static buffers and gc-allocated memory to be all the same type, 
handled with the same functions.
May 18 2021
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Sunday, 16 May 2021 at 16:33:32 UTC, Ola Fosheim Grostad wrote:

 My MAIN POINT was however that D does not have a system level 
 management option if it does not have an option that deemed 
 good enough for DMD. And that would be the default.

 Calling free manually isnt it, because that is manual 
 management that nobody wants to do, and not calling free is 
 even worse.


See? Walter picked the worse option on your scale. So he has 
different priorities for DMD than you think he should, perhaps 
rightfully so.

You're asserting that if you gave Walter a good system level 
management option, he would use it in place of `malloc`/`exit`.

How can you know he would do that, when he already makes the 
"wrong" choice `malloc`/`exit` versus `malloc`/`free`?

In my opinion, DMD allocation strategy shows nothing about D, it 
shows something only about Walter's priorities.
May 18 2021
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 18 May 2021 at 08:37:57 UTC, Dukc wrote:

 In my opinion, DMD allocation strategy shows nothing about D, 
 it shows something only about Walter's priorities.


Maybe so, but even then it does not change the fact that for 
small languages seasoned programmers will look at how the 
language is used in the compiler. The assumption being, it is big 
enough to show if the language scales well and if the language 
designers cannot make good use of the language features then 
nobody can... It is an important showcase. I've done this several 
times.

Second point is that language designers cannot make good language 
design decisions if they dont use the feature set on a larger 
project.

Isn't this obvious!?
May 18 2021
next sibling parent zjh <fqbqrr 163.com> writes:
I totally agree with you.
May 18 2021
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 18 May 2021 at 09:10:49 UTC, Ola Fosheim Grostad 
wrote:

 Maybe so, but even then it does not change the fact that for 
 small languages seasoned programmers will look at how the 
 language is used in the compiler.

 Second point is that language designers cannot make good 
 language design decisions if they dont use the feature set on a 
 larger project.

 Isn't this obvious!?


For the first point, no. Since you investigate the compiler of a 
language you're learning, I presume you're not the only one and 
some indeed do that.

It's not obvious for me that it's the majority of seasoned 
programmers, though. Compilers may be a bit too advanced for 
someone new to the language, one could also opt for investigating 
a simpler project instead, to have a quicker start.

As for the second point, why do you suspect it isn't obvious? 
Phobos and DUB are much more iDiomatic than DMD, so the language 
designers are using the whole feature set of D regardless of DMD 
implementation.
May 18 2021
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 18 May 2021 at 09:43:08 UTC, Dukc wrote:

 As for the second point, why do you suspect it isn't obvious? 
 Phobos and DUB are much more iDiomatic than DMD, so the 
 language designers are using the whole feature set of D 
 regardless of DMD implementation.


Well, what I said is considered a norm in academic circles. So 
the belief that compilers is a show case is not uncommon.

I would never judge a standard library as they tend to be 
affected by issues related to code gen and OS. The standard 
library is kinda part of the compiler backend and runtime. It is 
common for standard libs to be unidiomatic.
May 18 2021
parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 18 May 2021 at 09:47:45 UTC, Ola Fosheim Grostad 
wrote:

 Well, what I said is considered a norm in academic circles. So 
 the belief that compilers is a show case is not uncommon.

 I would never judge a standard library as they tend to be 
 affected by issues related to code gen and OS. The standard 
 library is kinda part of the compiler backend and runtime. It 
 is common for standard libs to be unidiomatic.


So, if I understood right you're criticizing DMD implementation, 
not D memory management options?
May 18 2021
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 18 May 2021 at 10:11:10 UTC, Dukc wrote:

 On Tuesday, 18 May 2021 at 09:47:45 UTC, Ola Fosheim Grostad 
 wrote:

 Well, what I said is considered a norm in academic circles. So 
 the belief that compilers is a show case is not uncommon.

 I would never judge a standard library as they tend to be 
 affected by issues related to code gen and OS. The standard 
 library is kinda part of the compiler backend and runtime. It 
 is common for standard libs to be unidiomatic.


 So, if I understood right you're criticizing DMD 
 implementation, not D memory management options?


There should be other options, but if you have a solution for DMD 
then it would be expexted to be enabled by default. If it isn't, 
how can you expect pergformance conscious system level 
programmers to think there is an good solution available? Show 
not tell...
May 18 2021
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 18 May 2021 at 10:29:24 UTC, Ola Fosheim Grostad 
wrote:

 On Tuesday, 18 May 2021 at 10:11:10 UTC, Dukc wrote:

 On Tuesday, 18 May 2021 at 09:47:45 UTC, Ola Fosheim Grostad 
 wrote:

 Well, what I said is considered a norm in academic circles. 
 So the belief that compilers is a show case is not uncommon.

 I would never judge a standard library as they tend to be 
 affected by issues related to code gen and OS. The standard 
 library is kinda part of the compiler backend and runtime. It 
 is common for standard libs to be unidiomatic.


 So, if I understood right you're criticizing DMD 
 implementation, not D memory management options?


 There should be other options, but if you have a solution for 
 DMD then it would be expexted to be enabled by default. If it 
 isn't, how can you expect pergformance conscious system level 
 programmers to think there is an good solution available? Show 
 not tell...


And to avoid any misunderstanding I think that a GC ought to be 
good enough for a single threaded batch compiler, but you would 
need to measure using stress tests to find when performance 
deteriorates and by how much.
May 18 2021
parent reply russhy <russhy gmail.com> writes:
the people who claim D should double down on the GC NEVER USED 
THE D's GC FOR REAL WORLD SCENARIOS

Even  Ola Fosheim Grostad admits it, he uses GO... who got a 
point now?

The problem of the GC is IT DOESN'T SCALE

What in the world, LET'S ALL DOUBLE DOWN on a GC that DOESN'T 
scale

And people wonder why no adoption, c'mon people, we can do better 
than cli-tools right?



agents, they want D to turn into a shitty managed language that 
can't scale in the day and age of microservices and scalable web 
apps, THE IRONY is strong here

No what can we do about it

Ohh wait wait wait, what D is even all about?

It saddens me that people WHO DON'T USE D FOR THEIR SERVERS, want 
to DOUBLE DOWN ON GC, they don't even use it, they opted for an 
alternative language


Now please compare GO's GC with D's GC, and please do the same 


And also test it with Nim's

Then, and only then you'll start to understand what i mean by the 
GC has no place in D

This comunity is full of people who don't use D and want D to be 
a Java like language

When D is best at playing with C/C++; they want it to play with 
Java instead, the IRONY

Use your strength to make a great language

WHY THE HELL GC when you want double down on C/C++ interop


Fucking hell, no strategy since years ago

This comunity's goal is to give room for a new language to 
emmerge and YET AGAIN EAT ALL OF OUR CAKE

You can't even learn from the GO's success

I'm telling you, the people who wants D to double down on GC are 
the ones responsible of its death

I'll respect this GC lover comunity the day you'll come up with 
this https://malloc.se/blog/zgc-jdk16

Until then you better think twice what you want to achieve with D

Your focus on web servers, D doesn't even have good libraries for 
that

All the good ecosystem is around the system libraries, task based 
GC for that? sure, that is the priority /s ;)


--

TLDR; is D a web server language? answser is no

What are D's strengths? good at being a system language, FOCUS ON 
THAT instead of bloating the language and STD with more cancerous 
bloat driven APIs and memory management schemes


Let allocators rot in std.experiments, that module? what a pity 
and laughable fate
May 18 2021
next sibling parent reply russhy <russhy gmail.com> writes:
D could have been the promised alternative to the shitty C++

But no, the GC lovers killed that opportunity, they wanted to be 
instead Java killer, and go are their dreams, now nobody know 
anymore what the GC lovers want D to be?

They can't even admit they were wrong, 0 balls
May 18 2021
next sibling parent russhy <russhy gmail.com> writes:
*go ate their dreams
May 18 2021
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
you are right.
d's right direction is to be a better C++.
We must get gid of GC,and GC seris language's influence.
Because only a real system level language can be truly 
competitive.
May 18 2021
next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 18 May 2021 at 15:10:58 UTC, zjh wrote:


 We must get gid of GC,and GC seris language's influence.


No

-Alex
May 18 2021
prev sibling next sibling parent reply Zoadian <no no.no> writes:
On Tuesday, 18 May 2021 at 15:10:58 UTC, zjh wrote:

 you are right.
 d's right direction is to be a better C++.
 We must get gid of GC,and GC seris language's influence.
 Because only a real system level language can be truly 
 competitive.


you can do that already, mark you main function  nogc and don't 
link the GC.
you'll lose a few language features, but it's totally useable.
A 'better' GC probably requires write barriers which cost 
performance, so D opts to not use them.

And D's GC is perfectly fine for a lot of programs.

Also the dmd compiler is boost licensed, so you could just fork 
it and create your own language with all the features you need.
May 18 2021
parent reply zjh <fqbqrr 163.com> writes:
You're splitting D.
May 18 2021
next sibling parent reply zjh <fqbqrr 163.com> writes:
D has many shortcomings. D needs to be reborn.
Need to big open and big close, need to reconstruct, need to BIG 
CHANGE.
Don't be afraid. Our current D scale is too small, you can change 
it greatly.
If you are afraid of change, you will lose.
C++20 has been very powerful. D must be greatly changed.
Don't believe those who advocate GC, they are the enemy of D.
When I think about it, I can't imagine that compiling a D library 
will take up a whole memory,and crash.
Only by doing the best can we be competitive.
.
Only by doing real system programming can there be a way out.
A single spark can start a prairie fire. We can completely change 
it, just like PY3 and py2.
.
Don't be afraid. If you are afraid, you will lose.(repete 3 times)
PY3, only 3 has a way out. Otherwise, python will die..
May 18 2021
parent reply Zoadian <no no.no> writes:
On Tuesday, 18 May 2021 at 16:02:10 UTC, zjh wrote:

 D has many shortcomings. D needs to be reborn.
 Need to big open and big close, need to reconstruct, need to 
 BIG CHANGE.
 Don't be afraid. Our current D scale is too small, you can 
 change it greatly.
 If you are afraid of change, you will lose.
 C++20 has been very powerful. D must be greatly changed.
 Don't believe those who advocate GC, they are the enemy of D.
 When I think about it, I can't imagine that compiling a D 
 library will take up a whole memory,and crash.
 Only by doing the best can we be competitive.
 .
 Only by doing real system programming can there be a way out.
 A single spark can start a prairie fire. We can completely 
 change it, just like PY3 and py2.
 .
 Don't be afraid. If you are afraid, you will lose.(repete 3 
 times)
 PY3, only 3 has a way out. Otherwise, python will die..


if you want D to be reborn, again, what is stopping you?
dmd is boost licensed. go ahead.
people who spend their free time developing D and are happy with 
a GC will probably not rip out the GC just because you don't like 
the GC.
May 18 2021
parent reply dogman <dogman somewhere.com> writes:
On Tuesday, 18 May 2021 at 16:20:53 UTC, Zoadian wrote:

 On Tuesday, 18 May 2021 at 16:02:10 UTC, zjh wrote:

 D has many shortcomings. D needs to be reborn.


 people who spend their free time developing D and are happy 
 with a GC will probably not rip out the GC just because you 
 don't like the GC.


Folks lets dont fight over GC vs no-GC. Its a futile fight. We 
need both. Infact GC is the right approach for the majority of 
the cases IMHO. This post was mainly asking the core developers 
about the roadmap.
a. can we make language more secure and memory safe(like rust) 
with and without GC.
b. can D without GC use hashmaps, stdlib and other libraries. 
Libraries can be used with or without GC. Is it technically 
possible.
May 18 2021
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 18 May 2021 at 16:32:01 UTC, dogman wrote:

 a. can we make language more secure and memory safe(like rust) 
 with and without GC.


With, obviously. Without, only if add RC, but RC without ARC is 
not going to be popular.  You cannot have safe borrowing like 
Rust without tedium. Anyway, the real problem is having to do RC 
eveywhere on the heap, because proving anything about pointers on 
the heap is a HARD problem. So unless you want everything to be 
an acyclic tree datastuctures, you will then be forced to use RC 
for backpointers, which is moronic!

So, no, the theoretical knowledge is not where it has to be to 
write efficient safe code. It is not possible, in the general 
case, as of today.



 b. can D without GC use hashmaps, stdlib and other libraries. 
 Libraries can be used with or without GC. Is it technically 
 possible.


The problem is, what about cleanup? D does not have fully precise 
collection.
Destuctors on the GC heap cannot follow pointers to GC objects 
safely...
May 18 2021
prev sibling next sibling parent Zoadian <no no.no> writes:
On Tuesday, 18 May 2021 at 15:32:07 UTC, zjh wrote:

 You're splitting D.


no, no i'm not.
people who want to get rid of the GC are the ones who want to 
split the language (and i'm not against it, but don't force it on 
D).
gc and nogc can happily coexist in the current D language.
May 18 2021
prev sibling next sibling parent nkm1 <t4nk074 openmailbox.org> writes:
On Tuesday, 18 May 2021 at 15:32:07 UTC, zjh wrote:

 You're splitting D.


Actually, it seems like a great idea. I would like it if D was 
split into D proper (with GC) and DasBetterC (with "return scope" 
or whatever it is). I mean split for real, more than currently is 
the case. Then just remove  nogc from D.
May 18 2021
prev sibling parent reply zjh <fqbqrr 163.com> writes:
I have come to the conclusion that the fighting power of language 
is:

adheres to `GC`, I will move `d` to the end and directly choose 
`C++` because`d` retains `disadvantages` and gives up 
`advantages`. Because there are many places where` memory is very 
important `. The less`memory` means the less `cost`. Only in this 
way,` industrial users` will choose you.

At present, `c++`'s comprehensive strength is the strongest .

If we make BIG changes, we can change it to better `c++`.

since `d` has much fewer users, it can be either a `disadvantage 
or an advantage`. Because you can be confident and bold to make 
changes. When you have more users, you are really constrained. 
This is where `C++` can't beat `d`.
May 18 2021
next sibling parent reply zjh <fqbqrr 163.com> writes:
not trust,but Rust.
Translation problems.
May 18 2021
next sibling parent zjh <fqbqrr 163.com> writes:
At least you have to know D's road map, D's development 
expectation and D's self position, so that you can work 
accordingly.
Otherwise, it will be a blind toss.
May 18 2021
prev sibling parent reply zjh <fqbqrr 163.com> writes:
When everyone is pulling D towards`C++/Java/Python/go`, it's 
useless if you want to pull `C++`. Can you wake them up without 
saying it aloud?
D need `a sense of urgency`. Really, when `C++23` is comming, 
`reflection / network` is available. Even you are trying to use 
C++. where is `D's place`?
May 18 2021
next sibling parent reply zjh <fqbqrr 163.com> writes:

one translate,ten errors.too funny.
May 18 2021
parent reply zjh <fqbqrr 163.com> writes:
OK, back to the original question, what is `d`, What do you want 
to be?What is `d'`s road map? How to `complete` it?
Just like the slogan of `C++`:`extreme abstraction/never waste`. 
This is` C++`:`focus on performance, squeeze out performance`.
If you can't win the first place, it's OK. I've always regarded 
`d` as the first class language. But`GC`will drag you back. If 

What I put forward is that `d` focuses on becoming a `better 
c++`. As long as` GC` is removed from the standard library, I 
think it is possible to achieve this goal. A better c++ `is the 
best language`.
  Let's make a list of all the important problems we are facing. 
Similar to dependency analysis, we should first solve the most 
fundamental problems and then solve them one by one.
Our relationship with C++ is both `competition and cooperation`.
`C++` has learned a lot from `py`, and it remains `C++`. `d` 
becoming a better `C++` still has its `style`.
May 19 2021
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 19 May 2021 at 09:09:10 UTC, zjh wrote:

 OK, back to the original question, what is `d`, What do you 
 want to be?What is `d'`s road map? How to `complete` it?
 Just like the slogan of `C++`:`extreme abstraction/never 
 waste`. This is` C++`:`focus on performance, squeeze out 
 performance`.


Yes, this is what makes C++ the best language for low level 
programming at the moment, but if one tries to do high level 
programming in C++ it tends to be verbose or too easy to make 
mistakes in comparison to other languages. But it is usually not 
too difficult to mix C++ with other languages.


 What I put forward is that `d` focuses on becoming a `better 
 c++`. As long as` GC` is removed from the standard library, I 
 think it is possible to achieve this goal. A better c++ `is the 
 best language`.


Yes, that was what D claimed to be around 2006? And that is why I 
picked it up, but the GC killed it for what I wanted to create (+ 
compiler bugs). And that was like... 15 years ago? Since then it 
has aggregated lots of features I don't really wanted, but the GC 
and compiler bugs issue is remaining.

So I am very happy that memory management is on the plan, let's 
keep focus on that one until it is done. Then address the 
compiler bugs and D will finally get close to what it claimed to 
be like 15 years ago...

But C++ was a different language back then. Trying to become what 
C++ is going to be in the future is too much. Way too much to 
achieve. Let's try to achieve the goals D had 15 years ago 
first... Then set new goals... :-D
May 19 2021
next sibling parent norm <norm.rowtree gmail.com> writes:
On Wednesday, 19 May 2021 at 10:57:55 UTC, Ola Fosheim Grøstad 
wrote:

[snip]

 Let's try to achieve the goals D had 15 years ago first... Then 
 set new goals... :-D


+1

I think we're all arguing our agreement :)
May 19 2021
prev sibling parent reply josh <vinsentt gmail.com> writes:
I don't like GC either, but the real issue is the absence of any 
ideology, target market, goals and plans. When you work on any 
project, you should have an idea what are you going to achieve. 
You should set your goals and try to make them come true. These 
are such elementary things that I'm genuinely surprised that the 
management does not understand it. The current situation with D 
looks pretty vague. No goals, no plans, no targeting. We're 
trying to please everyone and we get stuck because we don't like 
to compromise. Earlier, we had a motto "C++ done right" (or 
something like that). Right now we don't even have one. Somebody 
should define current goals and start making unpopular decisions 
or D will stay a broken bicycle forever. Is there any chance that 
D will get a list of goals and clear roadmap? Do the maintainers 
even care about it?
May 19 2021
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 19 May 2021 at 11:58:21 UTC, josh wrote:

 I don't like GC either, but the real issue is the absence of 
 any ideology, target market, goals and plans.


There is an ideology in  safe, but the problem is that pointer 
analysis is a research topic, so pursuing it in  nogc code is not 
realistic... Goals are set too high.

Lower the goal to having a library RC pointer with ARC and 
suddenly you are in a better position than C++ for some use cases.

By pursuing  safe in non-gc code it will either take forever or 
you'll end up with something too annoying to use.
May 20 2021
parent reply IGotD- <nise nise.com> writes:
On Thursday, 20 May 2021 at 08:31:47 UTC, Ola Fosheim Grostad 
wrote:

 Lower the goal to having a library RC pointer with ARC and 
 suddenly you are in a better position than C++ for some use 
 cases.

 By pursuing  safe in non-gc code it will either take forever or 
 you'll end up with something too annoying to use.


Doesn't D already have that?

https://dlang.org/library/std/typecons/ref_counted.html

Also when you mention ARC, is that atomic reference counting or 
automatic reference counting?

Yes,  safe and non-gc/any-gc goals should be separated.
May 20 2021
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 20 May 2021 at 11:10:25 UTC, IGotD- wrote:

 Also when you mention ARC, is that atomic reference counting or 
 automatic reference counting?


I mean removing inc/dec by static analysis. Possibly also turning 
shared_ptr into unique_ptr where possible, which is tricky 
because of sizeof. I guess I dont mean library RC, but something 
close to it. It could look like a template.

Done in a way that could later be extended to the heap, so if you 
can prove that something is used as a stack, you can get rid of 
the refcount...
May 20 2021
next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 20 May 2021 at 12:59:48 UTC, Ola Fosheim Grostad 
wrote:

 On Thursday, 20 May 2021 at 11:10:25 UTC, IGotD- wrote:

 Also when you mention ARC, is that atomic reference counting 
 or automatic reference counting?


 I mean removing inc/dec by static analysis. Possibly also 
 turning shared_ptr into unique_ptr where possible, which is 
 tricky because of sizeof. I guess I dont mean library RC, but


Well, actually, if you accept one indirection then they would 
have the same sizeof, but it would be slow.
May 20 2021
prev sibling next sibling parent reply sighoya <sighoya gmail.com> writes:
On Thursday, 20 May 2021 at 12:59:48 UTC, Ola Fosheim Grostad 
wrote:

 I mean removing inc/dec by static analysis. Possibly also 
 turning shared_ptr into unique_ptr where possible, which is 
 tricky because of sizeof. I guess I dont mean library RC, but 
 something close to it. It could look like a template.


Why not go further and turn GC pointer to RC if acyclicity is 
given, and if possible turn it into an owned pointer?
May 20 2021
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 20 May 2021 at 14:58:36 UTC, sighoya wrote:

 On Thursday, 20 May 2021 at 12:59:48 UTC, Ola Fosheim Grostad 
 wrote:

 I mean removing inc/dec by static analysis. Possibly also 
 turning shared_ptr into unique_ptr where possible, which is 
 tricky because of sizeof. I guess I dont mean library RC, but 
 something close to it. It could look like a template.


 Why not go further and turn GC pointer to RC if acyclicity is 
 given, and if possible turn it into an owned pointer?


There is no GC pointer, only raw pointers?
May 20 2021
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 20 May 2021 at 12:59:48 UTC, Ola Fosheim Grostad 
wrote:

 On Thursday, 20 May 2021 at 11:10:25 UTC, IGotD- wrote:

 Also when you mention ARC, is that atomic reference counting 
 or automatic reference counting?


 I mean removing inc/dec by static analysis. Possibly also 
 turning shared_ptr into unique_ptr where possible, which is 
 tricky because of sizeof. I guess I dont mean library RC, but 
 something close to it. It could look like a template.

 Done in a way that could later be extended to the heap, so if 
 you can prove that something is used as a stack, you can get 
 rid of the refcount...


Contrary to popular belief ARC implementations are quite lousy.

Good in theory, not so much when placed in benchmarks, but I 
guess Apple's marketing helps selling the pivot regarding 
Objective-C GC failure.

https://github.com/ixy-languages/ixy-languages

To the point that in all these years Microsoft never bothered to 
try that in any of their C++ COM/UWP aware implementations.

Also there isn't a single C++ compiler that does such 
optimizations to their smart pointer classes.
May 20 2021
next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 20 May 2021 at 15:28:52 UTC, Paulo Pinto wrote:
  > Contrary to popular belief ARC implementations are quite lousy.

If we can get rid of 40% that is pretty good. It is for ownership 
only, in performance code, raw pointers everywhere else.


 Also there isn't a single C++ compiler that does such 
 optimizations to their smart pointer classes.


Their IRs are low level and cannot do ARC well, LLVM lost too 
much context.

D can assume single threaded counters which makes a big 
difference.
May 20 2021
prev sibling parent reply IGotD- <nise nise.com> writes:
On Thursday, 20 May 2021 at 15:28:52 UTC, Paulo Pinto wrote:

 Contrary to popular belief ARC implementations are quite lousy.

 Good in theory, not so much when placed in benchmarks, but I 
 guess Apple's marketing helps selling the pivot regarding 
 Objective-C GC failure.

 https://github.com/ixy-languages/ixy-languages

 To the point that in all these years Microsoft never bothered 
 to try that in any of their C++ COM/UWP aware implementations.

 Also there isn't a single C++ compiler that does such 
 optimizations to their smart pointer classes.


Compared to what?

So a tracing GC is faster and as RAM increases what happens to 
the time spent scanning? Reference counting has a performance 
impact which is known. The reference counting in Nim has been a 
success a provided in general better performance than the tracing 
ones (something Nim can easily do as you can just swap them out). 
Because of the RC is now the default GC type in Nim. RC has also 
a known performance impact that is spread through out the 
execution. Loops can be optimized so that any inc/dec can be 
avoided.

Rust has interesting take on RC as move is the default. There is 
no inc/dec on a move and neither when borrowing (you borrow the 
inner type). It's kind of a natural optimization because of this. 
Because of this I would rather see a move by default by type in D.
May 20 2021
next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 20 May 2021 at 16:33:09 UTC, IGotD- wrote:

 impact which is known. The reference counting in Nim has been a 
 success a provided in general better performance than the 
 tracing ones (something Nim can easily do as you can just swap 
 them out). Because of the RC is now the default GC type in Nim.


How does Nim deal with references to array elements and struct 
fields? Does it use fat pointers?
May 20 2021
parent IGotD- <nise nise.com> writes:
On Thursday, 20 May 2021 at 17:52:11 UTC, Ola Fosheim Grostad 
wrote:

 How does Nim deal with references to array elements and struct 
 fields? Does it use fat pointers?


Yes, Nim has fat pointers denoted by the "ref" keyword which 
means that it is GC allocated.

https://nim-lang.org/docs/manual.html

*References (similar to pointers in other programming languages) 
are a way to introduce many-to-one relationships. This means 
different references can point to and modify the same location in 
memory (also called aliasing).*

*Nim distinguishes between traced and untraced references. 
Untraced references are also called pointers. Traced references 
point to objects of a garbage-collected heap, untraced references 
point to manually allocated objects or objects somewhere else in 
memory. Thus untraced references are unsafe. However, for certain 
low-level operations (accessing the hardware) untraced references 
are unavoidable.*

*Traced references are declared with the ref keyword, untraced 
references are declared with the ptr keyword. In general, a ptr T 
is implicitly convertible to the pointer type.*
May 20 2021
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 20 May 2021 at 16:33:09 UTC, IGotD- wrote:

 On Thursday, 20 May 2021 at 15:28:52 UTC, Paulo Pinto wrote:

 Contrary to popular belief ARC implementations are quite lousy.

 Good in theory, not so much when placed in benchmarks, but I 
 guess Apple's marketing helps selling the pivot regarding 
 Objective-C GC failure.

 https://github.com/ixy-languages/ixy-languages

 To the point that in all these years Microsoft never bothered 
 to try that in any of their C++ COM/UWP aware implementations.

 Also there isn't a single C++ compiler that does such 
 optimizations to their smart pointer classes.


 Compared to what?

 So a tracing GC is faster and as RAM increases what happens to 
 the time spent scanning? Reference counting has a performance 
 impact which is known. The reference counting in Nim has been a 
 success a provided in general better performance than the 
 tracing ones (something Nim can easily do as you can just swap 
 them out). Because of the RC is now the default GC type in Nim. 
 RC has also a known performance impact that is spread through 
 out the execution. Loops can be optimized so that any inc/dec 
 can be avoided.

 Rust has interesting take on RC as move is the default. There 
 is no inc/dec on a move and neither when borrowing (you borrow 
 the inner type). It's kind of a natural optimization because of 
 this. Because of this I would rather see a move by default by 
 type in D.


Looking forward to the Nim RC beating these benchmarks.

https://devblogs.microsoft.com/aspnet/grpc-performance-improvements-in-net-5/

https://www.techempower.com/benchmarks/

And it isn't as if Nim has a community that much greater than D 
currently has.

Rust doesn't have RC, just library types, Arc/RC everywhere is 
just as slow as shared_ptr everywhere.

In fact, the way that Apple got around improving ARC wasn't 
spending more development resources on their Objective-C/Swift 
compilers, rather develop a complete new CPU.

Now iDevices have turned into Swift/Objective-C machines.

  
https://blog.metaobject.com/2020/11/m1-memory-and-performance.html
May 20 2021
next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 20 May 2021 at 18:18:40 UTC, Paulo Pinto wrote:

 Rust doesn't have RC, just library types, Arc/RC everywhere is 
 just as slow as shared_ptr everywhere.


 system code does not have to be  safe. Next step would be to add 
borrowing selectively. You can also use borrowcounters during 
testing, no need to go for static borrowing, actually.


 In fact, the way that Apple got around improving ARC wasn't 
 spending more development resources on their Objective-C/Swift 
 compilers, rather develop a complete new CPU.


D only needs atomics for shared, not comparable, as an Apple 
engineer kindly has pointed out in this forum some years ago. He 
did no discourage D from pursuing ARC, on the contrary.
May 20 2021
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 20 May 2021 at 18:35:58 UTC, Ola Fosheim Grostad 
wrote:

 On Thursday, 20 May 2021 at 18:18:40 UTC, Paulo Pinto wrote:

 Rust doesn't have RC, just library types, Arc/RC everywhere is 
 just as slow as shared_ptr everywhere.


  system code does not have to be  safe. Next step would be to 
 add borrowing selectively. You can also use borrowcounters 
 during testing, no need to go for static borrowing, actually.


 In fact, the way that Apple got around improving ARC wasn't 
 spending more development resources on their Objective-C/Swift 
 compilers, rather develop a complete new CPU.


 D only needs atomics for shared, not comparable, as an Apple 
 engineer kindly has pointed out in this forum some years ago. 
 He did no discourage D from pursuing ARC, on the contrary.


As you can see Obj-C had some extra challenges because of 
compatibility with manual RC:

http://forum.dlang.org/post/hgmhgirfervrsvcghchw forum.dlang.org
May 20 2021
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 20 May 2021 at 19:11:56 UTC, Ola Fosheim Grostad 
wrote:

 On Thursday, 20 May 2021 at 18:35:58 UTC, Ola Fosheim Grostad 
 wrote:

 On Thursday, 20 May 2021 at 18:18:40 UTC, Paulo Pinto wrote:

 Rust doesn't have RC, just library types, Arc/RC everywhere 
 is just as slow as shared_ptr everywhere.


  system code does not have to be  safe. Next step would be to 
 add borrowing selectively. You can also use borrowcounters 
 during testing, no need to go for static borrowing, actually.


 In fact, the way that Apple got around improving ARC wasn't 
 spending more development resources on their 
 Objective-C/Swift compilers, rather develop a complete new 
 CPU.


 D only needs atomics for shared, not comparable, as an Apple 
 engineer kindly has pointed out in this forum some years ago. 
 He did no discourage D from pursuing ARC, on the contrary.


 As you can see Obj-C had some extra challenges because of 
 compatibility with manual RC:

 http://forum.dlang.org/post/hgmhgirfervrsvcghchw forum.dlang.org


I guess everyone over here will keep talking in circles about 
memory management.

Meanwhile TinyGo, CircuitPyhton, Meadow, Astrobe, MakeCode. 
microEJ just keep increasing their market share, while D keeps 
its soul search for the golden solution to replace GC.
May 21 2021
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Friday, 21 May 2021 at 07:07:19 UTC, Paulo Pinto wrote:

 I guess everyone over here will keep talking in circles about 
 memory management.

 Meanwhile TinyGo, CircuitPyhton, Meadow, Astrobe, MakeCode. 
 microEJ just keep increasing their market share, while D keeps 
 its soul search for the golden solution to replace GC.


What do you propose that D should do?

I am not in a position to do anything more than propose ideas 
that can be developed into something that both satisfies the high 
level D programmers and the low level programmers and try to 
build some common ground. Building common ground takes time and 
repeated communication. You need to consider many proposals and 
evolve them to get to a good solution.

Nim seems to have considered and tested several options before 
landing on ARC, that is the right approach. Don't settle for 
anything before you have explored the options.

In my opinion a task based GC + shared RC should satisfy the 
needs of both groups and most single threaded code would not need 
many changes.
May 21 2021
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 21 May 2021 at 07:29:35 UTC, Ola Fosheim Grostad wrote:

 On Friday, 21 May 2021 at 07:07:19 UTC, Paulo Pinto wrote:

 [...]


 What do you propose that D should do?

 I am not in a position to do anything more than propose ideas 
 that can be developed into something that both satisfies the 
 high level D programmers and the low level programmers and try 
 to build some common ground. Building common ground takes time 
 and repeated communication. You need to consider many proposals 
 and evolve them to get to a good solution.

 Nim seems to have considered and tested several options before 
 landing on ARC, that is the right approach. Don't settle for 
 anything before you have explored the options.

 In my opinion a task based GC + shared RC should satisfy the 
 needs of both groups and most single threaded code would not 
 need many changes.


Do like those projects, the powers at the steering wheel should 
stick with the original design and push it no matter what, 
instead of switching direction every couple of years and never 
finishing it.
May 21 2021
next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Friday, 21 May 2021 at 08:43:44 UTC, Paulo Pinto wrote:

 Do like those projects, the powers at the steering wheel should 
 stick with the original design and push it no matter what, 
 instead of switching direction every couple of years and never 
 finishing it.


There is no future for a glorified scripting language, there are 
too many powerful alternatives for scripting. That is effectively 
proposing long tail decay as a strategy.

D has to support those that use D for scriptlike programming 
today, but there is no future in it, if that is all it aspires to 
do well.
May 21 2021
parent Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 21 May 2021 at 08:51:08 UTC, Ola Fosheim Grostad wrote:

 On Friday, 21 May 2021 at 08:43:44 UTC, Paulo Pinto wrote:

 Do like those projects, the powers at the steering wheel 
 should stick with the original design and push it no matter 
 what, instead of switching direction every couple of years and 
 never finishing it.


 There is no future for a glorified scripting language, there 
 are too many powerful alternatives for scripting. That is 
 effectively proposing long tail decay as a strategy.

 D has to support those that use D for scriptlike programming 
 today, but there is no future in it, if that is all it aspires 
 to do well.


Something like gVisor, runc, Android GPU Inspector or USB Armory 
could have been made better in D, but I digress, apparently it is 
just glorified scripting.
May 21 2021
prev sibling next sibling parent reply IGotD- <nise nise.com> writes:
On Friday, 21 May 2021 at 08:43:44 UTC, Paulo Pinto wrote:

 Do like those projects, the powers at the steering wheel should 
 stick with the original design and push it no matter what, 
 instead of switching direction every couple of years and never 
 finishing it.


The reason we want to move away from tracing GC is because of 
this, to quote Araq in this thread.

https://forum.dlang.org/post/fttikqwuygkdmpbfocdh forum.dlang.org

*But Nim actually bets on RC because it's much more amenable to 
manual optimizations and because it works well with custom memory 
management, making it a good fit for "systems programming".*

If D wants be a viable option in embedded and systems 
programming, it has to move away from the tracing GC it has 
today. This is one of the big reasons D doesn't gain popularity. 
For high level scripting languages, there are plenty of 
alternatives.
May 21 2021
next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Friday, 21 May 2021 at 09:02:32 UTC, IGotD- wrote:

 popularity. For high level scripting languages, there are 
 plenty of alternatives.


Exactly, to do high level well you are also better off using a 
JIT as it opens for new and interesting language smantics (and 
performance).
May 21 2021
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Friday, 21 May 2021 at 09:25:06 UTC, Ola Fosheim Grostad wrote:

 On Friday, 21 May 2021 at 09:02:32 UTC, IGotD- wrote:

 popularity. For high level scripting languages, there are 
 plenty of alternatives.


 Exactly, to do high level well you are also better off using a 
 JIT as it opens for new and interesting language smantics (and 
 performance).


Let us also remind ourself that almost anything that can be done 
in batch in parallell will run faster in the cloud on rented 
compute-nodes. That space is moving to fast for small players...
May 21 2021
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 21 May 2021 at 09:02:32 UTC, IGotD- wrote:

 On Friday, 21 May 2021 at 08:43:44 UTC, Paulo Pinto wrote:

 Do like those projects, the powers at the steering wheel 
 should stick with the original design and push it no matter 
 what, instead of switching direction every couple of years and 
 never finishing it.


 The reason we want to move away from tracing GC is because of 
 this, to quote Araq in this thread.

 https://forum.dlang.org/post/fttikqwuygkdmpbfocdh forum.dlang.org

 *But Nim actually bets on RC because it's much more amenable to 
 manual optimizations and because it works well with custom 
 memory management, making it a good fit for "systems 
 programming".*

 If D wants be a viable option in embedded and systems 
 programming, it has to move away from the tracing GC it has 
 today. This is one of the big reasons D doesn't gain 
 popularity. For high level scripting languages, there are 
 plenty of alternatives.


Why bother with D given the competition?

https://www.f-secure.com/en/consulting/foundry/usb-armory

https://www.astrobe.com/

https://www.ptc.com/en/products/developer-tools/perc

https://www.aicas.com/wp/products-services/jamaicavm/

https://tinygo.org/

http://www.ulisp.com/

https://makecode.microbit.org/

https://www.wildernesslabs.co/

Just reboot memory managment yet again, better make it sooner 
than Go gets its first generics release by the end of the year, 
though.
May 21 2021
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Friday, 21 May 2021 at 10:12:00 UTC, Paulo Pinto wrote:

 Just reboot memory managment yet again, better make it sooner 
 than Go gets its first generics release by the end of the year, 
 though.


D has never changed memory management, only the implementation.

That IS the issue...
May 21 2021
parent reply IGotD- <nise nise.com> writes:
On Friday, 21 May 2021 at 13:00:54 UTC, Ola Fosheim Grostad wrote:

 D has never changed memory management, only the implementation.

 That IS the issue...


The issue is that D doesn't offer a wide variety of memory 
management options. Right now we have discussion about which GC 
is the best and if the GC in D is enough. Basically GC X is 
better than Y, which this is not about. What this is about is 
that D should offer the programmers a choice, a memory management 
that suits them whatever that is.

Right now the GC in D is one size should fit all, which it 
doesn't.
May 21 2021
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Friday, 21 May 2021 at 16:16:06 UTC, IGotD- wrote:

 Basically GC X is better than Y, which this is not about. What 
 this is about is that D should offer the programmers a choice, 
 a memory management that suits them whatever that is.

 Right now the GC in D is one size should fit all, which it 
 doesn't.


Right, but the one size GC will not scale. It has been improved 
over 10 years, but computers also have 8x cores and 64x memory. 
In another 10 years, the highend could have another 8x cores and 
another 64x memory. At some point we have like 64 cores and 1TB 
memory... At some point this type of GC will only work for small 
applications.

But D also needs something that is coherent. Something that can 
migrate between threads (possibly between CPUs in the future).

So regardless of how people feel, the concept of a task/actor is 
becoming more relevant. We see this on many scales, also in cloud 
solutions. Partioning computations and memory, making it less 
dependent on architecture, allows for scaling (and ultimately 
distributed computing).
May 21 2021
parent reply Tejas <notrealemail gmail.com> writes:
 So regardless of how people feel, the concept of a task/actor 
 is becoming more relevant. We see this on many scales, also in 
 cloud solutions. Partioning computations and memory, making it 
 less dependent on architecture, allows for scaling (and 
 ultimately distributed computing).


Have you heard of a language called pony? They seem to be going 
in that direction.

ponylang.io/

The following is a video of a guy whose company made a 
nanosecond-level response time data stream processor with it. It 
has a task based GC, like you want.Don't know about 
metaprogramming though.

https://youtu.be/GigBhej1gfI
May 21 2021
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Friday, 21 May 2021 at 17:44:51 UTC, Tejas wrote:

 Have you heard of a language called pony? They seem to be going 
 in that direction.

 ponylang.io/

 The following is a video of a guy whose company made a 
 nanosecond-level response time data stream processor with it. 
 It has a task based GC, like you want.Don't know about 
 metaprogramming though.


Yes, it is interesting, especially the type system, but it is a 
high level language, not a systems level language.

I believe C++ is getting tasks, their coroutines are also (at 
least MS implementation) switchable in nanoseconds so that you 
can switch to another task/coroutine while waiting for memory to 
be transferred to the cache. At least that it was is being 
claimed.
May 21 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 21 May 2021 at 17:58:59 UTC, Ola Fosheim Grostad wrote:

 I believe C++ is getting tasks, their coroutines are also (at 
 least MS implementation) switchable in nanoseconds so that you 
 can switch to another task/coroutine while waiting for memory 
 to be transferred to the cache. At least that it was is being 
 claimed.


It turns out that Swift is going heavy in the direction of actors 
too.

I read some of the future direction documenation for Swift and it 
was pointed out that copying values is what keeps the performance 
down, so they are working on that, but also on concurrency.

They are switching from thread-local to task-local:

https://github.com/apple/swift-evolution/blob/main/proposals/0311-task-locals.md

Tasks and executors:

https://github.com/apple/swift-evolution/blob/main/proposals/0304-structured-concurrency.md

C++ also have things in the pipeline on 
concurrency/tasks/executors...

Seems like Swift and C++ are heading in the same direction then. 
Maybe D's main competitor will be Swift, in addition to Nim et al.
May 22 2021
next sibling parent reply Tejas <notrealemail gmail.com> writes:
On Saturday, 22 May 2021 at 11:27:10 UTC, Ola Fosheim Grøstad 
wrote:

 On Friday, 21 May 2021 at 17:58:59 UTC, Ola Fosheim Grostad 
 wrote:

 I believe C++ is getting tasks, their coroutines are also (at 
 least MS implementation) switchable in nanoseconds so that you 
 can switch to another task/coroutine while waiting for memory 
 to be transferred to the cache. At least that it was is being 
 claimed.


 It turns out that Swift is going heavy in the direction of 
 actors too.

 I read some of the future direction documenation for Swift and 
 it was pointed out that copying values is what keeps the 
 performance down, so they are working on that, but also on 
 concurrency.

 They are switching from thread-local to task-local:

 https://github.com/apple/swift-evolution/blob/main/proposals/0311-task-locals.md

 Tasks and executors:

 https://github.com/apple/swift-evolution/blob/main/proposals/0304-structured-concurrency.md

 C++ also have things in the pipeline on 
 concurrency/tasks/executors...

 Seems like Swift and C++ are heading in the same direction 
 then. Maybe D's main competitor will be Swift, in addition to 
 Nim et al.


*sigh*

How ironic that the larger organizations are more nimble about 
these things than we, a vastly smaller community, are(or maybe 
that's why?)

I can't help but feel it might be best if I just left for C++20. 
Experimental stuff for C++23 is available anyways, can't be any 
worse than the bugs in the D compilers. If I want the flexibility 
of Python, I can learn how to embed `boost.python` properly.

And (if) when D's ambitions of Dpp and ImportC materialize, I 
will just automatically generate headers/modules for D. That's 
the intention, right?

... I think I've lurked in too many negative posts about D. Might 
be good to stay away from the general posts for a while. See you 
guys next month or later.
May 22 2021
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 22 May 2021 at 12:47:17 UTC, Tejas wrote:

 How ironic that the larger organizations are more nimble about 
 these things than we, a vastly smaller community, are(or maybe 
 that's why?)


C++ has had concurrency workgroups for a long time? And key Swift 
people have been involved with clang/LLVM? So it is not like this 
is happening fast, but they have prepared for it for a longer 
time perhaps?


 I can't help but feel it might be best if I just left for C++20.


I think only MS has C++20 implemented, clang has bits and pieces 
of it. I guess it will take one year for clang to have the full 
C++20 production ready.

But things are happening in the concurrency domain, for sure.
May 22 2021
prev sibling parent reply sighoya <sighoya gmail.com> writes:
On Saturday, 22 May 2021 at 12:47:17 UTC, Tejas wrote:

 I can't help but feel it might be best if I just left for 
 C++20. Experimental stuff for C++23 is available anyways, can't 
 be any worse than the bugs in the D compilers. If I want the 
 flexibility of Python, I can learn how to embed `boost.python` 
 properly.


Can't speak for you, but this is a no-option for me. C++ has a 
massive complexity bolted on it, you have an abundance of ugly 
code which won't be upgraded and will even grow as of today.
Still improved support for templates in C++ aren't enough to 
replace C macros, so you have to deal with them anyway.
The syntax still feels hard to read these days, I don't know.
And then developing without a GC and dealing with many memory 
containers which aren't that safely convertible to each other, 
no, thanks.
May 22 2021
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 22 May 2021 at 13:36:11 UTC, sighoya wrote:

 On Saturday, 22 May 2021 at 12:47:17 UTC, Tejas wrote:

 [...]


 Can't speak for you, but this is a no-option for me. C++ has a 
 massive complexity bolted on it, you have an abundance of ugly 
 code which won't be upgraded and will even grow as of today.
 Still improved support for templates in C++ aren't enough to 
 replace C macros, so you have to deal with them anyway.
 The syntax still feels hard to read these days, I don't know.
 And then developing without a GC and dealing with many memory 
 containers which aren't that safely convertible to each other, 
 no, thanks.


+1

I think D will succeed if we just manage to focus
May 22 2021
prev sibling next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Saturday, 22 May 2021 at 13:36:11 UTC, sighoya wrote:

 Can't speak for you, but this is a no-option for me. C++ has a 
 massive complexity bolted on it, you have an abundance of ugly 
 code which won't be upgraded and will even grow as of today.


I guess you are talking about libraries, sure most of the larger 
frameworks were designed many years ago and have outdated APIs. 
Also, many C++ programmers are set in their ways and continue to 
write code in their own set ways. More social than language...

D is becoming quite complex too though, it could be made simpler. 
D allows more compact syntax, but not sure what the effect of 
that is when you get large code bases.


 Still improved support for templates in C++ aren't enough to 
 replace C macros, so you have to deal with them anyway.
 The syntax still feels hard to read these days, I don't know.


As was pointed out, STL can be verbose, but the last versions 
have improved on that by language and library changes, so I am 
starting to find it bearable.

I don't use macros in C++... Not sure what you meant there?


 And then developing without a GC and dealing with many memory 
 containers which aren't that safely convertible to each other, 
 no, thanks.


Not sure what you mean by memory containers?

What makes C++ challenging is that libraries tend to focus on 
performance and detailed control, so that can often make them 
harder to set up and use than in other languages where speed is 
less in focus.
May 22 2021
prev sibling parent reply IGotD- <nise nise.com> writes:
On Saturday, 22 May 2021 at 13:36:11 UTC, sighoya wrote:

 And then developing without a GC and dealing with many memory 
 containers which aren't that safely convertible to each other, 
 no, thanks.


This is point I have also thought about. If you only have one 
pointer type GC or not, then the algorithms of the data 
structures will work with any type of memory. Also there is no 
need for code duplication to work with different types of memory 
management containers.

Is is enough not to justify fat pointers? I personally don't 
think so. The generic programming of D is so good that you can 
create algorithms that will work with any MM container that you 
throw at it (with code duplication of course).

Not dealing with several MM containers like C++ (unique_ptr, 
shared_ptr, atomic_shared_ptr) and Rust is kinda nice, but only 
one like Nim with the "ref" keyword is acceptable I think.
May 22 2021
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Saturday, 22 May 2021 at 16:12:12 UTC, IGotD- wrote:

 Not dealing with several MM containers like C++ (unique_ptr, 
 shared_ptr, atomic_shared_ptr)


Ok, so mean smart pointers. Never had a single issue with this. 
They are owning pointers, usually encapsulated as private class 
members. You typically don't pass them around much, and they are 
usually unique_ptrs unless the design is a mess. What you pass 
around are mostly views or borrowed pointers?
May 22 2021
parent reply sighoya <sighoya gmail.com> writes:
On Saturday, 22 May 2021 at 16:21:06 UTC, Ola Fosheim Grostad 
wrote:

 Ok, so mean smart pointers. Never had a single issue with this.


It's not just that, every large framework tends to have their own 
pointers with their own memory reclaim rules, like QPointers in 
Qt, mixing them, and you slip into an unpredictable state.
May 22 2021
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Saturday, 22 May 2021 at 16:53:49 UTC, sighoya wrote:

 On Saturday, 22 May 2021 at 16:21:06 UTC, Ola Fosheim Grostad 
 wrote:

 Ok, so mean smart pointers. Never had a single issue with this.


 It's not just that, every large framework tends to have their 
 own pointers with their own memory reclaim rules, like 
 QPointers in Qt, mixing them, and you slip into an 
 unpredictable state.


Yes, and their own strings etc, but they are usually out if date 
in their API design or just making up their own style... C++ is 
just not a good eco system for high level programming. For that 
purpose D with GC is obviously more accessible. C++ is good for 
low level programming, but one needs a well thought out model 
before coding. It is not a good language for prototyping and 
playing with ideas.
May 22 2021
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 22 May 2021 at 11:27:10 UTC, Ola Fosheim Grøstad 
wrote:

 Seems like Swift and C++ are heading in the same direction 
 then. Maybe D's main competitor will be Swift, in addition to 
 Nim et al.


I came over this endless document outlining future Swift C++ 
interop today:

https://github.com/apple/swift/blob/main/docs/CppInteroperabilityManifesto.md

They have some limited capabilities already (although 
Objective-C++ is probably still better). Seems like Apple are 
putting a massive effort into C++ interop for Swift now, didn't 
really expect that.
May 23 2021
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Friday, 21 May 2021 at 08:43:44 UTC, Paulo Pinto wrote:

 Do like those projects, the powers at the steering wheel should 
 stick with the original design and push it no matter what, 
 instead of switching direction every couple of years and never 
 finishing it.


I'm glad D did not follow that literally. Remember, templates are 
the result of breaking that rule and changing direction early in 
D history.

But of course you're right that a prior direction should always 
have favour over new directions.
May 21 2021
parent reply JN <666total wp.pl> writes:
On Friday, 21 May 2021 at 09:57:32 UTC, Dukc wrote:

 I'm glad D did not follow that literally. Remember, templates 
 are the result of breaking that rule and changing direction 
 early in D history.


It's interesting to see how D would turn out without templates 
however. Template metaprogramming comes with a cost, such as 
forever dooming yourself to subpar IDE experience.
May 21 2021
parent sighoya <sighoya gmail.com> writes:
On Friday, 21 May 2021 at 10:53:28 UTC, JN wrote:

 It's interesting to see how D would turn out without templates 
 however. Template metaprogramming comes with a cost, such as 
 forever dooming yourself to subpar IDE experience.


I think templates aren't the problem, rather the corner cases 
introduced in their implementation, making it hard to implement 
correct reasoning in IDEs.
May 21 2021
prev sibling parent reply Araq <rumpf_a web.de> writes:
On Thursday, 20 May 2021 at 18:18:40 UTC, Paulo Pinto wrote:

 Looking forward to the Nim RC beating these benchmarks.


Benchmarks can usually be tweaked to produce the outcome you're 
after. I usually get better latency and memory consumption and 
worse throughput with "Nim RC". However, the Nim compiler itself 
is over 100K lines of code and 22% faster when compiled with "Nim 
RC", so in this case the throughput is better. That particular 
result might be machine specific though as I tested it on an M1 
indeed. :-)

The fact that the RC algorithm is oblivious to the involved heap 
sizes and to the amount of alive data makes it a nice default 
though -- works well when you use much memory or when you have 
little heap sizes.

But Nim actually bets on RC because it's much more amenable to 
manual optimizations and because it works well with custom memory 
management, making it a good fit for "systems programming".
May 20 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 20 May 2021 at 21:09:22 UTC, Araq wrote:

 But Nim actually bets on RC because it's much more amenable to 
 manual optimizations and because it works well with custom 
 memory management, making it a good fit for "systems 
 programming".


How much better do you feel Nim could get at getting rid of 
inc/dec pairs compared to where you are now?
May 20 2021
parent Araq <rumpf_a web.de> writes:
On Thursday, 20 May 2021 at 22:52:35 UTC, Ola Fosheim Grøstad 
wrote:


 How much better do you feel Nim could get at getting rid of 
 inc/dec pairs compared to where you are now?


Not much -- we implemented all worthwhile optimizations. And 
given the right annotations (sink, lent, move) there are no 
superfluous inc/dec pairs left.

We're at the point where tweaking the inliner further makes more 
sense then focussing on inc/dec pairs.
May 20 2021
prev sibling parent reply zjh <fqbqrr 163.com> writes:
Perhaps, we should also be considerate of author D. perhaps, what 
we discussed, `D author`, has been discussed for a long time. We 
can't check all quotations of `D author`. Maybe he just doesn't 
want to spend time explaining.
I used to remember that `D author` told us just to do what we 
were interested in. Maybe,`let's just do it`.
Those who tells us to do `DC++` alone just want us to leave. They 

just improve it on `d`.
`D author` has been focusing on action rather than management. 
OK, let's do it ourselves.
`We can start with the details of where we feel uncomfortable`.
If we don't act, and wait for `d author` to lead us or give us 
directions. Maybe it will be `a long time`.
However, we still need to use `d`. Let's start with `small 
details` one by one. Don't wait for them. Let's just do it 
ourselves.
May 19 2021
next sibling parent reply nkm1 <t4nk074 openmailbox.org> writes:
On Wednesday, 19 May 2021 at 12:30:18 UTC, zjh wrote:


 Those who tells us to do `DC++` alone just want us to leave. 



It was already that! It changed horses in midstream, trying to 
become DC++.


 `We can start with the details of where we feel uncomfortable`.


There are various problems with DMD and other software, those are 
all solvable or tolerable.
The big technical problem is that the D programming language 
tries to offer good support
for different kinds of memory management. This is a hell of a 
task, especially in a situation of limited resourses (manpower 
etc).
As far as I can tell, the plan (implicitly) is (was?) this: 
implement some kind of limited-borrow-checker-kind-of-thing 
(dip1000), implement refcounting of pointers and use dip1000 to 
optimize the refcounting. And then presumably abandon the GC.
For now it doesn't seem to work, probably because it's very 
difficult to do all that. Meanwhile, GC does work, even though 
it's not a great one.


 If we don't act, and wait for `d author` to lead us or give us 
 directions. Maybe it will be `a long time`.
 However, we still need to use `d`. Let's start with `small 
 details` one by one.


What's the point of talking about small details when there is an 
elephant in the room.
May 19 2021
parent reply zjh <fqbqrr 163.com> writes:
Well, I don't know what to do.
No small change, no big change.
Let's stand still.
May 19 2021
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 19 May 2021 at 13:25:20 UTC, zjh wrote:

 Well, I don't know what to do.
 No small change, no big change.
 Let's stand still.


If this was my process then I would have created an opn working 
group forum for memory management, defined what is off limits 
(core requirements) and let people discuss. They apparently are 
going for a closed group. The problem with this is that you can 
get en echo chamber where the wrong solution is picked... Meaning 
if you select people that already agree with you, you might end 
up with more of the wrong questions and then you also get the 
wrong answers...

But, we'll see.

I cannot tell you what to do, but I am starting to look at 
combining Swift and C++.
May 19 2021
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 19 May 2021 at 12:30:18 UTC, zjh wrote:

 We'll just improve it on `d`.
 `D author` has been focusing on action rather than management. 
 OK, let's do it ourselves.
 `We can start with the details of where we feel uncomfortable`.
 If we don't act, and wait for `d author` to lead us or give us 
 directions. Maybe it will be `a long time`.


Yes, that is also what I fear when I see new big features being 
added.


 However, we still need to use `d`. Let's start with `small 
 details` one by one. Don't wait for them. Let's just do it 
 ourselves.


I think I can fix most of the small details that bugs me the 
most, myself, but not the larger issues such as memory 
management. At some point it becomes easier to switch focus to 
something like Feeble's CX language or design your own from 
scratch. So, if CX is being developed into something interesting 
and D does not get proper memory management, that is a more 
likely option I think.

Anyway, as I pointed out, forking DMD is not so difficult, but 
the main issue with it is that the DMD source code should be 
split into smaller files. Then one can "overwrite" files that has 
not changed when DMD is updated with new versions, and manually 
modify (or patch up) the DMD files that has changed. Maybe it is 
easy to do this with the large source files DMD has for someone 
that does this all the time, but I have no intent of being an 
expert on merging... (rebasing). So at it stands, DMD needs 
restructuring before I want to do big changes to it.
May 19 2021
parent zjh <fqbqrr 163.com> writes:
my c++ source file is also small.
I like small files too.
indeed,I feel `D author` is using `d` like `C`,and not much like 
`C++'s` OOP.
May 19 2021
prev sibling next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 19 May 2021 at 03:36:10 UTC, zjh wrote:

 D need `a sense of urgency`. Really, when `C++23` is comming, 
 `reflection / network` is available. Even you are trying to use 
 C++. where is `D's place`?


Yes, it is true that the C++ people have become effective at 
pushing ideas and turning them into designs. With Microsoft, 
Google and Apple behind them now they also have a variety if 
theoretical and technical expertise that others don't. So it is 
better for  D to find its own identity, but it should follow a 
plan, absolutely.

C++ is out if reach, let's move on?
May 19 2021
prev sibling parent reply norm <norm.rowtree gmail.com> writes:
On Wednesday, 19 May 2021 at 03:36:10 UTC, zjh wrote:

 When everyone is pulling D towards`C++/Java/Python/go`, it's 
 useless if you want to pull `C++`. Can you wake them up without 
 saying it aloud?
 D need `a sense of urgency`. Really, when `C++23` is comming, 
 `reflection / network` is available. Even you are trying to use 
 C++. where is `D's place`?


Why does D need a sense of urgency? D and its community need to 
learn how to be comfortable being D and not get distracted 
chasing perfection in an attempt to be the next Big Thing.

I choose to use C++20 at the moment because it is fun again and I 
like where it is heading. At some point I may switch back to D 
but it depends on where D ends up. I'm not interested in another 
Rust or C++, they already exist but D once felt like it was a 
Python/C++ lovechild and that was an interesting and fun language 
to use for a while. Really low friction, simple to get into quick 
to code in and powerful features. But like I said it stalled in 
its development of new features in that direction chasing 
perfection.

On a completely unrelated note I will say D newsgroups are an 
amazing resource. I have learned an enormous amount just lurking 
on discussions between the core devs and looking over their 
shoulders at the PRs which result from those discussions.
May 19 2021
parent reply IGotD- <nise nise.com> writes:
On Wednesday, 19 May 2021 at 08:21:38 UTC, norm wrote:

 Why does D need a sense of urgency? D and its community need to 
 learn how to be comfortable being D and not get distracted 
 chasing perfection in an attempt to be the next Big Thing.


I kind of agree with that D chases what is fads in computer 
languages too much. However, the issue with memory management is 
urgent and this is what blocks D for becoming popular where C++ 
dominates and that is performance applications.

I blame the maintainers who are behaving like ostriches with the 
head in the sand. They don't even discuss the issue and if there 
is no official direction/plan, then the community will not do 
anything.
May 19 2021
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 19 May 2021 at 09:26:59 UTC, IGotD- wrote:

 On Wednesday, 19 May 2021 at 08:21:38 UTC, norm wrote:

 Why does D need a sense of urgency? D and its community need 
 to learn how to be comfortable being D and not get distracted 
 chasing perfection in an attempt to be the next Big Thing.


 I kind of agree with that D chases what is fads in computer 
 languages too much. However, the issue with memory management 
 is urgent and this is what blocks D for becoming popular where 
 C++ dominates and that is performance applications.

 I blame the maintainers who are behaving like ostriches with 
 the head in the sand. They don't even discuss the issue and if 
 there is no official direction/plan, then the community will 
 not do anything.


Hmm, do we really lack memory management techniques?

I'm guessing you mean *in* the language?

https://wiki.dlang.org/Memory_Management
https://github.com/atilaneves/automem
...
May 19 2021
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 19 May 2021 at 09:55:43 UTC, Imperatorn wrote:

 On Wednesday, 19 May 2021 at 09:26:59 UTC, IGotD- wrote:

 On Wednesday, 19 May 2021 at 08:21:38 UTC, norm wrote:

[...]


 I kind of agree with that D chases what is fads in computer 
 languages too much. However, the issue with memory management 
 is urgent and this is what blocks D for becoming popular where 
 C++ dominates and that is performance applications.

 I blame the maintainers who are behaving like ostriches with 
 the head in the sand. They don't even discuss the issue and if 
 there is no official direction/plan, then the community will 
 not do anything.


 Hmm, do we really lack memory management techniques?

 I'm guessing you mean *in* the language?

 https://wiki.dlang.org/Memory_Management
 https://github.com/atilaneves/automem
 ...


https://forum.dlang.org/post/pagbapldtkrnlegpwybm forum.dlang.org
https://www.youtube.com/watch?v=_PB6Hdi4R7M
May 19 2021
prev sibling parent IGotD- <nise nise.com> writes:
On Wednesday, 19 May 2021 at 09:55:43 UTC, Imperatorn wrote:

 Hmm, do we really lack memory management techniques?

 I'm guessing you mean *in* the language?

 https://wiki.dlang.org/Memory_Management
 https://github.com/atilaneves/automem
 ...


Yes, that is what I meant. To quote the text in one of the links 
you provided.

*D has built-in types that may be difficult to use without the 
GC: exceptions, strings, dynamic arrays, associative arrays, and 
delegate closures.*

It's exactly these primitives that make D a nice language. They 
should be rewritten so that they don't rely on GC or can be 
retargetted to any GC.

Also, that I want the GC type should be opaque like in Nim would 
be nice.
May 19 2021
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 19 May 2021 at 00:21:11 UTC, zjh wrote:

 I will move `d` to the end and directly choose `C++`


Good bye. Best of luck to you on your project.
May 18 2021
prev sibling parent reply norm <norm.rowtree gmail.com> writes:
On Wednesday, 19 May 2021 at 00:21:11 UTC, zjh wrote:

 I have come to the conclusion that the fighting power of 
 language is:

 adheres to `GC`, I will move `d` to the end and directly choose 
 `C++` because`d` retains `disadvantages` and gives up 
 `advantages`. Because there are many places where` memory is 
 very important `. The less`memory` means the less `cost`. Only 
 in this way,` industrial users` will choose you.

 At present, `c++`'s comprehensive strength is the strongest .

 If we make BIG changes, we can change it to better `c++`.

 since `d` has much fewer users, it can be either a 
 `disadvantage or an advantage`. Because you can be confident 
 and bold to make changes. When you have more users, you are 
 really constrained. This is where `C++` can't beat `d`.


This thread is D and has been for the last 10+yrs.

Changing requires effort but unfortunately the louder someone 
bitches and moans on the forum the less effort they seem to be 
willing to put in to fixing the issues they have. You can 
contribute your ideas with PRs and DIPs today, or you can fork 
the compiler and create PDAY, Perfect D According to You.

But both require effort other than the hot air been blown all 
over the newsgroup.

The other alternative is, as you say, go to C++. This is what I 
did a while back and now I use C++20 for most projects. For me 
personally D kinda stalled in terms of what I was looking for and 
started chasing the tail of Rust. So I may as well use C++20 and 
beyond, which has or will have most of the features that 
originally drew me to D.


Go killer language. All that is just a distraction.
May 18 2021
next sibling parent norm <norm.rowtree gmail.com> writes:
On Wednesday, 19 May 2021 at 03:11:15 UTC, norm wrote:

 On Wednesday, 19 May 2021 at 00:21:11 UTC, zjh wrote:

 I have come to the conclusion that the fighting power of 
 language is:

 adheres to `GC`, I will move `d` to the end and directly 
 choose `C++` because`d` retains `disadvantages` and gives up 
 `advantages`. Because there are many places where` memory is 
 very important `. The less`memory` means the less `cost`. Only 
 in this way,` industrial users` will choose you.

 At present, `c++`'s comprehensive strength is the strongest .

 If we make BIG changes, we can change it to better `c++`.

 since `d` has much fewer users, it can be either a 
 `disadvantage or an advantage`. Because you can be confident 
 and bold to make changes. When you have more users, you are 
 really constrained. This is where `C++` can't beat `d`.


 This thread is D and has been for the last 10+yrs.

 Changing requires effort but unfortunately the louder someone 
 bitches and moans on the forum the less effort they seem to be 
 willing to put in to fixing the issues they have. You can 
 contribute your ideas with PRs and DIPs today, or you can fork 
 the compiler and create PDAY, Perfect D According to You.

 But both require effort other than the hot air been blown all 
 over the newsgroup.

 The other alternative is, as you say, go to C++. This is what I 
 did a while back and now I use C++20 for most projects. For me 
 personally D kinda stalled in terms of what I was looking for 
 and started chasing the tail of Rust. So I may as well use 
 C++20 and beyond, which has or will have most of the features 
 that originally drew me to D.


 Rust, Go killer language. All that is just a distraction.


On Wednesday, 19 May 2021 at 03:11:15 UTC, norm wrote:

But back to the OP, it would be interesting to see quarterly 
roadmaps published for D on the wiki. It doesn't matter if most 
items are dropped or never implemented, what it provides for the 
community is a snapshot of what the core team are working on and 
their near term plans at the time of writing. If it changes by 
next quarter, who cares it is still of interest.
May 18 2021
prev sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 19 May 2021 at 03:11:15 UTC, norm wrote:

 Changing requires effort but unfortunately the louder someone 
 bitches and moans on the forum the less effort they seem to be 
 willing to put in to fixing the issues they have. You can 
 contribute your ideas with PRs and DIPs today, or you can fork 
 the compiler and create PDAY, Perfect D According to You.


No, it is important to build common ground and make people 
understand key issues that the language has and make sure these 
ideas are understood and internalized. It is also important to 
get a wide variety of options on the table. D has been chasing 
the tail of other languages too much, it needs its own ideas. 
DIPs have limited value, because of veto power, you need 
preapproval + common ground. How do you make common ground 
without using the forums? You can use chat I guess, but that is 
very time consuming.

I am happy to see that some of the key issues I have had with the 
language is on the table now. I will probably write a DIP about 
type unification if nobody else beats me to it, but it should 
wait till after the most important weakness, memory management, 
is dealt with. So that DIP can wait... No point in shifting focus 
now, as memory management is difficult to get right in a 
competetive manner. Atila confirming that MM is on the plan was 
good to hear.

Yeah, I fork, but the compiler needs restructuring after 20 
years, like most software. It is currently "resistant to change" 
. Changing is still possible, but how do I rebase? The current 
structure limits how much you ought to change, so I only change 
stable parts... So my fork is in limbo until I am bored enough to 
find rebasing entertaining, probably october...

I mean I could restructure DMD myself, but how would I then get 
the DMD changes in?
May 19 2021
prev sibling parent reply zjh <fqbqrr 163.com> writes:
What are the advantages of D
It's metaprogramming


If we want to survive, we must compete with C++ and cooperate 
with C++.
Our advantage is metaprogramming.
Our disadvantage is GC.
There are a lot of talents in C/C++,you don't want to attract 
them?
you want to attract little white like python?
NO!this is a DEAD way.
With master, there is library. With library, there is ecology. 
With ecology, there is d's future.
May 18 2021
next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 18 May 2021 at 15:26:08 UTC, zjh wrote:

 What are the advantages of D
 It's metaprogramming



I think C++20 surpasses D in terms of metaprogramming and 
modelling. Concepts and stackless coroutines does make a 
difference.

But C++ takes years to master... So there is a high investment of 
time needed.


 Our disadvantage is GC.


One disadvantage is that the D's GC design is a sledgehammer from 
a time when CPUs had 1 core and kilobytes of memory.

The real disadvantage is that it is taking so much time to get an 
alternative memory managment strategy. That is primarily because 
too much effort is spent arguing about  safe.

It would have been better to just require  safe to use GC and let 
 nogc be  system, because  safe is clearly out of reach on a 
theoretical level if you don't want a tedious attribute infested 
coding experience... At least in this decade.
May 18 2021
parent zjh <fqbqrr 163.com> writes:
Yes, I'm also saying,
If you can insert memory management as a template parameter, 
that's good.
Just like `C++`,`c++'s`later memory management improvements 
benefited from it.
May 18 2021
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 18 May 2021 at 15:26:08 UTC, zjh wrote:

 What are the advantages of D
 It's metaprogramming


 all.
 If we want to survive, we must compete with C++ and cooperate 
 with C++.
 Our advantage is metaprogramming.
 Our disadvantage is GC.
 There are a lot of talents in C/C++,you don't want to attract 
 them?
 you want to attract little white like python?
 NO!this is a DEAD way.
 With master, there is library. With library, there is ecology. 
 With ecology, there is d's future.


Here, TinyGO for the Switch.

https://tinygo.org/docs/reference/microcontrollers/nintendoswitch/

Or statically compiled subsets from Typescript and Python for 
gaming handhelds.

https://arcade.makecode.com/#

Guess which language kids will prefer, regardless of your opinion 
on GC?

Your special flavoured no GC D or one of those with GC and shinny 
hardware?

Those kids are going to be the programmers from tomorrow.
May 18 2021
prev sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 18 May 2021 at 14:47:16 UTC, russhy wrote:

 D could have been the promised alternative to the shitty C++

 But no, the GC lovers killed that opportunity, they wanted to 
 be instead Java killer, and go are their dreams, now nobody 
 know anymore what the GC lovers want D to be?

 They can't even admit they were wrong, 0 balls


What is killing D is lack of management.


workloads, including game engines, AR/VR, unikernels, 
hypervisors, GPGPU debuggers and embedded development.

In case of a complaint regarding Swift, RC is GC as per CS 
definition.

https://gchandbook.org/
May 18 2021
prev sibling next sibling parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 18 May 2021 at 14:41:55 UTC, russhy wrote:

 the people who claim D should double down on the GC NEVER USED 
 THE D's GC FOR REAL WORLD SCENARIOS

 Even  Ola Fosheim Grostad admits it, he uses GO... who got a 
 point now?


:-D You are funny, but It is really the only attractive option on 
Google App Engine when Python isn't appropriate. I am not likely 
to use Go for hobby-projects... It is not a fun language, but it 
gets the job done.

D is however completely different from Go an Python...

I think D should be compared to something like Swift + C++.
May 18 2021
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 18 May 2021 at 14:41:55 UTC, russhy wrote:

 the people who claim D should double down on the GC NEVER USED 
 THE D's GC FOR REAL WORLD SCENARIOS


speak for yourself buddy

service guarantees citizenship
May 18 2021
prev sibling parent reply Berni44 <someone somemail.com> writes:
On Sunday, 16 May 2021 at 03:58:15 UTC, Mike Parker wrote:

 dmd doesn't release memory, either.


That's the missing puzzle piece. Since about two months I wonder 
why running the unittests on phobos with 3 cores on my computer 
practically uses 4 cores. I meanwhile found out, that the 4th 
core is the swap demon and that it happens when the regex modules 
(containing a lot of memory consuming unittests) are compiled...
May 16 2021
parent Max Haughton <maxhaton gmail.com> writes:
On Sunday, 16 May 2021 at 13:01:58 UTC, Berni44 wrote:

 On Sunday, 16 May 2021 at 03:58:15 UTC, Mike Parker wrote:

 dmd doesn't release memory, either.


 That's the missing puzzle piece. Since about two months I 
 wonder why running the unittests on phobos with 3 cores on my 
 computer practically uses 4 cores. I meanwhile found out, that 
 the 4th core is the swap demon and that it happens when the 
 regex modules (containing a lot of memory consuming unittests) 
 are compiled...


Oh yes. If you look at ASan's output (compile with ldc or gdc) on 
a typical dmd test suite run you're looking at hundreds of 
thousands of lines worth of memory leaks (some of this is from 
the GC, others not). This isn't a huge problem in the normal case 
however the memory allocation/access patterns are not pretty when 
the going gets tough.
May 16 2021
prev sibling next sibling parent surlymoor <surlymoor cock.li> writes:
On Thursday, 13 May 2021 at 20:57:13 UTC, dogman wrote:

 [...]


Ah yes, another thread in which energy is expended on internet 
slap-fights that, in the end, precipitate in nothing but negative 
feelings.
May 16 2021
prev sibling next sibling parent Atila Neves <atila.neves gmail.com> writes:
On Thursday, 13 May 2021 at 20:57:13 UTC, dogman wrote:

 Question to the core team. Whats the plan and roadmap for D ?
 a. are we planning to keep D just as a hobby language or a real 
 contender for industry use. Despite being complex, rust has 
 started to get adopted in industries. Whats our plan ?


It's already being used in industry. The plan is definitely that.


 b. When are we planning to focus on memory safety and use that 
 as our strength


Now. This is the current priority.


 c. Will we ever make D as both a GC and non GC language.


It already is. The goal is to make non-GC use easier/safer 
without sacrificing the existing language and the ease-of-use of 
the GC.


 d. Why there are no working groups for tooling, webframeworks, 
 performance, compiler etc so that we can improve on each area.


Because the foundation only has so much donation money.


 f. D has all properties to make it a good language. But needs 
 more work and marketing. Why cant we make D as a safe and fast 
 extension to C++ & python


My personal opinion is that it already is a safe and fast 
alternative to both those languages. What do you think is lacking?
May 17 2021
prev sibling next sibling parent reply JN <666total wp.pl> writes:
On Thursday, 13 May 2021 at 20:57:13 UTC, dogman wrote:

 Question to the core team. Whats the plan and roadmap for D ?
 a. are we planning to keep D just as a hobby language or a real 
 contender for industry use. Despite being complex, rust has 
 started to get adopted in industries. Whats our plan ?


Selection bias is in play here too. Rust is getting more popular, 
previously Go was starting to gain popularity also, but just as 
many languages succeed, many fail to reach the expectations. You 
have languages like Nim or Crystal, which have their own 
fanbases, but are relatively unknown in the general programming 
population (also, most programmers aren't really familiar with 
Rust/Go either). D is also in that category. You also have many 
languages that failed completely to gain attention and are dying 
away in programming language limbo.

But you also have languages which should succeed by most metrics, 
and yet they don't. Look at Dart. It's a well designed language 
(it's one of my favorite languages), it has good IDE support, it 
has Google behind it, and yet it never reached wide adoption. 
Outside of Flutter, the usage of Dart is very limited, and 
TypeScript took most of those usecases instead.

As for Rust, most people aren't flocking to Rust for memory 
safety or for GC-less memory management. Just like most people 
aren't flocking away from D because of GC (even if they claim 
it's because of GC). For many people, unless doing low level 
programming, memory management is more of an implementation 
detail.

Borrow checker isn't attracting people to Rust. It's a bonus, 
catching more bugs during compile time, but it's not the main 
feature. The main features that attract people to Rust is the 
cohesive story, good vision and a good ecosystem of tooling, 
libraries and bindings. Just like people did webdev with Python 
not because Python is great for webdev, but because it's good 
enough and easy to get started. With lots of libraries available, 
you can pip download flask, pip download pandas and make some 
nice dashboards within hours. Rust is similar to that extent. 
There are many packages, and you can expect many libraries to be 
existing, or at least if not existing, then the bindings to C/C++ 
libraries are available to cover that gap.

Both languages represent somewhat different mentality. Rust has a 
core team that is paid to work on Rust. These people can work on 
the design of the language and can force the decision whenever a 
problematic topic comes. D is mostly a volunteer project and 
doesn't have that luxury. Every problem that comes up needs a 
consensus to overcome. And in some cases the consensus is hard to 
get.

It is a chicken and the egg problem. Because D isn't very 
popular, it doesn't have the same level of ecosystem, and because 
it doesn't have the same level of ecosystem, it doesn't get 
popular. On the other hand, not every language needs to hit it 
big. I am satisfied with the state of the D and I've seen great 
improvements over the years. Dub really improved the ergonomics 
of using D, things like Code-D work fairly well (and get better 
every year also).

Sure, we can switch the language from garbage collection to 
manual memory management or reference counting. Will it change 
much? I doubt it, the people complaining about GC would just 
complain about RC. We would throw the existing ecosystem through 
the window, and there would be new bugs that come from the 
improvements.

Personally, I think what should happen is narrowing the scope of 
the language. I actually wish D went with GC fully, without 
giving escape hatches in form of  nogc. We shouldn't be chasing 
borrowing. Did that ever go anywhere? I don't even know if 
dip1000 works now, it's all hidden somewhere in spec documents. 
We don't have dozens of paid developers working on D full time. 
We have to manage with the resources we have, and spreading them 
thin over the language is not the optimal usage of such resources.
May 17 2021
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Monday, 17 May 2021 at 19:32:14 UTC, JN wrote:

 Selection bias is in play here too. Rust is getting more 
 popular, previously Go was starting to gain popularity also,


Go is far far far more used than Rust will ever be...


 but just as many languages succeed, many fail to reach the 
 expectations. You have languages like Nim or Crystal, which 
 have their own fanbases, but are relatively unknown in the 
 general programming population (also, most programmers aren't 
 really familiar with Rust/Go either). D is also in that 
 category.


And here is the real trouble, more and more viable hobby 
languages are emerging, so the hobbyists are split up and eco 
systems suffer, so language enthusiasts gravitate towards the 
bigger ones that have polished that one feature they are 
interested in.


 But you also have languages which should succeed by most 
 metrics, and yet they don't. Look at Dart. It's a well designed 
 language (it's one of my favorite languages), it has good IDE 
 support, it has Google behind it, and yet it never reached wide 
 adoption. Outside of Flutter, the usage of Dart is very 
 limited, and TypeScript took most of those usecases instead.


This is inaccurate, I was an early Dart adopter. To keep it 
short, Google has sabbotaged it on numerous occations. First by 
designing it as a deliberately bland dynamic language (later made 
more static), then by not supporting it in Chrome as promised, 
then by having poorer framework support for it than for other web 
languages, add to this that debugging dart code in browsers was 
worse tha TypeScript and you have the reason for why I will not 
use Dart in web apps in the near future. 100% selfinflicted 
wounds.


 As for Rust, most people aren't flocking to Rust for memory 
 safety or for GC-less memory management.


That is obviously wrong.


 Borrow checker isn't attracting people to Rust. It's a bonus, 
 catching more bugs during compile time, but it's not the main 
 feature. The main features that attract people to Rust is the 
 cohesive story, good vision and a good ecosystem of tooling, 
 libraries and binding


The eco system was nonexisting when Rust gained momentum and 
attention. That attention was 100% driven by safe system 
programming. Btw, the same was true for Go initially, they later 
had to admit that they did not offer a proper solution for 
systems programming...


 Just like people did webdev with Python not because Python is 
 great for webdev, but because it's good enough and easy to get 
 started.


Python is excellent for web dev. Never found anything that can 
touch it in that domain (assuming cloud).


 Sure, we can switch the language from garbage collection to 
 manual memory management or reference counting. Will it change 
 much? I doubt it, the people complaining about GC would just 
 complain about RC.


Without ARC, probably.


 We don't have dozens of paid developers working on D full time. 
 We have to manage with the resources we have, and spreading 
 them thin over the language is not the optimal usage of such 
 resources.


That's true, the best solution is to reduce the feature set and 
improve metaprogramming, but nobody wants to see features removed 
and new features are being cheered on, so D is and is likely to 
stay a growing language experiment, which is perfectly ok by me 
as a D hobbyist
... It is what the process is making it to be, which is more one 
of growth than metamorphosis.

But lets not extrapolate too much from other languages, most of 
them follow a different process and are driven by other ideas and 
ideologies.
May 17 2021
parent reply JN <666total wp.pl> writes:
On Monday, 17 May 2021 at 20:06:05 UTC, Ola Fosheim Grostad wrote:

 That's true, the best solution is to reduce the feature set and 
 improve metaprogramming, but nobody wants to see features 
 removed and new features are being cheered on, so D is and is 
 likely to stay a growing language experiment, which is 
 perfectly ok by me as a D hobbyist
 ... It is what the process is making it to be, which is more 
 one of growth than metamorphosis.


"replace features with metaprogramming" comes with a cost. When 
templates break, the error messages are rough enough already. 
Also, compilation time will go up as the templates get expanded 
over and over.

Also, high risk of "curse of Lisp" kicking in.
May 17 2021
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Monday, 17 May 2021 at 22:39:51 UTC, JN wrote:

 On Monday, 17 May 2021 at 20:06:05 UTC, Ola Fosheim Grostad 
 wrote:
 "replace features with metaprogramming" comes with a cost. When 
 templates break, the error messages are rough enough already. 
 Also, compilation time will go up as the templates get expanded 
 over and over.


Error messages is a challenge, but then that would be sn area for 
impovement. Im sure intersting things could be done with pattern 
matching.

Caching could fix compilation times.


 Also, high risk of "curse of Lisp" kicking in.


I dont know, you might say that javascript suffers from it, but 
it looks like it thrives by it. When you get frameworks that 
curse becomes an assets. Ive never used Common LISP Music, but 
Ive heard composers create interesting things with it. When you 
can create DSLs, you  open up new arenas. Kinda like D does for 
some in scientific computing.
May 17 2021
prev sibling next sibling parent aberba <karabutaworld gmail.com> writes:
On Thursday, 13 May 2021 at 20:57:13 UTC, dogman wrote:

 Question to the core team. Whats the plan and roadmap for D ?
 a. are we planning to keep D just as a hobby language or a real 
 contender for industry use. Despite being complex, rust has 
 started to get adopted in industries. Whats our plan ?

 b. When are we planning to focus on memory safety and use that 
 as our strength


D is already pretty memory safe. Not sure how D lacks in that 
department to the point that it's become a problem. Plus it's not 
like that the only thing worth looking at or priority No. 1 for 
that matter.


 c. Will we ever make D as both a GC and non GC language. So 
 that it can be used across control plane, data plane, kernel. I 
 know betterC, but could we make it more easy and accessible 
 common public to able to use phobos. I know people say 95% is 
 done etc.


D can already be used just like any other language can. Anyone 
who can't use D for any of such use cases it problem the problem 
itself. Of course, all language require certain compromises to 
work in certain environment and D is not different.


 d. Why there are no working groups for tooling, web frameworks, 
 performance, compiler etc so that we can improve on each area.


The working group is for maintaining the language. Web framework 
etc. is not an issue or limitation of D. By the way, what king of 
web framework or web functionality cannot be done in current D? 
we got vibe.d, hunt, arsd CGI, etc.


 e. Why is weka not sponsoring ? why are we not advertising that 
 the fastest filesystem is made in D ?


They've done quite a bit of marketing in the past. By the way, 
many other companies are using D partially or exclusively 
(https://dlang.org/orgs-using-d.html). The fastest file system 
isn't written in PHP yet it's quite popular. Why is that so? Why 
do a lot of people use PHP that much?


 f. D has all properties to make it a good language. But needs 
 more work and marketing. Why cant we make D as a safe and fast 
 extension to C++ & python


Moot.
May 18 2021
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 13 May 2021 at 20:57:13 UTC, dogman wrote:

 Question to the core team. Whats the plan and roadmap for D ?
 a. are we planning to keep D just as a hobby language or a real 
 contender for industry use. Despite being complex, rust has 
 started to get adopted in industries. Whats our plan ?


D is already largely fit for industry. In my niche, there is only 
C++ competitors, and exactly zero Rust/Go/Zig competitors. D is a 
practical language, not the "earn the maximum of points of 
HN"-type language.
May 19 2021
next sibling parent Max Haughton <maxhaton gmail.com> writes:
On Wednesday, 19 May 2021 at 16:16:39 UTC, Guillaume Piolat wrote:

 On Thursday, 13 May 2021 at 20:57:13 UTC, dogman wrote:

 Question to the core team. Whats the plan and roadmap for D ?
 a. are we planning to keep D just as a hobby language or a 
 real contender for industry use. Despite being complex, rust 
 has started to get adopted in industries. Whats our plan ?


 D is already largely fit for industry. In my niche, there is 
 only C++ competitors, and exactly zero Rust/Go/Zig competitors. 
 D is a practical language, not the "earn the maximum of points 
 of HN"-type language.


Hackernews is one of the only places you can actually find people 
who've even heard of D.

D is already in a good state but there are still things that 
leave a lot to be desired, and people on hackernews may enjoy 
fashion but they usually aren't dumb so I wouldn't be too 
dismissive.
May 19 2021
prev sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 19 May 2021 at 16:16:39 UTC, Guillaume Piolat wrote:

 On Thursday, 13 May 2021 at 20:57:13 UTC, dogman wrote:

 Question to the core team. Whats the plan and roadmap for D ?
 a. are we planning to keep D just as a hobby language or a 
 real contender for industry use. Despite being complex, rust 
 has started to get adopted in industries. Whats our plan ?


 D is already largely fit for industry. In my niche, there is 
 only C++ competitors, and exactly zero Rust/Go/Zig competitors. 
 D is a practical language, not the "earn the maximum of points 
 of HN"-type language.


I think JUCE is largely the reason for why almost everyone starts 
out with C++.

Anyway, audio is an area where you have to write your own MM no 
matter which language, sabso it a bit atypical. If you create 
many similar products, then you can create you own framework with 
your own MM. Most dont, so then you need a solid MM for that 
application.

I find that the easy option for GUI on mac now is SwiftUI, 
implies xcode, implies C++.

If I planned to do many similar applications, then I might have 
considered something else...
May 21 2021
parent reply claptrap <clap trap.com> writes:
On Friday, 21 May 2021 at 13:59:23 UTC, Ola Fosheim Grostad wrote:

 On Wednesday, 19 May 2021 at 16:16:39 UTC, Guillaume Piolat 
 wrote:

 On Thursday, 13 May 2021 at 20:57:13 UTC, dogman wrote:

 Question to the core team. Whats the plan and roadmap for D ?
 a. are we planning to keep D just as a hobby language or a 
 real contender for industry use. Despite being complex, rust 
 has started to get adopted in industries. Whats our plan ?


 D is already largely fit for industry. In my niche, there is 
 only C++ competitors, and exactly zero Rust/Go/Zig 
 competitors. D is a practical language, not the "earn the 
 maximum of points of HN"-type language.


 I think JUCE is largely the reason for why almost everyone 
 starts out with C++.


Commercial audio dev was almost 100% C++ before JUCE. The plugin 
APIs are all C/C++, most of the hosts were/are C++. Its really 
nothing to do with JUCE imo.
May 21 2021
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Friday, 21 May 2021 at 14:55:38 UTC, claptrap wrote:

 On Friday, 21 May 2021 at 13:59:23 UTC, Ola Fosheim Grostad 
 wrote:
 Commercial audio dev was almost 100% C++ before JUCE. The 
 plugin APIs are all C/C++, most of the hosts were/are C++. Its 
 really nothing to do with JUCE imo.


But JUCE came before Rust... The point I tried to make was that 
there is a threshold you have to cross to get developers over to 
your language. People look for the easiest/most used solution. 
(Many audio engines are C + DSL, but that wasn't my point)
May 21 2021
parent Guillaume Piolat <first.last gmail.com> writes:
On Friday, 21 May 2021 at 15:15:37 UTC, Ola Fosheim Grostad wrote:

 But JUCE came before Rust... The point I tried to make was that 
 there is a threshold you have to cross to get developers over 
 to your language. People look for the easiest/most used 
 solution. (Many audio engines are C + DSL, but that wasn't my 
 point)


Ola is right in that choice of framework is the primary driver of 
language selection.
The handlful of people that chose Dplug didn't know D before.

That's why I think (sorry for turning this into another "D needs 
X" argument) D needs a slightly better library ecosystem to have 
more users ("yes you can do that in 3 lines, here are the 
lines"), and documentation is one way to achieve it.

JUCE has lasting power thanks to better documentation and 
identifiers. It's easy to overlook how much an easy API with good 
identifiers can lure people. I feel like this is a grave 
shortcoming of the Stepanov STL style.
May 21 2021
prev sibling next sibling parent reply sai <sai blah.com> writes:
I believe something like this will shut up most of the criticisms 
on planning/roadmap etc:

https://isocpp.org/files/img/wg21-timeline-2020-02.png

It doesn't have to be very detailed, just one page summary very 
easy to digest. If dates are not known, just use "TBD".

Most importantly, people wants to know what is happening and what 
will happen in future for D-language and who are the primary 
owners/leaders of that work at *birds eye view*. A simple table 
with key information may suffice.

Most definitely I don't want to see buckets and buckets of of 
text like these: https://wiki.dlang.org/Vision_statements

Core team and current leadership may know whats happening 
nowadays, but for external visitors, its never clear from the 
dlang website.

my 2c.
May 19 2021
parent Greg Strong <mageofmaple protonmail.com> writes:
On Wednesday, 19 May 2021 at 17:09:25 UTC, sai wrote:

 I believe something like this will shut up most of the 
 criticisms on planning/roadmap etc:

 https://isocpp.org/files/img/wg21-timeline-2020-02.png

 It doesn't have to be very detailed, just one page summary very 
 easy to digest. If dates are not known, just use "TBD".

 Most importantly, people wants to know what is happening and 
 what will happen in future for D-language and who are the 
 primary owners/leaders of that work at *birds eye view*. A 
 simple table with key information may suffice.


Thank you!  This is exactly what I'm looking for (personally).  
Well said.
May 19 2021
prev sibling parent Bienlein <ffm2002 web.de> writes:
What are the alternatives? D remains a hobby language forever, 
because it does not exceed some critical usage level, or you make 
all the required breaking changes and make a new start. I would 
choose the latter one ;-).
May 20 2021