www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Pitching D to a gang of Gophers

reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
I'm having an opportunity to do a small tech-talk on things D in a 
eCommerce shop that is currently sold on Go (migrating to SOA from PHP 
monolith). I do not intend that to become Go vs D battle but it gives 
the context.

What guys seem to like of Go from my observation:
- goroutines instead of direct asynchronous programming*
- fast runtime with state of the art GC
- host of ready-made libraries esp. http & networking**
- lightweight OOP that doesn't get in your way
- tooling, tooling, tooling (IDE plugins and build tools work great)

*Note: all of standard I/O is transparently handled with goroutines much 
like vibe.d but goroutines are migrating across thread pool
** That being said there are tons of 1-man projects of dubious quality,

So far I'd thought of a few big themes:
- little nice things (slices/maps, things like 1_000_000 and e.g. a < b 
&& d < e is parse error, UFCS)
- code reuse (templates & ranges, with examples like generic min and 
some algo)
- compile-time works (CTFE, need simpler example then regex)

I'm still pondering whether I should dive into UDA, I'd try to stay 
simple as simplicity is one of things Go guys known to love.

What features you'd highlight to enterprise-ish user?

-- 
Dmitry Olshansky
Mar 05 2016
next sibling parent reply Jakob Bornecrantz <wallbraker gmail.com> writes:
On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky wrote:
 What features you'd highlight to enterprise-ish user?
Have go solved stacktraces in gorutines, last I checked this was a big pain point for go developers, otherwise its a good issue to bring up. Cheers, Jakob.
Mar 05 2016
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 05-Mar-2016 14:11, Jakob Bornecrantz wrote:
 On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky wrote:
 What features you'd highlight to enterprise-ish user?
Have go solved stacktraces in gorutines, last I checked this was a big pain point for go developers, otherwise its a good issue to bring up. Cheers, Jakob.
Sort of, yes - there is a tool that trims down stacktraces from irrelevant goroutines on panic if that is what you refer to. Also it's done by default in the latest v1.6. -- Dmitry Olshansky
Mar 05 2016
prev sibling next sibling parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky wrote:
 I'm having an opportunity to do a small tech-talk on things D 
 in a eCommerce shop that is currently sold on Go (migrating to 
 SOA from PHP monolith). I do not intend that to become Go vs D 
 battle but it gives the context.

 [...]
Have you seen this? http://www.jtolds.com/writing/2016/03/go-channels-are-bad-and- ou-should-feel-bad/ I'm not sure if it's all correct and how to compare the situation to D, but it was interesting to read.
Mar 05 2016
next sibling parent Shammah Chancellor <shammah.chancellor gmail.com> writes:
On Saturday, 5 March 2016 at 11:31:27 UTC, John Colvin wrote:
 On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky 
 wrote:
 I'm having an opportunity to do a small tech-talk on things D 
 in a eCommerce shop that is currently sold on Go (migrating to 
 SOA from PHP monolith). I do not intend that to become Go vs D 
 battle but it gives the context.

 [...]
Have you seen this? http://www.jtolds.com/writing/2016/03/go-channels-are-bad-and- ou-should-feel-bad/ I'm not sure if it's all correct and how to compare the situation to D, but it was interesting to read.
That article is correct -- I've used go extensively at this point. This is also a good article: https://gist.github.com/kachayev/21e7fe149bc5ae0bd878
Mar 05 2016
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 05-Mar-2016 14:31, John Colvin wrote:
 On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky wrote:
 I'm having an opportunity to do a small tech-talk on things D in a
 eCommerce shop that is currently sold on Go (migrating to SOA from PHP
 monolith). I do not intend that to become Go vs D battle but it gives
 the context.

 [...]
