Discussion on Go and D

[deadalnix]

Le 09/04/2012 02:24, Alex Rønne Petersen a écrit :
> On 09-04-2012 02:18, Manu wrote:
>> On 9 April 2012 02:24, Walter Bright <newshound2 at digitalmars.com
>> <mailto:newshound2 at digitalmars.com>> wrote:
>>
>> On 4/8/2012 3:57 PM, Manu wrote:
>>
>> What do you base that statistic on? I'm not arguing that fact,
>> just that I
>> haven't seen any evidence one way or the other. What causes Go
>> to create
>> significantly more garbage than D? Are there benchmarks or test
>> cases I should
>> be aware of on the topic?
>>
>>
>> The first ycombinator reference is a person who didn't run out of
>> memory using D. That implies far less pressure on the gc.
>>
>> My understanding of Go is that when it does structural conformance,
>> it builds some of the necessary data at runtime on the gc heap.
>>
>> Anyhow, D has a lot of facilities for putting things on the stack
>> rather than the heap, immutable data doesn't need to get copied, and
>> slices allow lots of reuse of existing objects.
>>
>>
>> "optimized D was slightly faster than Go at almost anything and consumed
>> up to 70% less memory"
>> Interesting... I don't know enough about Go to reason that finding, I
>> guess I assumed it has most of the same possibilities available to D.
>> (no immutable data? no stack structs? no references/pointers/slices?
>> crazy...)
>>
>> The only D program I have significant experience with is VisualD, and it
>> hogs 1-2gb of ram for me under general usage, and eventually crashes,
>> after paging heavily and bringing my computer to a crawl. Not a good
>> sign from the first and only productive D app I've run yet ;)
>> This seems a lot like his experience with Go... but comparisons aside, D
>> still clearly isn't there yet when it comes to the GC either, and I'm
>> amazed Google thing Go is production ready if that guys findings are
>> true!
>
> Google likes to invent random useless languages. See: Dart. Both
> languages are solutions looking for problems. ;)
>
> And yes, precise GC is more essential than most people think.
>

I posted some an article about that. 64bits pretty much solve the false 
positive problem.

Still, precise GC is nice, but alternative like precise on heap and 
imprecise on stack are very valid alternatives.