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.

--bb

Walter Bright wrote:
> Bill Baxter wrote:
>> It's harder to find those when you're skimming through trying to get
>> the highlights with a 5 minute limit.  :-) What are some things is it
>> missing?
> 
> Off the top of my head, some major ones:
> 
> . exception handling
> . generic programming
> . metaprogramming
> . inline assembler
> . interface to C
> . RAII
> . immutability for anything but strings
> . vector operations
> . operator overloading
> . purity
> . CTFE
> . unit testing
> . documentation generation
> . ability to write systems code like implement a GC
> . conditional compilation
> . contracts
> . 80 bit floating point
> . introspection (runtime or compile time)
> . delegates
> . reference parameters
> 
> Not sure if it has closures or not.
> 
> And of course a lot of minor ones,
> 
> . no _ in integer literals
> . no nesting comments
> . no entities
> 
> etc.

I think the "go" language creators would consider a language with all these features to be bloated.

What's interesting to me is the approach they take to concurrency: completely different from D's approach. What's more interesting is that their approach comes from their practical experience implementing web servers.

Bill Baxter, el 11 de noviembre a las 11:25 me escribiste:
> On Wed, Nov 11, 2009 at 10:55 AM, Walter Bright <newshound1@digitalmars.com> wrote:
> > Bill Baxter wrote:
> >>
> >> It's harder to find those when you're skimming through trying to get the highlights with a 5 minute limit.  :-) What are some things is it missing?
> >
> > Off the top of my head, some major ones:
> >
> > . exception handling

They say it's a pending, they didn't find a model they liked yet.

> > . generic programming

Same here.

> > . metaprogramming
> > . inline assembler
> > . interface to C
> 
> He does say there is a FFI that lets you call C that "coming along nicely" or something like that.  Not sure how cumbersome it's gonna be though.

It's there, here is an example: http://code.google.com/p/go/source/browse/misc/cgo/gmp/gmp.go?r=release

> > . RAII
> > . immutability for anything but strings
> > . vector operations
> > . operator overloading
> > . purity
> > . CTFE
> > . unit testing

It have a testing framework in the library, and a command line utility to run the tests.

> > . documentation generation
> 
> They have a "godoc" tool written in go already, though.
> 
> > . ability to write systems code like implement a GC
> > . conditional compilation
> > . contracts
> > . 80 bit floating point
> > . introspection (runtime or compile time)

It has runtime introspection, they use it a lot (for example, for Printf).

> > . delegates

It has full closures and function literals.

But I agree it lacks a lot of features.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Se va a licitar un sistema de vuelos espaciales mendiante el cual, desde una
plataforma que quizás se instale en la provincia de Córdoba. Esas naves
espaciales va a salir de la atmósfera, va a remontar la estratósfera y desde
ahí elegir el lugar donde quieran ir de tal forma que en una hora y media
podamos desde Argentina estar en Japón, en Corea o en cualquier parte.
	-- Carlos Saúl Menem (sic)

Bill Baxter wrote:
> I think Walter even gave a talk at Google, once.  Didn't he?

Twice, and both on D.

Whenever I give a talk on D, I start out by asking the audience who has heard of it. In the last few years, nearly everyone raises their hand.

hasenj wrote:
> I think the "go" language creators would consider a language with all these features to be bloated.

Probably true. The trouble with a too-simple language, however, is it makes the user code overly complex. Consider the Java IDE that generates hundreds of lines of boilerplate with a single click. The IDE is essentially providing the high level features that the language lacks.

Finding the sweet spot between simplistic and bloat is not at all easy.


> What's interesting to me is the approach they take to concurrency: completely different from D's approach. What's more interesting is that their approach comes from their practical experience implementing web servers.

Message passing for concurrency is a solid solution for many types of concurrency problems, but it isn't a panacea.

Walter Bright wrote:
> hasenj wrote:
>> I think the "go" language creators would consider a language with all these features to be bloated.
> 
> Probably true. The trouble with a too-simple language, however, is it makes the user code overly complex. Consider the Java IDE that generates hundreds of lines of boilerplate with a single click. The IDE is essentially providing the high level features that the language lacks.
> 
> Finding the sweet spot between simplistic and bloat is not at all easy.
> 
> 
>> What's interesting to me is the approach they take to concurrency: completely different from D's approach. What's more interesting is that their approach comes from their practical experience implementing web servers.
> 
> 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?

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.

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

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

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

I don't know.

> 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 don't know about that, either.