www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D Language Foundation Monthly Meeting Summary

reply Mike Parker <aldacron gmail.com> writes:
We've just completed our monthly meeting for the month of May 
2021. One decision we made is to start providing summaries of the 
topics discussed. Hence this forum post.

The participants: Walter, Atila, Andrei, Razvan, Max, and me.



The primary topic on our agenda for this meeting was a 
goal-oriented task list. In place of the old vision documents, we 
want to start maintaining a list of our current major long-term 
goals and some more minor short-term goals, broken down into 
specific tasks. This serves both as the current vision and as a 
task list for community members looking to make an impact with 
their contributions. For example, Bugzilla issues that fall under 
a goal will be labeled as such, so contributors can more 
effectively focus their attention. The list will also be used to 
guide some of the work our new strike teams will be doing.

We've got a preliminary list of high-level goals that we will 
flesh out with specific tasks over the next couple of weeks. For 
example, major long-term goals are memory safety (e.g., specific 
bugs, fully enabling DIP 1000 support) and Phobos v2. There were 
other goals discussed, such as implementing named arguments, 
improving compile-time introspection, improving Phobos  safety, 
and more. I don't know yet what the initial version of the final 
list will look like, but I hope to publish it in the next two or 
three weeks.



We discussed how to improve error messages. Walter exhorts 
everyone to please raise a Bugzilla issue for specific error 
messages you encounter that you think need improvement. Walter 
also said he is open to accepting the implementation of a 
command-line switch that enables URLs in error messages to 
provide more information.



Our next monthly meeting will take place on June 25th. We haven't 
yet set the agenda, but a portion of it will be devoted to 
following up on some of the topics discussed in today's meeting.
May 28
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Friday, 28 May 2021 at 14:56:08 UTC, Mike Parker wrote:
 We've just completed our monthly meeting for the month of May 
 2021. One decision we made is to start providing summaries of 
 the topics discussed. Hence this forum post.

 The participants: Walter, Atila, Andrei, Razvan, Max, and me.
And Ali!
May 28
prev sibling next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 28 May 2021 at 14:56:08 UTC, Mike Parker wrote:
 We've just completed our monthly meeting for the month of May 
 2021. One decision we made is to start providing summaries of 
 the topics discussed. Hence this forum post.

 [...]
Splendid! Communication is king
May 28
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
On Friday, 28 May 2021 at 14:56:08 UTC, Mike Parker wrote:
 We've ...
Good,maybe we can raise our sounding slogan "Better C++" again!
May 28
parent reply zjh <fqbqrr 163.com> writes:
On Saturday, 29 May 2021 at 00:26:54 UTC, zjh wrote:
 Good,maybe we can raise our sounding slogan "Better C++" again!
There are too many talents in C++ We must attract them. Only them can make d great!Because they are library writer. They can make d great.
May 28
next sibling parent zjh <fqbqrr 163.com> writes:
On Saturday, 29 May 2021 at 00:30:38 UTC, zjh wrote:
 Good,maybe we can raise our sounding slogan "Better C++" again!
If I'm a marketer of `rust`, I'll say `rust` is `abnormal C++`.would you like a try? If I were a marketing person of D, I would say `d` is a `Better c++`.will you try? We can make use of the `C++` fame to make us famous. `C++` is `always` our good friend.
May 28
prev sibling parent reply JN <666total wp.pl> writes:
On Saturday, 29 May 2021 at 00:30:38 UTC, zjh wrote:
 On Saturday, 29 May 2021 at 00:26:54 UTC, zjh wrote:
 Good,maybe we can raise our sounding slogan "Better C++" again!
