On Tue, 19 Aug 2014 07:13:45 -0700
Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> One issue with this is e.g. hashtables have no primitive for freeing entries.
ah, so don't use built-in AAs. templated class/struct can replace 'em, let with less beauty in declaration. i believe that something similar can be done with arrays and strings, and with RC slices. and 2.066 moved some built-in properties to functions, which will help too.

but seems that *most* people are OK with GC, so such replacements should not be defaults. and if somebody will port Leandro's CDGC, "stop the world" problem can be avoided almost entirely.

but maybe there is some sense to shipping alternate "nogc/rc" runtime with D. the main problem with that is that someone has to write and support it. ;-)

>> i don't know if D lambdas can work without GC and don't leak.
> They don't use GC if scoped.
that's great. i'm very used to GNU C extension, which allows nested functions and something like lambdas in C, and was very happy to find that feature ofically blessed in D. i'm even more happy now when i know for sure that they will not trigger allocations.

On Tue, 19 Aug 2014 18:13:27 +0000
bachmeier via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Java or .NET programmer looking at the language. Java devs complain about Scala. I can't imagine what they'd say about Rust.
Java devs can speak?! O_O

On Tuesday, 19 August 2014 at 18:13:28 UTC, bachmeier wrote:
> On Tuesday, 19 August 2014 at 17:16:32 UTC, Dicebot wrote:
>
>> It does look like a niche language but a very good one in declared niche.
>
> On that we agree. It's great for its niche. I was picturing a Java or .NET programmer looking at the language. Java devs complain about Scala. I can't imagine what they'd say about Rust.

I imagine you are speaking about enterprise coding drones, as I also develop in Java and already expressed my opinion about Rust. :)

--
Paulo

On 8/18/14, 9:05 PM, bearophile wrote:
> Ary Borenszweig:
>
>> It's very smart, yes. But it takes half an hour to compile the
>> compiler itself.
>
> I think this is mostly a back-end issue. How much time does it take to
> compile ldc2? Can't they create a Rust with dmc back-end? :o)

Not all hope is lost, though:

https://github.com/rust-lang/rust/issues/16624

With such bugs, one can expect a lot of performance improvements in the future :-)

On Wednesday, 20 August 2014 at 13:43:19 UTC, Ary Borenszweig wrote:
> On 8/18/14, 9:05 PM, bearophile wrote:
>> Ary Borenszweig:
>>
>>> It's very smart, yes. But it takes half an hour to compile the
>>> compiler itself.
>>
>> I think this is mostly a back-end issue. How much time does it take to
>> compile ldc2? Can't they create a Rust with dmc back-end? :o)
>
> Not all hope is lost, though:
>
> https://github.com/rust-lang/rust/issues/16624
>
> With such bugs, one can expect a lot of performance improvements in the future :-)

btw it takes 6 minutes to build LDC package from scratch on my machine - that is including cloning git repos and packaging actual tarball.

Am Tue, 19 Aug 2014 07:23:33 +0000
schrieb "Kagamin" <spam@here.lot>:

> >  With GC you give up deterministic behavior, which is
> > *absolutely* not worth giving up for 1% of objects.
> 
> Memory needs deterministic management only under condition of memory scarcity, but it's not a common case, and D allows manual memory management, but why force it on everyone because only someone needs it?

Don't dismiss his point easily. The real memory cost is not
always visible. Take for example bindings to GUI libraries
where bitmap objects left to be garbage collected may have a
16 byte wrapper object, but several megabytes of memory
associated with it inside a C library. The GC wont see the
need to run a sweep and the working set blows out of
proportion. (Happened to me a few years ago.)
Other times you may just run out of handles because the GC is
not called for a while.

In practice you then add .close/.release methods to every
resource object: and here we are back at malloc/free. Cycles
aside, reference counting does a better job here.
In other words, a GC cannot handle anything outside of the
runtime it was written for, in short: OS handles and
foreign language library data structures.

-- 
Marco

On Tuesday, 26 August 2014 at 07:10:32 UTC, Marco Leise wrote:
> In practice you then add .close/.release methods to every
> resource object

Yes.

> and here we are back at malloc/free.

No.

GC exists because general purpose memory has different properties and used in a different ways than other resources. For example, you can't build a cycle of files. Hence different ways of management for memory and other types of resources. And people coming from unmanaged environments, like C++, should learn about that difference and how to manage resources in GC environment. I agree it's a problem there's no tutorial for that. Maybe, .net tutorials can be used to teach it.