I come back to this forum I read a long time ago, because after having used Go for several projects, I've recently switched to D, and I wanted to share my opinion on it.
First, if I can make a caricatural comparison, i'd like to say that to me, Go is just a "much better C", while D is instead a "much better C++". I mean, like Go, D has also an incredibly fast compilation, a GC, and it provides very convenient maps, arrays, strings, slices, foreach, ranges, concurrency, etc, all at the language level. But D also gives you reference classes, genericity, function polymorphism, conditional compilation, design by contract assertions, compile-time meta programming, and many other features that are severely lacking in Go. Moreover, with D you can really go low-level like in C if you need to. It *also* has C-like pointers, structs, inline assembly, etc, if you want to use C or C++ functions and data structures without wrapper code. Finally, what's really nice is that D provides all these features through a very simple, classic and convenient syntax, which make it quite easy to port your code from C, C++, Java, C#, Go, etc. Of course, Go, as a web-centric language, has obviously a much more complete standard library when it comes to web development. So if you want to interact with servers, databases and anything like that, Go may remain the best alternative. But for your command line or desktop developments, I think D could be much more appropriate than Go... On Friday, October 11, 2013 at 9:54:23 PM UTC+1, Rohit Yadav wrote: > > Hi, > > Since the last active message on this thread a lot of progress was > achieved by both the projects, would anyone like to share latest > comparisons between the two languages and the ecosystem around it (tooling, > usage, adoption, etc.)? > We see that Go is nowadays used for not just writing servers but general > programs as well, how does D scale to that and if Andrei and others can > update us on D with respect to areas where Go excels such as ease of > writing concurrent software, tooling, ease of learning the language and its > hackability. > > Regards, > Rohit > > On Saturday, 14 August 2010 06:09:36 UTC+5:30, Andrei Alexandrescu wrote: >> >> On Aug 13, 3:00 pm, Ian Lance Taylor <i...@google.com> wrote: >> > Andrei Alexandrescu <iro...@gmail.com> writes: >> > >http://www.informit.com/articles/printerfriendly.aspx?p=1609144 >> > >> > Thanks. As you know, this approach is clearly different from the one >> in >> > Go, which is a transfer of ownership model, where the transfer of >> > ownership is enforced only by convention. And, of course, Go doesn't >> > use the type system, which follows Go's general guideline of keeping >> the >> > type system light weight. >> >> I understand. So what we have now is: >> >> (1) Pass-by-bitblt through channels for value types (i.e. no >> indirections, which means dynamic arrays are unduly shared). There is >> no checking that a value type being passed actually does not have >> indirections. >> >> (2) Pass of ownership by unchecked convention for data with >> indirections. >> >> (3) Everything else is undefined. >> >> If that's true, parts 1 and 2 are of limited expressiveness but it's >> part 3 that's really problematic, and I'm not sure a putative >> programmer understands the implications. Essentially that means even >> lock-based programming relies on implementation-level vagaries because >> without a memory model the compiler and the processor are relatively >> free to hoist data around rather freely. We're back to the reorderings >> hell often showcased as motivators of Java's and C++0x's memory >> models. >> >> > >> You're quite right: Go does permit data races, and does currently >> rely >> > >> only on convention to avoid them. Go's advantage over C++, and it >> is a >> > >> significant advantage, is that the rules for valid sharing are >> fairly >> > >> simple, and the language makes it much easier to do valid sharing. >> > >> > > How does Go simplify the rules for valid sharing? Far as I can tell >> it >> > > can only simplify if it renders undue aliasing undefined. Does Go >> have >> > > something equivalent to Java's volatile and C++0x's atomic? >> > >> > The rules for valid sharing are encapsulated in the slogan "don't >> > communicate by sharing memory; instead, share memory by communicating." >> > That is, always use channels to communicate between goroutines. Always >> > ensure that a single goroutine owns shared data, and use an explicit >> > channel send to transfer ownership to a different goroutine. >> > >> > This approach can be used in other languages also, of course; the >> > advantage I see in Go is that the language makes it simple and easy. >> >> A memory model may as well be the perfect example where simplicity is >> your enemy - not defining one is indeed simple, but has huge costs to >> the user in one or more of correctness, portability, safety, >> expressiveness, and efficiency. >> >> So essentially (again I'm basing this on inference from what I've read >> on golang.org and this discussion) one must only use the patterns (1) >> and (2) in concurrent code. This severe limitation further erodes Go's >> capabilities when compared to C, and I think it's reasonable that I >> find Go's offering severely wanting for serious concurrent work. >> >> >> Andrei >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
