Andrei's list of barriers to D adoption

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 7 June 2016 at 09:29:35 UTC, Russel Winder wrote:
> That is the current state after 7 years of development, and at 
> least three GCs. The arguments about GCs in the Go mailing list 
> were almost similar to those in these D mailing lists.

It probably was. I only followed those mailing lists when Go was 
first launched and people didn't complain then, but they 
complained about lacking exceptions and non-null pointers.

I knew Go users complained about GC performance after some time 
(when trying to use it in production), but I didn't know they 
complained about having a GC?

> However it is, and always has been, emphasized as a systems 
> programming language. Their "strap line" is effectively that GC 
> is not a problem for systems programming. And they are right.

They initially said it was a systems programming language, but 
they later turned around and said it isn't and isn't trying to 
be. Go is a high level language, it does not try to give unbiased 
access to hardware semantics. So it cannot be considered a system 
level language. I am not even sure if Rust fully qualifies atm.


> Which is why D has no problem with being a GC language.

Well... that remains unproven. :-) And I don't agree.

> If C++ and Rust can only offer 20% improvement they are dead in 
> the water.

I meant that by not having a GC C++ can get approx 20% 
improvement over Go with the same code as the Go code by writing 
idiomatic. There is also overhead when making system calls and 
also C-calls in Go, thanks to the GC.

That said, in the cloud it makes a lot of sense to not use a 
system level language and use a high level "virtual" environment 
so that you can upgrade hardware without affecting the behaviour 
of services.

If Go was positioned as a system level language it would be dead.


> I would love to create a CSP thing for D but I cannot give the 
> time to do this on my own.

I don't use CSP in Go... The only thing I care about regarding Go 
is: high level (not particularly hardware dependent), GC, http, 
significantly faster than Python for web-servers, AppEngine 
support and good searchable online documentation (traction).

If Go was a system level language I would not consider using it 
actually and I am only starting to adopt it, very very slowly, as 
Python still have many advantages over Go in production. I am 
never going to use Go for something I couldn't do with Python.

So to me C++ and Go have disjunct application areas. Rust and D 
mostly are in the C++ domain, with a little bit more overlap with 
Go than C++, but not much.

That said, if the basic simplicity-oriented design philosophy in 
D1 had been refined, then D could have taken on Go. As it stands, 
I don't think D can without making very radical  changes to the 
language.