www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GC/nogc status in docs

reply aberba <karabutaworld gmail.com> writes:
Has there been any consideration on tagging Phobos function as 
either GC or no-GC depending on how they behave for general 
awareness when reading the docs?

I'm thinking it could be useful to know what you get.
Jul 09 2020
next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Thursday, 9 July 2020 at 12:55:45 UTC, aberba wrote:

 Has there been any consideration on tagging Phobos function as 
 either GC or no-GC depending on how they behave for general 
 awareness when reading the docs?

 I'm thinking it could be useful to know what you get.


So I need to expand on this. For example if you read this post's 
cmments:

https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/

There's lots of comments about D's GC which most core members of 
the community know its isn't true at all CURRENTLY. The rumors 
eventually becomes facts. And there's a lot of cleaning up of D's 
reputation to do.

Its everywhere I read about D.

Lots of misinformation out there about the current status of 
Phobos in terms of how much of it is GC/nogc and the myth around 
the need for GC in the first place.

Atila answered very well quite a lot of the questions but that's 
for just SOMEONE who read the post's comments.

GC, RAII, RC, so many misinformation HN, reddit, etc. (been doing 
some research BTW)

The

 From what I have read,...


is all over the place.
See 
https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/#comment-14607

Marking functions in docs as GC or nogc goes beyond just function 
signatures cus what you find in the D docs is meaningless IMO to 
many new comers. OR a least anyway else to improve and make 
things clear.

BTW, its not just GC. IDEs, debugging, etc it all add up. Can we 
a least remove all the dead IDEs/editors and GUIs from the Wiki 
and only leave out the good/reliable options?
Jul 13 2020
parent reply SealabJaster <sealabjaster gmail.com> writes:
On Monday, 13 July 2020 at 11:16:07 UTC, aberba wrote:

 The

 From what I have read,...


 is all over the place.


Perhaps we need a sort of "mythbusting" page.

"
MYTH: D's GC will **randomly** cause pauses in your program!

FACT: D's GC only decides if it needs to run during allocations, 
and collections can be manually disabled for hot 
paths(GC.disable/GC.enable), as well as forced prematurely 
(GC.collect).
"

And the like.
Jul 13 2020
parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 13 July 2020 at 12:38:05 UTC, SealabJaster wrote:

 On Monday, 13 July 2020 at 11:16:07 UTC, aberba wrote:

 The

 From what I have read,...


 is all over the place.


 Perhaps we need a sort of "mythbusting" page.

 "
 MYTH: D's GC will **randomly** cause pauses in your program!

 FACT: D's GC only decides if it needs to run during 
 allocations, and collections can be manually disabled for hot 
 paths(GC.disable/GC.enable), as well as forced prematurely 
 (GC.collect).
 "

 And the like.


It won't make a bit of difference. Walter wrote the original 
version of the GC page way back when [1] (pretty sure I read in 
in 2004 or so and, with my Java background, found it a refreshing 
attitude). Didn't matter. I started the GC series on the blog 
partly to counter misinformation here and on reddit. Didn't 
matter (I find an opportunity to link to it most D threads on 
reddit). Whether it's GC or any of the other complaints we hear 
about, it won't matter. There will always be some number of 
people who have a lot to say about why they aren't using D, or 
any language, and it very often is not the same list of 
complaints you get from those who actually are using it. This has 
been the same surrounding every language I've ever used.

A mythbuster page isn't aimed at the people we need to reach. 
There are other ways to do that. Like, write games that use the 
GC and do a blog or video series on it. Write blog posts about 
real world D projects using the GC now, or focusing on any other 
D feature (what this algorithm or that container looks like in D, 
etc). Write about your own personal experience with D, the GC, 
Phobos, and so on.

This is the sort of stuff that attracts interest. And the people 
it attracts aren't going to be the ones you see in reddit threads 
throwing up one excuse after another about why they aren't using 
D. The ones it attracts are those who mention two or three years 
later in a forum thread "I first came to D when I saw a blog post 
about it on reddit".

