On Thursday, 15 October 2015 at 08:11:20 UTC, Kagamin wrote:
> On Thursday, 15 October 2015 at 06:36:32 UTC, logicchains wrote:
>> Even if it's not entirely logical, all these unfinished aspects can add up to produce a less positive aesthetic impression of the language compared to a language that comes across as more polished.
>
> If go is finished, why there's activity in its repository?

I agree with logicchains. The impression people have is exactly this. Go = neat and tidy, D = mess. This has nothing to do with whether Go is actually finished and tidy or not. Go also appeals to people, because it is highly prescriptive and leaves no room for doubt "You do it like this, because we think it's the best way to do it! Full stop." Weird, but this appeals to people.

On 10/15/15 11:11 AM, Kagamin wrote:
> On Thursday, 15 October 2015 at 06:36:32 UTC, logicchains wrote:
>> Even if it's not entirely logical, all these unfinished aspects can
>> add up to produce a less positive aesthetic impression of the language
>> compared to a language that comes across as more polished.
>
> If go is finished, why there's activity in its repository?

I would agree that we're less polished than Go and other languages. This is something we need to work on - just show the world a completely defined and implemented language. -- Andrei

On Thursday, 15 October 2015 at 10:24:34 UTC, Andrei Alexandrescu wrote:
> On 10/15/15 11:11 AM, Kagamin wrote:
>> On Thursday, 15 October 2015 at 06:36:32 UTC, logicchains wrote:
>>> Even if it's not entirely logical, all these unfinished aspects can
>>> add up to produce a less positive aesthetic impression of the language
...
> I would agree that we're less polished than Go and other languages. This is something we need to work on - just show the world a completely defined and implemented language. -- Andrei

I'd like to see a roadmap, covering some of the pain points that logicchains brought up. It'd be nice to look at it, and get the impression that those issues will be resolved within an estimated time period; mainly around GC and ref.

On Thursday, 15 October 2015 at 18:38:38 UTC, Charles Pritchard wrote:
> On Thursday, 15 October 2015 at 10:24:34 UTC, Andrei Alexandrescu wrote:
>> On 10/15/15 11:11 AM, Kagamin wrote:
>>> On Thursday, 15 October 2015 at 06:36:32 UTC, logicchains wrote:
>>>> Even if it's not entirely logical, all these unfinished aspects can
>>>> add up to produce a less positive aesthetic impression of the language
> ...
>> I would agree that we're less polished than Go and other languages. This is something we need to work on - just show the world a completely defined and implemented language. -- Andrei
>
> I'd like to see a roadmap, covering some of the pain points that logicchains brought up. It'd be nice to look at it, and get the impression that those issues will be resolved within an estimated time period; mainly around GC and ref.

Making a roadmap when you don't have people you pay to stick to it doesn't really work. It's like trying to transport frogs using a wheelbarrel.

On Thursday, 15 October 2015 at 19:16:08 UTC, deadalnix wrote:
> Making a roadmap when you don't have people you pay to stick to it doesn't really work. It's like trying to transport frogs using a wheelbarrel.

s/barrel/barrow/

On Thursday, 15 October 2015 at 09:09:22 UTC, Chris wrote:
> I agree with logicchains. The impression people have is exactly this. Go = neat and tidy, D = mess. This has nothing to do with whether Go is actually finished and tidy or not.

The core Go language specification is finished, implemented and fully supported on Google App Engine, just like Java and Python. That is a strong signal for Go being production ready.

The fact that they continue optimizing the runtime and backend is another matter.

On Thursday, 15 October 2015 at 10:24:34 UTC, Andrei Alexandrescu wrote:
> I would agree that we're less polished than Go and other languages. This is something we need to work on - just show the world a completely defined and implemented language. -- Andrei

Hello Andrei. A bit off-topic, but,
you are on that now, right? I saw in the media you
left Facebook to do D things and manage the D foundation.

As a proficient C++ coder for many years, but not as much as you :),
this was kind of the news of the year for me. I expect a push to the
language.

I have had high hopes for D, but C++ is also improving. I took a look at Nim and
Rust. I think D is more practical for real use at this point.
Though, did not try myself on a real scenario, I always end up choosing C++
for my taks because it has great support.

My main concerns to changing to D are:

- Garbage collector. I think there was a plan for Phobos without GC, but...
what about the run-time, can be disabled? I am not sure this meets the
requirements of some embedded devices I work/have worked with.
- Memory-control: Allocators. I saw this has been solved.
- Production-readiness: when I go to C++, the ecosystem is simply unbeatable.
This keeps me away from moving to D.
- Platform support: For C++, I can use it in phones, embedded, PCs... basically
everywhere.
What areas are considered "incomplete" as of now to consider D a production-ready product, in your opinion?


As a long-term C++ user, I understand D quite well but did not try it a lot
for real world use. The standard library
looks very good to me, though, I do not know how much it relies on GC at this
point. Something that, in C++, I do not need to worry about.

On Friday, 16 October 2015 at 08:03:06 UTC, German Diago wrote:
> [...]

Just a small note FYI, there's an easy way to get a feel for the current state of GC reliance:

void main() @nogc
{
    // try stuff out
}

On Thursday, 15 October 2015 at 09:09:22 UTC, Chris wrote:
> I agree with logicchains. The impression people have is exactly this. Go = neat and tidy, D = mess.

Do people have the same impression from generic code in Go?

On Friday, 16 October 2015 at 08:11:18 UTC, John Colvin wrote:
> On Friday, 16 October 2015 at 08:03:06 UTC, German Diago wrote:
>> [...]
>
> Just a small note FYI, there's an easy way to get a feel for the current state of GC reliance:
>
> void main() @nogc
> {
>     // try stuff out
> }

Thanks for the tip. Is this 100% reliable?