
Will Go be the new go-to programming language? - mtgx
http://gigaom.com/cloud/will-go-be-the-new-go-to-programming-language/
======
Jabbles
Yes.

The speed of development is far better than any other language I've
experienced. I use it as a replacement for C++ and Bash, a statement I don't
think you could make about any other language. Apart from the lowest-level
kernel work and the highest-performance code, I think Go will become the NBL.
Even on the subject of performance, Go is improving quickly, and if you're
using it as a replacement for, say Python, your performance will be
substantially improved anyway.

Its simplicity is astonishing. Very few things will surprise you whilst
coding, although a few topics take a while to learn. I know many hackers try
to work in accordance with the phrase "Perfection is achieved, not when there
is nothing more to add, but when there is nothing left to take away.". I
cannot think of anything Go has that it doesn't need. Not even goto :P

<http://www.quotationspage.com/quote/26979.html>
<http://golang.org/ref/spec#Goto_statements>

~~~
slurgfest
'Performance' is not a bullet point. Please do not wave hands about
'performance' without thinking about the actual benefit in the actual domain
you are programming in.

If you need to write fine-grained embedded, DSP or graphics code you are
probably going to use a true low level language like C or C++ anyway, not a gc
language.

If you are not working in a domain like that, you need to _measure_ to even
know whether the language is even a significant bottleneck. By the time you
have measured you can often find a targeted place to optimize with FFI or
extension modules.

If you are using a language just because you think it is faster at everything,
you are optimizing prematurely and in a somewhat naive way.

~~~
genwin
> If you are not working in a domain like that, you need to measure to even
> know whether the language is even a significant bottleneck.

Or, if one is confident that the project can be done in Go, and that existing
performance measurements of alternatives are accurate and show much worse
performance, and the alternatives aren't much easier to use anyway, use Go and
don't look back. Why optimize with FFI or extension modules when one can scrap
that idea at little expense?

As an analogy if I wanted a faster car I'd probably be better off switching
cars than tweaking my existing car's engine.

~~~
mseebach
To continue your car analogy, buying a Porche isn't going to make you go
faster if the route you're optimizing is across Los Angeles in rush hour.

~~~
genwin
True! But the whole cross-state trip likely has plenty of open road.

------
michaelhoffman
> Betteridge's Law of Headlines is an adage that states, "Any headline which
> ends in a question mark can be answered by the word 'no'".

<http://en.wikipedia.org/wiki/Betteridge%27s_Law_of_Headlines>

~~~
polshaw
Is there a law about people always quoting a law from wikipedia?.. Betteridge,
Poe, Godwin, Dunning-Kruger.. it is getting just as old as the terrible blog
post titles that provoke them them.

This is not really even such a ridiculous proposition, either- certainly
worthy of discussion.

~~~
mcantelon
Cantelon's Law: if you put someone's name in front of an adage people will
feel savvy when they quote it.

~~~
agilord
You shall create a wikipedia page for that, that way we can refer to it :)

------
EwanToo
It's certainly the new go-to programming language for blog posts about
programming languages :)

It's a very nice language, I like it a lot, but if there's one thing we all
should have learnt over the last few years, it's that no programming language
is the right choice for every task.

------
TylerE
It's close. The tooling is really user-friendly, which is a big win.

Add some sort of decent generics and you're really close.

A top-class GUI toolkit would be good too.

~~~
kitsune_
I feel like not including generics is a huge oversight. Also, the way many go
aficionados discuss this over at golang-nuts put me off a great deal.

~~~
sanderjd
What is an example of a use case for generics that can't be done, or is
significantly less convenient to do, with interfaces? It sounds like there is
at least some thought that generics may be included at some point, but I
really haven't missed them thus far.

~~~
pufuwozu
A lot of functional constructs heavily rely on parametric polymorphism. For
example:

    
    
        map :: (a -> b) -> [a] -> [b]
    

Interfaces can't provide this type of code reuse.