Have you seen this? http://www.jtolds.com/writing/2016/03/go-channels-are-bad-and-you-should-feel-bad/ I'm not sure if it's all correct and how to compare the situation to D, but it was interesting to read.
Rings true with my (limited) experience with Go. -- Dmitry Olshansky
Mar 06 2016
prev sibling next sibling parent reply Chris Wright <dhasenan gmail.com> writes:
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.
Mar 05 2016
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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
Mar 06 2016
parent Jacob Carlborg <doob me.com> writes:
On 2016-03-06 10:05, Dmitry Olshansky wrote:

 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.
I'm wondering how much work it would be to expose the read/write functions from vibe.d, update a C library to use the read/write functions from vibe.d and use that C library together with vibe.d. -- /Jacob Carlborg
Mar 06 2016
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/5/2016 3:05 AM, Dmitry Olshansky wrote:
 What features you'd highlight to enterprise-ish user?
Interfacing to existing C and C++ code.
Mar 05 2016
next sibling parent Jack Stouffer <jack jackstouffer.com> writes:
On Saturday, 5 March 2016 at 22:13:40 UTC, Walter Bright wrote:
 On 3/5/2016 3:05 AM, Dmitry Olshansky wrote:
 What features you'd highlight to enterprise-ish user?
Interfacing to existing C and C++ code.
If they were a PHP shop, then this wouldn't matter much to them.
Mar 05 2016
prev sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 06-Mar-2016 01:13, Walter Bright wrote:
 On 3/5/2016 3:05 AM, Dmitry Olshansky wrote:
 What features you'd highlight to enterprise-ish user?
Interfacing to existing C and C++ code.
They have no C/C++ code to interface to, so it makes little sense to them. Many prominent C libraries actually have fine Go bindings for things like compression/encryption, in fact there most likely more of them then for D (because of popularity of Go). -- Dmitry Olshansky
Mar 06 2016
prev sibling next sibling parent reply Shammah Chancellor <shammah.chancellor gmail.com> writes:
On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky wrote:
 I'm having an opportunity to do a small tech-talk on things D 
 in a eCommerce shop that is currently sold on Go (migrating to 
 SOA from PHP monolith). I do not intend that to become Go vs D 
 battle but it gives the context.

 What guys seem to like of Go from my observation:
 - goroutines instead of direct asynchronous programming*
 - fast runtime with state of the art GC
 - host of ready-made libraries esp. http & networking**
 - lightweight OOP that doesn't get in your way
 - tooling, tooling, tooling (IDE plugins and build tools work 
 great)

 *Note: all of standard I/O is transparently handled with 
 goroutines much like vibe.d but goroutines are migrating across 
 thread pool
 ** That being said there are tons of 1-man projects of dubious 
 quality,

 So far I'd thought of a few big themes:
 - little nice things (slices/maps, things like 1_000_000 and 
 e.g. a < b && d < e is parse error, UFCS)
 - code reuse (templates & ranges, with examples like generic 
 min and some algo)
 - compile-time works (CTFE, need simpler example then regex)

 I'm still pondering whether I should dive into UDA, I'd try to 
 stay simple as simplicity is one of things Go guys known to 
 love.

 What features you'd highlight to enterprise-ish user?
