Pitching D to a gang of Gophers

[Dmitry Olshansky via Digitalmars-d]

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