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 Bjrklund" <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 Bjrklund" <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 Bjrklund" <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 Bjrklund" <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.
Yes OOP; just not in the traditional Java/C# style.
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