There are too many talents in C++ We must attract them. Only them can make d great!Because they are library writer. They can make d great.
I disagree. Attracting C++ folks doesn't seem to work. You may try to lure them with promises of nicer templates and no header files, but after a while they will complain about the garbage collector and go back to their new C++ draft standard. If you advertise yourself as Better C++, you are instantly setting yourself up for comparison and are turning away everyone who dislikes C++ in the first place. Rust doesn't advertise itself as "Safe C++", Go doesn't advertise itself as "Native Java", Zig doesn't advertise itself as "Better C".
Jun 03
parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 3 June 2021 at 22:40:50 UTC, JN wrote:
 On Saturday, 29 May 2021 at 00:30:38 UTC, zjh wrote:
 On Saturday, 29 May 2021 at 00:26:54 UTC, zjh wrote:
OK, how do you position "d"? What kind of programmers do you want to attract? beginner?pythoner?scripter? How to attract them and why and what feature attact them? What slogan of "d", Can d occupy a bigger market? Does d still occupy the field of system programming The GC of D is a burden.in the speaking of AA. D does not owns the advantages of GC , but all the disadvantages of GC .Why not discard it?
Jun 03
next sibling parent reply zjh <fqbqrr 163.com> writes:
OK, how do you position "d"?
What kind of programmers do you want to attract? 
beginner?pythoner?scripter?
How to attract them and why and what feature attact them?
What slogan of "d", Can d occupy a bigger market?
Does d still occupy the field of system programming

The GC of D is a burden.in the speaking of AA.
D does not owns the advantages of GC , but all the disadvantages 
of GC .Why not discard it?
Jun 03
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 3 June 2021 at 23:48:16 UTC, zjh wrote:
 OK, how do you position "d"?
As a small language, if you want to succeed.There is no way out except to be the best. Otherwise, why don't I use C++? rust,go,zim.I dislike them. Rust: slow compilation, weak template function. Go: there is no template function, and the abstraction is not strong,error process,time question.spaghetti.... Zim: the grammar is ugly. D's advantage is template.But now the advantage over `C++20` is smaller. So `D` should have `a sense of urgency`. D's position is too vague. Don't want to gain everything,Everything is nothing. what `D` need to do is `enhancing advantages`, `discarding` disadvantages, so simple! `Template metagramming` is a big advantage, we should enhance. GC is disadvantage, we should discard it! discard `GC`,attract `C++er` ,`pythoner/scripter/learner` will all come. otherwise,who help you write the lib?
Jun 03
next sibling parent reply IGotD- <nise nise.com> writes:
On Friday, 4 June 2021 at 00:14:11 UTC, zjh wrote:
 Zim: the grammar is ugly.
Zim? Is that what they speak in Zimbabwe?
Jun 03
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 4 June 2021 at 00:39:41 UTC, IGotD- wrote:
 On Friday, 4 June 2021 at 00:14:11 UTC, zjh wrote:
 Zim: the grammar is ugly.
Zim? Is that what they speak in Zimbabwe?
Zig.
Jun 03
prev sibling next sibling parent reply sighoya <sighoya gmail.com> writes:
Yet another GC vs NoGC thread :sigh:
Jun 04
parent zjh <fqbqrr 163.com> writes:
On Friday, 4 June 2021 at 11:41:49 UTC, sighoya wrote:
 Yet another GC vs NoGC thread :sigh:
Routine determines success or failure.
Jun 04
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 4 June 2021 at 00:14:11 UTC, zjh wrote:
 On Thursday, 3 June 2021 at 23:48:16 UTC, zjh wrote:
 [...]
As a small language, if you want to succeed.There is no way out except to be the best. Otherwise, why don't I use C++? [...]
GC won't go away tho. What might happen is more flexibility. The GC-phobia is irrational.
Jun 04
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 4 June 2021 at 12:44:07 UTC, Imperatorn wrote:
 GC won't go away tho. What might happen is more flexibility. 
 The GC-phobia is irrational.
