www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Go: A new system programing language

reply Knud Soerensen <4tuu4k002 sneakemail.com> writes:
Google have made a new language.

See http://www.youtube.com/watch?v=rKnDgT73v8s

-- 
Join me on
CrowdNews  http://crowdnews.eu/users/addGuide/42/
Facebook   http://www.facebook.com/profile.php?id=1198821880
Linkedin   http://www.linkedin.com/pub/0/117/a54
Mandala    http://www.mandala.dk/view-profile.php4?profileID=7660
Nov 10 2009
next sibling parent Justin Johansson <no spam.com> writes:
Knud Soerensen Wrote:


 Google have made a new language.
 
 See http://www.youtube.com/watch?v=rKnDgT73v8s
 
 -- 
 Join me on
 CrowdNews  http://crowdnews.eu/users/addGuide/42/
 Facebook   http://www.facebook.com/profile.php?id=1198821880
 Linkedin   http://www.linkedin.com/pub/0/117/a54
 Mandala    http://www.mandala.dk/view-profile.php4?profileID=7660


web site URL: The Go Programming Language

http://golang.org/
Nov 10 2009
prev sibling next sibling parent hasenj <hasan.aljudy gmail.com> writes:
Knud Soerensen wrote:

 Google have made a new language.
 
 See http://www.youtube.com/watch?v=rKnDgT73v8s
 


It fills the same niche that D is trying to fill:

- Systems programming language with ideas taken from dynamic languages 
like Python to make life easier
- Fast compile times
- Built-in support for concurrency
Nov 10 2009
prev sibling next sibling parent reply Justin Johansson <no spam.com> writes:
Knud Soerensen Wrote:


 Google have made a new language.
 
 See http://www.youtube.com/watch?v=rKnDgT73v8s


Some of the people in the Go team include Ken Thompson and Rob Pike.

As a matter of interest these people have been mentioned in a few past D NG
articles.
Apparently Ken Thompson designed UTF-8.

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=42316

http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=43505&header

Justin
Nov 10 2009
parent reply "Phil Deets" <pjdeets2 gmail.com> writes:
On Tue, 10 Nov 2009 23:09:13 -0500, Justin Johansson <no spam.com> wrote:


 Knud Soerensen Wrote:


 Google have made a new language.

 See http://www.youtube.com/watch?v=rKnDgT73v8s


 Some of the people in the Go team include Ken Thompson and Rob Pike.

 As a matter of interest these people have been mentioned in a few past D  
 NG articles.
 Apparently Ken Thompson designed UTF-8.


Sorry if I'm stating something you already know, but Ken Thompson also was  
one of the main creators of UNIX.
Nov 10 2009
parent reply Justin Johansson <no spam.com> writes:
Phil Deets Wrote:


 On Tue, 10 Nov 2009 23:09:13 -0500, Justin Johansson <no spam.com> wrote:
 

 Knud Soerensen Wrote:


 Google have made a new language.

 See http://www.youtube.com/watch?v=rKnDgT73v8s


 Some of the people in the Go team include Ken Thompson and Rob Pike.

 As a matter of interest these people have been mentioned in a few past D  
 NG articles.
 Apparently Ken Thompson designed UTF-8.


 
 Sorry if I'm stating something you already know, but Ken Thompson also was  
 one of the main creators of UNIX.


Thanks.  I had forgotten that.  Whenever a new language comes on the horizon,
it's
useful to know exactly who are the people behind it.

I tried watching the YT video but, as unfortunately my Three mobile broadband
is just so 
s l o w, I stopped after 10 mins. (Anybody thinking of Three in your neck of
the woods for broadband forget it.)

Anyway I think the speaker (Rob Pike) said something along the lines that "no
new systems
programming language has been developed in the last ten years" and there was no
mention
of D (at least that I picked up).  Wonder if they ever looked at D or if Walter
knows any of
these people apart from just name?

Justin
Nov 10 2009
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Justin Johansson wrote:


 Anyway I think the speaker (Rob Pike) said something along the lines that "no
new systems
 programming language has been developed in the last ten years" and there was
no mention
 of D (at least that I picked up).  Wonder if they ever looked at D or if
Walter knows any of
 these people apart from just name?


They started the project in "late 2007", which is one year after D was
released. So I guess D is not considered a "new major systems language".

"By mid 2008 the language was mostly designed and the implementation 
(compiler, run-time) starting to work."  --from the Go Tech talk slides

--anders
Nov 10 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:hddph6$2r9t$1 digitalmars.com...

 Justin Johansson wrote:


 Anyway I think the speaker (Rob Pike) said something along the lines that 
 "no new systems
 programming language has been developed in the last ten years" and there 
 was no mention
 of D (at least that I picked up).  Wonder if they ever looked at D or if 
 Walter knows any of
 these people apart from just name?


 They started the project in "late 2007", which is one year after D was
 released. So I guess D is not considered a "new major systems language".

 "By mid 2008 the language was mostly designed and the implementation 
 (compiler, run-time) starting to work."  --from the Go Tech talk slides

 --anders


I was using D well before late 2006 (and never had any sort of special 
non-public access).

From some of the stuff I saw on the tutorial page, I noticed a few things 
that seemed like they could easily have been inspired from D.

Of course, being a longtime D user, that "no new systems programming 
language has been developed in the last ten years" kinda pisses me 
off...Although not as pissed as I'll be if the connection with google causes 
its use and popularity to soar past D...from the example code it looks like 
D but with a really garbled and annoying syntax.
Nov 11 2009
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Nick Sabalausky wrote:


 They started the project in "late 2007", which is one year after D was
 released. So I guess D is not considered a "new major systems language".




...

 I was using D well before late 2006 (and never had any sort of special 
 non-public access).


I meant the 1.0 release, in case that wasn't obvious ?
The D project was started ten years ago (1999), I think.

Started in 2004 myself, when GDC was first released...
DMD didn't run on my Mac, so never noticed it earlier.

--anders
Nov 11 2009
parent reply "Nick Sabalausky" <a a.a> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:hde7e8$107g$1 digitalmars.com...

 Nick Sabalausky wrote:


 They started the project in "late 2007", which is one year after D was
 released. So I guess D is not considered a "new major systems language".




 ...

 I was using D well before late 2006 (and never had any sort of special 
 non-public access).


 I meant the 1.0 release, in case that wasn't obvious ?
 The D project was started ten years ago (1999), I think.


Ah. Since 1.0 was just an arbitrary stake-in-the-ground some time after D 
was already perfectly usable,so I've never thought of 1.0's release as being 
anything special. So to me, when "D was released" means whenever the actual 
first release was (or whenever it became practical for actual use, 
subjective as that may be), and the only thing notable about the time of 
1.0's release was that it was somewhere roughly around that point when D2 
branched off.
Nov 11 2009
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Nick Sabalausky wrote:


 I meant the 1.0 release, in case that wasn't obvious ?
 The D project was started ten years ago (1999), I think.


 
 Ah. Since 1.0 was just an arbitrary stake-in-the-ground some time after D 
 was already perfectly usable,so I've never thought of 1.0's release as being 
 anything special.


Sure, I think the "official" web site http://d-programming-language.org/
and the 1.0 release that followed was mostly to generate some interest ?

I guess the next line-in-the-sand will be the book release, and whatever
version of DMD 2.x (compiler and specification) that will come with it ?

--anders
Nov 11 2009
parent "Nick Sabalausky" <a a.a> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:hde8r9$1347$1 digitalmars.com...

 Nick Sabalausky wrote:


 I meant the 1.0 release, in case that wasn't obvious ?
 The D project was started ten years ago (1999), I think.


 Ah. Since 1.0 was just an arbitrary stake-in-the-ground some time after D 
 was already perfectly usable,so I've never thought of 1.0's release as 
 being anything special.


 Sure, I think the "official" web site http://d-programming-language.org/
 and the 1.0 release that followed was mostly to generate some interest ?

 I guess the next line-in-the-sand will be the book release, and whatever
 version of DMD 2.x (compiler and specification) that will come with it ?