I notice a lot of enthusiasm lately for promoting and 
evangelizing D, and that's a good thing! We will always need more 
material out there, yes. But IMO, it should be the sort of 
material that focuses on showing what D can actually do and how 
it's actually used as opposed to material that's purely 
promotional. We want people to stumble across it and think, "Hey, 
that's neat! I should check that out."

It believe it also helps when addressing misinformation directly 
in reddit/HN comments that we shouldn't argue or debate. Just lay 
some facts down, with links if necessary, and walk away. Only 
reply to responses that are crying out for more laying down of 
facts, but do so sparingly. Your target audience should rarely be 
the person you're replying to, whose mind you are almost 
certainly not going to change, but people reading the comment 
thread at any point in time thereafter.

[1] https://dlang.org/spec/garbage.html
Jul 13 2020
next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Monday, 13 July 2020 at 19:16:31 UTC, Mike Parker wrote:

 On Monday, 13 July 2020 at 12:38:05 UTC, SealabJaster wrote:

 On Monday, 13 July 2020 at 11:16:07 UTC, aberba wrote:

 The

 From what I have read,...


 is all over the place.


 Perhaps we need a sort of "mythbusting" page.




I remember one Linux OS project did this and really made an 
impact. [1]


 I started the GC series on the blog partly to counter 
 misinformation here and on reddit. Didn't matter (I find an 
 opportunity to link to it most D threads on reddit). Whether 
 it's GC or any of the other complaints we hear about, it won't 
 matter.


Actually it did and still making more impact than you think. I 
see that post referenced in many places. Some do actually read to 
understand. Its actually a gem I use for the D preaching work.

You're right, there are naysayers but also people with genuine 
interest in making a decision.

1. 
https://blog.elementary.io/busting-major-myths-around-elementary-os/
Jul 13 2020
parent Mike Parker <aldacron gmail.com> writes:
On Monday, 13 July 2020 at 19:43:07 UTC, aberba wrote:


 I started the GC series on the blog partly to counter 
 misinformation here and on reddit. Didn't matter (I find an 
 opportunity to link to it most D threads on reddit). Whether 
 it's GC or any of the other complaints we hear about, it won't 
 matter.


 Actually it did and still making more impact than you think. I 
 see that post referenced in many places. Some do actually read 
 to understand. Its actually a gem I use for the D preaching 
 work.


Oh, I'm sure some folks may find it useful as an introductory 
reference. My point is that it isn't going to kill the noise that 
pops up about D's GC. Trying to change a narrative that's been 
going almost 20 years is a losing battle.


 You're right, there are naysayers but also people with genuine 
 interest in making a decision.

 1. 
 https://blog.elementary.io/busting-major-myths-around-elementary-os/


Yes, and those people who want to make a decision are the ones 
you target. What I'm trying to say is, bust the myths without 
telling people you're busting the myths.

Notice how in that blog page the author is essentially listing 
arguments and counterarguments. When you do that, you're 
naturally putting the reader in a position to view you as being 
on the defensive. You're also triggering the "which side should I 
believe" mode. As someone who doesn't know anything about 
Elementary OS, I'm going to have to follow the links the author 
provides and dig a bit into the other side, the myths he's 
supposedly busting, to decide if I trust him or not. That means I 
have to be motivated to spend the time to do that.

I can't say that sort of page will never change a mind, or spark 
an interest, but I'm pretty confident it isn't the most efficient 
way to do so. What if, instead, the author took each of those 
myths and wrote an individual article targeting each of them, 
incorporating the counterarguments without once presenting them 
as counterarguments for a myth?

