A few notes on choosing between Go and D for a quick project

[Russel Winder via Digitalmars-d]

On Sat, 2015-03-14 at 12:54 -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 3/14/15 11:24 AM, Russel Winder via Digitalmars-d wrote:
> > But yes, it certainly shows you can create shared-memory
> > "multi-threading" this way,
> 
> So your affirmation has been refuted.

It appears so, I grovel at the feet of logic and proof.

The core issue here is the ability to ship memory addresses around
instead of having to ship values. I still believe dataflow to be the
superior architecture for concurrent and parallel systems. Actian
Datarush and GPars are on the JVM and avoid Unsafe, and whilst you can
set up sharing of mutable data structures, it is a lot harder than as in
Go. Likewise with Python-CSP and PyCSP sending values that are not
references to shared mutable state is the norm. It is quite hard to do
otherwise with Python as a consequence of the GIL and the necessity to
use multiprocessing (i.e. each process is a separate PVM and hence
separate OS process, and hence different address space).

> > but anyone actually doing it would be being
> > very silly.
> 
> That's "design by prayer". Aren't most bugs created by people doing very 
> silly things?

And prayer achieves nothing.

I think you can probably remove the "very" there and it still be right.

> > Sending addresses down multiple channels
> 
> One is enough.

Actually no, you need two. I believe you are thinking that the sender
retains the reference and sends the reference so one send is enough.
True per se. But what Rust is trying to enforce, which C++ (and D?) do
not, is ownership of the reference, so that you can send a reference the
originator cannot then use.  Clearly std::unique_ptr is trying to
provide this for C++ but it isn't enforced as has to be to avoid the
situation you coded up in Go.
> 
> > is obvious here and
> > definitely not the right thing to do unless the datum contains an
> > embedded lock which is then used. cf.
> > https://talks.golang.org/2012/10things.slide#3
> 
> Yes, of course it's not the right thing to do. Your point being...?

A language has to enforce not manipulating shared mutable memory or the
programs will likely be broken. Functional programming's obsession with
copying rather than sharing, helps with this.

> > It would be better if channels could only accept value types, and not
> > reference types.
> 
> Probably not as that would further hamstrung the language.

I am not sure that is true. I find it somewhat strange that Go allows
sharing of references to mutable state in this way, it certainly doesn't
fit with the way I was brought up to use dataflow.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150317/3a7e5afd/attachment.sig>