www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - "In praise of Go" discussion on ycombinator

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
http://news.ycombinator.com/item?id=1912728

Andrei
Nov 16 2010
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 17 Nov 2010 00:10:54 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 http://news.ycombinator.com/item?id=1912728

 Andrei
"I like go because every single feature go has is the best ever!" yawn... -Steve
Nov 16 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/16/10 9:21 PM, Steven Schveighoffer wrote:
 On Wed, 17 Nov 2010 00:10:54 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 http://news.ycombinator.com/item?id=1912728

 Andrei
"I like go because every single feature go has is the best ever!" yawn... -Steve
I'm curious what the response to my example will be. So far I got one that doesn't even address it. Andrei
Nov 16 2010
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 17 Nov 2010 00:24:50 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:

 On 11/16/10 9:21 PM, Steven Schveighoffer wrote:
 On Wed, 17 Nov 2010 00:10:54 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 http://news.ycombinator.com/item?id=1912728

 Andrei
"I like go because every single feature go has is the best ever!" yawn... -Steve
I'm curious what the response to my example will be. So far I got one that doesn't even address it.
It's possible that you left your point as an exercise for the reader, so it may be lost. But it's not important. It's unlikely that you will convince goers that the language deficiencies are not worth the advantages. Only time will tell how popular/useful it will be. That one point you made would be a deal-killer for me (not that I'm close to using Go or anything, but no need to invest any more time on it after that). (cue retard's comment about D zealots not having any open mindedness) -Steve
Nov 16 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/16/10 9:58 PM, Steven Schveighoffer wrote:
 On Wed, 17 Nov 2010 00:24:50 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 On 11/16/10 9:21 PM, Steven Schveighoffer wrote:
 On Wed, 17 Nov 2010 00:10:54 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 http://news.ycombinator.com/item?id=1912728

 Andrei
"I like go because every single feature go has is the best ever!" yawn... -Steve
I'm curious what the response to my example will be. So far I got one that doesn't even address it.
It's possible that you left your point as an exercise for the reader, so it may be lost. But it's not important. It's unlikely that you will convince goers that the language deficiencies are not worth the advantages. Only time will tell how popular/useful it will be. That one point you made would be a deal-killer for me (not that I'm close to using Go or anything, but no need to invest any more time on it after that). (cue retard's comment about D zealots not having any open mindedness) -Steve
I think as soon as that defect registers at Go's creators, they will scramble to fix it one way or another. It's a blatant syntax design mistake. Andrei
Nov 16 2010
prev sibling next sibling parent reply Jay Byrd <JayByrd rebels.com> writes:
On Wed, 17 Nov 2010 00:58:28 -0500, Steven Schveighoffer wrote:

 On Wed, 17 Nov 2010 00:24:50 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:
 
 On 11/16/10 9:21 PM, Steven Schveighoffer wrote:
 On Wed, 17 Nov 2010 00:10:54 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 http://news.ycombinator.com/item?id=1912728

 Andrei
"I like go because every single feature go has is the best ever!" yawn... -Steve
I'm curious what the response to my example will be. So far I got one that doesn't even address it.
It's possible that you left your point as an exercise for the reader, so it may be lost. But it's not important. It's unlikely that you will convince goers that the language deficiencies are not worth the advantages. Only time will tell how popular/useful it will be. That one point you made would be a deal-killer for me (not that I'm close to using Go or anything, but no need to invest any more time on it after that).
The problem pointed out can readily be fixed by requiring statements to have at least one token. go has much more severe problems than that. And there are plenty of bugs and mistakes in D, harder to fix, that could be deemed "deal-killers" by someone with an axe to grind. It's not an intellectually honest approach.
 (cue retard's comment about D zealots not having any open mindedness)
 
 -Steve
No zealots are open minded. That's why I'm a supporter of various things but not a zealot about anything.
Nov 16 2010
next sibling parent so <so so.do> writes:
 The problem pointed out can readily be fixed by requiring statements to
 have at least one token. go has much more severe problems than that. And
 there are plenty of bugs and mistakes in D, harder to fix, that could be
 deemed "deal-killers" by someone with an axe to grind. It's not an
 intellectually honest approach.
Since you are trying to fix it, you agree it is a design error. For the "bugs and mistakes in D": Bugs are bugs, what you say is just nonsense. With mistakes i take you mean mistakes in D design, and you said there are many of them, you need to elaborate that one a bit. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 17 2010
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 17 Nov 2010 02:56:09 -0500, Jay Byrd <JayByrd rebels.com> wrote:

 On Wed, 17 Nov 2010 00:58:28 -0500, Steven Schveighoffer wrote:

 On Wed, 17 Nov 2010 00:24:50 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 On 11/16/10 9:21 PM, Steven Schveighoffer wrote:
 On Wed, 17 Nov 2010 00:10:54 -0500, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org> wrote:

 http://news.ycombinator.com/item?id=1912728

 Andrei
"I like go because every single feature go has is the best ever!" yawn... -Steve
I'm curious what the response to my example will be. So far I got one that doesn't even address it.
It's possible that you left your point as an exercise for the reader, so it may be lost. But it's not important. It's unlikely that you will convince goers that the language deficiencies are not worth the advantages. Only time will tell how popular/useful it will be. That one point you made would be a deal-killer for me (not that I'm close to using Go or anything, but no need to invest any more time on it after that).
The problem pointed out can readily be fixed by requiring statements to have at least one token.
Yes, but instead of that, they decided to point it out in the tutorial and documentation, it's on you to not make the mistake, not them. Makes you feel like they said "yes, we noticed that you can have that problem, but we don't think it's a big deal, just remember to be careful." Being someone who likes the "brace-on-its-own-line" style, I can't really see myself getting past that part. And I don't really have any other complaints about Go, I've never used it. This one issue needs to be fixed for Go to be considered a serious language. Hopefully they realize this. When a language has an error-prone issue, one that allows you to write valid code that is never desired, but looks completely correct, it results in buggy code, period. An instance of this in D was the precedence for logic operators and comparison operators. x | y == 5 was interpreted as x | (y == 5). This was thankfully fixed, and it's a very similar issue to Go's mistake. With all the experience people have with designing languages and code analysis by compilers, there are no excuses to have something like this get into a new language. The best thing to teach Go's creators about how bad this is is to make the change you suggest and see how their standard library fares. This has been instrumental in having such changes made to D (for example, the logic operator thing found about 6 cases in phobos where the code was incorrect).
 go has much more severe problems than that. And
 there are plenty of bugs and mistakes in D, harder to fix, that could be
 deemed "deal-killers" by someone with an axe to grind. It's not an
 intellectually honest approach.
