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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
prev sibling next sibling parent reply sighoya <sighoya gmail.com> writes:
Yet another GC vs NoGC thread :sigh:
Jun 04 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021
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 2021