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. 

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.

 it's got corporate support, so for an enterprise crowd I'd sooner
 recommend it.



with a bit different set of trade-offs. Like native code C/C++ inter-op 


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


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



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



 Thanks, both fixed!


Also some typos:

  "ellimination" -> "elimination" 


"usefull" -> "useful"
"simillar" -> "similar"
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



 Thanks, both fixed!


 Also some typos:

   "ellimination" -> "elimination"


 "usefull" -> "useful"
 "simillar" -> "similar"



Thx, fixed these too.

-- 
Dmitry Olshansky
Mar 14 2016