iPhone vs Android

[Laeeth Isharc via Digitalmars-d]

On Tuesday, 13 September 2016 at 19:30:16 UTC, Marco Leise wrote:
> Am Tue, 13 Sep 2016 18:16:27 +0000
> schrieb Laeeth Isharc <laeethnospam at nospamlaeeth.com>:
>
>> Thanks you for the clear explanation.   So if you don't have 
>> GC allocations within RC structures and pick one or the other,
>>  then the concern does not apply?
>
> That's right. Often such structures contain collections of
> things, not just plain fields. And a list or a hash map working
> in a @nogc environment typically checks its contained type for
> any pointers with hasIndirections!T and if so adds its storage
> area to the GC scanned memory to be on the safe side.
> That means every collection needs a way to exempt its contents
> from GC scanning and the user needs to remember to tell it so.
>
> A practical example of that are the EMSI containers, but other 
> containers, i.e. in my own private code look similar.
>
> https://github.com/economicmodeling/containers
>
>   struct DynamicArray(T, Allocator = Mallocator, bool supportGC 
> = shouldAddGCRange!T)a certain
>   {
>       ...
>   }
>
> Here, when you use a dynamic array you need to specify the type 
> and allocator before you get to the point of opting out of GC 
> scanning. Many will prefer concise code, go with GC scanning to 
> be "better safe than sorry" or don't want to fiddle with the 
> options as long as the program works. This is no complaint, I'm 
> just trying to draw a picture of how people end up with more GC 
> scanned memory than necessary. :)

Thanks,  Marco.

So to a certain extent it's a problem of perception and of 
cognitive load when one is coming to the language - none of the 
steps taken together is necessarily difficult,  but cumulatively 
it's a lot to take in or figure out yourself - then, as you say 
people do what's easy or manageable, and then those habits come 
to constitute ones sense of what's implied by the language and 
implementation when that's not necessarily right.

There's a great blog post to be written on getting along with and 
without the GC for fun and profit - showing how to do the things 
you discussed,comparing the amount of GC D generates with eg Java 
to make vivid and concrete just how the situation is different,  
illustrating how one can use the allocator for significant 
allocations alongside the GC for trivial ones,  illustrating how 
to pre allocate buffers,  and finally demonstrating how in 
practice to use the GC profiling instrumentation we have.

Or perhaps rather a series of blog posts.   It would be helpful 
there to get across how the situation has improved.   Because the 
topic is almost guaranteed to come up in social media discussions 
(which matter as when people Google for it that is often what 
they will find), and we live in an age where the complexity means 
people use heuristic thinking,  and you can hardly blame them 
when there is no one place to point them too (as we have for 
ranges,  slices etc).

I would write it myself if I had time and understood better not 
just garbage collection techniques,  but also how other languages 
are in practice.   But it's not something for me at this point,  
and so someone else will have to do so.   I will see when it is a 
bit quieter in a year or two if someone that works with me wants 
to do it,  but in the meantime it's a great opportunity to 
improve the messaging.

The wiki could also be a bit clearer last I looked on low-GC 
solutions.   Eg you won't easily find EMSI containers from a 
casual browse.

Walter has mentioned the value as a technology professional from 
blogging and having a personal page and I think that is right.


Laeeth