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.