Perhaps, but this time around there seems to be a major effort to get as 
many details as possible worked out before drawing that line. (Yay! :) )
Nov 11 2009
prev sibling next sibling parent Justin Johansson <no spam.com> writes:
Nick Sabalausky Wrote:


 "Anders F Björklund" <afb algonet.se> wrote in message 
 news:hddph6$2r9t$1 digitalmars.com...

 Justin Johansson wrote:


 Anyway I think the speaker (Rob Pike) said something along the lines that 
 "no new systems
 programming language has been developed in the last ten years" and there 
 was no mention
 of D (at least that I picked up).  Wonder if they ever looked at D or if 
 Walter knows any of
 these people apart from just name?


 They started the project in "late 2007", which is one year after D was
 released. So I guess D is not considered a "new major systems language".

 "By mid 2008 the language was mostly designed and the implementation 
 (compiler, run-time) starting to work."  --from the Go Tech talk slides

 --anders


 
 I was using D well before late 2006 (and never had any sort of special 
 non-public access).
 
 From some of the stuff I saw on the tutorial page, I noticed a few things 
 that seemed like they could easily have been inspired from D.
 
 Of course, being a longtime D user, that "no new systems programming 
 language has been developed in the last ten years" kinda pisses me 
 off...Although not as pissed as I'll be if the connection with google causes 
 its use and popularity to soar past D...from the example code it looks like 
 D but with a really garbled and annoying syntax. 


 
Did you read the FAQ?  This will really piss you off :-(

"What is the purpose of the project?"

http://golang.org/doc/go_faq.html

Slashdotters are pretty quick to the announcement as well, just today ...

http://developers.slashdot.org/story/09/11/11/0210212/Go-Googles-New-Open-Source-Programming-Language

How many comments to you think this story got over there?
Nov 11 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Wed, Nov 11, 2009 at 3:14 AM, Nick Sabalausky <a a.a> wrote:


 Of course, being a longtime D user, that "no new systems programming
 language has been developed in the last ten years" kinda pisses me
 off...


"No new *major* systems language" is what they said.  "Major" is a
marketing word that can mean whatever you want it to.  If you define
"major" as say a user base at least 5% of C or C++'s, then yeh, D
probably isn't there.  Or you could measure the number of D books in
your local bookstore vs C++ books.

--bb
Nov 11 2009
prev sibling next sibling parent reply "Phil Deets" <pjdeets2 gmail.com> writes:
On Tue, 10 Nov 2009 21:21:27 -0500, Knud Soerensen  
<4tuu4k002 sneakemail.com> wrote:


 Google have made a new language.

 See http://www.youtube.com/watch?v=rKnDgT73v8s


I watched the video. The language sounds like a cross between Smalltalk  
and C, but with better concurrency support. I was somewhat underwhelmed,  
but I do think the concurrency features are interesting.
Nov 10 2009
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Phil Deets (pjdeets2 gmail.com)'s article

 On Tue, 10 Nov 2009 21:21:27 -0500, Knud Soerensen
 <4tuu4k002 sneakemail.com> wrote:

 Google have made a new language.

 See http://www.youtube.com/watch?v=rKnDgT73v8s


 I watched the video. The language sounds like a cross between Smalltalk
 and C, but with better concurrency support. I was somewhat underwhelmed,
 but I do think the concurrency features are interesting.


I watched part of the video, though I'm curious enough about it that I'll
probably
watch the rest later, esp. if Go keeps coming up around here.  However, for me
personally "normal" static typing is too rigid for just about anything.  I would
never choose a language that didn't either have duck typing or good templates
that
basically amount to compile-time duck typing.  I'm not sure how Go addresses
this.
Nov 10 2009
parent Michael Farnsworth <mike.farnsworth gmail.com> writes:
On 11/10/2009 09:02 PM, dsimcha wrote:

 == Quote from Phil Deets (pjdeets2 gmail.com)'s article

 On Tue, 10 Nov 2009 21:21:27 -0500, Knud Soerensen
 <4tuu4k002 sneakemail.com>  wrote:

 Google have made a new language.

 See http://www.youtube.com/watch?v=rKnDgT73v8s


 I watched the video. The language sounds like a cross between Smalltalk
 and C, but with better concurrency support. I was somewhat underwhelmed,
 but I do think the concurrency features are interesting.


 I watched part of the video, though I'm curious enough about it that I'll
probably
 watch the rest later, esp. if Go keeps coming up around here.  However, for me
 personally "normal" static typing is too rigid for just about anything.  I
would
 never choose a language that didn't either have duck typing or good templates
that
 basically amount to compile-time duck typing.  I'm not sure how Go addresses
this.


See http://golang.org/doc/go_lang_faq.html#inheritance

"Rather than requiring the programmer to declare ahead of time that two 
types are related, in Go a type automatically satisfies any interface 
that specifies a subset of its methods. Besides reducing the 
bookkeeping, this approach has real advantages. Types can satisfy many 
interfaces at once, without the complexities of traditional multiple 
inheritance."

That, my friend, is duck typing.

Incidentally, with pure duck typing I tend to feel a little bit...naked, 
unconstrained.  So while it's very flexible and allows any compatible 
types to "just work," it also makes it a little hard to define any 
useful constraints in practice.  Smalltalk makes this a tiny bit better 
because of its message passing syntax (the keyword arguments make things 
a little more clear), but I think D strikes a nice balance with 
templates and metaprogramming techniques, while still having some 
type-constrained relationships where they make sense.

-Mike
Nov 10 2009
prev sibling next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
On Wed, 11 Nov 2009 03:21:27 +0100, Knud Soerensen wrote:


 Google have made a new language.
 
 See http://www.youtube.com/watch?v=rKnDgT73v8s


You could take like the first 15 minutes and just replace the word 'Go' 
with D.

I found the way interfaces were handled to be quit interesting, similar 
to how Andrei is doing his range implementation. Not sure if an object 
hierarchy would get in the way of having it in D though.

For those who didn't/can't watch: A function requires a specific 
interface; the compiler checks that the functions are implemented at 
compile-time.
Nov 10 2009
prev sibling next sibling parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Knud Soerensen wrote:

 Google have made a new language.


Interestingly there was already a "Go!" language,
much like when Sun introduced their "D" language.

http://code.google.com/p/go/issues/detail?id=9
http://www.lulu.com/content/paperback-book/lets-go/641689

--anders
Nov 11 2009
prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
Looks interesting.

* Uses a module system
* Built-in arrays are value types.
* Python like slice syntx  a[lo:hi]
* immutable strings
* switch has no break.  Use "fallthrough" to fallthrough.
* Nested functions
* First class tuples  ( a,b =3D func(),   a,b=3Db,a )
* :=3D for assignment
* Uses "var" to declare variables (this was chapmpioned by some here
instead of auto)
* varible type comes after declaration and is optional
* return type of functions comes after parameters
* No Windows port yet.  That's going to be a bit of a roadblock to
widespread adoption.
* Iota!?
* ...

There's a lot there that looks either like D or like things people in
the D community have argued for.
And it's got the billion dollar backing of a major company.

--bb

On Tue, Nov 10, 2009 at 6:21 PM, Knud Soerensen
<4tuu4k002 sneakemail.com> wrote:

 Google have made a new language.

 See http://www.youtube.com/watch?v=3DrKnDgT73v8s

 --
 Join me on
 CrowdNews =A0http://crowdnews.eu/users/addGuide/42/
 Facebook =A0 http://www.facebook.com/profile.php?id=3D1198821880
 Linkedin =A0 http://www.linkedin.com/pub/0/117/a54
 Mandala =A0 =A0http://www.mandala.dk/view-profile.php4?profileID=3D7660
Nov 11 2009
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 Looks interesting.
 
 * Uses a module system
 * Built-in arrays are value types.
 * Python like slice syntx  a[lo:hi]
 * immutable strings
 * switch has no break.  Use "fallthrough" to fallthrough.
 * Nested functions
 * First class tuples  ( a,b = func(),   a,b=b,a )
 * := for assignment
 * Uses "var" to declare variables (this was chapmpioned by some here
 instead of auto)
 * varible type comes after declaration and is optional
 * return type of functions comes after parameters
 * No Windows port yet.  That's going to be a bit of a roadblock to
 widespread adoption.
 * Iota!?
 * ...
 
 There's a lot there that looks either like D or like things people in
 the D community have argued for.


It's also missing quite a few things that people in the D community take 
for granted.


 And it's got the billion dollar backing of a major company.


That part I missed.


Andrei
Nov 11 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Wed, Nov 11, 2009 at 7:56 AM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 Looks interesting.

 * Uses a module system
 * Built-in arrays are value types.
 * Python like slice syntx =A0a[lo:hi]
 * immutable strings
 * switch has no break. =A0Use "fallthrough" to fallthrough.
 * Nested functions
 * First class tuples =A0( a,b =3D func(), =A0 a,b=3Db,a )
 * :=3D for assignment
 * Uses "var" to declare variables (this was chapmpioned by some here
 instead of auto)
 * varible type comes after declaration and is optional
 * return type of functions comes after parameters
 * No Windows port yet. =A0That's going to be a bit of a roadblock to
 widespread adoption.
 * Iota!?
 * ...

 There's a lot there that looks either like D or like things people in
 the D community have argued for.


 It's also missing quite a few things that people in the D community take =


for

 granted.


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?   (Also recall that D lacked even templates until long after
its inception -- so if the language can muster some level of
acceptance, probably popular demand will eventually lead to adding
more of those missing features.)


 And it's got the billion dollar backing of a major company.


 That part I missed.


I should have said "backing of a billion-dollar company" not
"billion-dollar backing".  Certainly it doesn't have the latter.  But
it has backing in some sense, anyway.  Even if it's the 20% time of
five guys, Google's paying them for that time.  And whether or not
they *have* any deep pocket backing, people will perceive a tie
between the company and the language, which means it can ride on the
wave of Google's excellent mind-share, esp. among programmers.   Ken
Thompson is also a very well-known and respected name from Unix and
Plan 9  (and Rob Pike too?).  These are all very strong marketing
advantages.  Looking to the future, I suspect if Google does adopt a
new systems language, it's much more likely to come from within than
be NIH.  Because that way they'll have much more control over it if,
and not have to worry so much about IP issues (not that Google spends
much time worrying about IP...), etc.   And if it becomes widely used
in Google, then that's a very bouncy spring board from which to foist
it on the rest of the world.

It's definitely going to be a strong competitor for D's audience.

--bb
Nov 11 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Nov 11 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
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. =A0:-) 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


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.


 . RAII
 . immutability for anything but strings
 . vector operations
 . operator overloading
 . purity
 . CTFE
 . unit testing
 . 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)
 . delegates
 . reference parameters

 Not sure if it has closures or not.