The topic doesn't fit in this thread, but it isn't irrational. You have to wait for all participating threads to be ready to collect, so it isn't only about collection speed. In essence you end up with some of the same issues as with cooperative multitasking. And it is also obvious that collection speed will drop as your application grows and you start working with larger datasets. So, you might initially think it is fine, but end up rewriting your codebase because it only worked well with the simple prototype you started with. That's not a good strategy. (but ok for batch programs)
Jun 04
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 4 June 2021 at 13:32:37 UTC, Ola Fosheim Grøstad wrote:
 On Friday, 4 June 2021 at 12:44:07 UTC, Imperatorn wrote:
 GC won't go away tho. What might happen is more flexibility. 
 The GC-phobia is irrational.
The topic doesn't fit in this thread, but it isn't irrational.
The most irrational issue here is that the language itself prevents precise collection, and there is no willpower to change it. If you combine task-local GC with fully precise compiler-guided scanning, then you'd have something that would work.
Jun 04
prev sibling next sibling parent reply drug <drug2004 bk.ru> writes:
04.06.2021 16:32, Ola Fosheim Grøstad пишет:
 On Friday, 4 June 2021 at 12:44:07 UTC, Imperatorn wrote:
 GC won't go away tho. What might happen is more flexibility. The 
 GC-phobia is irrational.
The topic doesn't fit in this thread, but it isn't irrational. You have to wait for all participating threads to be ready to collect, so it isn't only about collection speed. In essence you end up with some of the same issues as with cooperative multitasking. And it is also obvious that collection speed will drop as your application grows and you start working with larger datasets. So, you might initially think it is fine, but end up rewriting your codebase because it only worked well with the simple prototype you started with. That's not a good strategy. (but ok for batch programs)
I use GC when developing an algorithm to solve my problem. After I has implemented the algorithm I can redesign it to avoid GC (if needed). It works pretty nice in my case at least. Because initially I concentrate on my domain problem and then I only deal with memory management. This separation is very helpful. Also there is no rewriting when you switch to manual management - you just add new code, no replacing old code. Again often API is worse after switching than in case of GC.
Jun 04
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 4 June 2021 at 14:07:38 UTC, drug wrote:
 I use GC when developing an algorithm to solve my problem. 
 After I has implemented the algorithm I can redesign it to 
 avoid GC (if needed). It works pretty nice in my case at least. 
 Because initially I concentrate on my domain problem and then I 
 only deal with memory management. This separation is very 
 helpful.
Yes, if you select that strategy from the start. But think for a moment how much easier it would be if the language had ownership pointers. I also believe that careful usage of ownership pointers in combination with precise scanning could lead to much less memory being scanned. There are no language features in D that support GC-strategies. That's not a strength. They can be remedied, but it takes willpower.
Jun 04
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 4 June 2021 at 13:32:37 UTC, Ola Fosheim Grøstad wrote:
 On Friday, 4 June 2021 at 12:44:07 UTC, Imperatorn wrote:
 GC won't go away tho. What might happen is more flexibility. 
 The GC-phobia is irrational.
The topic doesn't fit in this thread, but it isn't irrational. You have to wait for all participating threads to be ready to collect, so it isn't only about collection speed. In essence you end up with some of the same issues as with cooperative multitasking. And it is also obvious that collection speed will drop as your application grows and you start working with larger datasets. So, you might initially think it is fine, but end up rewriting your codebase because it only worked well with the simple prototype you started with. That's not a good strategy. (but ok for batch programs)
You might be surprised, but it's actually not up to you what topic fits or not. I said GC-phobia is irrational, I did not say any criticism of it is. Obviously GC is good for some things and not good at all for other things. What *is* irrational is saying it has absolutely no place at all.
Jun 04
next sibling parent reply IGotD- <nise nise.com> writes:
On Friday, 4 June 2021 at 18:34:32 UTC, Imperatorn wrote:
 You might be surprised, but it's actually not up to you what 
 topic fits or not.

 I said GC-phobia is irrational, I did not say any criticism of 
 it is.
 Obviously GC is good for some things and not good at all for 
 other things.

 What *is* irrational is saying it has absolutely no place at 
 all.