I work in a 99% Go shop (a splash of C, and some smattering of scripts for in-house tools.) I've tried to use D for a few things, and tried to get other people interested in it. So, here's my perception: Everything you've said is true, and D should focus on making some of these things much better. Additionally, the compiled (mostly single binary nature) of Go makes it very nice for deployments. Focusing on dfmt, and dfix would be a huge win. Here's some stuff D shares with Go: "Single" binary deployments. Garbage Collector In-language slices and maps Foreach (Although D is much more powerful here) Some things D is weak on: * The name -- all I ever hear are penis jokes. * Garbage Collector (!) * dfix and dfmt aren't as good as gofmt and gofix. (And believe me I understand they will be much more difficult to get to parity due to the feature set of D) * Docs -- although these have gotten much much better recently -- the current implementation of concepts makes it hard for people to know where and when they can use a type. E.g sort docs (http://dlang.org/phobos/std_algorithm_sorting.html#sort) How do I know what types of things I can sort as a newcomer? Even if I figure out that I need to look at isForwardRange, the docs there aren't terribly helpful either (https://dlang.org/phobos/std_range_primitives.html#isForwardRange) I would put up a PR, but I don't know how to fix it without introducing a language structure for Concepts -- but this has been veto'd for a variety of reasons (primarily type explosion as I understand the arguments) * Libraries Some things D is much better on (and would cause me to choose it every time and just contribute fixes where I could to the external tools): * Package management/build tools * Integration with existing build systems/libraries * Reusable algorithms that are FAST * Empowering programmer expressiveness without enabling magic -S.
Mar 05 2016
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 06-Mar-2016 10:21, Shammah Chancellor wrote:
 On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky wrote:
[snip]
 Here's some stuff D shares with Go:

 "Single" binary deployments.
 Garbage Collector
 In-language slices and maps
 Foreach (Although D is much more powerful here)

 Some things D is weak on:
 * The name -- all I ever hear are penis jokes.
Thankfully not in my country ;)
 * Garbage Collector (!)
This is indeed a sore spot, Go rapidly advanced their GC and even took advantage of it being non-copying to deliver on lower-latency front. Wonder if we could squeeze some more bang out of GC.
 * dfix and dfmt aren't as good as gofmt and gofix. (And believe me I
 understand they will be much more difficult to get to parity due to the
 feature set of D)
Strangely people love single imposed code style of Go, and in many ways other enforced conventions.
 * Docs  -- although these have gotten much much better recently -- the
 current implementation of concepts makes it hard for people to know
 where and when they can use a type.  E.g sort docs
 (http://dlang.org/phobos/std_algorithm_sorting.html#sort) How do I know
 what types of things I can sort as a newcomer? Even if I figure out that
 I need to look at isForwardRange, the docs there aren't terribly helpful
 either
 (https://dlang.org/phobos/std_range_primitives.html#isForwardRange)  I
 would put up a PR, but I don't know how to fix it without introducing a
 language structure for Concepts -- but this has been veto'd for a
 variety of reasons (primarily type explosion as I understand the arguments)
 * Libraries
Probably the biggest issue. Another one I'd pull is complexity, there is sooo many moving parts in D by now that we consistently fail to deliver a feature complete spec and/or compiler for it.
 Some things D is much better on (and would cause me to choose it every
 time and just contribute fixes where I could to the external tools):

 * Package management/build tools
 * Integration with existing build systems/libraries
 * Reusable algorithms that are FAST
 * Empowering programmer expressiveness without enabling magic
Overall my impression is that if we were to compare D and Go as tools, D would be more of meta tool - i.e. a tool to create tools whereas Go is ready made toolkit that is nicely crafted but quite limited. Now I only need to appeal to the former somehow ;)
 -S.
-- Dmitry Olshansky
Mar 06 2016
parent cym13 <cpicard openmailbox.org> writes:
On Sunday, 6 March 2016 at 14:02:25 UTC, Dmitry Olshansky wrote:
 On 06-Mar-2016 10:21, Shammah Chancellor wrote:
 On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky 
 wrote:
[snip]
 Here's some stuff D shares with Go:

 "Single" binary deployments.
 Garbage Collector
 In-language slices and maps
 Foreach (Although D is much more powerful here)

 Some things D is weak on:
 * The name -- all I ever hear are penis jokes.
Thankfully not in my country ;)
 * Garbage Collector (!)
This is indeed a sore spot, Go rapidly advanced their GC and even took advantage of it being non-copying to deliver on lower-latency front. Wonder if we could squeeze some more bang out of GC.
 * dfix and dfmt aren't as good as gofmt and gofix. (And 
 believe me I
 understand they will be much more difficult to get to parity 
 due to the
 feature set of D)
