
Google’s Go has some coders raving - bockris
http://arstechnica.com/information-technology/2013/05/my-favorite-programming-language-googles-go-has-some-coders-raving/
======
anon1385
I think the thing that amuses me most about the current Go hype is when people
defend the language with statements along the lines of "it is supposed to be
boring"[1]. Go is the new (old) Java and the arguments echo those of 15 years
ago.

1) created for people less smart than the designers (even if not
intentionally: maybe Gosling and Pike really do believe that generics and HOF
are too difficult for the average programmer)

2) designed to be easy to use in a corporate environment with large teams of
varying abilities (the 'simplicity', which is really more familiarity: most
people can write boilerplate filled imperative C-family language style code
already).

3) attempts to make certain types of errors harder than the languages it
replaces (in Java thats memory errors, in Go it's concurrency errors), but by
ignoring established PL research still gives you a big gun that is loaded and
aimed at your foot (doing concurrency in Java with threads and locks, NULL and
deadlocks in Go, etc). i.e. very conservative when it comes to adopting PL
ideas, but perhaps bringing one old idea to the mainstream, and being prepared
to make a lot of sacrifices (to ensure an 'easy' language) to get people on
board with that one idea.

The amusing thing is that the creators of Go are some of the fiercest critics
of Java, but they have created something that seems to follow a very similar
philosophy to the original Java. I guess it remains to be seen if Go will have
added as many features in 15 years time as Java has in the last 15.

I don't mean this as a slight against Go (or Java!). I just find the
comparison illuminating.

[1] <http://news.ycombinator.com/item?id=5750256>

~~~
ominous_prime
my rant re: generics, I wish people would read through the documentation (FAQ)
and discussion of this first.

The language designers have not ruled out generics, and are fully open to
providing them at some point. The issue is that they have yet to find an
implementation that fits within the language design goals.

Yes, if you jump on the mailing list, and propose that they somehow "use"
.NETs generics, and you actually have no idea how that would be implemented,
or impact the compiler and runtime, you're not going to be greeted cordially.
This happens fairly frequently, and is probably why people think the community
is totally against generics.

The Go team wants generics, _when_ they find the right way to handle them
within the language. In the meantime, most heavy users seem to agree that lack
of generics is better than poor generics.

~~~
quatrevingts
I am highly skeptical that they are actively investigating ways to support
generics, or that they are willing to change anything else about the language
to support them better.

This statement, part of the standard Go talking points, seems to be designed
to persuade the unsure to give the language a chance, "and generics will be
around later once we figure it out." Not likely.

I think the designers know that no perfect shining implementation of generics
--compatible with all of Go's existing design decisions--is going to arise
deus ex machina after eluding researchers for all these years.

~~~
ominous_prime
I would like to believe that the go team members aren't being disingenuous
when they say this.

There has been some talk, but it's mixed in with a lot of noise too.

I don't think that anyone is expecting a PL research breakthrough to provide
some generics panacea. I think this is more along the lines of how can we
pragmatically introduce generics without messing up too bad. From what I've
seen, I personally think some form of templating has the most promise (though
I am far from qualified to actually comment on its viability).

~~~
papsosouid
>I don't think that anyone is expecting a PL research breakthrough to provide
some generics panacea

That already happened. In 1976. There is simply no excuse for this
disingenuous "oh but go is magic and special and can't do it the same way
everyone else can" nonsense. If people want that argument to be taken
seriously, then they need to start offering actual specific problems with
parametric polymorphism as it would apply to go. Not just saying "we're
special".

~~~
ominous_prime
No one is saying generics can't be implemented in go, or that go is "special".

Implementing generics requires tradeoffs of some sort -- compile-time and
size, runtime efficiency, or language-complexity. The creators didn't want to
accept any of these compromises, at least for the initial release of go.

~~~
papsosouid
No, it does not require a trade off. That is exactly what I just pointed out.
There is no such problem. Parametric polymorphism was solved in 1976. None of
the things you mentioned are actual problems, they simply do not exist. Those
are invented excuses. If Rob seriously still hasn't bothered to read CS papers
from 30+ years ago, that is very unfortunate. But it does not mean the problem
wasn't solved, it just means he is unaware of the solution.

~~~
Daishiman
I'm more willing to trust Rob Pike on his assesment than a random Internet
comment from someone who has neither knowledge of Go nor has read the comments
on their mailing list.

~~~
azth
Appeal to authority. You don't have to trust some random comment on the
Internet. Read a little about how generics are implemented in other languages
today, and you will be able to see the points the commenter is making.

~~~
pkroll
Quick searches turn up slow compile times as a definite issue with generics.
Which means papsosouid's premise is wrong: there IS an issue, and it's one of
the ones the Go team considers important. EDIT: read name wrong.

~~~
papsosouid
>Quick searches turn up slow compile times as a definite issue with generics

Where? I can find nothing of the sort. And given that we have proof otherwise
(compare D to go for example) it seems likely that you are choosing to
interpret "some languages made their compilers slower" with "parametric
polymorphism must make a compiler slower".

~~~
azth
On the Go mailing list I suppose :) They (the authors) seem that they did not
research this issue deeply enough as you mentioned.