Yes, he says in the video that funcs are full closures.


 And of course a lot of minor ones,

 . no _ in integer literals
 . no nesting comments
 . no entities


Also
. no pointer arithmetic

Not sure what I think about that.  Can you even have a "systems"
language that doesn't allow pointer manipulation?

But that's a good list.  In the video he makes it sound like generics
will probably happen eventually, they're just not sure how best to do
it yet.   Lack of operator overloading is annoying.  I guess that's
not unexpected given that their mission was to write a good language
for writing servers.  But if they don't do something about it (among
other things) they'll miss out on the game and numerics audience.

--bb
Nov 11 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:

 Not sure what I think about that.  Can you even have a "systems"
 language that doesn't allow pointer manipulation?


If you cannot implement a GC in a language, then it ain't a systems 
language. I'm pretty sure that's a necessary criteria, less sure it is a 
sufficient one.



 But that's a good list.  In the video he makes it sound like generics
 will probably happen eventually, they're just not sure how best to do
 it yet.   Lack of operator overloading is annoying.  I guess that's
 not unexpected given that their mission was to write a good language
 for writing servers.  But if they don't do something about it (among
 other things) they'll miss out on the game and numerics audience.


I was talking to David Held (if you haven't met him yet, you should at 
the next NWCPP meeting!). He has a lot of corporate experience with 
Java. Something he said piqued my interest when we were talking about 
IDEs. He said that IDEs for Java were necessary, and one reason why was 
because with "one click" the IDE will automatically generate hundreds of 
lines of boilerplate.

It seems that the Java IDE is serving the need that other languages have 
macros, templates, metaprogramming and other generative programming 
features for. If D needed an IDE to generate such boilerplate, I'd 
consider D to have a severe lack of expressive power.

Go doesn't seem to have any generative abilities.
Nov 11 2009
parent div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Walter Bright wrote:

 He said that IDEs for Java were necessary, and one reason why was
 because with "one click" the IDE will automatically generate hundreds of
 lines of boilerplate.


That's the best short argument against Java I've heard so far.

- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFK+zbZT9LetA9XoXwRAtczAJ9BDqhjy8ICGYJUMcDdW5J73DYxDQCgwjKp
jixeXWPd94RgnQni2UajIqE=
=kNtp
-----END PGP SIGNATURE-----
Nov 11 2009
prev sibling parent Leandro Lucarella <llucax gmail.com> writes:
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)
Nov 11 2009
prev sibling next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
On Wed, Nov 11, 2009 at 11:25 AM, Bill Baxter <wbaxter gmail.com> wrote:

 But that's a good list. =A0In the video he makes it sound like generics
 will probably happen eventually, they're just not sure how best to do
 it yet.


Just noticed, The Language FAQ[1] says the same thing about
exceptions.  They're interested, just not sure how to do it.

[1] http://golang.org/doc/go_lang_faq.html#exceptions

--bb
Nov 11 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:

 On Wed, Nov 11, 2009 at 11:25 AM, Bill Baxter <wbaxter gmail.com> wrote:

 But that's a good list.  In the video he makes it sound like generics
 will probably happen eventually, they're just not sure how best to do
 it yet.


 
 Just noticed, The Language FAQ[1] says the same thing about
 exceptions.  They're interested, just not sure how to do it.
 
 [1] http://golang.org/doc/go_lang_faq.html#exceptions



Exceptions are a fair amount of work to implement. I wouldn't expect it 
soon.
Nov 11 2009
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Wed, Nov 11, 2009 at 11:25 AM, Bill Baxter <wbaxter gmail.com> wrote:

 But that's a good list.  In the video he makes it sound like generics
 will probably happen eventually, they're just not sure how best to do
 it yet.


 
 Just noticed, The Language FAQ[1] says the same thing about
 exceptions.  They're interested, just not sure how to do it.
 
 [1] http://golang.org/doc/go_lang_faq.html#exceptions


So they are roughly where D was eleven years ago.