Strangely people love single imposed code style of Go, and in many ways other enforced conventions.
 * Docs  -- although these have gotten much much better 
 recently -- the
 current implementation of concepts makes it hard for people to 
 know
 where and when they can use a type.  E.g sort docs
 (http://dlang.org/phobos/std_algorithm_sorting.html#sort) How 
 do I know
 what types of things I can sort as a newcomer? Even if I 
 figure out that
 I need to look at isForwardRange, the docs there aren't 
 terribly helpful
 either
 (https://dlang.org/phobos/std_range_primitives.html#isForwardRange)  I
 would put up a PR, but I don't know how to fix it without 
 introducing a
 language structure for Concepts -- but this has been veto'd 
 for a
 variety of reasons (primarily type explosion as I understand 
 the arguments)
 * Libraries
Probably the biggest issue. Another one I'd pull is complexity, there is sooo many moving parts in D by now that we consistently fail to deliver a feature complete spec and/or compiler for it.
 Some things D is much better on (and would cause me to choose 
 it every
 time and just contribute fixes where I could to the external 
 tools):

 * Package management/build tools
 * Integration with existing build systems/libraries
 * Reusable algorithms that are FAST
 * Empowering programmer expressiveness without enabling magic
Overall my impression is that if we were to compare D and Go as tools, D would be more of meta tool - i.e. a tool to create tools whereas Go is ready made toolkit that is nicely crafted but quite limited. Now I only need to appeal to the former somehow ;)
 -S.
Just to temper some points that I agree with in principle:
 * Garbage Collector (!)
D doesn't need a better GC in my opinion. Go's GC has to be really good because AFAIK there is no other way to manage memory. Same for Java. But as good as a GC can be it will never be good enough for all applications. D solved the problem by proposing other memory management schemes so when the GC isn't good enough you just don't use it. Developping such schemes is *way* more important to D's future than a better GC that can never be more than good enough for more people but never everybody.
 * Libraries
There again as using C libraries in Go is tiresome there is more incentive not to reuse them. OK, this is a weak point, I too think this is maybe the most proeminent D flaw.
Mar 06 2016
prev sibling next sibling parent reply landaire <landergriffith+dlang gmail.com> writes:
On Saturday, 5 March 2016 at 11:05:09 UTC, Dmitry Olshansky wrote:
 - tooling, tooling, tooling (IDE plugins and build tools work 
 great)
I'd like to add that one of the things that I love about Go is that it is crazy easy to cross-compile. `GOOS=freebsd go build` and I have a FreeBSD binary sitting in my working directory, ready to send off. Things I really like about D though are the UFC makes for really pleasant method chaining and cleaner code (along with map/filter/reduce for things), code reuse as you pointed out, and Dub being an actual package manager that seems to have common issues with dependency management solved. At least with my limited experience with D I haven't run into any Dub-related issues. I'd like to toss in that D's lack of solid and stable `io` APIs in phobos is kind of sad and resulted in one of my recent projects being rewritten in Go.
Mar 07 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 03/07/2016 02:17 PM, landaire wrote:
 I'd like to add that one of the things that I love about Go is that it
 is crazy easy to cross-compile. `GOOS=freebsd go build` and I have a
 FreeBSD binary sitting in my working directory, ready to send off.
What would be some good cases for that? When I want to cross-compile, I ssh into the target machine and build there. -- Andrei
Mar 09 2016
next sibling parent ZombineDev <petar.p.kirov gmail.com> writes:
On Wednesday, 9 March 2016 at 13:23:55 UTC, Andrei Alexandrescu 
wrote:
 On 03/07/2016 02:17 PM, landaire wrote:
 I'd like to add that one of the things that I love about Go is 
 that it
 is crazy easy to cross-compile. `GOOS=freebsd go build` and I 
 have a
 FreeBSD binary sitting in my working directory, ready to send 
 off.
What would be some good cases for that? When I want to cross-compile, I ssh into the target machine and build there. -- Andrei
You can't use all target platforms as development platforms - e.g. Apple Watch, microcontrollers, and so on. Sometimes you don't have any other options than cross-compilation. It is also more flexible from a DevOps perspective. You can setup a Linux build server and use it to produce builds for several targets.
Mar 09 2016
prev sibling next sibling parent Shammah Chancellor <shammah.chancellor gmail.com> writes:
On Wednesday, 9 March 2016 at 13:23:55 UTC, Andrei Alexandrescu 
wrote:
 On 03/07/2016 02:17 PM, landaire wrote:
 I'd like to add that one of the things that I love about Go is 
 that it
 is crazy easy to cross-compile. `GOOS=freebsd go build` and I 
 have a
 FreeBSD binary sitting in my working directory, ready to send 
 off.
What would be some good cases for that? When I want to cross-compile, I ssh into the target machine and build there. -- Andrei
Well, at least in a commercial environment, not having to have multiple pools of build machines is very helpful. That is to say, I don't need 10 windows machines sitting around waiting to accept a job, since I can just cross compile with `GOOS=windows GOARCH=386 go build` on linux. This is also why gofmt is so awesome -- if you're working with a team of 40 other engineers, you don't want to be messing with formatting holy-wars. And another item for this thread that D really shines at: const and immutable -- Golang lacks const and immutable. When working with large-ish teams, it's pretty annoying not to be able to require a library take a const, or immutable parameter. -S
Mar 09 2016
prev sibling parent sanjayss <dummy dummy.dummy> writes:
On Wednesday, 9 March 2016 at 13:23:55 UTC, Andrei Alexandrescu 
wrote:
 On 03/07/2016 02:17 PM, landaire wrote:
 I'd like to add that one of the things that I love about Go is 
 that it
 is crazy easy to cross-compile. `GOOS=freebsd go build` and I 
 have a
 FreeBSD binary sitting in my working directory, ready to send 
 off.
What would be some good cases for that? When I want to cross-compile, I ssh into the target machine and build there. -- Andrei
It's typical in an embedded target development environment that you are working on Windows (or nowadays Linux) and developing for some target platform (though yeah, perhaps it doesn't make much sense to build on Windows for FreeBSD, I assume the idea is to make target platform development sort of generic). It also helps if you are trying to develop a multi-platform tool and prefer to develop on just one platform -- a single build could potentially generate binaries for all the target platforms.
Mar 14 2016
prev sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 05-Mar-2016 14:05, Dmitry Olshansky wrote:
 I'm having an opportunity to do a small tech-talk on things D in a
 eCommerce shop that is currently sold on Go (migrating to SOA from PHP
 monolith). I do not intend that to become Go vs D battle but it gives
 the context.