------
shurcooL
The main reason I love Go is because it makes me feel like the more I use it,
the more I'm able to do and get it done faster. When I solve a given problem,
it's solved for all my current and future projects written in Go.

When I was working with C++ earlier, that was not really the case. After
spending many years with it, I couldn't write a simple web server in under 5
minutes. Making something into a library had too much overhead. In Go, once
I've done something [1], the next time it's one line to import it.

Also, working with the language programmatically is a pleasure. There's a full
parser in the standard library.

[1] e.g. <https://gist.github.com/shurcooL/5571468>,
<https://gist.github.com/shurcooL/5504644>

~~~
swalsh
stupid question, but from your second example what does the _ do? in this
line?

"for _, "

~~~
ominous_prime
"_" is when you must assign a value, but don't want to use it.

range in the for loop return 2 values (index, value). If you don't want the
index, you can assign it to "_" to ignore it.

<http://golang.org/ref/spec#Blank_identifier>

~~~
swalsh
oh! that's pretty cool.

~~~
steveklabnik
Check your favorite language, it probably has this feature. Ruby, Haskell,
tons of them.

------
elithrar
I'm still a little confused as to why Haunts keeps getting used as an example
of Go "failing". As discussed in other Go-related comment threads, the project
would have likely failed with any language, not just because Go doesn't have a
version pinning package manager.

~~~
brown9-2
It's confusing why anyone would seek to blame a project's failure on the
choice of programming language.

The presence of this anecdote in the article seems to fulfill some sort of
journalistic requirement to balance any positive stories with criticism as
well, to be in the center. It doesn't make a lot of sense when writing about
programming languages.

~~~
obviouslygreen
_It's confusing why anyone would seek to blame a project's failure on the
choice of programming language._

The choice of language _does_ have the potential to deep six a project;
however, it's rarely something that can be blamed on the language itself.

I've seen projects fail because of the language the chose for at least two
reasons, but I think these two are the most obviously harmful:

1\. Choosing a language that isn't just unsuitable, its design goals and
tradeoffs should make it an obviously poor choice in terms of your
requirements.

2\. Choosing a language for use by a team that has no experience with it, no
time to learn it, and/or lacks the discipline to learn it in sufficient depth
to use it efficiently for the project's purposes.

Again, these are not failures of any given language. They are, however,
potential project-killers that are only possible based on the _choice of
programming language._

------
programminggeek
Go has always looked interesting to me, but I don't understand why Google
hasn't put go on Android yet. It seems like a better long term solution for
Google than Java is for just about everything, but maybe it's not.

~~~
tptacek
I like that it's not on Android right now. It's one of the things that makes
me think Golang is a real language and not a corporate initiative.

~~~
mh-
what does that even mean? it sounds like "golang got too mainstream, it sold
out to _the man_."

but, I'm giving you the benefit of the doubt that there's an intelligent
comment here

~~~
B-Con
It doesn't sound like that whatsoever. Here's what I interpreted:

"If Google were pushing Go and it were on Android, it may feel as though Go's
goal was political, ie another way for Google to assert control over the
development process and bring people under their umbrella.

"Given that Go isn't on Android, it feels more like Google is trying to
contribute a useful tool than push an agenda."

You may disagree, but that's what was implied.