One thing I dislike about Go is the incult attitude it fosters. 
Apparently its creators weren't aware about the existence of D, which is 
quite difficult in this day and age (D is the *second* result when 
searching for system programming language with Google after the 
obligatory Wikipedia entry, so it takes a lot of effort to dismiss it as 
not being "major" and essentially pretend it doesn't exist). The authors 
failed to even exercise due diligence - there's a language called Go! 
that has even a book written about (the news is all over 
http://www.reddit.com/r/programming/).

Also, the language does not make use of many advances that PL technology 
has made in the recent years. These things combined are quite indicative 
of an attitude towards language design that I highly disapprove of.

Funny detail - one goal is to avoid "stuttering" (one of the first 
examples in the video). Yet "Hello, World" defines package main and 
function main in the main file, and imports fmt "fmt".



Andrei
Nov 11 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Wed, Nov 11, 2009 at 1:34 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 On Wed, Nov 11, 2009 at 11:25 AM, Bill Baxter <wbaxter gmail.com> wrote:

 But that's a good list. =A0In the video he makes it sound like generics
 will probably happen eventually, they're just not sure how best to do
 it yet.


 Just noticed, The Language FAQ[1] says the same thing about
 exceptions. =A0They're interested, just not sure how to do it.

 [1] http://golang.org/doc/go_lang_faq.html#exceptions


 So they are roughly where D was eleven years ago.


Yeh.  :-)   But unlike D 11 years ago, they have 5 guys and a budget
to hire interns.  And the ability to hire more full-timers if it
catches on.


 One thing I dislike about Go is the incult attitude it fosters. Apparentl=


y

 its creators weren't aware about the existence of D, which is quite
 difficult in this day and age (D is the *second* result when searching fo=


r

 system programming language with Google after the obligatory Wikipedia
 entry, so it takes a lot of effort to dismiss it as not being "major" and
 essentially pretend it doesn't exist).


I think Walter even gave a talk at Google, once.  Didn't he?


 The authors failed to even exercise
 due diligence - there's a language called Go! that has even a book writte=


n

 about (the news is all over http://www.reddit.com/r/programming/).


Yeh, but you have to admit it *is* a good name for their language,
with Ogle for the debugger.  And "Go!" !=3D "Go".  And it's hard to
trademark a common word.  And Google doesn't really believe in IP
anyway.  And they can probably buy the name from the guy if it comes
to that anyway.  So while I'm sure it sucks for the Go! guy, at least
he's getting some publicity for his language out of it now.


 Also, the language does not make use of many advances that PL technology =


has

 made in the recent years. These things combined are quite indicative of a=


n

 attitude towards language design that I highly disapprove of.


I have to admit I was surprised that they don't have any kind of story
about compile-time code generation.  The website doesn't even mention
it anywhere as far as I can see.  They talk about generics in the FAQ
as if that's some kind of pinnacle of PL design rather than a
compromise settled on by languages that can't manage full compile-time
capabilities.


 Funny detail - one goal is to avoid "stuttering" (one of the first exampl=


es

 in the video). Yet "Hello, World" defines package main and function main =


in

 the main file, and imports fmt "fmt".


I think  import fmt "fmt"  is a renamed import.  So it could have been
just import "fmt" or  import foo "fmt".   And he mutters something
about the "package main" maybe going away.  But yeh, funny.

--bb
Nov 11 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
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.
Nov 11 2009
prev sibling parent reply hasenj <hasan.aljudy gmail.com> writes:
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.
Nov 11 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Nov 11 2009
parent reply hasenj <hasan.aljudy gmail.com> writes:
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?
Nov 11 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Nov 11 2009
next sibling parent reply Bill Baxter <wbaxter gmail.com> writes:
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
Nov 11 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
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.
Nov 11 2009
prev sibling next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
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/
Nov 11 2009
prev sibling parent "Joel C. Salomon" <joelcsalomon gmail.com> writes:
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
Nov 12 2009
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== 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.
Nov 11 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
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.
Nov 11 2009
prev sibling next sibling parent hasenj <hasan.aljudy gmail.com> writes:
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.
Nov 11 2009
prev sibling parent reply "Joel C. Salomon" <joelcsalomon gmail.com> writes:
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
Nov 12 2009
parent "Robert Jacques" <sandford jhu.edu> writes:
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 :)
Nov 12 2009
prev sibling next sibling parent Nick B <"nick_NOSPAM_.barbalich" gmail.com> writes:
Bill Baxter wrote:

 On Wed, Nov 11, 2009 at 7:56 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 Looks interesting.







 
 I should have said "backing of a billion-dollar company" not
 "billion-dollar backing".  Certainly it doesn't have the latter.  But
 it has backing in some sense, anyway.  Even if it's the 20% time of
 five guys, Google's paying them for that time.  And whether or not
 they *have* any deep pocket backing, people will perceive a tie
 between the company and the language, which means it can ride on the
 wave of Google's excellent mind-share, esp. among programmers.   Ken
 Thompson is also a very well-known and respected name from Unix and
 Plan 9  (and Rob Pike too?).  These are all very strong marketing
 advantages.  Looking to the future, I suspect if Google does adopt a
 new systems language, it's much more likely to come from within than
 be NIH.  Because that way they'll have much more control over it if,
 and not have to worry so much about IP issues (not that Google spends
 much time worrying about IP...), etc.   And if it becomes widely used
 in Google, then that's a very bouncy spring board from which to foist
 it on the rest of the world.
 
 It's definitely going to be a strong competitor for D's audience.
 
 --bb


Bill - you are absolutely correct. It will be targeting the _same_ 
audience as D. It can be said that D now have a serious competitor.
Will Walter increase the marketing for D ?

Even though the current D developers will likely NOT move to Go, it is 
possible that new developers may not come to the D community in the 
future, in the same numbers.
Of course this all depends on how good Go actually is, and how easily 
they can build a community, and what leadership,  - and the quality of 
the  leadership -  they have.

Nick B
Nov 11 2009
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Bill Baxter wrote:

 On Wed, Nov 11, 2009 at 7:56 AM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 Bill Baxter wrote:

 Looks interesting.

 * Uses a module system
 * Built-in arrays are value types.
 * Python like slice syntx  a[lo:hi]
 * immutable strings
 * switch has no break.  Use "fallthrough" to fallthrough.
 * Nested functions
 * First class tuples  ( a,b = func(),   a,b=b,a )
 * := for assignment
 * Uses "var" to declare variables (this was chapmpioned by some here
 instead of auto)
 * varible type comes after declaration and is optional
 * return type of functions comes after parameters
 * No Windows port yet.  That's going to be a bit of a roadblock to
 widespread adoption.
 * Iota!?
 * ...

 There's a lot there that looks either like D or like things people in
 the D community have argued for.


 It's also missing quite a few things that people in the D community take for
 granted.


 
 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?   (Also recall that D lacked even templates until long after
 its inception -- so if the language can muster some level of
 acceptance, probably popular demand will eventually lead to adding
 more of those missing features.)
 

 And it's got the billion dollar backing of a major company.


 That part I missed.


 
 I should have said "backing of a billion-dollar company" not
 "billion-dollar backing".  Certainly it doesn't have the latter.  But
 it has backing in some sense, anyway.  Even if it's the 20% time of
 five guys, Google's paying them for that time.  And whether or not
 they *have* any deep pocket backing, people will perceive a tie
 between the company and the language, which means it can ride on the
 wave of Google's excellent mind-share, esp. among programmers.   Ken
 Thompson is also a very well-known and respected name from Unix and
 Plan 9  (and Rob Pike too?).  These are all very strong marketing
 advantages.  Looking to the future, I suspect if Google does adopt a
 new systems language, it's much more likely to come from within than
 be NIH.  Because that way they'll have much more control over it if,
 and not have to worry so much about IP issues (not that Google spends
 much time worrying about IP...), etc.   And if it becomes widely used
 in Google, then that's a very bouncy spring board from which to foist
 it on the rest of the world.
 
 It's definitely going to be a strong competitor for D's audience.


Possibly, but IMHO not on technical merit at all. It is many years 
behind becoming usable for a real system. It will be interesting how it 
plays out.

Andrei
Nov 11 2009
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-11-11 14:02:17 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:


 It's definitely going to be a strong competitor for D's audience.


 
 Possibly, but IMHO not on technical merit at all. It is many years 
 behind becoming usable for a real system. It will be interesting how it 
 plays out.


At least Go programs run on my computer. I can't say the same about D2 
(OS X 10.6 here).

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Nov 11 2009
parent Bill Baxter <wbaxter gmail.com> writes:
On Wed, Nov 11, 2009 at 2:00 PM, Michel Fortin
<michel.fortin michelf.com> wrote:

 On 2009-11-11 14:02:17 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> said:


 It's definitely going to be a strong competitor for D's audience.


 Possibly, but IMHO not on technical merit at all. It is many years behind
 becoming usable for a real system. It will be interesting how it plays out.


 At least Go programs run on my computer. I can't say the same about D2 (OS X
 10.6 here).


They don't run on mine or 95% of the other PCs out in the world  (Windows here).

--bb
Nov 11 2009
prev sibling parent reply BLS <windevguy hotmail.de> writes:
On 11/11/2009 18:35, 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?   (Also recall that D lacked even templates until long after
 its inception -- so if the language can muster some level of
 acceptance, probably popular demand will eventually lead to adding
 more of those missing features.)


No OOP,
a NoGo language for me.
Nov 11 2009
parent hasenj <hasan.aljudy gmail.com> writes:
BLS wrote:

 On 11/11/2009 18:35, 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?   (Also recall that D lacked even templates until long after
 its inception -- so if the language can muster some level of
 acceptance, probably popular demand will eventually lead to adding
 more of those missing features.)


 
 No OOP,
 a NoGo language for me.
Nov 11 2009
prev sibling next sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Wed, 11 Nov 2009 09:59:36 -0500, Bill Baxter <wbaxter gmail.com> wrote:


 Looks interesting.

 * Uses a module system
 * Built-in arrays are value types.
 * Python like slice syntx  a[lo:hi]
 * immutable strings
 * switch has no break.  Use "fallthrough" to fallthrough.
 * Nested functions
 * First class tuples  ( a,b = func(),   a,b=b,a )
 * := for assignment
 * Uses "var" to declare variables (this was chapmpioned by some here
 instead of auto)
 * varible type comes after declaration and is optional
 * return type of functions comes after parameters
 * No Windows port yet.  That's going to be a bit of a roadblock to
 widespread adoption.
 * Iota!?
 * ...

 There's a lot there that looks either like D or like things people in
 the D community have argued for.
 And it's got the billion dollar backing of a major company.

 --bb

 On Tue, Nov 10, 2009 at 6:21 PM, Knud Soerensen
 <4tuu4k002 sneakemail.com> wrote:

 Google have made a new language.

 See http://www.youtube.com/watch?v=rKnDgT73v8s

 --
 Join me on
 CrowdNews  http://crowdnews.eu/users/addGuide/42/
 Facebook   http://www.facebook.com/profile.php?id=1198821880
 Linkedin   http://www.linkedin.com/pub/0/117/a54
 Mandala    http://www.mandala.dk/view-profile.php4?profileID=7660




  * := isn't used for assignment, it's used for automatic type deduction  
and assignment:
  In Go: t := T(5);
  In D:  auto t = T(5);

  * var is also required for standard, typed variable declaration in  
addition to automatic deduction
  In Go: var t float;
  In D:  float t;

  * Uses '+' for concatenation
Nov 11 2009
parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-11-11 10:57:20 -0500, "Robert Jacques" <sandford jhu.edu> said:


   * Uses '+' for concatenation


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.

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Nov 11 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
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:


 =A0* 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 qu=


ite

 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
Nov 11 2009
parent Pablo Ripolles <in-call gmx.net> writes:
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!
Nov 12 2009
prev sibling next sibling parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Bill Baxter wrote:

 Looks interesting.
 


And the go compiler isn't written in go because of the difficulties of
bootstrapping.


 There's a lot there that looks either like D or like things people in
 the D community have argued for.
 And it's got the billion dollar backing of a major company.
 
 --bb


It isn't clear to me whether google is explicitly endorsing go, or those
5 engineers are just working on it in their 20% time.
Nov 11 2009
prev sibling parent "Joel C. Salomon" <joelcsalomon gmail.com> writes:
On 11/11/2009 9:59 AM, Bill Baxter wrote:

 Looks interesting.

 * ...

 There's a lot there that looks either like D or like things people in
 the D community have argued for.


The important thing about Go is its concurrency model.  Combine the CSP 
model with Bartosz’s type system and D wins.

—Joel Salomon
Nov 11 2009
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
I'm affraid, goroutines and interfaces are the only interesting things in the
language.
Nov 11 2009
parent hasenj <hasan.aljudy gmail.com> writes:
Kagamin wrote:

 I'm affraid, goroutines and interfaces are the only interesting things in the
language.


And "channels".

It's not the "only" interesting thing; what's interesting is they put 
these things on top of an restricted/improved subset of C (with a 
modified syntax).
Nov 11 2009
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
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:
 
 . inline assembler
 . interface to C


Their definition of "systems programming language" is clearly different from
mine then.  Shouldn't this classify Java as a systems language as well?
Nov 11 2009
parent Bill Baxter <wbaxter gmail.com> writes:
On Wed, Nov 11, 2009 at 2:54 PM, Sean Kelly <sean invisibleduck.org> wrote:

 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. =A0:-) What are some things is i=