I agree that D has hard to fix mistakes. The glaring one IMO is lack of tail-const for classes. It's a huge hole in the const feature set and I can see people being turned off by it. Another is lack of runtime introspection, or the conservative GC. That doesn't mean D is worse or better than Go. It's just that Go is a non-starter (at least for me) without fixing that mistake. If they fixed it, would I start using Go? Probably not, I have too much other things to do. But if Go was around when I was looking for a language to switch to from C++ 4 years ago, that one issue makes the decision a no-brainer.
 (cue retard's comment about D zealots not having any open mindedness)

 -Steve
No zealots are open minded. That's why I'm a supporter of various things but not a zealot about anything.
I consider myself not to be a zealot either (but definitely biased). The comment was a friendly dig at retard, that's all ;) -Steve
Nov 17 2010
parent reply Matthias Pleh <sufu alter.com> writes:
Am 17.11.2010 14:55, schrieb Steven Schveighoffer:
 Being someone who likes the "brace-on-its-own-line" style
i++ greets Matthias
Nov 17 2010
parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
Matthias Pleh <sufu alter.com> wrote:

 Am 17.11.2010 14:55, schrieb Steven Schveighoffer:
 Being someone who likes the "brace-on-its-own-line" style
i++
Surely you mean: i ++ ; -- Simen
Nov 17 2010
prev sibling parent ponce <cont4ct gamesfr0mmar5.fr> writes:
 That one point you made would be a  
 deal-killer for me (not that I'm close to using Go or anything, but no  
 need to invest any more time on it after that).
That was a good point and it's a deal-killer for me too. It's too much similar to the Javascript object literal syntax http://stackoverflow.com/questions/3641519/why-results-varies-upon-placement-of-curly-brace -in-javascript-code
Nov 17 2010
prev sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
On 11/16/2010 22:24, Andrei Alexandrescu wrote:
 I'm curious what the response to my example will be. So far I got one
 that doesn't even address it.
I really don't see the problem with requiring that '{' goes on the same line as 'if'. It's something you learn once and never forget because it is reinforced through constant exposure. After a day or two, '{' on a separate line will just feel wrong and raise an immediate alarm in your mind. I would even argue that Go's syntax actually makes code /easier/ to read and write. Let's say I see something like this in C/C++/D: if(blah()) { x++; } This is not my usual style, so I have to stop and think. It could be correct code written in another style, or it could be code that has been mangled during editing and now needs to be fixed. In Go, I /know/ it's mangled code, and I'm far less likely to encounter it, so I can find mangled code much more easily. A compiler error would be even better, but Go's syntax is already an improvement over C/C++/D. There are huge problems with Go that will probably keep me from ever using the language. This isn't one of them. -- Rainer Deyke - rainerd eldwood.com
Nov 16 2010
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday 16 November 2010 22:55:42 Rainer Deyke wrote:
 On 11/16/2010 22:24, Andrei Alexandrescu wrote:
 I'm curious what the response to my example will be. So far I got one
 that doesn't even address it.
I really don't see the problem with requiring that '{' goes on the same line as 'if'. It's something you learn once and never forget because it is reinforced through constant exposure. After a day or two, '{' on a separate line will just feel wrong and raise an immediate alarm in your mind. I would even argue that Go's syntax actually makes code /easier/ to read and write. Let's say I see something like this in C/C++/D: if(blah()) { x++; } This is not my usual style, so I have to stop and think. It could be correct code written in another style, or it could be code that has been mangled during editing and now needs to be fixed. In Go, I /know/ it's mangled code, and I'm far less likely to encounter it, so I can find mangled code much more easily. A compiler error would be even better, but Go's syntax is already an improvement over C/C++/D. There are huge problems with Go that will probably keep me from ever using the language. This isn't one of them.
Personally, I _hate_ the style of putting the brace on the same line, so I'm instantly biased as far as that goes, but the fact that the language does not actually require that you put the braces in a particular place and yet you have to to make it work properly is definitely a big problem. It's one that can be gotten around easily enough with strict formatting guidelines, but C-based languages are supposed to be pretty much freely formattable (otherwise why even make it optional), so it's a definite faux pas on their part. It's one that they should be able to fix without too much trouble, so hopefully it won't really be an issue in the long run, but it's definitely troubling. At least with a language like Python, it's extremely clear that formatting matters. - Jonathan M Davis
Nov 16 2010
prev sibling next sibling parent reply Jay Byrd <JayByrd rebels.com> writes:
On Tue, 16 Nov 2010 23:55:42 -0700, Rainer Deyke wrote:

 On 11/16/2010 22:24, Andrei Alexandrescu wrote:
 I'm curious what the response to my example will be. So far I got one
 that doesn't even address it.
I really don't see the problem with requiring that '{' goes on the same line as 'if'.
It *isn't* required. But if you don't put it there, *you get the wrong result*. I really don't understand why the problem with Andrei's example isn't blatantly obvious to everyone, but I would not want to use any product of anyone for whom it isn't.
 It's something you learn once and never forget because it
 is reinforced through constant exposure.  After a day or two, '{' on a
 separate line will just feel wrong and raise an immediate alarm in your
 mind.
 
 I would even argue that Go's syntax actually makes code /easier/ to read
 and write.  Let's say I see something like this in C/C++/D:
 
 if(blah())
 {
   x++;
 }
 
 This is not my usual style, so I have to stop and think.  It could be
 correct code written in another style, or it could be code that has been
 mangled during editing and now needs to be fixed.  In Go, I /know/ it's
 mangled code, and I'm far less likely to encounter it, so I can find
 mangled code much more easily.  A compiler error would be even better,
 but Go's syntax is already an improvement over C/C++/D.
 
 There are huge problems with Go that will probably keep me from ever
 using the language.  This isn't one of them.
Nov 17 2010
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/17/10 12:00 AM, Jay Byrd wrote:
 On Tue, 16 Nov 2010 23:55:42 -0700, Rainer Deyke wrote:

 On 11/16/2010 22:24, Andrei Alexandrescu wrote:
 I'm curious what the response to my example will be. So far I got one
 that doesn't even address it.
I really don't see the problem with requiring that '{' goes on the same line as 'if'.
It *isn't* required. But if you don't put it there, *you get the wrong result*. I really don't understand why the problem with Andrei's example isn't blatantly obvious to everyone, but I would not want to use any product of anyone for whom it isn't.
Exactly, that comes as a big surprise to me, too, in that discussion. I can only hypothesize that some readers just glaze over the example thinking "ah, whatever... a snippet trying to support some naysay", and they reply armed with that presupposition. Andrei
Nov 17 2010
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:ic03ui$gjg$1 digitalmars.com...
 On 11/17/10 12:00 AM, Jay Byrd wrote:
 On Tue, 16 Nov 2010 23:55:42 -0700, Rainer Deyke wrote:

 On 11/16/2010 22:24, Andrei Alexandrescu wrote:
 I'm curious what the response to my example will be. So far I got one
 that doesn't even address it.
I really don't see the problem with requiring that '{' goes on the same line as 'if'.
It *isn't* required. But if you don't put it there, *you get the wrong result*. I really don't understand why the problem with Andrei's example isn't blatantly obvious to everyone, but I would not want to use any product of anyone for whom it isn't.
Exactly, that comes as a big surprise to me, too, in that discussion. I can only hypothesize that some readers just glaze over the example thinking "ah, whatever... a snippet trying to support some naysay", and they reply armed with that presupposition.
Sad as it may be, most people, and worse still, most programmers, have no qualms about "safety by convention". That's why they don't see this as a big problem. Safety-by-convention is one of those things that's only recognized as a real problem by people with enough self-discipline and people who have actually been burned enough by dong it wrong.
Nov 17 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:

Sad as it may be, most people, and worse still, most programmers, have no
qualms about "safety by convention".<
This is an interesting topic, there is a lot to say about it. Bugs and errors have many sources, and you need to balance different and sometimes opposed needs to minimize them. Some of the sources of those troubles are not intuitive at all. In some situations "safety by convention" is the less bad solution. You are used to C-like languages, and probably you don't see the very large amounts of "safety by convention" things they do or ask to do. If you look at safer languages (like SPARK, a safer variant of Ada) you see a large amount of things you never want to do in normal programs. And I am now aware that even SPARK contains big amounts of things that are safe just because the programmer is supposed to do them in the right way. If you start piling more and more constraints and requirements on the work of the programmer you don't produce a safer language, but a language that no one is able to use or no one has enough time and resources to use (unless the program is critically important). This is a bit like the "worse is better" design strategy, sometimes to maximize the safety you have to leave the program some space to do things that don't look safe at all. Designing a good language some things wrong (like using + to concat strings, or much worse http://blogs.msdn.com/b/ericlippert/archive/2007/10/17/covariance-and-contravariance-in-c-part-two-a ray-covariance.aspx ). Bye, bearophile
Nov 17 2010
prev sibling parent reply so <so so.do> writes:
 It *isn't* required. But if you don't put it there, *you get the wrong
 result*.
You didn't mean that, did you? -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 17 2010
parent so <so so.do> writes:
 It *isn't* required. But if you don't put it there, *you get the wrong
 result*.
You didn't mean that, did you?
Oh you did! and i agree. -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 17 2010
prev sibling next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Rainer Deyke schrieb:
 On 11/16/2010 22:24, Andrei Alexandrescu wrote:
 I'm curious what the response to my example will be. So far I got one
 that doesn't even address it.
I really don't see the problem with requiring that '{' goes on the same line as 'if'. It's something you learn once and never forget because it is reinforced through constant exposure. After a day or two, '{' on a separate line will just feel wrong and raise an immediate alarm in your mind. I would even argue that Go's syntax actually makes code /easier/ to read and write. Let's say I see something like this in C/C++/D: if(blah()) { x++; } This is not my usual style, so I have to stop and think.
What about if( (blah() || foo()) && (x > 42) && (baz.iDontKnowHowtoNameThisMethod() !is null) && someOtherThing.color = COLORS.Octarine ) { x++; }
Nov 17 2010
next sibling parent Daniel Gibson <metalcaedes gmail.com> writes:
Daniel Gibson schrieb:
 Rainer Deyke schrieb:
 On 11/16/2010 22:24, Andrei Alexandrescu wrote:
 I'm curious what the response to my example will be. So far I got one
 that doesn't even address it.
I really don't see the problem with requiring that '{' goes on the same line as 'if'. It's something you learn once and never forget because it is reinforced through constant exposure. After a day or two, '{' on a separate line will just feel wrong and raise an immediate alarm in your mind. I would even argue that Go's syntax actually makes code /easier/ to read and write. Let's say I see something like this in C/C++/D: if(blah()) { x++; } This is not my usual style, so I have to stop and think.
What about if( (blah() || foo()) && (x > 42) && (baz.iDontKnowHowtoNameThisMethod() !is null) && someOtherThing.color = COLORS.Octarine ) { x++; }
"someOtherThing.color = COLORS.Octarine" was supposed to be "someOtherThing.color == COLORS.Octarine" of course.
Nov 17 2010
prev sibling parent Rainer Deyke <rainerd eldwood.com> writes:
On 11/17/2010 03:26, Daniel Gibson wrote:
 Rainer Deyke schrieb:
 Let's say I see something like this in C/C++/D:

 if(blah())
 {
   x++;
 }

 This is not my usual style, so I have to stop and think.  
What about if( (blah() || foo()) && (x > 42) && (baz.iDontKnowHowtoNameThisMethod() !is null) && someOtherThing.color = COLORS.Octarine ) { x++; }
At first glance, it looks like two statements to me. The intended meaning could have been this: if ((blah() || foo()) && (x > 42) && (baz.iDontKnowHowtoNameThisMethod() !is null) && someOtherThing.color == COLORS.Octarine) { ++x; } Or this: if((blah() || foo()) && (x > 42) && (baz.iDontKnowHowtoNameThisMethod() !is null) && someOtherThing.color == COLORS.Octarine) {} { ++x; } The latter seems extremely unlikely, so it was probably the former. Still, I have to stop and think about it. There is also the third possibility that the intended meaning of the statement is something else entirely, and the relevant parts have been lost or have not yet been written. Language-enforced coding standards are a good thing, because they make foreign code easier to read. For this purpose, it doesn't matter if the chosen style is your usual style or if you subjectively like it. Even a bad coding standard is better than no coding standard. -- Rainer Deyke - rainerd eldwood.com
Nov 17 2010
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 17/11/2010 06:55, Rainer Deyke wrote:
 There are huge problems with Go that will probably keep me from ever
 using the language.  This isn't one of them.
I have to agree. The issue itself is a fairly minor one. For starters because it is trivial to fix: if this ever becomes a more important issue in the community of Go users (which likely it will), then the creators will just change it. It won't have a significant impact on language design, unlike generics or plenty of other stuff, which can be quite cumbersome to add if not designed from the beginning. You can say that the issue is somewhat telling of the design principles of the language creators, but otherwise I doubt it will make much difference. -- Bruno Medeiros - Software Engineer
Nov 30 2010