------
hierro
The only things that really bothers me about Go is how difficult is to
contribute a patch (even when I'm listed as a contributor). First, you have to
sign an agreement to give an unlimited license to Google to use your code as
they see fit, then you have to use a special HG extension to get your patches
uploaded to codereview.google.com (which disables branches/commits/etc, and
doesn't let you submit multiple patches affecting the same files) and,
finally, the patches may sit in review for a few weeks until someone from the
core dev team takes a look at them.

~~~
rsc
Thanks for your contributions. I apologize that you've found it difficult.
Just to respond to your points:

1\. CLAs are a fact of life in open source to keep the lawyers happy
(<http://en.wikipedia.org/wiki/Contributor_License_Agreement>). We've tried to
make it as simple as possible: you fill out one web form, we do the rest. And
it's just once, not every time. So if you're already listed as a contributor,
you're done with this forever.

2\. You're free of course to prepare the code any way you want. We insist on
the hg extension to manage the review of the patch, mainly because it makes
our lives easier: there are a LOT more contributors than there are core Go
team members doing code reviews. (And we don't just review; sometimes we even
like to write our own code.) I hope using the tool isn't really too
burdensome. Many people work with other things, like git in the same dir or hg
in another dir, and then they copy the changes into their "review" tree.

3\. This is a real problem. We don't have a good system for tracking these: so
far we've just been letting everyone watch the same stream and deal with what
needs dealing with. But the volume has gotten high enough that we are dropping
too many incoming changes or bug reports on the floor. We're working on a new
system to track incoming changes and bug reports and assign them to a clear
owner so that everyone knows who is responsible for what. I hope this will go
live soon.

------
fixxer
I am totally one of these ravers.

Go is the right language for the right time: easy enough for the Python people
(like me) to pick up quickly, but with a concurrency model that makes taking
advantage of multi-core very easy.

Anyone prefer Scala to Go?

~~~
zohebv
+100 for Scala.

You can pry the super powerful type system, functional programming support,
monad comprehensions, library ecosystem, IDE support from my cold dead hands
:D

~~~
fixxer
Alright, Scala has been added to my list.

------
beck5
The thing I really miss about my C# days is the automated refactoring. How
good are the available refactoring tools for golang?

~~~
jweir
I am not familiar with C#, but what Go does have is gofmt.

This forces all Go code to be formatted and styled in a consisten manner. This
not only solves readability issues, but makes all code consistent for machine
reading and replacing.

gofmt also supplies a pattern replace method, which is a bit more
sophisticated than a regex search and replace.

<http://golang.org/cmd/gofmt/>

~~~
kvb
Refactoring is not reformatting, nor are text replacement systems comparable.
Refactoring allows you to keep program behavior the same while safely making
structural changes to your code. Renaming is one simple example of this (where
true refactoring tools are superior to textual find-and-replace because they
understand which occurrences of an identifier are semantically identical). But
there are many other useful refactoring operations, such as extracting a bit
of logic into its own method, etc.

------
andrewljohnson
Make no mistake, Google developers often make great programming tools. It
stems from a culture of engineering and dog-fooding.

Some examples are AppEngine, Angular.js, Go, GWT, and Chrome Developer tools.

~~~
adrianlmm
You forgot to add Dart.

~~~
alvivi
No, he doesn't.

------
bokglobule
I wonder if Go will be similar to Scala where it arrives to solve issues with
Java (or C++). I found that although Scala is a nice language in many ways,
the smallness of the community prevented me from adopting it big time for most
work. The same holds true for languages like F#. They're fine for special
cases (likely what Google intended with Go), but won't be a general purpose
replacement for more mainstream languages without some huge advance in support
(like what the Rails team did for the Ruby language).

Just my humble opinion..

~~~
azth
Scala has a small community? :)

~~~
bokglobule
I guess it's how you look at it, but Indeed still shows very little movement
over the last years with interest in Scala developers by businesses. Even
compared to Go, it's very small.

[http://www.indeed.com/jobtrends?q=scala%2C++go&l=](http://www.indeed.com/jobtrends?q=scala%2C++go&l=)

~~~
happy_dino
The search term you chose looks really favourable to Go, but closer inspection
reveals that it doesn't contain a single Go job.

I think this is more accurate:
<http://www.indeed.com/jobtrends?q=scala%2C++golang>

Golang: 8 Jobs

Scala: 1,434 Jobs

------
venomsnake
Can golang do function decorators - I have been using it for some pet projects
(nothing fancy) but could not find this so loved python feature there?

~~~
supersillyus
Yes, in the same sense that any language with first class functions can.

So, like:

    
    
       var SomeFunc = RequireAuth(func(...) {
            ...
       });
    

However, there's no language-level support, so you can't decorate methods as
easily as you might in a language like Python.

------
WayneDB
Go is alright, but I don't understand their naming convention for packages.
Why "fmt" instead of "format"?

OK, I guess they think abbreviations are useful...but then they went with
"database" instead of "db", "encoding" instead of "enc" and "image" instead of
"img".

At least be consistent.

<http://golang.org/pkg/>

~~~
codygman
I'm guessing fmt is the odd one out because it's used a lot and clear that it
means format. Of course by that logic, image should be img too.

------
whataaa
I like more Dart.

~~~
andyhmltn
you more need grammar learn

~~~
bachback
Me build my own GRAMMERS! chomsky rulez.

~~~
brightsize
In Soviet Russia ....