t

 missing?


 Off the top of my head, some major ones:

 . inline assembler
 . interface to C


 Their definition of "systems programming language" is clearly different f=


rom mine then. =A0Shouldn't this classify Java as a systems language as wel=
l?

I'm starting to think their definition must just be "compiles to
native code" maybe together with "has static typing".

--bb
Nov 11 2009
prev sibling next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
Bill Baxter Wrote:

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


I think so.  It sounds like they basically just have a thread pool that
executes fibers, and D 2.0 already has fibers.


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


In the description, it sounds like they're just talking about the stacks
resizing on demand.  Maybe the "segmented" bit comes from the stack not being
contiguous in memory, but that sounds a bit weird.  Either way, the
underpinnings are already in place in D's fibers for auto stack growth (thanks
to Mikola Lysenko), so I don't see this as a compiler-dependent feature or
anything like that.
Nov 11 2009
parent reply Bill Baxter <wbaxter gmail.com> writes:
On Wed, Nov 11, 2009 at 9:00 PM, Sean Kelly <sean invisibleduck.org> wrote:

 Bill Baxter Wrote:

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


 I think so. =A0It sounds like they basically just have a thread pool that=


 executes fibers, and D 2.0 already has fibers.

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


 In the description, it sounds like they're just talking about the stacks =


resizing on demand. =A0Maybe the "segmented" bit comes from the stack not b=
eing contiguous in memory, but that sounds a bit weird. =A0Either way, the =
underpinnings are already in place in D's fibers for auto stack growth (tha=
nks to Mikola Lysenko), so I don't see this as a compiler-dependent feature=
 or anything like that.


So fibers are there today in D2?  I didn't realize that bit of Tango's
runtime was now rolled in.  Cool!  Are they documented anywhere?
Looks like docs for all of core are not yet being shown on
digitalmars.com.

--bb



 Nov 12 2009



  parent  Mike Parker <aldacron gmail.com>  writes:


Bill Baxter wrote:

 On Wed, Nov 11, 2009 at 9:00 PM, Sean Kelly <sean invisibleduck.org> wrote:

 Bill Baxter Wrote:

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


 I think so.  It sounds like they basically just have a thread pool that
executes fibers, and D 2.0 already has fibers.


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


 In the description, it sounds like they're just talking about the stacks
resizing on demand.  Maybe the "segmented" bit comes from the stack not being
contiguous in memory, but that sounds a bit weird.  Either way, the
underpinnings are already in place in D's fibers for auto stack growth (thanks
to Mikola Lysenko), so I don't see this as a compiler-dependent feature or
anything like that.


 
 So fibers are there today in D2?  I didn't realize that bit of Tango's
 runtime was now rolled in.  Cool!  Are they documented anywhere?
 Looks like docs for all of core are not yet being shown on
 digitalmars.com.
 
 --bb


Try here:

http://www.dsource.org/projects/druntime/browser/trunk/src/common/core/thread.d#L2640



 Nov 12 2009



