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