I don't think it is a phobia but it is a question of choice. We can clearly observe how different the demands are for different programmers in this forum. I enjoy GC for the appropriate programs, however there are SW where GC is a problem and cannot be used. Because of this Phobos must take the lowest common denominator approach (malloc/free) in order to be able to accommodate all the different needs. D is one these Swiss army knife languages that can be used for everything, including low level software and everything in between. What D should strive for is to give programmers a choice and put up as few barriers as possible. It's certainly challenging to make a library and language fitting everyone needs but D is at least one of the best foundation of achieving that goal.
Jun 04
next sibling parent reply sighoya <sighoya gmail.com> writes:
On Friday, 4 June 2021 at 19:31:57 UTC, IGotD- wrote:
Because of this Phobos must take the lowest common denominator 
approach (malloc/free) in order to be able to accommodate all 
the different needs.
This uniformization sounds too good to be true. I think most people think that, but it's simply not true. malloc/free is incompatible to garbage collection. You can parametrize over all possible MM strategies making every function generic and pass the right MM into it. Beside increasing template bloat it isn't that optimal as the same code has different performance characteristic for each MM, so you need to overload over all these and even then you won't cover all the MM because there are people wanting to insert their custom MM, but the library was already written. I'm asking myself, even if we don't care about the cons, would that at all be possible with a ~20 years old language with a ~20 years of ecosystem evolution. How many things need to be rewritten?
Jun 04
parent reply IGotD- <nise nise.com> writes:
On Friday, 4 June 2021 at 19:56:06 UTC, sighoya wrote:
 This uniformization sounds too good to be true. I think most 
 people think that, but it's simply not true. malloc/free is 
 incompatible to garbage collection.
This is true and even druntime has a malloc/free option for the GC. However, its implementation is really bad. Also the implementation of the current GC has a lot of room for improvements. It is still not appropriate for many embedded systems as it requires another layer that steals CPU time and code memory. In the case of Phobos, in order to make as versatile as possible it shall not assume any other layer than malloc/free.
 I'm asking myself, even if we don't care about the cons, would 
 that at all be possible with a ~20 years old language with a 
 ~20 years of ecosystem evolution. How many things need to be 
 rewritten?
D certainly has the power to do so but the question is if there is any will power in this community. Nothing has happened for almost 20 years.
Jun 04
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 4 June 2021 at 21:35:43 UTC, IGotD- wrote:
 D certainly has the power to do so but the question is if there 
 is any will power in this community. Nothing has happened for 
 almost 20 years.
I guess importC will make changes even more unlikely. Absorbing C is nice, but it has the unfortunate effect of giving D some of the same disadvantages as C++.
Jun 04
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 4 June 2021 at 21:35:43 UTC, IGotD- wrote:
 On Friday, 4 June 2021 at 19:56:06 UTC, sighoya wrote:
 This uniformization sounds too good to be true. I think most 
 people think that, but it's simply not true. malloc/free is 
 incompatible to garbage collection.
This is true and even druntime has a malloc/free option for the GC. However, its implementation is really bad. Also the implementation of the current GC has a lot of room for improvements. It is still not appropriate for many embedded systems as it requires another layer that steals CPU time and code memory.
Speaking of embedded, https://learn.adafruit.com/welcome-to-circuitpython https://blog.arduino.cc/2019/08/23/tinygo-on-arduino https://www.microsoft.com/en-us/makecode/resources http://www.ulisp.com/ https://developer.android.com/training/wearables/principles https://www.microej.com/product/vee/ Meanwhile kids, the future generation of developers, keeps adopting the hardware and programming languages listed above, completly oblivious there is a programming language where all discussion threads turn into GC vs no-GC no matter what was the original subject.
Jun 05
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 5 June 2021 at 08:58:47 UTC, Paulo Pinto wrote:
 Meanwhile kids, the future generation of developers, keeps 
 adopting the hardware and programming languages listed above,