prev sibling next sibling parent  Eldar Insafutdinov <e.insafutdinov gmail.com>  writes:


Knud Soerensen Wrote:


 Google have made a new language.
 
 See http://www.youtube.com/watch?v=rKnDgT73v8s
 
 -- 
 Join me on
 CrowdNews  http://crowdnews.eu/users/addGuide/42/
 Facebook   http://www.facebook.com/profile.php?id=1198821880
 Linkedin   http://www.linkedin.com/pub/0/117/a54
 Mandala    http://www.mandala.dk/view-profile.php4?profileID=7660


Some things I don't like, but OOP model in Go really appeals to me. That's
basically all I wanted. They simplified things a lot and got a transparent and
flexible system, at a cost of dropping function overloads for instance.



 Nov 12 2009



prev sibling next sibling parent reply Mike Hearn <mike plan99.net>  writes:


 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.


For what it's worth there's a segment of the Google engineering community that
would love to use D internally (I'm one of them). 

Go is still very new and isn't used much here. Actually, I don't know of
anything that it's used for off the top of my head. Google is based on C++ and
Java with Python being used for a lot of glue/admin type stuff.

Personally, I'd rather use D2 than Go for my next project - especially given
the c++ compatibility. With a few minor improvements (eg namespace support)
that'd save a lot of time. But I don't know of anybody doing the necessary work
to make it usable here, and besides, there's a lot of resistance to introducing
new languages without a really good reason. D2 is close to being a Really Good
Reason all on its own IMO, but the inertia is huge. How do you find a code
reviewer for something written in D? What about compiler quality? Who will
write the style guideline and do readability reviews?  (you have to pass a
"readability" review for a language before you're allowed to check in code
written with it).



 Nov 12 2009



  parent reply Walter Bright <newshound1 digitalmars.com>  writes:


Mike Hearn wrote:

 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.


 
 For what it's worth there's a segment of the Google engineering
 community that would love to use D internally (I'm one of them).
 
 Go is still very new and isn't used much here. Actually, I don't know
 of anything that it's used for off the top of my head. Google is
 based on C++ and Java with Python being used for a lot of glue/admin
 type stuff.
 
 Personally, I'd rather use D2 than Go for my next project -
 especially given the c++ compatibility. With a few minor improvements
 (eg namespace support) that'd save a lot of time. But I don't know of
 anybody doing the necessary work to make it usable here, and besides,
 there's a lot of resistance to introducing new languages without a
 really good reason. D2 is close to being a Really Good Reason all on
 its own IMO, but the inertia is huge. How do you find a code reviewer
 for something written in D? What about compiler quality? Who will
 write the style guideline and do readability reviews?  (you have to
 pass a "readability" review for a language before you're allowed to
 check in code written with it).


This is very interesting to hear.

If there is anything I can do to help any adoption of D at Google, 
please let me know.



 Nov 12 2009



  parent reply Mike Hearn <mike plan99.net>  writes:


Walter Bright Wrote:

 This is very interesting to hear.
 
 If there is anything I can do to help any adoption of D at Google, 
 please let me know.


Thanks, I will. Off hand the only thing I can think of is "finish D2 and commit
to it being supported/stable for a few years" :-) I realize there are already
interesting ideas kicking around for D3 but if they can be integrated in a
backwards compatible way ....

Anyway, the amount of work required to integrate a new general purpose language
at Google is pretty big, it'd probably be several 20% projects worth of work
over a period of about half a year. For illustration here are a few of the
tasks that'd be either required or strongly wanted (some stuff is still
confidential and I can't mention). I'm not suggesting this list is typical of
large companies but it might prove interesting anyway.


- Integration of a compiler with our in-house build system (proprietary). If
it's GCC based that's better.

- Some kind of standard unit testing framework that the testing infrastructure
knows how to drive. If it works similar to the ones we use for C++ that's
better:
http://code.google.com/p/googletest/
http://code.google.com/p/googlemock/

- Protocol buffer support
http://code.google.com/p/protobuf/

- google style command line flags implementation:
http://code.google.com/p/google-gflags/

- Style guide: It's an open question whether this would purely be how code
looks or like the C++ guide also restrict some features. D is a very feature
rich language even compared to C++. I'm not sure if expecting developers and
reviewers to be familiar with *every* feature is realistic or worth the cost.
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

- The aforementioned readability reviews, reviewers need to be found (they are
volunteers) and trained, Perforce needs to be taught about the new filetypes:
http://1-800-magic.blogspot.com/2008/01/after-8-months-no-longer-noogler.html

- Training materials so engineers who haven't encountered D before can get up
to speed quickly, at least to the level where they can do code reviews even if
they aren't a master of all the features.

- By default emacs/vim at google import customizations for our environment,
integrating a d-mode with that would be nice.

- Bindings to the core libraries for accessing things like GFS/BigTable and
doing RPCs: optional but the utility of any language that can't use them is
limited. C++ compatibility would certainly make this easier but SWIG
integration would make it even easier still, as we already have SWIG set up for
Python. Figuring out an easy way to integrate the garbage collected world with
the manually managed world is also a trick. I presume the Python bindings
already figured this out but it'd obviously be nice if the bindings could be as
thin as possible.


Of all those, the last would be the most work. The google "standard library" is
a huge collection of robust and well written code - everything from well known
stuff like BigTable down to custom threading and malloc libraries. The nice
things D brings to the table can't compensate for the loss of that codebase. I
haven't tried binding stuff into D, although given that it's got some C/C++
compatibility it's way ahead of Python and Java already.



 Nov 17 2009



 next sibling parent reply bearophile <bearophileHUGS lycos.com>  writes:


Mike Hearn:


With a few minor improvements (eg namespace support) that'd save a lot of time.<


This change to D language is not planned. You can explain why you think
namespace support is useful (and you can explain those other minor improvements
too).



- Integration of a compiler with our in-house build system (proprietary). If
it's GCC based that's better.<


There's a D compiled based on GCC, but at the moment the best D1 compiler is
LDC, based on LLVM, especially if you care for top performance of the binary.



If it works similar to the ones we use for C++ that's better:<


I hope D will do better here :-) But it will take time.



D is a very feature rich language even compared to C++.<


But usually D features are designed to be safer, higher level, less tricky and
more handy, and sometimes slower. Go designers have removed almost everything,
so when you use Go you don't need a restrictive style guide like Google C++ one
that forbids people to use several language features :-)



 - By default emacs/vim at google import customizations for our environment,
integrating a d-mode with that would be nice.<


This is something that probably needs to be done regardless possible D usage at
Google.



I haven't tried binding stuff into D, although given that it's got some C/C++
compatibility it's way ahead of Python and Java already.<


C compatibility of D is good. C++ compatibility is currently limited by design.

If Google hires Walter he may use 50% of his free time developing D2 (as Guido
has 50% for Python itself, and 50% developing Python code).

Bye,
bearophile



 Nov 17 2009



  parent reply Bill Baxter <wbaxter gmail.com>  writes:


On Tue, Nov 17, 2009 at 7:07 AM, bearophile <bearophileHUGS lycos.com> wrote:

 Mike Hearn:


With a few minor improvements (eg namespace support) that'd save a lot of time.<


 This change to D language is not planned. You can explain why you think
namespace support is useful (and you can explain those other minor improvements
too).


To be more specific, Walter thinks is good enough namespace support
(in addition to the fact that every module is a namespace).

struct Namespace {
     static:
     // ...
}

If you need something more, then it would be great if you could explain it.

--bb



 Nov 17 2009



  parent reply Walter Bright <newshound1 digitalmars.com>  writes:


Bill Baxter wrote:

 On Tue, Nov 17, 2009 at 7:07 AM, bearophile <bearophileHUGS lycos.com> wrote:

 Mike Hearn:


 With a few minor improvements (eg namespace support) that'd save a lot of
