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
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
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
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
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
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
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
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
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
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
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
next sibling parent zjh <fqbqrr 163.com> writes:
On Tuesday, 18 May 2021 at 00:54:04 UTC, dogman wrote:

+10086.
May 17
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
next sibling parent zjh <fqbqrr 163.com> writes:
I totally agree with you.
May 18
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
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
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
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
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
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
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
next sibling parent russhy <russhy gmail.com> writes:
*go ate their dreams
May 18
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
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
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
parent reply zjh <fqbqrr 163.com> writes:
You're splitting D.
May 18
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
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
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
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
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
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
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
next sibling parent reply zjh <fqbqrr 163.com> writes:
not trust,but Rust.
Translation problems.
May 18
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
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
next sibling parent reply zjh <fqbqrr 163.com> writes:

one translate,ten errors.too funny.
May 18
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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