~~~
mseepgood
If you're attached to FP style you shouldn't choose an imperative language in
the first place.

~~~
jerf
It has been pretty conclusively demonstrated at this point that a basic suite
of "weak" FP tools is pretty useful in any language. No serious modern
language should try to work without convenient closures and a functioning map
and filter statement/function/whatever. This hasn't got anything to do with
purity or academic goodness, and everything to do with the fact that languages
like Python or Ruby, which are emphatically not FP languages, have simply
shown such things to be indispensable tools for concise code.

~~~
eckyptang
Pretty useful: yes.

Essential: no.

Map/Filter introduce several new semantic concepts to a language. I think they
were avoided for simplicity's sake and the fact you can achieve the same
result with a for loop, even if it is slightly less concise.

~~~
nephesh
With this standard for "essential" you may as well just drop down into
assembly language.

The only added simplicity here is for the compiler writers, not the end users.

~~~
mseepgood
numbers = map(numbers, func(n int) int { return n * n })

for i, n := range numbers { numbers[i] = n * n }

Sorry, but I do not see a difference in the order of assembly language vs.
high-level language.

~~~
nephesh
Now try it on a more complex type. Then try and compose various operations.
Then swap out the container type.

~~~
mseepgood
(Unfortunately, formatting is lost)

a) With a more complex type (I don't see how this would affect one more than
the other)

Functional would be:

foos = map(foos, func(f Foo) Foo { return Foo{f.A * f.A, f.B * f.B} })

Iterative is:

for i, f := range foos { foos[i] = Foo{f.A * f.A, f.B * f.B} }

b) Composing various operations. Composing filter + map:

Functional would be:

x := filter(map(numbers, func(n int) int { return n * n }), func(n int) bool {
return n % 2 == 0 })

Iterative is:

x := make([]int, 0); for _, n := range numbers { sq := n * n; if sq % 2 == 0 {
x = append(x, sq) } }

c) Swapping the container type is just a matter of swapping "_, n := range
numbers".

~~~
nephesh
> With a more complex type (I don't see how this would affect one more than
> the other)

It does because the discussion is about generics. The fact that you're writing
out types for one and not the other makes your comparisons a bit disingenuous,
though I understand if Go isn't very good at functional programming.

b) Composing various operations. Composing filter + map:

As you keep building them up the imperative style will have more code overhead
and less efficiency.

> c) Swapping the container type is just a matter of swapping "_, n := range
> numbers".

This isn't true since the functional one could easily swap out to use an
infinite data source whereas the imperative will be constrained to the arrays
you're already using.

~~~
mseepgood
a) Generics would not make the function signatures shorter. You would have to
introduce yet another concept: type inference for the signatures of anonymous
functions.

b) No, it will not be less efficient. It's all done within one loop, in-place.
You can compose everything inside the body of the loop. A functional language
would do the same if it's intelligent.

c) You can easily create an infinite data source in Go with the generator
pattern:

numbers := make(chan int); go func() { for i := 0; ; i++ { numbers <\- i } }()

for n := range numbers {...}

~~~
nephesh
> Generics would not make the function signatures shorter. You would have to
> introduce yet another concept: type inference for the signatures of
> anonymous functions

Yes, I should have said type inference obviously. I can't think of a decent
functional language that doesn't have type inference though.

> No, it will not be less efficient. It's all done within one loop, in-place.
> You can compose everything inside the body of the loop. A functional
> language would do the same if it's intelligent.

If it's all done in one loop then it isn't composing. It's writing custom code
every time you need to do something.

> You can easily create an infinite data source in Go with the generator
> pattern:

That's nice, you only need to change all of your code to do so. The functional
version doesn't have that problem.

~~~
thebigshane
================

Please note that if your comment thread starts getting squished against the
right side of the page like this, it might be time to move the conversation
off of HN.

================

------
realrocker
The following features make Go as the "go-to" language for me:

1.Coroutines, Channels and Select: Concurrency with built in synchronization
and communication is accessible(especially if your are new to concurrent
programming) enough to handle "most" of the grunt work. 2.gofmt: Formats your
code for you. No more debates(procrastination) on that. 3.godoc: Generates
documents. No more looking for the best 3rd party tool and wasting time. 4\.
Defer and Close: Helps you to do better post-operation tasks i.e better
resource management. 5\. Error Handling: Multivalue returns. 6\. Type
Hierarchy: No type hierarchy exists in the conventional sense. 7\. Slices &
Maps: Just two of them, and that's why I love it. 8\. Brevity and Readability:
Clutter free syntax. WYSISWYG language. 9\. Philosophy of Exclusiveness: This
is most important non-feature which makes Go different and exciting. Go's
vision is to be an exclusive programming paradigm rather than being an
inclusive one. In this Google I/O video: <http://www.youtube.com/watch?v=sln-
gJaURzk>, Robert Griesemer speaks about an incident that how in a "D"
programming conference, the developers intended to include a new programming
paradigm in the future. This is what sold it for me as I care more about how
the language will grow instead of what new cool features will come in.

Performance is a contentious issue. In an ideal world, performance would just
depend on the platform and the language, but in reality it also depends on the
skill and idiosyncrasies of the programmer. For me, that is a non-issue.

Quick Reference to Go talks: <http://code.google.com/p/go-wiki/wiki/GoTalks>

------
jph
Yes. :) I'm using it now, and it feels better to me than Java and C/C++. The
language is cleaner and the toolchain is very smooth.

The new Go Revel framework (by HN user robfig) looks especially promising for
web MVC apps: <http://robfig.github.com/revel/>

------
new299
This is a terrible article, with no substance. I'm baffled as to why anyone
would up vote it, other than "because it's about Go and I like Go".

~~~
jongraehl
Many people don't really read the articles, I'd guess. This article really is
devoid of insight.

------
mhd
For small ad-hoc multi-processing servers that web shops are writing. Maybe,
that seems like a good use case. Not as exotic as Erlang, and not a very
demanding environment.

No big chance for enterprise or academia. And I believe that for ordinary
"check this, forward that" backend programming, Ruby, Python and Perl will
still remain staples, with a few percentage points shifting back and forth, as
usual. Rails didn't end Python.

On the other hand, I wouldn't shed a tear if it would eat up the majority of
node.js' marketshare.

~~~
eckyptang
Enterprise here. We're knocking huge monolithic applications sitting on CLR
and JVM processes into greater numbers of smaller stand-alone components (SOA
style). Go fits here very well indeed.

Our authentication, filestore, directory services, messaging and web front end
are all easy targets.

------
TOGoS
No. Not for me, anyway.

Go seems okay. I tried to write a few small programs in it but spent a lot of
time hunting around in the manual for how to do things. D (as in dlang.org)
has a very similar feature set (static but not annoying typing, lightweight
threads, value types, GC, native high-level arrays, yaddah yaddah) but is more
familiar to us C/Java programmers. One feeling I get is that Go exposes a lot
of quirks (e.g. the 'make' function and inter-thread messaging) in the syntax
of the language, whereas D takes care of those cases with regular library
functions. I was impressed that while writing my first D program I rarely
committed any syntax errors, as I found it an intuitive extension of Java/C
syntax. So if anything is to by my next go-to language, it's more likely to be
D than Go. Or does that make it a d-to language? Ha ha ha heh hrm _cough_.

------
tsahyt
I think Go has big potential, especially with those who now code C++ or Java
but also with some users of dynamic typing languages. I have a feeling Go is
here to stay for a while.

------
kingmanaz
Things Go got right;

1\. Go doesn't discard the last 40+ years of programming history. Ints, chars,
arrays, pointers, structs -- in addition to minimalist types that build on
these -- are at the heart of Go's lexicon.

2\. Following off of point 1: C and C++ source code and algorithms are easily
translatable into Go because they look like Go.

3\. Following off of point 2: Because old C/C++ code looks similar to Go, Go's
libraries will soon number C/C++.