The talk went better then I would expect with lots of good questions. Compile-time features generated the most favorable discussion. Obligatory slides: http://slides.com/dmitryolshansky/deck/fullscreen/ std.concurrency working only with threads and lack of better integration of fibers in std is our weak spot as prompted by further questions. -- Dmitry Olshansky
Mar 12 2016
next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 2016-03-12 at 11:09 +0300, Dmitry Olshansky via Digitalmars-d
wrote:
 On 05-Mar-2016 14:05, Dmitry Olshansky wrote:
=20
 I'm having an opportunity to do a small tech-talk on things D in a
 eCommerce shop that is currently sold on Go (migrating to SOA from
 PHP
 monolith). I do not intend that to become Go vs D battle but it
 gives
 the context.
Switching from PHP to Go is not a bad idea as CloudFlare have blazed that trail and created a who community around it.=C2=A0
 The talk went better then I would expect with lots of good
 questions.=C2=A0
Sounds like some good people, using Go for good reasons not blind fashion.
 Compile-time features generated the most favorable discussion.
This is now a bit topic again in C++, witness all the debating over constexpr and C++17 and C++20.
 Obligatory slides:
 http://slides.com/dmitryolshansky/deck/fullscreen/
=20
 std.concurrency working only with threads and lack of better
 integration=C2=A0
 of fibers in std is our weak spot as prompted by further questions.
