On Sat, 05 Mar 2016 14:05:09 +0300, Dmitry Olshansky wrote: > What features you'd highlight to enterprise-ish user?
Go isn't bad from an enterprise perspective -- it's better than D, in fact. Go has a major company heavily invested in it, and a number of other companies are supporting it. D is much more programmer-friendly, and that's where it tends to shine. C# is close enough that there's no order-of-magnitude difference, plus it's got corporate support, so for an enterprise crowd I'd sooner recommend it. Things I might talk about: Interacting with the fiber scheduler explicitly. Goroutines are hermetically sealed. D Fibers are much more open. * Need fiber-local storage? Subclass Fiber and you're a cast away from it. Need goroutine-local storage? There's a library for it, but it's a terribly ugly hack. * Need to shut down a goroutine and stop it from running? You have to have it explicitly check in every location another goroutine might want to stop it, and it's not a trivial check either. Plus you need to propagate a channel down the stack somehow. In D, it's almost trivial to stop a Fiber. * Need to schedule things precisely? Impossible. You can sleep, or you can wait on IO, but that's it. You can't rate-limit an operation, or add thread affinity so one set of goroutines is reliably scheduled independently of another. In D, you can implement all of that. Templates vs interface{}. interface{} is nice to have sometimes, and we've got std.variant for those times. But almost always we want actual type safety and not to put casts everywhere. Better control over the garbage collector. You can prevent collections from running in D and have the compiler enforce non-usage of the GC. Then there are all the ways in which Go deviates from standard practices and gets things wrong. There's a giant list of them, and D doesn't give a specific advantage.