4\. A well thought-out, minimalist toolchain. Working with "go install", vim,
and gocode is like dancing in the clouds when compared with the morass that is
Eclipse or Visual Studio, let alone C/C++ and its makefiles.

5\. Go's object-orientation is done right. Go strongly emphasizes "has-a"
relations and eschews the "is-a" relations that are prevalent in C# and Java.
To see the effect this has on code readability, look at Go's documentation.
For example, <http://golang.org/pkg/database/sql/> ...scanning one page tells
one all that's needs to be known about a package. Go's objects ride just above
atomic data structures. There is not a five-mile chain of object dependencies
and corresponding taxonomy clouding one's understanding as in C# or Java.

6\. Go's channels give the programmer their very own ksh/bash built right in
to the language. Admittedly, this is an oversimplification, but piping program
units together is a proven method of _strongly_ modularizing applications and
has the added benefit of being inherently concurrent. Languages have been
moving away from the shell for decades and have in the process lost its
advantages.

(With all that said in point 6, there is still room for something like a
lightweight, cross-platform, glue-language similar to bash/ksh that -- like Go
-- does not throw out 40+ years of shell history. Unsung Tcl/Tk
(<http://www.softpanorama.org/Scripting/tcl.shtml>) and Expect seems to fit
the bill the closest currently, though it does not read like the C family of
languages. Perhaps if someone were to build a Go shell, or create a cshell
that used used Go's conventions, Go would have a good glue-language
counterpart.)

~~~
pjmlp
> Go doesn't discard the last 40+ years of programming history

Except for:

\- enumerations

\- exceptions

\- generics

\- dynamic modules

\- ...

~~~
aaronblohowiak

      - iota
      - http://golang.org/doc/go_faq.html#exceptions
      - http://golang.org/doc/go_faq.html#generics

~~~
pjmlp
iota is a poor man's solution compared with what real enumerations are

<http://en.wikipedia.org/wiki/Enumerated_type>

As for the other two links Go fanboys like to throw them around to feel happy
that they beloved language is comparable to programming languages developed in
the 70's.

~~~
aaronblohowiak
Ignoring and being selective are different things. The golang designers have
made intentional choices and the reasoning is provided in the links I sent. I
am not a fanboy. IMHO, Go would have been MUCH more interesting if goroutines
did not run in a shared address space and if they implemented generics (even
as a hygenic macro..)

The things that you left off your list that I think are much more interesting
are:

    
    
      - Weak/Strong purity, enforced by the type system
      - uniqueness typing
      - chan is too special.  The difficulty with implementing a good netchan interface is starting to show this.

------
jrb1
Why would you write critical software on a language developed by one company
that has a habit of dropping projects once they get bored with them?

As the consternation of C# developers about windows 8, and java developers
about Oracle lawsuits, relying on a language that a single company makes is
foolish - especially companies that have a track record of abandoning
projects.

I think C++11 will be the new go to language. It is standardized. As Moore's
law runs out for single cores, C++ is positioned as the language that can run
fast on a single process and scale easily to multicore

------
Kilimanjaro
"C will always have its place but Ruby and Python code bases will go to Go."

Not in the web world. Go will take programmers from the C/Java camp, but not
many from the ruby/python camp.

Not even one in a hundred startups will use Go as their main programming
language. Ask PG to confirm.

I am an early golang user and once in a while play with it to try new stuff,
but still coding everything else in python.

To answer the question: Yes for systems work, No for web work.

~~~
papsosouid
Go offers nothing for C programmers, and Java/C++ programmers are largely
using languages by corporate decree, not choice. Go's main audience is in fact
people who are still clinging to dynamically typed languages. Where modern
languages like haskell or scala are too scary for them, go is familiar enough
to draw them in, and show them that static typing doesn't mean java.

~~~
slurgfest
'clinging to dynamically typed languages' and 'too scary' implies that the
only people using such languages are incompetent beginners. That is posturing
more than it is an honest description of reality. Same applies to your
description of Go as nothing more than a bridge to Scala.

Are you so sure that everyone using languages other than Scala and Haskell is
that much dumber than you are?

It took a while for C++ and then for Java to become languages of corporate
decree. If Go will ever become one of those languages, it will take around the
same amount of time.

~~~
papsosouid
>'clinging to dynamically typed languages' and 'too scary' implies that the
only people using such languages are incompetent beginners

No it doesn't, it implies they are accustomed to dynamically typed languages,
and unfamiliar with modern statically typed languages.

>Same applies to your description of Go as nothing more than a bridge to
Scala.

That's interesting given that I said no such thing.

>Are you so sure that everyone using languages other than Scala and Haskell is
that much dumber than you are?

Who are you replying to? I said nothing of the sort.

>If Go will ever become one of those languages, it will take around the same
amount of time.

What does that have to do with anything? Nobody is discussing whether or not
go will become the corporate standard language.

------
erichocean
I'd like to see Cassandra implemented in Go (currently its Java/JVM-based).

~~~
kingkilr
Why?

~~~
erichocean
Mainly to see if it would have better GC ability than Cassandra.

I love Cassandra, and the JVM is solid too, but the "stop-the-world-pause" in
it's current garbage collectors truly blows. All of that fast latency is for
not if the JVM decides to spend a few seconds churning through garbage. :(

I've looked into Azul's Zing JVM, but it's basically only for beefy hardware
(16+ cores and 32GB+ RAM), and it's also crazy expensive.

~~~
EwanToo
I've never used Cassandra, but from what I'd read about Netflix and other's
use of it, everyone used at least 32GB of RAM in each node?

Am I totally wrong?

~~~
erichocean
So, there's a difference between "how much RAM is in the box", and "how much
RAM is allocated to the JVM".

The latter is where Azul Zing requires a lot of RAM to operate, as I
understand it.

The recommended RAM for the JVM heap running Cassandra is 8GB, and 4GB isn't
uncommon in the cloud. Netflix uses 12GB, and is contemplating going back to
8GB (they made that decision awhile ago, and things have changed since then).

I have boxes that run JVM heaps as low as 2GB just fine. It really just
depends on how you're using it. (I've heard of people using 256MB heaps with
Cassandra.)

~~~
EwanToo
Thanks, that makes sense

------
soapdog
For those wanting to learn more Go I recommend this online book:
<http://www.golang-book.com/>

------
zackmorris
I can't use Go until they fix the whitespace bug:

[http://zackarymorris.tumblr.com/post/26701252898/a-mistake-i...](http://zackarymorris.tumblr.com/post/26701252898/a-mistake-
in-go)

But other than that, it looks like a very tasteful language and I want to use
it for some parallel computation experiments since they make it so easy to
spin off tasks.

~~~
thebigshane
Wow... I don't understand diving into a language like this without reading
about or looking at other source code already written in the language. This is
not a bug! Golang enforces certain formatting, it is very opinionated and the
authors are very upfront about that.
<http://golang.org/doc/effective_go.html#formatting>

Also, you can use the `gofmt` tool (when running Go on your local machine) to
help you learn what Go prefers if you don't want to read all of the excellent
documentation on the site. [EDIT: I see you already know about this tool but
I'll leave this comment here for others]

~~~
loboman
Exactly, this is not a bug and this won't be fixed. Go adds a ";" at the end
of lines like "func main()", which in this case means "func main(){" has a
different meaning than "func main()".

~~~
sigzero
Oh god....

------
Yuioup
Yes. Combined with Dart and Google has their strategy for leaving Java and
Firefox in the dust.

~~~
viseztrance
I doubt dart will ever gain the momentum that go currently has.

~~~
sigzero
go has momentum? I am not sure I would go that far.

~~~
slurgfest
Go certainly has buzz.

I keep thinking I should get around to doing a real project with it, then I
get irritated by the strident advocacy and put it off again. For purposes
which seem to call for Go I can easily just go back to C. Which is already
beyond mature and plays nicely with almost any non-JVM language.

------
kodablah
Can anyone confirm that 32-bit problems still exist concerning memory leaks
and cgo? If so, this would confirm that it isn't a cross-platform "go-to
programming language".

------
ekm2
As an absolute amateur in programming i was surprised that i could master Go
syntax(in the sense of not having to check back in the notes) in under 2 hours
of practice.

------
thebigshane
summary: Click-bait title, content-free article, great language, excellent
conversation in (HN) comments.

~~~
thebigshane
Oh, and here's a pretty good comment on the article regarding static vs
dynamic typing:

    
    
      eamonnerbonne Thursday, September 13 2012
    
      It’s a night and day difference. Let me try a writing 
      analogy with Word + Notepad.
    
      Say you’re trying to write a text for a particularly 
      picky client that will reject your text if you make any 
      mistake or use any unclear phrase. Then dynamic typing is 
      like Notepad: you better be careful, have lots of 
      proofreaders, and expect to have your text rejected 
      often. And when you print it, it’s in a slow-to-read 
      monospaced font.
    
      Static typing is like Word with all the grammar checking 
      turned up to 11 (it won’t let you print or email any text 
      with what it thinks is an error). It’s harder to learn, 
      and sometimes your PC runs slowly, and the grammar 
      checker will find lots of irrelevant stuff, and to keep 
      it happy you might need to change your style, but it 
      *will* make certain types of error irrelevant (e.g. 
      spelling), and occasionally catch more complicated 
      mistakes too. Also, as a bonus that might or might not be 
      relevant, word prints in a font you can read much more 
      quickly.
    
      The point being: they’re totally different ways of doing 
      things.
    

[[http://gigaom.com/cloud/will-go-be-the-new-go-to-
programming...](http://gigaom.com/cloud/will-go-be-the-new-go-to-programming-
language/#comment-994342)]

------
wamatt
_“How big a deal is this static typing thing??”_ \- Barb Darrow (author of the
article)

wow

------
sigzero
I don't see it happening in the near future but it might.

------
markmm
It's all about the libraries, Python and C for example have libraries/bindings
for most things, e.g. Postgresql, ZMQ, Json etc. Google could invent the best
programming language ever but without _mature_ _robust_ libraries it is pretty
much useless.

~~~
tptacek
Go has a pretty decent standard library.

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

~~~
markmm
Yes it looks good, but what about mature 3rd party libraries?

~~~
Jabbles
Good software takes time. Asking a new programming language to have "mature
3rd party libraries" is a bit harsh. You are, of course, correct in that the
variety of libraries available in Go is more limited than older languages, but
I have hope that it will change rapidly.

<http://www.joelonsoftware.com/articles/fog0000000017.html>

~~~
markmm
I am not asking it to have anything, the article is insulating that GO is the
new go to language, it is not because it doesn't have mature and comprehensive
libraries. When I make a decision to use a particular language I don't wan't
to handicap myself, you need as much edge as possible. In 10 years maybe Go
will have a vast array of mature libs but until then I shall be choosing
Python and C.

~~~
Jabbles
I hesitate to contradict you, but the title and content of the article is
steeped in the future tense.

------
taw9
Go is awesome, but why must we limit ourselves to one language?!

My dev plan used to be Python for rapid prototyping and C for speed
optimization. With the advent of Go, I find I'm moving the infrastructure-
level Python work into Go and replacing many of the C-oriented middleware
tasks with it as well. I'm sure this will evolve as the libraries grow, but I
don't see Python & C going away. Nor do I think this is the vision at Google.
I suppose this is what is meant by "systems language".

I think Go could end up being the under 35-generation's version of Lisp (in
terms of love affair with language structure, etc.).

------
Evbn
No, it is less expressive than Ruby and JS and so will not be as popular with
the masses who optimize for LoC.

------
conradfr
Is Google behind all this hype ? There isn't a day without a Go article
somewhere.

