Pitching D to a gang of Gophers

[Dmitry Olshansky via Digitalmars-d]

On 05-Mar-2016 20:17, Chris Wright wrote:
> 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.

All true. In fact I've been worried that D may look like just another C# 
with a bit different set of trade-offs. Like native code C/C++ inter-op 
friendly C# with strong compile-time meta-programming capabilities.

Keeping in mind that folks sometimes are just fine with run-time 
meta-programming as in being able to use compiler as a library...

> Things I might talk about:
>
> Interacting with the fiber scheduler explicitly. Goroutines are
> hermetically sealed. D Fibers are much more open.

Interacting with scheduler directly is a type code these folks would 
LOVE to avoid. And looking at in-house library I can wholeheartedly 
agree, there is just not enough system-level expertise to meaningfully 
use this kind of control.

>   * 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?

Most likely the answer would - why should I. And indeed for the most 
purposes of a web-service there is rarely a good need for it.

> 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.
>

However the opposite is also bad - in D you need to re-implement ALL of 
network/IO libraries from scratch to use async+fibers like e.g. vibe.d. 
Our famous C/C++ interop actually hurts us in this case because it's 
TRIVIAL to stumble on a blocking call in a fiber via some 3rd party library.

> 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.

Working with JSON could be an interesting example as Go's solution 
involves lots of type-casting when working with dynamic structure.

> 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.

I count a lot of these, mostly all of them have to do with the fact that 
writing anything non-bogus by default requires great discipline to write 
highly repetitive non-trivial patterns. For instance, channels are 
awkwardly non-composable low-level primitives that are easy to get wrong 
in so many ways.

> There's a giant list of them, and D doesn't give a
> specific advantage.


-- 
Dmitry Olshansky