Take the first myth about GNOME Shell. As it is on that page, I 
can actually accept that the author is truthful in saying they 
use their homegrown Pantheon instead. By why should that matter 
to me? He mentions a couple of points where Pantheon is a better 
choice (GNOME is monolithic and written in JavaScript vs. 
Patheon's component-based architecture written in Vala), but 
that's directly triggering my "who should I believe" mode. He's 
using one paragraph for each, giving me nothing to work with in 
making a decision.

What if, instead, he wrote an article about Pantheon's 
component-based architecture? The entirety of the article would 
be focused on that topic. He could show diagrams, examples of it 
in use, sample code. I could get a broader picture of the 
components, and from the example code see that it's using Vala 
without his ever bringing a comparison to JavaScript into the 
equation. He could mention JavaScript if he wanted to, and 
monolithic architectures, and he could do it in a way that 
doesn't trigger any sort of comparison mode in my mind, e.g., "We 
chose Vala instead of other candidates like JavaScript because of 
these reasons." or "Older desktop environments, like GNOME, are 
monolithic. We opted for a component based approach for these 
reasons." And the reasons could be listed just as they are, 
without ever comparing them to the features of or reasons not to 
use JavaScript or Gnome. It puts the reader in a completely 
different mindset.

Promotional text should try to avoid leaving the reader with any 
sort of conflict or negativity in their mind by the end of the 
article. It's okay to take a jab at a competing 
language/product/etc somewhere in the middle (the more subtly so 
the better), but it should always open and end on a positive 
note. A page full of busted myths, particularly one with that 
term in the title, is the very opposite. It's confrontational and 
conflicting from beginning to end.

That's why I recommend anyone wanting to promote D do so by 
writing articles about D that show off particular features, or 
libraries, or algorithms, etc. Show D how and where it is used 
and let the text stand on its own merit. I firmly believe we 
reach more people that way.

Look at the my first post in the GC series. I saw an opportunity 
for a catchy title, so I used it. Catchy titles draw more eyes. 
In the first paragraph I mention how the GC has benefits and 
drawbacks. That's true. I then proceed with some advice on how to 
mitigate the drawbacks. Although the article (and the entire 
series) is presented as a D tutorial, my primary motivation was 
to counter misinformation about the GC. People who aren't yet 
using D yet but might be interested in it, they are my target. I 
wanted them to see that working with the GC in D isn't as bad as 
they might have read. The tutorial format was just an easy way to 
present it, with the added benefit that existing D users might 
find it useful.

I think I can boil it all down to this: evangelize without being 
an evangelist.
Jul 13 2020
prev sibling parent aberba <karabutaworld gmail.com> writes:
On Monday, 13 July 2020 at 19:16:31 UTC, Mike Parker wrote:

 On Monday, 13 July 2020 at 12:38:05 UTC, SealabJaster wrote:



 It believe it also helps when addressing misinformation 
 directly in reddit/HN comments that we shouldn't argue or 
 debate. Just lay some facts down, with links if necessary, and 
 walk away. Only reply to responses that are crying out for more 
 laying down of facts, but do so sparingly. Your target audience 
 should rarely be the person you're replying to, whose mind you 
 are almost certainly not going to change, but people reading 
 the comment thread at any point in time thereafter.


Good advice Mike. I believe its a much better approach.


 [1] https://dlang.org/spec/garbage.html
Jul 13 2020
prev sibling next sibling parent reply Ogi <ogion.art gmail.com> writes:
On Thursday, 9 July 2020 at 12:55:45 UTC, aberba wrote:

 Has there been any consideration on tagging Phobos function as 
 either GC or no-GC depending on how they behave for general 
 awareness when reading the docs?

 I'm thinking it could be useful to know what you get.


I wonder how much of Phobos is not  nogc simply because of the 
use of exceptions. Walter had some ideas that would allow 
exceptions to work without GC. Is there any progress?
Jul 13 2020
next sibling parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Monday, 13 July 2020 at 18:14:56 UTC, Ogi wrote:

 On Thursday, 9 July 2020 at 12:55:45 UTC, aberba wrote:

 Has there been any consideration on tagging Phobos function as 
 either GC or no-GC depending on how they behave for general 
 awareness when reading the docs?

 I'm thinking it could be useful to know what you get.


 I wonder how much of Phobos is not  nogc simply because of the 
 use of exceptions. Walter had some ideas that would allow 
 exceptions to work without GC. Is there any progress?


Use compiler flag - dip1008 and only throw as

throw new SomeExceptionType(msgString)

to get  nogc-ness.
Jul 13 2020
prev sibling next sibling parent Paul Backus <snarwin gmail.com> writes:
On Monday, 13 July 2020 at 18:14:56 UTC, Ogi wrote:

 On Thursday, 9 July 2020 at 12:55:45 UTC, aberba wrote:

 Has there been any consideration on tagging Phobos function as 
 either GC or no-GC depending on how they behave for general 
 awareness when reading the docs?

 I'm thinking it could be useful to know what you get.


 I wonder how much of Phobos is not  nogc simply because of the 
 use of exceptions. Walter had some ideas that would allow 
 exceptions to work without GC. Is there any progress?


You can enable  nogc exceptions with -preview=dip1008. Last I 
heard there were some issues with the implementation, but that 
was a while ago, so things may have changed.
Jul 13 2020
prev sibling parent Harry Gillanders <contact harrygillanders.com> writes:
On Monday, 13 July 2020 at 18:14:56 UTC, Ogi wrote:

 On Thursday, 9 July 2020 at 12:55:45 UTC, aberba wrote:

 Has there been any consideration on tagging Phobos function as 
 either GC or no-GC depending on how they behave for general 
 awareness when reading the docs?

 I'm thinking it could be useful to know what you get.


 I wonder how much of Phobos is not  nogc simply because of the 
 use of exceptions. Walter had some ideas that would allow 
 exceptions to work without GC. Is there any progress?



-dip1008 seems to work well enough.

But even when compiling with -dip1008, many exceptions in Phobos 
allocate a message string via the GC.
Moreover, many functions in std.exception rely on `lazy` 
parameters, which can't be inferred as  nogc, so any Phobos 
functions that use something like `enforce`, or `ifThrown` aren't 
 nogc.

See this example of something trivial which won't compile as 
 nogc even with -dip1008:

	import std.exception;

	void main ()  nogc
	{
		int x = 5;

		enforce(x <= 4);
	}
Jul 13 2020
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Thursday, 9 July 2020 at 12:55:45 UTC, aberba wrote:

 Has there been any consideration on tagging Phobos function as 
 either GC or no-GC depending on how they behave for general 
 awareness when reading the docs?

 I'm thinking it could be useful to know what you get.


I mentored work on adding  nogc information to every function in 
Phobos. It's not done yet, but it's nearly there.
Jul 14 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 14 July 2020 at 12:03:30 UTC, Atila Neves wrote:

 I mentored work on adding  nogc information to every function 
 in Phobos. It's not done yet, but it's nearly there.


Did you do it as  nogc unittests? Doing it with the direct 
annotation would be overly limiting due to lambdas etc.
Jul 14 2020
parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 14 July 2020 at 12:07:47 UTC, Adam D. Ruppe wrote:

 On Tuesday, 14 July 2020 at 12:03:30 UTC, Atila Neves wrote:

 I mentored work on adding  nogc information to every function 
 in Phobos. It's not done yet, but it's nearly there.


 Did you do it as  nogc unittests?


Yes.


 Doing it with the direct annotation would be overly limiting 
 due to lambdas etc.


I'm open to ideas on how to do it otherwise.
Jul 14 2020
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 14 July 2020 at 13:35:12 UTC, Atila Neves wrote:

 I'm open to ideas on how to do it otherwise.


 nogc unittests are good, and the docs should probably show that 
too - if the declaration has a  nogc unittest attached, the doc 
generator could and show it is at least conditionally compatible.

A  nogc on the function itself would reject non- nogc lambdas and 
such and that's unnecessarily limiting, but inference + unittest 
+ docs showing unittest annotations = win.

I'll prolly change adrdox later this week to do that, will be 
interesting to see how much of phobos will show conditional 
nogc/safe/pure as it is.
Jul 14 2020