On Mon, 2016-06-06 at 18:03 +0000, Ola Fosheim Grøstad via Digitalmars- d wrote: > […] > GC in Go is not an issue, because in Go the concurrent GC is > basically what it has to offer in addition to builtin decent HTTP > and cloud-server adoption.
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. The crucial difference the full time Go developers did something. D appears to not have that rather crucial resource. > GC is Go would have been a big big issue if Go was not designed > for it or tried to present itself as a system level programming > language. Go was always, and always will be a GC language, very true. 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. Which is why D has no problem with being a GC language. > For performance you would still not use Go, you would use either > C++ or Rust. But few servers in the cloud need those extra 20%. Go has blossomed due to the Web niche but it is used elsewhere. If C++ and Rust can only offer 20% improvement they are dead in the water. I am sure that by appropriate adjustment to the number of processors a well designed Go program can go far faster that 20% faster. The CSP emphasis of Go application design is a wonderful thing. Now I can use Kotlin+Quasar as well as Groovy+GPars to push this same message. Sadly D doesn't yet have an equivalent so therefore has a problem. I would love to create a CSP thing for D but I cannot give the time to do this on my own. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:[email protected] 41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected] London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
