Re: Go, D, and the GC

On 08/10/15 18:58, Marco Leise wrote: Am Mon, 05 Oct 2015 13:42:50 + schrieb Adam D. Ruppe : On Monday, 5 October 2015 at 07:40:35 UTC, deadalnix wrote: Not on the heap. There are many cases where the destructor won't run and it is allowed by spec. We should do

Re: Go, D, and the GC

On Friday, 9 October 2015 at 07:39:06 UTC, Shachar Shemesh wrote: On 08/10/15 18:58, Marco Leise wrote: Am Mon, 05 Oct 2015 13:42:50 + schrieb Adam D. Ruppe : On Monday, 5 October 2015 at 07:40:35 UTC, deadalnix wrote: Not on the heap. There are many cases

Re: Go, D, and the GC

On Friday, 9 October 2015 at 07:54:43 UTC, deadalnix wrote: It is also very useful as a safety net. When the object is released, if it still hold handle to scarce resource, it make sense to log and release it, or something similar. That is surely better than running out of the resource and

Re: Go, D, and the GC

Am Mon, 05 Oct 2015 13:42:50 + schrieb Adam D. Ruppe : > On Monday, 5 October 2015 at 07:40:35 UTC, deadalnix wrote: > > Not on the heap. There are many cases where the destructor > > won't run and it is allowed by spec. We should do better. > > To be fair, if you

Re: Go, D, and the GC

On Thursday, 8 October 2015 at 15:58:37 UTC, Marco Leise wrote: Am Mon, 05 Oct 2015 13:42:50 + schrieb Adam D. Ruppe : On Monday, 5 October 2015 at 07:40:35 UTC, deadalnix wrote: > Not on the heap. There are many cases where the destructor > won't run and it is

Re: Go, D, and the GC

Am Mon, 5 Oct 2015 12:22:59 +0300 schrieb Shachar Shemesh : > On 05/10/15 10:01, Dmitry Olshansky wrote: > > >> When D structs has a destructor that is guaranteed to run for any > >> instance that finished construction, no matter what is the use case, > >> then we can have that

Re: Go, D, and the GC

Am Sun, 04 Oct 2015 23:28:47 + schrieb Jonathan M Davis : > On Sunday, 4 October 2015 at 21:41:00 UTC, rsw0x wrote: > > If D has no intentions of aiding the GC, then the GC should > > just be dropped because it's basically just slapping Boehm on > > C++ right now. > >

Re: Go, D, and the GC

On Thursday, 8 October 2015 at 16:25:00 UTC, Marco Leise wrote: Am Sun, 04 Oct 2015 23:28:47 + schrieb Jonathan M Davis : [...] It was probably bad wording. I understood it as D's GC works on a similar basis as Boehm now - conservative, stop the world mark & sweep.

Re: Go, D, and the GC