time.<


 This change to D language is not planned. You can explain why you think
namespace support is useful (and you can explain those other minor improvements
too).


 
 To be more specific, Walter thinks is good enough namespace support
 (in addition to the fact that every module is a namespace).



Essentially all the uses of C++ namespaces I've seen map nicely onto D's 
module system.



 Nov 17 2009



  parent reply Bill Baxter <wbaxter gmail.com>  writes:


On Tue, Nov 17, 2009 at 4:12 PM, Walter Bright
<newshound1 digitalmars.com> wrote:

 Bill Baxter wrote:

 On Tue, Nov 17, 2009 at 7:07 AM, bearophile <bearophileHUGS lycos.com>
 wrote:

 Mike Hearn:


 With a few minor improvements (eg namespace support) that'd save a lot
 of time.<


 This change to D language is not planned. You can explain why you think
 namespace support is useful (and you can explain those other minor
 improvements too).


 To be more specific, Walter thinks is good enough namespace support
 (in addition to the fact that every module is a namespace).



 Essentially all the uses of C++ namespaces I've seen map nicely onto D's
 module system.


It's pretty common to see bits of a namespace get spread across many files.
There's no way to do that in D.  But I wouldn't go so far as to say
it's a necessity.

--bb



 Nov 17 2009



  parent  Walter Bright <newshound1 digitalmars.com>  writes:


Bill Baxter wrote:

 It's pretty common to see bits of a namespace get spread across many files.
 There's no way to do that in D.  But I wouldn't go so far as to say
 it's a necessity.


Yeah, Andrei and I talked about that and if it was a worthwhile 
capability. We decided it was a misfeature in that it would subvert 
encapsulation.

For example, if any source file can add functions to a namespace, how 
can function overloading be reliable?

C++ namespaces are often considered a failure, and this is one of the 
reasons.



 Nov 17 2009



prev sibling next sibling parent  Sean Kelly <sean invisibleduck.org>  writes:


Mike Hearn Wrote:

 
 - Bindings to the core libraries for accessing things like GFS/BigTable and
doing RPCs: optional but the utility of any language that can't use them is
limited. C++ compatibility would certainly make this easier but SWIG
integration would make it even easier still, as we already have SWIG set up for
Python. Figuring out an easy way to integrate the garbage collected world with
the manually managed world is also a trick. I presume the Python bindings
already figured this out but it'd obviously be nice if the bindings could be as
thin as possible.


RPC should be a part of messaging support, though possibly not right away. 
Socket IO in Phobos kind of stinks right now so that would need an overhaul
first.


 Of all those, the last would be the most work. The google "standard library"
is a huge collection of robust and well written code - everything from well
known stuff like BigTable down to custom threading and malloc libraries. The
nice things D brings to the table can't compensate for the loss of that
codebase. I haven't tried binding stuff into D, although given that it's got
some C/C++ compatibility it's way ahead of Python and Java already.


Sounds like Google may want to use a custom runtime.  It's pretty trivial to
replace core.thread from a project perspective, but dropping in a custom thread
implementation could take some work--the GC integration is tricky.



 Nov 17 2009



prev sibling  parent reply Walter Bright <newshound1 digitalmars.com>  writes:


Mike Hearn wrote:

 - Bindings to the core libraries for accessing things like
 GFS/BigTable and doing RPCs: optional but the utility of any language
 that can't use them is limited. C++ compatibility would certainly
 make this easier but SWIG integration would make it even easier
 still, as we already have SWIG set up for Python. Figuring out an
 easy way to integrate the garbage collected world with the manually
 managed world is also a trick. I presume the Python bindings already
 figured this out but it'd obviously be nice if the bindings could be
 as thin as possible.
 
 
 Of all those, the last would be the most work. The google "standard
 library" is a huge collection of robust and well written code -
 everything from well known stuff like BigTable down to custom
 threading and malloc libraries. The nice things D brings to the table
 can't compensate for the loss of that codebase. I haven't tried
 binding stuff into D, although given that it's got some C/C++
 compatibility it's way ahead of Python and Java already.


Of course, D has direct access to any and all C code, being binary 
compatible with the C ABI. D, in fact, relies on being linked with the 
standard C runtime library and startup code.

D2 has limited access to the C++ ABI:

. name mangling (i.e. global function overloading)
. single inheritance classes
. binary compatibility with C++ function calling conventions

I don't know the ABI for the Google libraries, but this should help.

Mixing D's gc world with manually managed memory isn't hard, as long as 
the following rules are followed:

1. don't allocate in one language and expect to free in another
2. keep a 'root' to all gc allocated data in the D side of the fence 
(otherwise it may get collected)



 Nov 17 2009



  parent reply Sean Kelly <sean invisibleduck.org>  writes:


Walter Bright Wrote:

 
 Mixing D's gc world with manually managed memory isn't hard, as long as 
 the following rules are followed:
 
 1. don't allocate in one language and expect to free in another
 2. keep a 'root' to all gc allocated data in the D side of the fence 
 (otherwise it may get collected)


This may actually work in D 2.0.  core.thread has thread_attachThis() to make
the D GC aware of an external thread, and gc_malloc() is an extern (C)
function.  I haven't tested this extensively however, so if you're keen to try
it, please let me know if there are any problems.



 Nov 17 2009



  parent reply Walter Bright <newshound1 digitalmars.com>  writes:


Sean Kelly wrote:

 Walter Bright Wrote:

 Mixing D's gc world with manually managed memory isn't hard, as
 long as the following rules are followed:
 
 1. don't allocate in one language and expect to free in another 2.
 keep a 'root' to all gc allocated data in the D side of the fence 
 (otherwise it may get collected)


 
 This may actually work in D 2.0.  core.thread has thread_attachThis()
 to make the D GC aware of an external thread, and gc_malloc() is an
 extern (C) function.  I haven't tested this extensively however, so
 if you're keen to try it, please let me know if there are any
 problems.


There's a more fundamental problem. There is simply no reliable way to 
find all the static data segments in a program. I talked with Hans Boehm 
about this, he uses some horrific kludges to try and do it in the Boehm 
gc. This problem is on every OS I've checked.

Windows has the bizarrely useless ability to find the beginning of your 
TLS data segments, but not the end! Useless.

The D runtime knows about D's allocated segments because I fixed the 
object file generation to provide that information. But if it's some 
other compiler, it's hosed.

Therefore, one has to keep on the D side of the fence roots to all data 
structures passed to foreign languages. It's pretty easy to do, just 
don't forget it!



 Nov 17 2009



  parent  Sean Kelly <sean invisibleduck.org>  writes:


Walter Bright Wrote:


 Sean Kelly wrote:

 Walter Bright Wrote:

 Mixing D's gc world with manually managed memory isn't hard, as
 long as the following rules are followed:
 
 1. don't allocate in one language and expect to free in another 2.
 keep a 'root' to all gc allocated data in the D side of the fence 
 (otherwise it may get collected)


 
 This may actually work in D 2.0.  core.thread has thread_attachThis()
 to make the D GC aware of an external thread, and gc_malloc() is an
 extern (C) function.  I haven't tested this extensively however, so
 if you're keen to try it, please let me know if there are any
 problems.


 
 There's a more fundamental problem. There is simply no reliable way to 
 find all the static data segments in a program. I talked with Hans Boehm 
 about this, he uses some horrific kludges to try and do it in the Boehm 
 gc. This problem is on every OS I've checked.


Yeah, that's a problem.  I've looked at this part of the Boehm collector too
and it's absolutely horrifying.  You'd think with the popularity (and history)
of GC that there would be some API-level way to do this.



 Nov 18 2009



prev sibling next sibling parent reply HOSOKAWA Kenchi <hskwk inter7.jp>  writes:


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.



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'm impressed by Go's selector expressions and anonymous fields.
They are what D's overload sets and opDot/alias this aimed to.
But I love implicit casts with alias this at the same time.

