Hi everyone, it's been almost a year since I used D but I was wanted to get back into it. I was checking the 2017 vision pages and was wondering why there hasn't been a 2018H1 vision page but also what the current status of being able to use D without a garbage collector is?

It was noted in the H1 and H2 pages for 2017 but looking through the compiler changelog doesn't indicate that we're there yet? https://wiki.dlang.org/Vision/2017H2

Thanks.

On Saturday, 17 February 2018 at 12:18:28 UTC, Peter Campbell wrote:
> I was checking the 2017 vision pages and was wondering why there hasn't been a 2018H1 vision page but also what the current status of being able to use D without a garbage collector is?

There are a number of ways to use D without the garbage collector.  However, one of the easiest is with the -betterC flag.  You'll want to read the two blog articles here (https://dlang.org/blog/category/betterc/) for more information about that.

2.079, the upcoming release will also have a way to use D without the runtime and without -betterC.  What this allows you to do is partially implement just the runtime features you wish to support.  You can read more about it in the nightly changelog here (https://dlang.org/changelog/pending.html#minimal_runtime)

You might also be interested in this article: https://wiki.dlang.org/Memory_Management

Mike

On Saturday, 17 February 2018 at 12:18:28 UTC, Peter Campbell wrote:
> Hi everyone, it's been almost a year since I used D but I was wanted to get back into it. I was checking the 2017 vision pages and was wondering why there hasn't been a 2018H1 vision page but also what the current status of being able to use D without a garbage collector is?
>
> It was noted in the H1 and H2 pages for 2017 but looking through the compiler changelog doesn't indicate that we're there yet? https://wiki.dlang.org/Vision/2017H2
>
> Thanks.

Let me do a bit advertising :) I'm writing a library for @nogc D programming, tanya. It has different aims than -betterC: I use the full set of D features, just except features that require GC. It isn't complete, I'm using it only in personal projects and it is also a big learn project for me, so don't wonder that it reimplements a lot of features "from scratch" and almost doesn't depend on phobos. But if you like to play with it, you're welcome:
https://github.com/caraus-ecms/tanya

On Saturday, 17 February 2018 at 12:18:28 UTC, Peter Campbell wrote:
> Hi everyone, it's been almost a year since I used D but I was wanted to get back into it. I was checking the 2017 vision pages and was wondering why there hasn't been a 2018H1 vision page but also what the current status of being able to use D without a garbage collector is?
>
> It was noted in the H1 and H2 pages for 2017 but looking through the compiler changelog doesn't indicate that we're there yet? https://wiki.dlang.org/Vision/2017H2
>
> Thanks.

The garbage collector in druntime is now lazily initialized on the first use:

https://github.com/dlang/druntime/pull/2057

(in master since a few days)

On Saturday, 17 February 2018 at 12:32:04 UTC, Mike Franklin wrote:
> There are a number of ways to use D without the garbage collector.  However, one of the easiest is with the -betterC flag.  You'll want to read the two blog articles here (https://dlang.org/blog/category/betterc/) for more information about that.
>
> 2.079, the upcoming release will also have a way to use D without the runtime and without -betterC.  What this allows you to do is partially implement just the runtime features you wish to support.  You can read more about it in the nightly changelog here (https://dlang.org/changelog/pending.html#minimal_runtime)
>
> You might also be interested in this article: https://wiki.dlang.org/Memory_Management
>
> Mike

I've read about BetterC and I'm interested in the minimal runtime feature, that seems like it'll be really cool. But these methods requiring not using certain D features which rely on the GC. My understanding from the vision documents and what Andrei mentioned at his DConf presentations is that the runtime itself will be modified to not rely on the GC, allowing for you to continue using features such as associative arrays and array concatenation, but without requiring the garbage collector. Is my understanding correct? If so is work still being done to make this happen and is there an easy way to follow the progress?

On Saturday, 17 February 2018 at 12:44:35 UTC, Eugene Wissner wrote:
> Let me do a bit advertising :) I'm writing a library for @nogc D programming, tanya. It has different aims than -betterC: I use the full set of D features, just except features that require GC. It isn't complete, I'm using it only in personal projects and it is also a big learn project for me, so don't wonder that it reimplements a lot of features "from scratch" and almost doesn't depend on phobos. But if you like to play with it, you're welcome:
> https://github.com/caraus-ecms/tanya

That's an interesting project, I'll be sure to take a look!

On Saturday, 17 February 2018 at 14:25:41 UTC, Seb wrote:
> On Saturday, 17 February 2018 at 12:18:28 UTC, Peter Campbell wrote:
> The garbage collector in druntime is now lazily initialized on the first use:
>
> https://github.com/dlang/druntime/pull/2057
>
> (in master since a few days)

That's really nice to hear 2.079 is looking really cool!

On Saturday, 17 February 2018 at 18:03:44 UTC, Peter Campbell wrote:

> My understanding from the vision documents and what Andrei mentioned at his DConf presentations is that the runtime itself will be modified to not rely on the GC, allowing for you to continue using features such as associative arrays and array concatenation, but without requiring the garbage collector. Is my understanding correct? If so is work still being done to make this happen

