Discussion on Go and D

[Alex Rønne Petersen]

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.

-- 
- Alex