D isn't useful for teaching kids programming. Waaaay too complicated. Most Arduino users, who build useful stuff, use C++. But it is not a good strategy for D to become more like C++, too late. It would've been a good strategy 6 years ago to align D semantics with C++ and have full interop, but too late now. D needs a feature-set that makes it attractive for people wanting to do high profile interactive stuff, like games, graphics editors, sound editors, high performance services. With useful optional GC and easy multithreading. The current GC strategy is a dead end. No GC makes the language too much of a C++ with no real edge. D needs to offer something other languages do not, to offset the cost of learning the language complexities.
Jun 05
parent reply sighoya <sighoya gmail.com> writes:
On Saturday, 5 June 2021 at 09:14:52 UTC, Ola Fosheim Grøstad 
wrote:

 The current GC strategy is a dead end. No GC makes the language 
 too much of a C++ with no real edge. D needs to offer something 
 other languages do not, to offset the cost of learning the 
 language complexities.
I think the switch to arc with cycle detection as opt out (like in python) is the right direction, it fits more to a system level language making use of destructors more often. Rewriting cyclic code to acyclic code is easier than lifetime management in general. Further, optimizations can be introduced that detect acyclic structures in D just as it is the case for nim (https://nim-lang.org/docs/manual.html#pragmas-acyclic-pragma). That doesn't mean tracing GC is bad, I'm still skeptical that arc + cycle detection is better than tracing in general for true high level languages.
Jun 10
next sibling parent IGotD- <nis nis.com> writes:
On Thursday, 10 June 2021 at 10:55:50 UTC, sighoya wrote:
 I think the switch to arc with cycle detection as opt out (like 
 in python) is the right direction, it fits more to a system 
 level language making use of destructors more often.

 Rewriting cyclic code to acyclic code is easier than lifetime 
 management in general.

 Further, optimizations can be introduced that detect acyclic 
 structures in D just as it is the case for nim 
 (https://nim-lang.org/docs/manual.html#pragmas-acyclic-pragma).

 That doesn't mean tracing GC is bad, I'm still skeptical that 
 arc + cycle detection is better than tracing in general for 
 true high level languages.
Yes, this is a way forward. Walter doesn't want to add fat pointers, however he hasn't mentioned if that's part of the language or fat pointers as a library (like C++). It doesn't need to be part of the language but as a library type. Classes in D are essentially already library fat pointers. What we need is to extend this so that we have a generic fat pointer type (that can be recompiled to whatever GC type we want) that can be used for any type through out the entire code base if the programmer wishes that. Then we need refactor druntime/phobos to only use this fat pointer type. As you mentioned, in order to have better support for different GC, we can support compiler hooks (like your acyclic example) in order to give the compiler optimization hints. Whatever GC type you think is better for you, you should decide that and not forced by the D compiler and library. Basically GC X is better than Y is not an argument. What is the argument is how we can allow people to choose.
Jun 10
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 10 June 2021 at 10:55:50 UTC, sighoya wrote:
 On Saturday, 5 June 2021 at 09:14:52 UTC, Ola Fosheim Grøstad 
 wrote:

 The current GC strategy is a dead end. No GC makes the 
 language too much of a C++ with no real edge. D needs to offer 
 something other languages do not, to offset the cost of 
 learning the language complexities.
I think the switch to arc with cycle detection as opt out (like in python) is the right direction, it fits more to a system level language making use of destructors more often. Rewriting cyclic code to acyclic code is easier than lifetime management in general. Further, optimizations can be introduced that detect acyclic structures in D just as it is the case for nim (https://nim-lang.org/docs/manual.html#pragmas-acyclic-pragma). That doesn't mean tracing GC is bad, I'm still skeptical that arc + cycle detection is better than tracing in general for true high level languages.
Well, I advise reading "On Adding Garbage Collection and Runtime Types to a Strongly-Typed, Statically-Checked, Concurrent Language" http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-84-7_On_Adding_Garbage_Collection_and_Runtime_Types_to_a_Strongly-Typed_Statically-Checked_Concurrent_Language.pdf And watching the upcoming WWDC 2021 talk "ARC in Swift: Basics and beyond" on Friday. https://developer.apple.com/wwdc21/sessions What Cedar, Swift and Nim have in common that D lacks, are fat pointers, the compiler awareness for optimizations regarding elision of counter manipulation code, and tricks like background threads for the cycle collector or cascade deletions. It is no an accident that high performance reference counting GC is similar to tracing GC in regards to implementation complexity.
Jun 10
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 10 June 2021 at 10:55:50 UTC, sighoya wrote:
 That doesn't mean tracing GC is bad, I'm still skeptical that 
 arc + cycle detection is better than tracing in general for 
 true high level languages.
For truly high level languages garbage collection probably is the best, if you design the language semantics for it. The main issue with D is that the language semantics don't enable competitive GC advantages. I think at least D should go with ARC for shared resources. Then have a variety of options for task-local resources, including GC.
Jun 10
prev sibling parent reply Norm <norm.rowtree gmail.com> writes:
On Saturday, 5 June 2021 at 08:58:47 UTC, Paulo Pinto wrote:
 On Friday, 4 June 2021 at 21:35:43 UTC, IGotD- wrote:
 On Friday, 4 June 2021 at 19:56:06 UTC, sighoya wrote:
 This uniformization sounds too good to be true. I think most 
 people think that, but it's simply not true. malloc/free is 
 incompatible to garbage collection.
This is true and even druntime has a malloc/free option for the GC. However, its implementation is really bad. Also the implementation of the current GC has a lot of room for improvements. It is still not appropriate for many embedded systems as it requires another layer that steals CPU time and code memory.
Speaking of embedded, https://learn.adafruit.com/welcome-to-circuitpython https://blog.arduino.cc/2019/08/23/tinygo-on-arduino https://www.microsoft.com/en-us/makecode/resources http://www.ulisp.com/ https://developer.android.com/training/wearables/principles https://www.microej.com/product/vee/ Meanwhile kids, the future generation of developers, keeps adopting the hardware and programming languages listed above, completly oblivious there is a programming language where all discussion threads turn into GC vs no-GC no matter what was the original subject.
There is also https://micropython.org/ It would not be my choice of language for medical but uPython is used in a small number of embedded medical devices and has been ported to several flavours of STM32. This is a space where D could make a difference, although unfortunately the language has some dark corner cases and friction that put some people off to the point where they don't see any benefit moving to D.
Jun 07
parent Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 7 June 2021 at 23:04:12 UTC, Norm wrote:
 On Saturday, 5 June 2021 at 08:58:47 UTC, Paulo Pinto wrote:
 On Friday, 4 June 2021 at 21:35:43 UTC, IGotD- wrote:
 On Friday, 4 June 2021 at 19:56:06 UTC, sighoya wrote:
 This uniformization sounds too good to be true. I think most 
 people think that, but it's simply not true. malloc/free is 
 incompatible to garbage collection.
This is true and even druntime has a malloc/free option for the GC. However, its implementation is really bad. Also the implementation of the current GC has a lot of room for improvements. It is still not appropriate for many embedded systems as it requires another layer that steals CPU time and code memory.
Speaking of embedded, https://learn.adafruit.com/welcome-to-circuitpython https://blog.arduino.cc/2019/08/23/tinygo-on-arduino https://www.microsoft.com/en-us/makecode/resources http://www.ulisp.com/ https://developer.android.com/training/wearables/principles https://www.microej.com/product/vee/ Meanwhile kids, the future generation of developers, keeps adopting the hardware and programming languages listed above, completly oblivious there is a programming language where all discussion threads turn into GC vs no-GC no matter what was the original subject.
There is also https://micropython.org/
I just skipped MicroPython, because Circuit Python seems to have more uptake even though it is based on it.
 It would not be my choice of language for medical but uPython 
 is used in a small number of embedded medical devices and has 
 been ported to several flavours of STM32.

 This is a space where D could make a difference, although 
 unfortunately the language has some dark corner cases and 
 friction that put some people off to the point where they don't 
 see any benefit moving to D.
Exactly, and the whole GC vs no-GC take the language nowhere in that regard.
Jun 08
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Friday, 4 June 2021 at 19:31:57 UTC, IGotD- wrote:
 On Friday, 4 June 2021 at 18:34:32 UTC, Imperatorn wrote:
 You might be surprised, but it's actually not up to you what 
 topic fits or not.

 I said GC-phobia is irrational, I did not say any criticism of 
 it is.
 Obviously GC is good for some things and not good at all for 
 other things.

 What *is* irrational is saying it has absolutely no place at 
 all.
I don't think it is a phobia but it is a question of choice. We can clearly observe how different the demands are for different programmers in this forum. I enjoy GC for the appropriate programs, however there are SW where GC is a problem and cannot be used. Because of this Phobos must take the lowest common denominator approach (malloc/free) in order to be able to accommodate all the different needs. D is one these Swiss army knife languages that can be used for everything, including low level software and everything in between. What D should strive for is to give programmers a choice and put up as few barriers as possible. It's certainly challenging to make a library and language fitting everyone needs but D is at least one of the best foundation of achieving that goal.
I agree with the description of a swiss army knife. Like if some comany/brand said they're removing the little saw, and there are many ppl who bought the knife mainly to be able to do some quick n dirty sawing, they would choose another company/brand.
Jun 05
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 4 June 2021 at 18:34:32 UTC, Imperatorn wrote:
 You might be surprised, but it's actually not up to you what 
 topic fits or not.
This is the announce forum, so it is kinda misplaced, but we are all contributing to this so... :)
 Obviously GC is good for some things and not good at all for 
 other things.
The problem is that the D-style GC is not a good fit for anything interactive, beyond simple applications. My impression is that most people use D for batch programs, so I guess that shapes the opinion. And that is a problem for D. A bad GC-strategy is reinforced by the remaining majority, which is a tiny fraction of the overall programming community. These days you don't really need a system level language to write batch programs. So it is not a good strategy to hold onto this specific type of stop-everything-scan-everything GC. Unless D decides to not be a system level language, but then you need a lot more convenience features and become more scripty. The inbetween position is not the top-pick for anyone looking for a solution. Not being willing to switch MM strategy means being stuck on a tiny island, too afraid of crossing the ocean to get access to the main land. My impression is that Walter would rather stay on this tiny island than take any chances. The language is being extended with incomplete experimental features, instead of going to the core of the issue and doing something with the foundation for the language. That is not going to end well. You'll end up with a patchwork.
Jun 05
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 5 June 2021 at 08:51:07 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 4 June 2021 at 18:34:32 UTC, Imperatorn wrote:
 [...]
This is the announce forum, so it is kinda misplaced, but we are all contributing to this so... :) [...]
I get your point, but I still think GC will remain mainly because of the area D is trying to cover.
Jun 05
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 5 June 2021 at 09:47:11 UTC, Imperatorn wrote:
 I get your point, but I still think GC will remain mainly 
 because of the area D is trying to cover.
You mean the wait-for-everything-to-stop-scan-everything approach will remain? What is the area that D is trying to cover though? Somebody should write a memo on that.
Jun 05
parent reply sai <sai blah.com> writes:
On Saturday, 5 June 2021 at 09:58:23 UTC, Ola Fosheim Grøstad 
wrote:
 You mean the wait-for-everything-to-stop-scan-everything 
 approach will remain?

 What is the area that D is trying to cover though?

 Somebody should write a memo on that.
My use case of writing GUI apps for desktop - presence of GC does not matter for me at all. In fact its great for me. Hopefully D will not stop covering these use cases. I know all the web-apps folks who wants to serve 100000000000000 requests per second will not like GC, I guess.
Jun 07
next sibling parent IGotD- <nise nise.com> writes:
On Monday, 7 June 2021 at 18:37:54 UTC, sai wrote:
 Hopefully D will not stop covering these use cases.

 I know all the web-apps folks who wants to serve 
 100000000000000 requests per second will not like GC, I guess.
Absolutely not, D must continue with automatic memory management and I think about everybody agree with that. The discussion is about how D can support different types of memory management and how to approach that, this is where the opinions are very different.
Jun 07
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 7 June 2021 at 18:37:54 UTC, sai wrote:
 My use case of writing GUI apps for desktop - presence of GC 
 does not matter for me at all. In fact its great for me. 
 Hopefully D will not stop covering these use cases.
Great, I am interested in highly interactive apps (games, sound editors, graphics editors, audio plugins, etc). Maybe we could create a focus group and collect experiences, approaches, weak spots, strong spots? Right now I think many feel left in the dark when they come with an idea for an app as there is little guidance of how to build a bigger app. I sense this by watching the learn-forum.
Jun 08
prev sibling parent bachmeier <no spam.net> writes:
On Thursday, 3 June 2021 at 23:48:16 UTC, zjh wrote:

 D does not owns the advantages of GC , but all the 
 disadvantages of GC .Why not discard it?
This is not a realistic or helpful suggestion. You're proposing to get rid of current users of the language - many of whom like that there's a GC - in order to chase C++ programmers, who represent a small sliver of all programmers, who mostly wouldn't change languages anyway, and who would change to Rust if they were planning to change languages. Again, not a helpful suggestion.
Jun 04
prev sibling parent IGotD- <nise nise.com> writes:
On Thursday, 3 June 2021 at 23:47:07 UTC, zjh wrote:
 The GC of D is a burden.in the speaking of AA.
 D does not owns the advantages of GC , but all the 
 disadvantages of GC .Why not discard it?
Yes, for Phobos v2 one of the primary goals should be to not being forced to rely on GC. Phobos should only rely on malloc/free. Phobos may be using reference counting internally as it also only relies on malloc/free.
Jun 03
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Friday, 28 May 2021 at 14:56:08 UTC, Mike Parker wrote:
 For example, major long-term goals are memory safety (e.g., 
 specific bugs, fully enabling DIP 1000 support) and Phobos v2.
Phobos v2 is an official plan? That was news for me! Any chance to get a glimpse of what's planned for it?
Jun 02
parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 2 June 2021 at 11:10:36 UTC, Dukc wrote:
 Phobos v2 is an official plan? That was news for me! Any chance 
 to get a glimpse of what's planned for it?
The overall goal is that it doesn't replace the current Phobos, but sits alongside it. Changed/improved/new functionality goes in the std.v2 namespace (or whatever it looks like in the end) and you can import that alongside existing std packages. Andrei has talked about it a little here in the forums, and Steve did some preliminary work a while back. Beyond that, I have no details about plans. We'll have more after the workgroup gets going.
Jun 02
parent Kagamin <spam here.lot> writes:
On Wednesday, 2 June 2021 at 14:02:29 UTC, Mike Parker wrote:
 On Wednesday, 2 June 2021 at 11:10:36 UTC, Dukc wrote:
 Phobos v2 is an official plan? That was news for me! Any 
 chance to get a glimpse of what's planned for it?
The overall goal is that it doesn't replace the current Phobos, but sits alongside it. Changed/improved/new functionality goes in the std.v2 namespace (or whatever it looks like in the end) and you can import that alongside existing std packages.
I thought v2 is what it currently is, so the next would be v3.
Jun 04