Andrei recently said something about an announcement coming, but I don't have any details. https://www.reddit.com/r/programming/comments/7vw0gj/vanquish_forever_these_bugs_that_blasted_your/dtwb6fv/

On Saturday, 17 February 2018 at 19:32:50 UTC, bachmeier wrote:
> On Saturday, 17 February 2018 at 18:03:44 UTC, Peter Campbell wrote:
>
>> My understanding from the vision documents and what Andrei mentioned at his DConf presentations is that the runtime itself will be modified to not rely on the GC, allowing for you to continue using features such as associative arrays and array concatenation, but without requiring the garbage collector. Is my understanding correct? If so is work still being done to make this happen
>
> Andrei recently said something about an announcement coming, but I don't have any details. https://www.reddit.com/r/programming/comments/7vw0gj/vanquish_forever_these_bugs_that_blasted_your/dtwb6fv/

What a tease, but that sounds promising :)

On Saturday, 17 February 2018 at 18:03:44 UTC, Peter Campbell wrote:
> Andrei mentioned at his DConf presentations is that the runtime itself will be modified to not rely on the GC, allowing for you to continue using features such as associative arrays and array concatenation, but without requiring the garbage collector. Is my understanding correct?

I haven't heard anything about that, and I doubt it would happen. How would you actually manage the memory? The front-facing api there doesn't offer any access to it.

But, of course, it is quite easy to write your own types that do the same stuff (including operator overloading, of course) that do expose memory management, and you can use those with or without the runtime.

On Saturday, 17 February 2018 at 23:43:07 UTC, Adam D. Ruppe wrote:
> On Saturday, 17 February 2018 at 18:03:44 UTC, Peter Campbell wrote:
>> Andrei mentioned at his DConf presentations is that the runtime itself will be modified to not rely on the GC, allowing for you to continue using features such as associative arrays and array concatenation, but without requiring the garbage collector. Is my understanding correct?
>
> I haven't heard anything about that, and I doubt it would happen. How would you actually manage the memory? The front-facing api there doesn't offer any access to it.
>
> But, of course, it is quite easy to write your own types that do the same stuff (including operator overloading, of course) that do expose memory management, and you can use those with or without the runtime.

The first time I heard about this was the DConf 2016 keynote: https://www.youtube.com/watch?v=4oDK91E3VKs&feature=youtu.be&t=2023

Andrei discusses a reference counting based approach however there are requirements which make it difficult to implement in the runtime. It's also mentioned in both the 2017 vision documents on the wiki.

On 02/17/2018 07:03 PM, Peter Campbell wrote:
> My understanding from the vision documents and what Andrei mentioned at his DConf presentations is that the runtime itself will be modified to not rely on the GC, allowing for you to continue using features such as associative arrays and array concatenation, but without requiring the garbage collector. Is my understanding correct? If so is work still being done to make this happen and is there an easy way to follow the progress?

@nogc containers will most likely come in the form of a library.
We plan to move built-in hashes to a templated druntime implementation
(https://github.com/dlang/druntime/pull/1282), and at best make array
and hash literal syntax available for user defined types (w/ an
approach similar to C++'s initializer_list).
Our current std.container package does not use the GC
(https://dlang.org/phobos/std_container.html), but isn't really up to
par. Your best options atm. would be
[emsi_containers](http://code.dlang.org/packages/emsi_containers) for
containers and [automem](http://code.dlang.org/packages/automem) for
smart pointers.
Both libraries support custom allocators
(https://dlang.org/phobos/std_experimental_allocator.html).
Writing containers and smart pointers isn't rocket science, so it's
the least of our worries.

While heading for @nogc we've decided that we don't want to give up
@safe-ty (remember that GC based allocations don't suffer from memory
corruptions).
Walter has spent a lot of effort on preventing escaping of aliases
(DIP1000).
I'm currently working on a proposal (DIP) and implementation called
"limited lifetimes" that is targeted at preventing use-after-free bugs
at compile time without impeding usability too much.
We hopefully will have at least a prototype implementation for this
year's DConf in May.
This should become the foundation for `@safe @nogc` RC/Uniq/Weak
primitives, onto which we can layer `@safe @nogc` libraries.

In parallel Andrei and his students are investigating alternative approaches to reduce GC overhead or prevent use-after-free errors at runtime.

We've somewhat stopped to work on our GC, to focus on unique/ref-counted memory management. Though soon the GC implementation can be replaced with custom GCs from our package manager dub (https://github.com/dlang/druntime/pull/1924). This should open the door for low-latency GCs, based on CoW and dirty page flags. We don't want to add write-barriers to the language due to the ~5% overall slowdown, so generational GCs are out of reach, but there is an interesting paper on using type information to perform partial collections ([Connectivity-Based Garbage Collection](https://www.cs.purdue.edu/homes/hosking/690M/cbgc.pdf)).

At the moment there is no good way to track progress, as a lot is
being worked on behind the scenes by many distributed actors.
I think we are the ones most annoyed that this transition takes so
long, but our plans are also very ambitious, targeting minimal memory
footprint, optimal performance while supporting a @safe language
subset and advanced features like custom allocators or region based
allocations.

- -Martin