November 12, 2009
dsimcha wrote:
> The fact that message passing is built into
> Go! makes me wonder if there's a reason why it can't be done well in a library.

Interestingly, both D and Go have had associative arrays built in to the core language. But D now has enough expressive power that the AAs are moving into the library, with the barest syntactic sugar left. Similarly, complex types are moving to the library, typedefs, etc.

Go realized the importance of immutable strings, but didn't generalize that to having any other immutable types.
November 12, 2009
dsimcha wrote:
> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
>> hasenj wrote:
>>> Walter Bright wrote:
>>>> Message passing for concurrency is a solid solution for many types of
>>>> concurrency problems, but it isn't a panacea.
>>> Do you think D would benefit if you add this (or similar) feature to it?
>> Sean is working on a message passing (CSP) package for D. I'm not
>> convinced it needs to be a core language feature, though.
> 
> This is true.  After I created ParallelFuture (the lib w/ parallel foreach, map,
> reduce), a friend mentioned that my model was pretty similar to the OpenMP model.
>  I read a little about OpenMP and it really hit home how powerful a language D is,
> given that I was able to implement something OpenMP-ish as a pure library, without
> any modifications to the compiler.  The fact that message passing is built into
> Go! makes me wonder if there's a reason why it can't be done well in a library.

Same could be said about dynamic arrays and hash tables/maps/dictionaries. They can be implemented as libraries (C/C++ approach).

The reason these data structures are built into languages like D and Python is probably the same reason that Go has channels and goroutines built-in.

November 12, 2009
On Wed, 11 Nov 2009 20:03:37 -0500, Bill Baxter <wbaxter@gmail.com> wrote:

> On Wed, Nov 11, 2009 at 4:56 PM, Walter Bright
> <newshound1@digitalmars.com> wrote:
>> hasenj wrote:
>>>
>>> Walter Bright wrote:
>>>>
>>>> Message passing for concurrency is a solid solution for many types of
>>>> concurrency problems, but it isn't a panacea.
>>>
>>> Do you think D would benefit if you add this (or similar) feature to it?
>>
>>
>> Sean is working on a message passing (CSP) package for D. I'm not convinced
>> it needs to be a core language feature, though.
>>
>
> Is it possible to do the kind of "goroutine" scheduling they do purely
> as a library?
>
> That wasn't really clear to me how their "segmented stacks" thing
> works.  Sounds like it would need low-level runtime system support,
> though.
>
> --bb

Yes and no. At heart, they're basically co-routines or fibers, but with a grow-able stack. So the basic model can be done in a library (and is already in druntime, sans the CSP style message passing), but the compactness of a segmented stack are missing. And when you're creating 100_000 fibers, memory compactness is key. I'm extrapolating, because I didn't see anything obvious on the website, but basically a segmented stack allows ESP (the stack pointer) to vary independently of EBP (the current stack frame pointer). This requires the stack frame to contain a 'done' flag, it's size, etc, to allow memory reclamation (i.e. so the ESP can shrink), among other things.

However, a Cilk style task library is both possible and already available in D (see Dave Simcha's parallel foreach), and covers most of the examples in the videos; using fibers for simple tasks is overkill.

BTW, D currently requires: EBX, ESI, EDI, EBP must be preserved across function calls.

P.S. You might want to take a look at C++ CSP: http://www.cs.kent.ac.uk/projects/ofa/c++csp/
November 12, 2009
Bill Baxter Wrote:

> On Wed, Nov 11, 2009 at 2:05 PM, Michel Fortin <michel.fortin@michelf.com> wrote:
> > On 2009-11-11 10:57:20 -0500, "Robert Jacques" <sandford@jhu.edu> said:
> >
> >>  * Uses '+' for concatenation
> 
> Yeh, I was disappointed by that too.
> 
> > That's what I dislike the most about it. I quite like the syntax and I quite like the concept of interfaces as a replacement for traditional OOP.
> 
> I also dislike the use of Capitalization for protection levels.  Yeh, it's simple, and yeh it saves them a few keywords, and yeh it puts an end to the debate over camelCase vs CamelCase, but ... ugh.  It reminds me of Fortran with the rule of A-H are floats and I-N are ints or whatever that rule was.

Exactly! same feeling here!

I also dislike the need of tabs for indentation.

Cheers!


November 12, 2009
On 11/11/2009 8:03 PM, Bill Baxter wrote:

> Is it possible to do the kind of "goroutine" scheduling they do purely
> as a library?

It’s similar to how the Plan 9 thread library works, see the code at <http://plan9.bell-labs.com/sources/plan9/sys/src/libthread/>.

> That wasn't really clear to me how their "segmented stacks" thing
> works.  Sounds like it would need low-level runtime system support,
> though.

I got pointed to this: <http://gcc.gnu.org/wiki/SplitStacks>, apparently by the person doing the GCC Go implementation.

—Joel Salomon
November 12, 2009
On 11/11/2009 8:47 PM, dsimcha wrote:
> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
>> hasenj wrote:
>>> Do you think D would benefit if you add this (or similar) feature to it?
>> Sean is working on a message passing (CSP) package for D. I'm not
>> convinced it needs to be a core language feature, though.
>
> This is true.  After I created ParallelFuture (the lib w/ parallel foreach, map,
> reduce), a friend mentioned that my model was pretty similar to the OpenMP model.
>   I read a little about OpenMP and it really hit home how powerful a language D is,
> given that I was able to implement something OpenMP-ish as a pure library, without
> any modifications to the compiler.  The fact that message passing is built into
> Go! makes me wonder if there's a reason why it can't be done well in a library.

Most stuff can be done decently well in a library -- imagine Plan 9’s libthread with channels implemented input/output ranges.  Select is ugly though, without some language support; perhaps D’s compile-time stuff can implement a select block.

—Joel Salomon
November 13, 2009
On Thu, 12 Nov 2009 15:01:24 -0500, Joel C. Salomon <joelcsalomon@gmail.com> wrote:

> On 11/11/2009 8:47 PM, dsimcha wrote:
>> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
>>> hasenj wrote:
>>>> Do you think D would benefit if you add this (or similar) feature to it?
>>> Sean is working on a message passing (CSP) package for D. I'm not
>>> convinced it needs to be a core language feature, though.
>>
>> This is true.  After I created ParallelFuture (the lib w/ parallel foreach, map,
>> reduce), a friend mentioned that my model was pretty similar to the OpenMP model.
>>   I read a little about OpenMP and it really hit home how powerful a language D is,
>> given that I was able to implement something OpenMP-ish as a pure library, without
>> any modifications to the compiler.  The fact that message passing is built into
>> Go! makes me wonder if there's a reason why it can't be done well in a library.
>
> Most stuff can be done decently well in a library -- imagine Plan 9’s libthread with channels implemented input/output ranges.  Select is ugly though, without some language support; perhaps D’s compile-time stuff can implement a select block.
>
> —Joel Salomon

Ugly? I'm pretty sure you could do the following in D:

select(
    guard(chan1, x = chan1.value;),
    guard(chan2, y = chan2.value;),
    guard(true , writeln("always triggers") )
);

Aren't lazy variables grand :)
November 14, 2009
On 2009-11-12 22:50:20 +0100, HOSOKAWA Kenchi <hskwk@inter7.jp> said:
> These features give great power for numeric uses.
> Probably Go's developers would have never imagined to do numerical operations with their language.
> Only middlewares are in their sights.

I am a bit surprised that they'd still prefer Java Complex-like ugliness rather than supporting operator overloading or an infix function or method notation. Go is clearly coming from a C/Java background, making it refreshingly uncomplex, but life's hard for number crunching or building performant containers.

But hey, there is a compiler for 64-bit binaries :). Of course, I should swallow that, and help with the LDC efforts...

Take care,
Daniel

November 14, 2009
Daniel de Kok wrote:
> But hey, there is a compiler for 64-bit binaries :). Of course, I should swallow that, and help with the LDC efforts...

As far as I know, ldc+Tango already works on 64 bit. Also, Go has no Windows compiler, which is an _absolute_ show stopper.
November 14, 2009
grauzone wrote:
> Daniel de Kok wrote:
>> But hey, there is a compiler for 64-bit binaries :). Of course, I should swallow that, and help with the LDC efforts...
> 
> As far as I know, ldc+Tango already works on 64 bit. Also, Go has no Windows compiler, which is an _absolute_ show stopper.

Yeah, but that's something that can be fixed. What is more difficult to fix is that Go is all-over an unremarkable and unoriginal language (something that would become obvious if one thinks for a second what would have happened if Go wasn't associated with Google's brand name). On the other hand, it is associated with Google's brand name. :o) It will be interesting to see how things turn out.

Andrei