Pitching D to a gang of Gophers

[Chris Wright via Digitalmars-d]

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.