I withhold to say which is better, Go's interfaced pointers or D's
value-struct/reference-class.
On this point, both Go and D would have pros and cons.


p.s.
If both D and Go come to be major language,
There will be many disputes like fray between users of Python / Ruby / Perl.



 Nov 12 2009



  parent reply Daniel de Kok <me nowhere.nospam>  writes:


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



 Nov 14 2009



  parent reply grauzone <none example.net>  writes:


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.



 Nov 14 2009



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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



 Nov 14 2009



 next sibling parent reply grauzone <none example.net>  writes:


Andrei Alexandrescu wrote:

 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 


Don't underestimate the negative effects of a bad toolchain. D has the 
same problem, but (apparently) not as bad.


 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.


I agree, the brand name is probably the best what Go got. (But it's not 
that Go doesn't contain some good ideas.)


 Andrei





 Nov 14 2009



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


grauzone wrote:

 Andrei Alexandrescu wrote:

 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 


 
 Don't underestimate the negative effects of a bad toolchain. D has the 
 same problem, but (apparently) not as bad.
 

 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.


 
 I agree, the brand name is probably the best what Go got. (But it's not 
 that Go doesn't contain some good ideas.)


Well I'm not sure. I haven't seen anything original in Go, just 
regurgitations of prior approaches. Of course, there may be value in 
finding the right mix of herbs, but right now the soup is rather long*.

Andrei

* "long soup" = Romanian phrase for a soup rich in water but lacking in 
all other ingredients.



 Nov 14 2009



  parent reply Bill Baxter <wbaxter gmail.com>  writes:


On Sat, Nov 14, 2009 at 7:19 PM, Andrei Alexandrescu
<SeeWebsiteForEmail erdani.org> wrote:


 * "long soup" = Romanian phrase for a soup rich in water but lacking in all
 other ingredients.


A.k.a. "thin soup" in English.   :-)

--bb



 Nov 15 2009



 next sibling parent  Justin Johansson <no spam.com>  writes:


Bill Baxter Wrote:


 On Sat, Nov 14, 2009 at 7:19 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 

 * "long soup" = Romanian phrase for a soup rich in water but lacking in all
 other ingredients.


 
 A.k.a. "thin soup" in English.   :-)
 
 --bb


Also known as "all sizzle and no sausage" (Australian BBQ).



 Nov 15 2009



prev sibling  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


Bill Baxter wrote:

 On Sat, Nov 14, 2009 at 7:19 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 

 * "long soup" = Romanian phrase for a soup rich in water but lacking in all
 other ingredients.


 
 A.k.a. "thin soup" in English.   :-)


Thank you! This kind of stuff is difficult to find with a dictionary.

Andrei



 Nov 15 2009



prev sibling next sibling parent  Daniel de Kok <me nowhere.nospam>  writes:


On 2009-11-14 16:19:00 +0100, Andrei Alexandrescu 
<SeeWebsiteForEmail erdani.org> said:

 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.


Unremarkable, but to be fair it will appeal to a large number of people 
who want a more modern C without the complexity of C++ (or D). It 
resembles the approach of Objective-C quite much, but I think Google is 
better able to push it beyond their own products. That is if Google is 
actually interested in Go, other than it being a 20% project.

-- Daniel



 Nov 14 2009



prev sibling  parent reply Leandro Lucarella <llucax gmail.com>  writes:


Andrei Alexandrescu, el 14 de noviembre a las 09:19 me escribiste:

 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.


Don't forget it's designed by Rob Pike and Ken Thompson. That's *not*
irrelevant, it's not just a Google language.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
DESCARRILÓ EL GUSANO LOCO Y QUEDARON CHICOS ATRAPADOS
	-- Diario La Capital



 Nov 14 2009



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


Leandro Lucarella wrote:

 Andrei Alexandrescu, el 14 de noviembre a las 09:19 me escribiste:

 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.


 
 Don't forget it's designed by Rob Pike and Ken Thompson. That's *not*
 irrelevant, it's not just a Google language.


I have a huge amount of respect for both, but I think Rob Pike is not
quite a language designer. Ken Thompson is a brilliant designer, but I
don't know what recent work he has done in language design prior to Go.
Honest, I'd be much more worried about Go if Craig Chambers were involved.

Andrei



 Nov 14 2009



prev sibling  parent reply Daniel de Kok <me nowhere.nospam>  writes:


On 2009-11-14 13:35:08 +0100, grauzone <none example.net> said:

 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.


Sorry, D2 with Phobos is absolutely the only option for me. I use STL 
in C++ all the time, and I want something nearly equivalent.

Of course, there are older gdc versions that work with D2, but it seems 
kind of pointless to go so far back in time considering the recent 
great work...

-- Daniel



 Nov 14 2009



  parent  grauzone <none example.net>  writes:


Daniel de Kok wrote:

 On 2009-11-14 13:35:08 +0100, grauzone <none example.net> said:

 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.


 
 Sorry, D2 with Phobos is absolutely the only option for me. I use STL in 
 C++ all the time, and I want something nearly equivalent.


If there's one thing I don't miss from C++, then it's the STL.


 Of course, there are older gdc versions that work with D2, but it seems 
 kind of pointless to go so far back in time considering the recent great 
 work...
 
 -- Daniel
 





 Nov 14 2009



prev sibling next sibling parent  Mike Hearn <mike plan99.net>  writes:


 If you need something more, then it would be great 
 if you could explain it.


I haven't looked at this extensively. Suffice it to say that most of the useful
c++ classes are inside a namespace.



 Nov 18 2009



prev sibling next sibling parent reply Mike Hearn <mike plan99.net>  writes:


 Mixing D's gc world with manually managed memory isn't 
 hard, as long as  the following rules are followed:
 
 1. don't allocate in one language and expect to free in another
 2. keep a 'root' to all gc allocated data in the D side of the fence 
 (otherwise it may get collected)


Yes it's the second that's the tough part. For instance consider the case of
passing a callback (delegate) to the RPC system written in c++. How do you keep
the associated data rooted without causing leaks? You'd need to remember to
manually add it to the gc roots when the callback object is created and then
unroot them when it's invoked. So this needs some kind of glue/binding system.

I'm not saying it's impossible or even hard. Just that I've seen such things
done before and they were non-trivial.



 Nov 18 2009



  parent  Walter Bright <newshound1 digitalmars.com>  writes:


Mike Hearn wrote:

 Mixing D's gc world with manually managed memory isn't hard, as
 long as  the following rules are followed:
 
 1. don't allocate in one language and expect to free in another 2.
 keep a 'root' to all gc allocated data in the D side of the fence 
 (otherwise it may get collected)


 
 Yes it's the second that's the tough part. For instance consider the
 case of passing a callback (delegate) to the RPC system written in
 c++. How do you keep the associated data rooted without causing
 leaks? You'd need to remember to manually add it to the gc roots when
 the callback object is created and then unroot them when it's
 invoked. So this needs some kind of glue/binding system.
 
 I'm not saying it's impossible or even hard. Just that I've seen such
 things done before and they were non-trivial.


Most of the time, nothing needs to be done because the reference is on 
the parameter stack that calls the C function.

For the callback object, manually adding/removing the root (there are 
calls to the gc to do this) shouldn't be any more onerous than manually 
managing memory for it, which is done in C/C++ anyway.



 Nov 18 2009



prev sibling  parent  Mike Hearn <mike plan99.net>  writes:


 Socket IO in Phobos kind of stinks right now 
 so that would need an overhaul first.


We wouldn't be using raw socket io but rather binding to the c++ RPC
implementation. So the state of socket io in phobos (or tango) in neither here
nor there for the purposes of doing network communications inside Google.

Anyway, perhaps I'll see if anyone is interested in playing around with this
when Andreis book is out and D2 is finalized.



 Nov 18 2009