

My thoughts on Google Go - btilly
http://bentilly.blogspot.com/2009/11/my-thoughts-on-go-googles-new-language.html

======
dkersten
My thoughts on Google Go:

1\. Terrible name

2\. Theres no reason to keep to C-style syntax

3\. _go <function>_ is a nice feature

4\. Control structures add nothing new and just seem generally underwhelming
to me

5\. The built-in data types are an improvement over a lot of languages, but
are underwhelming when compared to something like Clojure, Haskell, OCaml or
Factor

6\. Channels are a great way of dealing with mutable data in a concurrent
environment, but I'm not convinced they're enough

7\. Slices and pointers without arithmetic are a good idea

8\. The interface system seems like an interesting idea

9\. I'm not sure I understand how this is to be a "systems language",
especially when they say that its impossible to do manual memory management

10\. Lack of things I like: lisp-like macros, closures, pattern matching,
parametric types, dataflow constructs, iterators, list comprehension..

Though I personally don't like the syntax very much, it is certainly familiar
and easy enough to pick up, so I imagine this will be useful to a lot of
people. I think Go is an interesting experiment which will, hopefully, lead to
some more powerful and interesting languages, but I cant see myself ever using
Go itself.

Its nice to see a C-like language take concurrency more seriously, but after
having used Clojure a lot over the past month or two, it just doesn't really
seem so concurrency oriented to me.

~~~
lacker
Go isn't trying to replace Clojure, Haskell, OCaml, or Factor. It's trying to
replace C++.

~~~
dkersten
Sure, I'm just saying that for me, personally, it doesn't add enough to make
it worthwhile[1]. D is a great C++ replacement too and I think one of the
reasons it never really took off is because it just doesn't add enough to be
worth it (and D adds a good few niceties while still being familiar enough
that C++ programmers can pick it up quickly and easily). Admittedly, D has a
few other issues, but I don't feel they're relevant to this conversation - Go
might have them too, who knows.

Having said that, I'd probably prefer people write code in Go over C hacks.

[1] C++ was my language of choice for a few years, so I do, at least
partially, compare a language to C++ when I learn a new one and not only to _<
latest cool language>_, though I admit I do that too.

------
matthw
My question about Go: why does it need pointers?

Given that it has garbage collection, arrays/slices, and it disallows pointer
arithmetic, it seems it would suffice to use references everywhere.

I thought maybe it was for easy interop with C APIs, but it seems it needs a
FFI for that anyway.

Perhaps someone can enlighten me about that design decision? I'm sure there's
a reason, I just don't immediately see it.

~~~
dkersten
I assume its because they don't want _references everywhere_. For example,
allowing the programmer to choose if an object is allocated on the stack or
heap, passed by reference (using a pointer) or by value.

~~~
euroclydon
Can you elaborate on when an object is "allocated on the stack" versus being
"allocated on the heap" in Go?

~~~
dkersten
The echo program from the tutorial[1], line 21:

 _var s string = "";_

Now, I don't see it written there that it is on the stack, but I imagine so.
From the source code of 6g, in cgen.c[2], line 884, you can see this comment:

    
    
      /*
       * n is on stack, either local variable
       * or return value from function call.
       * return n's offset from SP.
       */
    

Sounds to me that local variables and return values are always on the stack,
which makes sense to me.

[1] <http://golang.org/doc/go_tutorial.html#tmp_44>

[2]
[http://code.google.com/p/go/source/browse/src/cmd/6g/cgen.c?...](http://code.google.com/p/go/source/browse/src/cmd/6g/cgen.c?r=release)

------
shin_lao
The question I have about Go is: why?

From what I read, Erlang is better at what Go tries to do.

Maybe it's just a 20% project that is being released into the wild...

~~~
davidw
Erlang does some stuff very, very well, and other things... perhaps not so
well. Also, the syntax for most people is a bit of an initial stumbling block.
In other words, I don't think Go is really aimed at Erlang's sweet spot,
although perhaps it could be used to build Erlang-like systems, given some
time and effort.

~~~
legooolas
We need to encourage people to get over their fear of syntax which is not
C-like. I find much more pain in C-like syntax being jammed onto new languages
than new languages daring to be different (and possibly coming up trumps, or
being a disaster, but it's more interesting if they're different and perhaps
better in some ways, IMHO).

~~~
davidw
Sure, but perhaps that is not a battle this particular group wants to fight.

BTW, Erlang's syntax has some annoyances that go beyond just not being C. "Ant
turd tokens", for instance. Nothing that's going to stop a competent
developer, of course.

~~~
mononcqc
I've never got the "And turd tokens" thing after using the language for a few
days. It pretty much all makes sense to me.

I've already posted <http://news.ycombinator.com/item?id=837217> to express my
opinion on that though, if you want to read it.

~~~
davidw
<http://news.ycombinator.com/item?id=837462> \- the answer to your post - sums
up nicely why they are annoying: they make it so that one line of code is
often not interchangeable with the next, so when you refactor or cut and
paste, you have to go fiddle with line endings.