On 10/08/2015 05:20 AM, Shachar Shemesh wrote: On 07/10/15 12:58, Timon Gehr wrote: Shachar struct S{ @disable this(); @disable enum init=0; } void main(){ S s; // error auto d=S.init; // error } An honest question. Would that also cover all cases where init is being

Re: Go, D, and the GC

On 10/08/2015 06:09 PM, Marco Leise wrote: Am Mon, 5 Oct 2015 12:22:59 +0300 schrieb Shachar Shemesh : On 05/10/15 10:01, Dmitry Olshansky wrote: When D structs has a destructor that is guaranteed to run for any instance that finished construction, no matter what is the use

Re: Go, D, and the GC

On 07/10/15 12:58, Timon Gehr wrote: Shachar struct S{ @disable this(); @disable enum init=0; } void main(){ S s; // error auto d=S.init; // error } An honest question. Would that also cover all cases where init is being used implicitly by the compiler? I will need

Re: Go, D, and the GC

On Wednesday, 7 October 2015 at 14:50:52 UTC, Jonathan M Davis wrote: On Wednesday, 7 October 2015 at 14:13:38 UTC, Meta wrote: On Wednesday, 7 October 2015 at 09:59:05 UTC, Timon Gehr wrote: struct S{ @disable this(); @disable enum init=0; } void main(){ S s; // error auto

Re: Go, D, and the GC

On Wednesday, 7 October 2015 at 18:38:34 UTC, Timon Gehr wrote: On 10/07/2015 04:13 PM, Meta wrote: On Wednesday, 7 October 2015 at 09:59:05 UTC, Timon Gehr wrote: struct S{ @disable this(); @disable enum init=0; } void main(){ S s; // error auto d=S.init; // error } That's

Re: Go, D, and the GC

On 10/05/2015 12:57 PM, Shachar Shemesh wrote: On 05/10/15 13:39, Marc Schütz wrote: On Monday, 5 October 2015 at 09:25:30 UTC, Shachar Shemesh wrote: What's more, init is used even if you @disable this(). The following compile and does what you'd expect (but not what you want): struct S {

Re: Go, D, and the GC

On Wednesday, 7 October 2015 at 14:13:38 UTC, Meta wrote: On Wednesday, 7 October 2015 at 09:59:05 UTC, Timon Gehr wrote: struct S{ @disable this(); @disable enum init=0; } void main(){ S s; // error auto d=S.init; // error } That's just awful. Being able to declare a

Re: Go, D, and the GC

On Wednesday, 7 October 2015 at 09:59:05 UTC, Timon Gehr wrote: struct S{ @disable this(); @disable enum init=0; } void main(){ S s; // error auto d=S.init; // error } That's just awful.

Re: Go, D, and the GC

On 10/07/2015 04:13 PM, Meta wrote: On Wednesday, 7 October 2015 at 09:59:05 UTC, Timon Gehr wrote: struct S{ @disable this(); @disable enum init=0; } void main(){ S s; // error auto d=S.init; // error } That's just awful. I was responding to: The above shows that you

Re: Go, D, and the GC

On 10/07/2015 06:52 PM, Meta wrote: On Wednesday, 7 October 2015 at 14:50:52 UTC, Jonathan M Davis wrote: Being able to declare a member named init is just asking for trouble... https://issues.dlang.org/show_bug.cgi?id=14237 https://issues.dlang.org/show_bug.cgi?id=7066 - Jonathan M Davis

Re: Go, D, and the GC

On Wednesday, 7 October 2015 at 14:50:52 UTC, Jonathan M Davis wrote: Being able to declare a member named init is just asking for trouble... https://issues.dlang.org/show_bug.cgi?id=14237 https://issues.dlang.org/show_bug.cgi?id=7066 - Jonathan M Davis Yeah, no arguments there. This needs

Re: Go, D, and the GC

On 04/10/15 19:14, welkam wrote: On Sunday, 4 October 2015 at 12:40:00 UTC, rsw0x wrote: these tools are not very good and they don't help when the standard library(...or builtin language features...) use the GC and tie your hands IMO tools for memory management in D are way better than that

Re: Go, D, and the GC

On 05-Oct-2015 09:52, Shachar Shemesh wrote: On 04/10/15 19:14, welkam wrote: On Sunday, 4 October 2015 at 12:40:00 UTC, rsw0x wrote: these tools are not very good and they don't help when the standard library(...or builtin language features...) use the GC and tie your hands IMO tools for

Re: Go, D, and the GC

On Monday, 5 October 2015 at 07:01:35 UTC, Dmitry Olshansky wrote: Supposed to be the case for structs except for any bugs. Not on the heap. There are many cases where the destructor won't run and it is allowed by spec. We should do better. Until then, no, D's mechanisms for non-heap

Re: Go, D, and the GC

On 05-Oct-2015 10:40, deadalnix wrote: In C++ you can't - not only self-references are permitted but also there is no T.init so there is no bit-pattern that is guaranteed to not explode in dtor. Guaranteed construct/destruction is actually a desirable feature IMO. You get all kind of extra

Re: Go, D, and the GC

On 05/10/15 10:01, Dmitry Olshansky wrote: When D structs has a destructor that is guaranteed to run for any instance that finished construction, no matter what is the use case, then we can have that discussion. Supposed to be the case for structs except for any bugs. Check this one out

Re: Go, D, and the GC

On 05/10/15 10:40, deadalnix wrote: Guaranteed construct/destruction is actually a desirable feature IMO. You get all kind of extra case int he dtor to care for when you can't ensure proper construction, and it is not always possible to have a meaningful .init value, leading to many useless

Re: Go, D, and the GC

On 05/10/15 10:49, Dmitry Olshansky wrote: Yes and no, if your type is movable in C++ you have to have a T.init equivalent to leave something behind after move (oops!). No, under C++ you can choose whether it makes sense for your type to be movable or not. No oops at all. C++ does not make

Re: Go, D, and the GC

On Sunday, 4 October 2015 at 21:01:45 UTC, Jonathan M Davis wrote: That would be ideal but gets really nasty for a number of reasons - primarily having to do with casting. It's perfectly possible to cast to and from shared and much easier to create something as thread-local and then cast it to

Re: Go, D, and the GC

On 05/10/15 13:39, Marc Schütz wrote: On Monday, 5 October 2015 at 09:25:30 UTC, Shachar Shemesh wrote: What's more, init is used even if you @disable this(). The following compile and does what you'd expect (but not what you want): struct S { int d; @disable this(); this( int d ) {

Re: Go, D, and the GC

On Monday, 5 October 2015 at 10:57:57 UTC, Shachar Shemesh wrote: On 05/10/15 13:39, Marc Schütz wrote: On Monday, 5 October 2015 at 09:25:30 UTC, Shachar Shemesh wrote: What's more, init is used even if you @disable this(). The following compile and does what you'd expect (but not what you

Re: Go, D, and the GC

On Monday, 5 October 2015 at 09:25:30 UTC, Shachar Shemesh wrote: What's more, init is used even if you @disable this(). The following compile and does what you'd expect (but not what you want): struct S { int d; @disable this(); this( int d ) { this.d = d; } } ... S d

Re: Go, D, and the GC

On 05-Oct-2015 12:33, Shachar Shemesh wrote: On 05/10/15 10:49, Dmitry Olshansky wrote: Yes and no, if your type is movable in C++ you have to have a T.init equivalent to leave something behind after move (oops!). No, under C++ you can choose whether it makes sense for your type to be

Re: Go, D, and the GC

On Monday, 5 October 2015 at 07:40:35 UTC, deadalnix wrote: Not on the heap. There are many cases where the destructor won't run and it is allowed by spec. We should do better. To be fair, if you new a struct in C++ and never delete it, the destructor will never run there either. D's in the

Re: Go, D, and the GC

On Monday, 5 October 2015 at 11:41:11 UTC, Marc Schütz wrote: `@disable this();` works fine to prevent the user from doing that accidentally. But in your example, this doesn't happen by accident; you explicitly told the compiler to use the .init value. That's not something you do just because

Re: Go, D, and the GC

On Saturday, 3 October 2015 at 19:01:33 UTC, welkam wrote: D gives users tools to avoid heap allocations and if it is necessary to allocate heap memory you have scoped memory management or ref counting so your GC heap is small or non existent. People fear manual memory management because they

Re: Go, D, and the GC

On Friday, 2 October 2015 at 11:27:12 UTC, Tourist wrote: I know that it has the reputation of being of the simplest kind. Haven't looked at the code actually (and I wouldn't understand much even if I did). Go has a very simple GC itself. It's concurrent, so it trades low latency against

Re: Go, D, and the GC

On Saturday, 3 October 2015 at 07:49:35 UTC, Iain Buclaw wrote: On 2 Oct 2015 1:32 pm, "Tourist via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: On Friday, 2 October 2015 at 06:53:56 UTC, Iain Buclaw wrote: On 1 Oct 2015 11:35 am, "Tourist via Digitalmars-d" <

Re: Go, D, and the GC

On Sunday, 4 October 2015 at 17:22:52 UTC, Martin Nowak wrote: On Friday, 2 October 2015 at 11:27:12 UTC, Tourist wrote: I know that it has the reputation of being of the simplest kind. Haven't looked at the code actually (and I wouldn't understand much even if I did). Go has a very simple

Re: Go, D, and the GC

On Sunday, 4 October 2015 at 12:40:00 UTC, rsw0x wrote: these tools are not very good and they don't help when the standard library(...or builtin language features...) use the GC and tie your hands IMO tools for memory management in D are way better than that of other languages. Game

Re: Go, D, and the GC

On Sunday, 4 October 2015 at 17:30:39 UTC, rsw0x wrote: I still say it's worth investigating a thread-local GC by taking advantage of the fact that shared has never really been properly fleshed out. This would heavily play to D's TLS by default, and preferring message passing over shared data.

Re: Go, D, and the GC

On Sunday, 4 October 2015 at 21:01:45 UTC, Jonathan M Davis wrote: On Sunday, 4 October 2015 at 17:30:39 UTC, rsw0x wrote: I still say it's worth investigating a thread-local GC by taking advantage of the fact that shared has never really been properly fleshed out. This would heavily play to

Re: Go, D, and the GC

On Sunday, 4 October 2015 at 21:41:00 UTC, rsw0x wrote: If D has no intentions of aiding the GC, then the GC should just be dropped because it's basically just slapping Boehm on C++ right now. I don't understand this attitude at all (and you're not the only one to voice it lately). D has a

Re: Go, D, and the GC

On Sunday, 4 October 2015 at 23:28:48 UTC, Jonathan M Davis wrote: D's templates alone blow C++ totally out of the water. - Jonathan M Davis I have to agree here. This is one feature of D that I can't complain about...at all. I honestly can't think of a single issue I have had with D's

Re: Go, D, and the GC

On Friday, 2 October 2015 at 07:32:02 UTC, Kagamin wrote: Low latency (also a synonym for fast) is required by interactive applications like client and server software Isn't a typical collection cycle's duration negligible compared to typical network latency?

Re: Go, D, and the GC

On Saturday, 3 October 2015 at 13:35:19 UTC, Vladimir Panteleev wrote: On Friday, 2 October 2015 at 07:32:02 UTC, Kagamin wrote: Low latency (also a synonym for fast) is required by interactive applications like client and server software Isn't a typical collection cycle's duration negligible

Re: Go, D, and the GC

On Saturday, 3 October 2015 at 18:26:32 UTC, Vladimir Panteleev wrote: On Saturday, 3 October 2015 at 18:21:55 UTC, deadalnix wrote: On Saturday, 3 October 2015 at 13:35:19 UTC, Vladimir Panteleev wrote: On Friday, 2 October 2015 at 07:32:02 UTC, Kagamin wrote: Low latency (also a synonym for

Re: Go, D, and the GC

D gives users tools to avoid heap allocations and if it is necessary to allocate heap memory you have scoped memory management or ref counting so your GC heap is small or non existent. People fear manual memory management because they hear stories about C but for most part it can be easy and

Re: Go, D, and the GC

On Saturday, 3 October 2015 at 18:21:55 UTC, deadalnix wrote: On Saturday, 3 October 2015 at 13:35:19 UTC, Vladimir Panteleev wrote: On Friday, 2 October 2015 at 07:32:02 UTC, Kagamin wrote: Low latency (also a synonym for fast) is required by interactive applications like client and server

Re: Go, D, and the GC

On 2 Oct 2015 1:32 pm, "Tourist via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: > > On Friday, 2 October 2015 at 06:53:56 UTC, Iain Buclaw wrote: >> >> On 1 Oct 2015 11:35 am, "Tourist via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: >>> >>> [...] >> >> good GC. And they keep

Re: Go, D, and the GC

On 1 Oct 2015 11:35 am, "Tourist via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: > > Hi Guys, > > I know that Go invested many time and resources in an implementation of a good GC. And they keep working on it, e.g.

Re: Go, D, and the GC

On Friday, 2 October 2015 at 06:53:56 UTC, Iain Buclaw wrote: On 1 Oct 2015 11:35 am, "Tourist via Digitalmars-d" < digitalmars-d@puremagic.com> wrote: [...] good GC. And they keep working on it, e.g. https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md [...]

Re: Go, D, and the GC

On Friday, 2 October 2015 at 01:21:15 UTC, rsw0x wrote: No, no it's not. Go's GC has a massive overhead because it's intended to have low latency because that's what Go programs typically require. Go's GC is actually pretty slow by design. Low latency (also a synonym for fast) is required by

Re: Go, D, and the GC

On Thursday, 1 October 2015 at 09:33:26 UTC, Tourist wrote: Hi Guys, I know that Go invested many time and resources in an implementation of a good GC. And they keep working on it, e.g. https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md I also see that the

Re: Go, D, and the GC

On Thursday, 1 October 2015 at 09:48:57 UTC, Kagamin wrote: On Thursday, 1 October 2015 at 09:40:09 UTC, Rikki Cattermole wrote: Go's GC would have been optimized for Go's patterns and usage of it. It's JIT, no? which usually gets optimized for patterns, the GC pattern is generic: collect

Re: Go, D, and the GC

On 01/10/15 10:33 PM, Tourist wrote: Hi Guys, I know that Go invested many time and resources in an implementation of a good GC. And they keep working on it, e.g. https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md I also see that the implementation is licensed as

Re: Go, D, and the GC

On 01-Oct-2015 12:33, Tourist wrote: Hi Guys, I know that Go invested many time and resources in an implementation of a good GC. And they keep working on it, e.g. https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md I also see that the implementation is licensed as

Re: Go, D, and the GC

On Thursday, 1 October 2015 at 09:40:09 UTC, Rikki Cattermole wrote: Go's GC would have been optimized for Go's patterns and usage of it. It's JIT, which usually gets optimized for patterns, the GC pattern is generic: collect the garbage and do it fast.

Go, D, and the GC

Hi Guys, I know that Go invested many time and resources in an implementation of a good GC. And they keep working on it, e.g. https://github.com/golang/proposal/blob/master/design/12800-sweep-free-alloc.md I also see that the implementation is licensed as BSD, as far as I see: