View mode: basic / threaded / horizontal-split · Log in · Help
November 12, 2009
Re: Go: A new system programing language
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
Re: Go: A new system programing language
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
Re: Go: A new system programing language
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
Re: Go: A new system programing language
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
Re: Go: A new system programing language
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
Re: Go: A new system programing language
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
Re: Go: A new system programing language
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
Re: Go: A new system programing language
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
Re: Go: A new system programing language
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
Re: Go: A new system programing language
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
2 3 4 5 6 7
Top | Discussion index | About this forum | D home