On Monday, 18 August 2014 at 23:48:24 UTC, Ary Borenszweig wrote:
> On 8/18/14, 8:51 AM, bearophile wrote:
>> Jonathan M Davis:
>>
>>> The biggest reason is memory safety. With a GC, it's possible to make
>>> compiler guarantees about memory safety, whereas with
>>> manual memory management, it isn't.
>>
>> Unless you have a very smart type system and you accept some compromises
>> (Rust also uses a reference counter some some cases, but I think most
>> allocations don't need it).
>>
>> Bye,
>> bearophile
>
> It's very smart, yes. But it takes half an hour to compile the compiler itself.

The compilation speed is caused by the C++ code in their compiler backend (LLVM), which gets compiled at least twice during the bootstraping process.

> And you have to put all those unwrap and types everywhere, I don't think it's fun or productive that way.


There I fully agree. If they don't improve lifetime's usability, I don't see Rust being adopted by average developers.

--
Paulo

On Monday, 18 August 2014 at 18:56:42 UTC, b wrote:
>
>  Besides that, in C++ it works like this.
>  90% of objects: value types, on stack or embedded into other objects
>  9% of objects: unique types, use unique_ptr, no overhead
>  ~1% of objects: shared, use shared_ptr/weak_ptr etc.
>
>  With GC you give up deterministic behavior, which is *absolutely* not worth giving up for 1% of objects.
>
>  I think most people simply haven't worked in an environment that supports unique/linear types. So everyone assumes that you need a GC. Rust is showing that this is nonsense, as C++ has already done for people using C++11.

I work in such an environment and I tend to agree with you. We use a combination of std::unique_ptr and raw pointers as weak ref. It works without hiccup even though people have to ensure manually that lifetimes of owners exceed lifetime of borrowers. A problem with scoped ownership is that it makes the pointer know about the lifetime, and that forces to give up type-safety a bit to write function taking any pointer type.

In D having deterministic resource release is harder because scoped ownership is less polished than in C++.

On Monday, 18 August 2014 at 18:56:42 UTC, b wrote:
>  Not really accurate. First of all, don't include unique_ptr as if it had the same overhead as the other two, it doesn't.

It's still scope guarded, which is not zero cost in sjlj and win32 seh exception models. It also injects (inlines?) cleanup code everywhere, which wastes cache.

>  With RC you pay a price during creation/deletion/sharing, but not while it is alive.
>  With GC you pay almost no cost during allocation/deletion, but a constant cost while it is alive. You allocate enough objects and the sum cost ant so small.

Quite the contrary: with RC creation and deletion should be cheaper because they don't scan whole memory, using the object is more expensive, because you need to track it always. With GC you pay the cost when collection runs, and it doesn't necessarily runs always.

>  Besides that, in C++ it works like this.
>  90% of objects: value types, on stack or embedded into other objects
>  9% of objects: unique types, use unique_ptr, no overhead
>  ~1% of objects: shared, use shared_ptr/weak_ptr etc.

Aren't strings inherently shared? Do you think they account for only 1% of objects?

>  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?

On Tue, 19 Aug 2014 07:14:17 +0000
ponce via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> I work in such an environment and I tend to agree with you.
just replace GC with stub doing only allocs (or use GC.disable) and
manage resource freeing manually (or with corresponding templated
struct wrappers).

> In D having deterministic resource release is harder because scoped ownership is less polished than in C++.
but why?! see 'scoped' to scope allocations. and, for example, 'File', which is refcounted internally. plus 'scope()' finalizers.

i'm pretty sure that scoped ownership in D at least on par with C++, if not better and simplier either to write, to read and to use.

of course, you'll loose such nice features as closures and slices, but hey, C++ doesn't have them too! ok, C++11 has lambdas, and i don't know if D lambdas can work without GC and don't leak.

On Tuesday, 19 August 2014 at 07:26:07 UTC, ketmar via Digitalmars-d wrote:
> but why?! see 'scoped' to scope allocations. and, for example, 'File',
> which is refcounted internally. plus 'scope()' finalizers.
>
> i'm pretty sure that scoped ownership in D at least on par with C++, if
> not better and simplier either to write, to read and to use.
>
> of course, you'll loose such nice features as closures and slices, but
> hey, C++ doesn't have them too! ok, C++11 has lambdas, and i don't know
> if D lambdas can work without GC and don't leak.

I'm well aware of all that exist to do deterministic destruction.
There is no _composable_ way to do it apart from using structs exclusively and RefCounted!.
I can't find the previous thread about this but there was problems, eg. Unique should work with both classes and structs but does not.

On Tue, 19 Aug 2014 10:24:07 +0000
ponce via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

seems that i misunderstand you. sorry.

On 8/19/14, 3:50 AM, Paulo Pinto wrote:
> On Monday, 18 August 2014 at 23:48:24 UTC, Ary Borenszweig wrote:
>> On 8/18/14, 8:51 AM, bearophile wrote:
>>> Jonathan M Davis:
>>>
>>>> The biggest reason is memory safety. With a GC, it's possible to make
>>>> compiler guarantees about memory safety, whereas with
>>>> manual memory management, it isn't.
>>>
>>> Unless you have a very smart type system and you accept some compromises
>>> (Rust also uses a reference counter some some cases, but I think most
>>> allocations don't need it).
>>>
>>> Bye,
>>> bearophile
>>
>> It's very smart, yes. But it takes half an hour to compile the
>> compiler itself.
>
> The compilation speed is caused by the C++ code in their compiler
> backend (LLVM), which gets compiled at least twice during the
> bootstraping process.

Actually, it's 26m to just compile Rust without LLVM. Take a look at this:

https://twitter.com/steveklabnik/status/496774607610052608

Then here someone from the team says he can't say a way to improve the performance by an order of magnitude:

https://www.mail-archive.com/rust-dev@mozilla.org/msg02856.html

(but I don't know how true is that)

>
>> And you have to put all those unwrap and types everywhere, I don't
>> think it's fun or productive that way.
>
>
> There I fully agree. If they don't improve lifetime's usability, I don't
> see Rust being adopted by average developers.

This. But maybe programming in a safe way is inherently hard? Who knows...

"Ary Borenszweig"  wrote in message news:lsviva$2ip0$1@digitalmars.com...

> Actually, it's 26m to just compile Rust without LLVM. Take a look at this:

Funny, the DDMD frontend compiles in ~6 seconds. 

On 8/19/14, 10:55 AM, Daniel Murphy wrote:
> "Ary Borenszweig"  wrote in message news:lsviva$2ip0$1@digitalmars.com...
>
>> Actually, it's 26m to just compile Rust without LLVM. Take a look at
>> this:
>
> Funny, the DDMD frontend compiles in ~6 seconds.

Nimrod's compiler takes 5 second. Crystal takes 6 seconds. I think compiling ldc2 also takes about the same time.

When I compile librustc with Rust with stats on, it takes 1.1 seconds to just *parse* the code. I think there's something very bad in their code...

On 8/18/14, 11:50 PM, Paulo Pinto wrote:
> On Monday, 18 August 2014 at 23:48:24 UTC, Ary Borenszweig wrote:
>> On 8/18/14, 8:51 AM, bearophile wrote:
>>> Jonathan M Davis:
>>>
>>>> The biggest reason is memory safety. With a GC, it's possible to make
>>>> compiler guarantees about memory safety, whereas with
>>>> manual memory management, it isn't.
>>>
>>> Unless you have a very smart type system and you accept some compromises
>>> (Rust also uses a reference counter some some cases, but I think most
>>> allocations don't need it).
>>>
>>> Bye,
>>> bearophile
>>
>> It's very smart, yes. But it takes half an hour to compile the
>> compiler itself.
>
> The compilation speed is caused by the C++ code in their compiler
> backend (LLVM), which gets compiled at least twice during the
> bootstraping process.

Generally speaking how fast is the Rust compiler at compiling Rust files?

>> And you have to put all those unwrap and types everywhere, I don't
>> think it's fun or productive that way.
>
>
> There I fully agree. If they don't improve lifetime's usability, I don't
> see Rust being adopted by average developers.

Could you please substantiate this with a couple of examples?


Andrei