Clearly there are many feature similarities between D and Go as well as differences (slices vs. generics). looked like a nice selection of example in teh slides to pick up on this. Thread pool and work stealing is clearly the way forward for actor/dataflow architecture, though explicit threads have their place as well. std.parallelism has a task pool system. I wonder if there should be a strategic move to (in some sense) merge std.concurrency, std.fibers and std.parallelism into a single consistent whole (possibly remaining three separate by connected packages rather than a single monolith. Java has had great benefit from having a single concurrency/parallelism strategy even though it ends up with different leaves not a monolith. =C2=A0 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Mar 12 2016
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 12-Mar-2016 11:56, Russel Winder via Digitalmars-d wrote:
 On Sat, 2016-03-12 at 11:09 +0300, Dmitry Olshansky via Digitalmars-d
 wrote:
 On 05-Mar-2016 14:05, Dmitry Olshansky wrote:
 I'm having an opportunity to do a small tech-talk on things D in a
 eCommerce shop that is currently sold on Go (migrating to SOA from
 PHP
 monolith). I do not intend that to become Go vs D battle but it
 gives
 the context.
Switching from PHP to Go is not a bad idea as CloudFlare have blazed that trail and created a who community around it.
I does go fairly well considering the simultaneous pressure for more features and overall poor state of the original PHP codebase.
 Obligatory slides:
 http://slides.com/dmitryolshansky/deck/fullscreen/

 std.concurrency working only with threads and lack of better
 integration
 of fibers in std is our weak spot as prompted by further questions.
Clearly there are many feature similarities between D and Go as well as differences (slices vs. generics). looked like a nice selection of example in teh slides to pick up on this.
Indeed I've picked up a lots of similarities esp. between D1 and Go. For instance, Go slices do allow stomping just like their D1 counterparts. OOP model and direct access to C are the major differences.
 Thread pool and work stealing is clearly the way forward for
 actor/dataflow architecture, though explicit threads have their place
 as well.

 std.parallelism has a task pool system. I wonder if there should be a
 strategic move to (in some sense) merge std.concurrency, std.fibers and
 std.parallelism into a single consistent whole (possibly remaining
 three separate by connected packages rather than a single monolith.
Yeah, preferably we'd have future+async style concurrency together with actor system all riding on top of some core functionality like thread pools with work-stealing. IO complicates matters as it also has to be a part of the picture for 'fiber as actor' model to work really well.
 Java has had great benefit from having a single concurrency/parallelism
 strategy even though it ends up with different leaves not a monolith.
-- Dmitry Olshansky
Mar 13 2016
parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 2016-03-13 at 20:39 +0300, Dmitry Olshansky via Digitalmars-d
wrote:
 [=E2=80=A6]
 Yeah, preferably we'd have future+async style concurrency together
 with=C2=A0
 actor system all riding on top of some core functionality like
 thread=C2=A0
 pools with work-stealing. IO complicates matters as it also has to be
 a=C2=A0
 part of the picture for 'fiber as actor' model to work really well.
Rust threw out async+future in favour of thread+channel =E2=80=93 in the language core, async+future still there but "demoted" to being a library.=C2=A0 --=C2=A0Russel.=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3DDr Russel Winder=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0t:= +44 20 7585 2200=C2=A0=C2=A0=C2=A0voip: sip:russel.winder ekiga.net41 Buck= master Road=C2=A0=C2=A0=C2=A0=C2=A0m: +44 7770 465 077=C2=A0=C2=A0=C2=A0xmp= p: russel winder.org.ukLondon SW11 1EN, UK=C2=A0=C2=A0=C2=A0w: www.russel.o= rg.uk=C2=A0=C2=A0skype: russel_winder
Mar 13 2016
prev sibling next sibling parent Jon D <jond noreply.com> writes:
On Saturday, 12 March 2016 at 08:09:41 UTC, Dmitry Olshansky 
wrote:
 On 05-Mar-2016 14:05, Dmitry Olshansky wrote:
 Obligatory slides:
 http://slides.com/dmitryolshansky/deck/fullscreen/
Very nice slide deck. Thanks for publishing. --Jon
Mar 12 2016
prev sibling parent reply kdmult <kdmult ru.ru> writes:
On Saturday, 12 March 2016 at 08:09:41 UTC, Dmitry Olshansky 
wrote:
 On 05-Mar-2016 14:05, Dmitry Olshansky wrote:
 Obligatory slides:
 http://slides.com/dmitryolshansky/deck/fullscreen/
There are 2 bugs in http://slides.com/dmitryolshansky/deck/fullscreen/#/4/1 --- zzz0.d 2016-03-13 22:10:44.548974800 +0300 +++ zzz1.d 2016-03-13 22:11:54.653984600 +0300 -2,7 +2,7 // slice is dynamic array on GC heap int[] slice = [1, 2, 3, 4, 5]; // slice the range of [1:3) - int[] a = slice[1..3]; + int[] a = slice[1..4]; assert(a == [2,3,4]); a ~= 6; // append 6 -15,7 +15,7 int[] b = a.dup; // duplicate (=copy) b[0] = 10; - assert(a[0] == 8); + assert(a[0] == 4); assert(*a.ptr == 4); int k = 1;
Mar 13 2016
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 13-Mar-2016 22:13, kdmult wrote:
 On Saturday, 12 March 2016 at 08:09:41 UTC, Dmitry Olshansky wrote:
 On 05-Mar-2016 14:05, Dmitry Olshansky wrote:
 Obligatory slides:
 http://slides.com/dmitryolshansky/deck/fullscreen/
There are 2 bugs in http://slides.com/dmitryolshansky/deck/fullscreen/#/4/1
Thanks, both fixed! -- Dmitry Olshansky
Mar 13 2016
parent reply cym13 <cpicard openmailbox.org> writes:
On Sunday, 13 March 2016 at 21:16:45 UTC, Dmitry Olshansky wrote:
 On 13-Mar-2016 22:13, kdmult wrote:
 On Saturday, 12 March 2016 at 08:09:41 UTC, Dmitry Olshansky 
 wrote:
 On 05-Mar-2016 14:05, Dmitry Olshansky wrote:
 Obligatory slides:
 http://slides.com/dmitryolshansky/deck/fullscreen/
There are 2 bugs in http://slides.com/dmitryolshansky/deck/fullscreen/#/4/1
Thanks, both fixed!
Also some typos: "ellimination" -> "elimination" http://slides.com/dmitryolshansky/deck/fullscreen/#/4/5 "usefull" -> "useful" "simillar" -> "similar" http://slides.com/dmitryolshansky/deck/fullscreen/#/5/6
Mar 13 2016
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 14-Mar-2016 00:32, cym13 wrote:
 On Sunday, 13 March 2016 at 21:16:45 UTC, Dmitry Olshansky wrote:
 On 13-Mar-2016 22:13, kdmult wrote:
 On Saturday, 12 March 2016 at 08:09:41 UTC, Dmitry Olshansky wrote:
 On 05-Mar-2016 14:05, Dmitry Olshansky wrote:
 Obligatory slides:
 http://slides.com/dmitryolshansky/deck/fullscreen/
There are 2 bugs in http://slides.com/dmitryolshansky/deck/fullscreen/#/4/1
Thanks, both fixed!
Also some typos: "ellimination" -> "elimination" http://slides.com/dmitryolshansky/deck/fullscreen/#/4/5 "usefull" -> "useful" "simillar" -> "similar" http://slides.com/dmitryolshansky/deck/fullscreen/#/5/6
Thx, fixed these too. -- Dmitry Olshansky
Mar 14 2016