In regards to this article https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/

I have a couple of questions,

1. I was wondering if this is going to make D lang just as complicated as Rust?
2. Would there be GC still if we use the ownership model?

On Saturday, 14 November 2020 at 05:33:24 UTC, joe wrote:
> 2. Would there be GC still if we use the ownership model?

The garbage collector is not going away. For much (most?) user-space code, the benefits of GC far outweigh its down sides.

The ownership model is primarily intended to benefit soft real-time applications, such as games, audio playback, operating systems, or very high performance web servers. If you're not writing code like this which requires low and consistent latency, then you can and probably should just go on using the garbage collector.

On 11/13/20 9:33 PM, joe wrote:
> In regards to this article https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/
> 
> I have a couple of questions,
> 
> 1. I was wondering if this is going to make D lang just as complicated as Rust?
> 2. Would there be GC still if we use the ownership model?

I don't know whether he will cover those questions but Walter Bright's DConf Online 2020 keynote is on that topic:

  https://dconf.org/2020/online/index.html

Ali

On Saturday, 14 November 2020 at 06:56:30 UTC, tsbockman wrote:
> On Saturday, 14 November 2020 at 05:33:24 UTC, joe wrote:
>> 2. Would there be GC still if we use the ownership model?
>
> The garbage collector is not going away. For much (most?) user-space code, the benefits of GC far outweigh its down sides.
>
> The ownership model is primarily intended to benefit soft real-time applications, such as games, audio playback, operating systems, or very high performance web servers. If you're not writing code like this which requires low and consistent latency, then you can and probably should just go on using the garbage collector.

Can I replace the GC model with the ownership model?

On Saturday, 14 November 2020 at 08:36:56 UTC, joe wrote:
> On Saturday, 14 November 2020 at 06:56:30 UTC, tsbockman wrote:
>> On Saturday, 14 November 2020 at 05:33:24 UTC, joe wrote:
>>> 2. Would there be GC still if we use the ownership model?
>>
>> The garbage collector is not going away. For much (most?) user-space code, the benefits of GC far outweigh its down sides.
>>
>> The ownership model is primarily intended to benefit soft real-time applications, such as games, audio playback, operating systems, or very high performance web servers. If you're not writing code like this which requires low and consistent latency, then you can and probably should just go on using the garbage collector.
>
> Can I replace the GC model with the ownership model?

Certain D features *few of them actually) are built with GC code so you can't swap them out. Unless there is a no-GC third-party alternative library you can plug in and use.

See https://dlang.org/blog/the-gc-series/

On Saturday, 14 November 2020 at 12:00:32 UTC, aberba wrote:
> On Saturday, 14 November 2020 at 08:36:56 UTC, joe wrote:
>> Can I replace the GC model with the ownership model?
>
> Certain D features *few of them actually) are built with GC code so you can't swap them out. Unless there is a no-GC third-party alternative library you can plug in and use.

None of the D features that require the GC are essential; all can be replaced by alternative techniques, although *some* are more complex and error-prone. The only thing that can't be done without the D GC, is interfacing with library code that assumes its availability.

Given that D can interface with C libraries (and some C++) rather easily, there really are no show-stoppers for @nogc D. It's just extra work to get it right, and shouldn't be done without a good reason.

On 11/13/2020 9:33 PM, joe wrote:
> In regards to this article https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/
> 
> I have a couple of questions,
> 
> 1. I was wondering if this is going to make D lang just as complicated as Rust?

Good question. That remains to be seen. In any case, you can use O/B on a function-by-function basis, you don't need to redesign and rewrite anything.

> 2. Would there be GC still if we use the ownership model?

Yes, though you wouldn't bother using @live functions if you used the GC. There's be no point.

On 15/11/2020 10:09 PM, Walter Bright wrote:
> On 11/13/2020 9:33 PM, joe wrote:
>> 2. Would there be GC still if we use the ownership model?
> 
> Yes, though you wouldn't bother using @live functions if you used the GC. There's be no point.

If you could turn on @live for specific variables, then there would be a point.

System resources (especially windowing related) absolutely needs a way to guarantee destruction and prevent moving a window ownership to another thread.

On Sunday, 15 November 2020 at 09:09:56 UTC, Walter Bright wrote:
>> 2. Would there be GC still if we use the ownership model?
>
> Yes, though you wouldn't bother using @live functions if you used the GC. There's be no point.

I thought @live can avoid refs count with regard to resource management, and still get deterministic destruction. That would be valuable even if there is a gc around.

On Saturday, 14 November 2020 at 05:33:24 UTC, joe wrote:
> In regards to this article https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/
>
> I have a couple of questions,
>
> 1. I was wondering if this is going to make D lang just as complicated as Rust?
> 2. Would there be GC still if we use the ownership model?

I can't answer your questions, but I can offer some observations based on my experience porting a personal finance application, originally written in C, to Rust (about 10,000 lines of code).

I am retired from a long career in software development and project management. I wrote my first line of code 60 years ago. I have learned a lot of programming languages during all those years and I have never encountered anything as difficult to learn and use as Rust. Haskell is a walk in the park compared to Rust. Rust does what they say it will do -- deliver memory-safety without a garbage collector. But the incremental price you, the programmer, must pay for the absence of a GC is significant.

Consideration of Rust require careful cost-benefit analysis. If you are about to write something that requires absolutely predictable latency, where you would normally reach for something like C or C++, then Rust is probably a better choice (I'm ignoring the issue of deadlines and whether you already know the language). They have done an excellent job, given the design constraints they have chosen.

But if you are writing an ordinary application, such as my financial application, Rust is not appropriate, in my view (I suspected that going in, but I'm retired and also a bit of a programming language enthusiast, so I went ahead despite my doubts; had I been doing this in the real world of business, I like to think that the project manager part of me would have done something more sensible).

I don't know exactly how Walter intends to proceed with adding Rust-like move semantics to D, but the little I know suggests that it will be optional. If I'm right, that's very wise. Move semantics and no GC for those who really need it (justifying its cost) and the luxury of the GC for those who don't.