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