Why I Program in Go

For the life of me I can't understand why anyone would give up the power (in terms of profiling, monitoring and ecosystem, and somewhat better performance, too) of the JVM, for a language marginally more convenient than Java, and arguably less expressive than other JVM languages. The only thing I could think of is a smaller RAM footprint, if you care about that sort of thing.<p>Whenever Go is compared to Java, the arguments in its favor seem kind of fuzzy. After all, one of the motivations behind Go was a C-like language with far better compilation time than C++. And Java already fits the bill. So, yeah, Go is leaner and more modern -- but certainly not by an order of magnitude, like other JVM languages. Here, too, the author says that he didn't like Java's IDEs (really? does Go have better tooling? Because Java IDEs really get the job done), frameworks etc. But those things are simply the result of years of changing fashions. Newer Java "frameworks" are just as lean-and-mean as Go.<p>There are so many new and exciting languages around, but Go seems to carry the least "oomph" of the lot. It's basically Java. A little nicer; a little slower; a lot less powerful.

Those are many of the same reasons I program in Go.<p>To add another:<p>* Go's build tools and the language's overall approach to building projects are fantastic.<p>For the vast majority of projects you don't need an external build manager like make. One of my least favorite bits of programming in C and C++, even when I was doing that on a daily basis years ago, was the huge morass of make/autoconf hell that would grow up around projects and would be very difficult to understand and reason about unless you were there for the entire project's development.<p>With Go open source projects (on git, svn, mercurial) much of the time you can just<p><pre><code> go get http://hosted-code-site/blah/(package) cd (package) go build </code></pre> ... out pops a working executable.

I just can't get that hyped about Go, but I will tell you (as a Rubyist, primarily) I've really been enjoying Rust. While they're not directly competing, my experience is similar to the author's PHP -&#62; Go, which is why I comment. I have programmed significant projects in statically typed languages in the past, but this new batch of languages (Rust/Go/Scala/etc) are certainly neat.

As an ex-Ruby cum Node.js lover recently converted to Go...<p>Programming in Go, once it clicks, really does feel relaxing and productive. If you're a decent Node.js programmer, it's like stepping up to "Node Pro", in the sense that you work close to the metal with your web server so everything feels clean and easy to wrap your mind around.<p>But Go code is cleaner and tighter. The code formatting conventions contribute to that greatly, as well as the fact that you just don't have to pull in as much 3rd party code because so much functionality is already beautifully integrated.<p>There are a lot of positives about Go that reveal themselves over the first couple days of coding in it.<p>I do wish the documentation convention included not only a brief description each function, etc., but also a brief example.<p>By the way, I also evaluated Scala for a few days before settling on Go as my preference. I like Scala, but it quickly becomes a sprawling language as your explore it further, and frameworks like Play and Lift bring even more baggage along for the ride. The core language, on its own, was attractive, but overall, the experience just didn't have the compact, robust, completely under control, and nimble feeling that came with Go.<p>Oh ya, and the Go syntax felt ugly and awkward at first. That feeling quickly faded after a day of use, but it's worth mentioning because I bet it turns some people away from Go before they even get to the great parts.<p>Just my 3 cents worth.

I love Go for many of the same reasons as the author. Go's fantastic performance doesn’t' hurt either. :)<p>These micro-benchmarks match what I have seen in the real world:<p><a href="http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-best.php?calc=chart&#38;go=on&#38;ghc=on&#38;sbcl=on&#38;java=on&#38;scala=on&#38;csharp=on&#38;fsharp=on&#38;php=on&#38;hipe=on&#38;python3=on&#38;erlang=on&#38;clojure=on&#38;yarv=on&#38;perl=on&#38;jruby=on&#38;xfullcpu=1&#38;xmem=1&#38;xloc=1&#38;nbody=1&#38;fannkuchredux=1&#38;meteor=1&#38;fasta=1&#38;fastaredux=1&#38;spectralnorm=1&#38;revcomp=1&#38;mandelbrot=1&#38;knucleotide=1&#38;regexdna=1&#38;pidigits=1&#38;chameneosredux=1&#38;threadring=1&#38;binarytreesredux=1&#38;binarytrees=1" rel="nofollow">http://benchmarksgame.alioth.debian.org/u64q/which-programs-...</a>

I want to try out Go...but I have to make one initial observation...It can be somewhat hard to Google (ironically) for Go programming examples. I'm sure there's some tinkering you can do in your search query to get slightly better results, but "Go" is a difficult proper pronoun to facet a search around.<p><a href="https://www.google.com/search?q=go+facial+recognition" rel="nofollow">https://www.google.com/search?q=go+facial+recognition</a><p><a href="https://www.google.com/search?q=python+facial+recognition" rel="nofollow">https://www.google.com/search?q=python+facial+recognition</a>

&#62; Now, you might want to ... acquaint yourself with [dataflow variables and declarative concurrency] because [they are] the centre-piece of Go's language features.<p>Not so. Go has native support for neither dataflow variables nor declarative concurrency. Go does have native support for message-passing concurrency--but that's different.

"Earlier I mentioned about the JVM being a bad trade-off for phantom portability. In practice, non-trivial Java programs also require porting for different systems."<p>I have used Java since the beginning (and I have written several Java books). I have had very few portability problems. The JVM is a great ecosystem that supports several fine programming languages.

If anyone is interested in learning go, my site has a compiled list of tutorials and so on<p><a href="http://pineapple.io/resources/tagged/go-language?type=tutorials" rel="nofollow">http://pineapple.io/resources/tagged/go-language?type=tutori...</a>

<i>Java is perhaps the most depressing language I've ever programmed in.</i><p>I'd have to agree with him there.

&#62; <i>Scalars (integers, characters, strings, floats, booleans), sequences (lists/arrays) and maps (key-value pairs) as built-ins are enough to support almost all data models.</i><p>There is some wisdom in Larry Wall's decision to make scalars, lists, and maps the main data structures in the Perl programming language and to give them the sigils $, @, %. The considerable wealth of Perl libraries available on CPAN today demonstrates that you can support essentially all data models using these three data types.

Go nails code readability and documentation better than any other language I'm aware of.<p>For example, look at the package documentation for Go's list data structure at <a href="http://golang.org/pkg/container/list/" rel="nofollow">http://golang.org/pkg/container/list/</a>.<p>5 seconds of reading this you immediately get what the package does and how to use it. Now let's say you want to know how the list is implemented. No problemo. Click the package files link list.go, <a href="http://golang.org/src/pkg/container/list/list.go" rel="nofollow">http://golang.org/src/pkg/container/list/list.go</a>, and you're presented with very readable source code.<p>Now compare this with Java. I just Google'd Java List. First link is this: <a href="http://docs.oracle.com/javase/6/docs/api/java/util/List.html" rel="nofollow">http://docs.oracle.com/javase/6/docs/api/java/util/List.html</a><p>Documentation looks OK, but wait, this is the interface. I want to see docs for a concrete implementation. I'm tempted to click on the AbstractList link, but oh wait, that's just another non-concrete class that other List classes probably inherit from. Let's see, let's go to the ArrayList ... this looks good. <a href="http://docs.oracle.com/javase/6/docs/api/java/util/ArrayList.html" rel="nofollow">http://docs.oracle.com/javase/6/docs/api/java/util/ArrayList...</a><p>Nice. I wonder how they implemented this. And I'll keep wondering because I can't find a link to the source code. Maybe there is a link to it, maybe not. We're talking about Oracle so without knowing better, I'll assume there is not ...<p>Let's try Scala. Google "Scala List". Click on first link. <a href="http://www.scala-lang.org/api/current/index.html#scala.collection.immutable.List" rel="nofollow">http://www.scala-lang.org/api/current/index.html#scala.colle...</a><p>What the fuh is a "sealed abstract class List[+A] extends AbstractSeq[A] with LinearSeq[A] with Product with GenericTraversableTemplate[A, List] with LinearSeqOptimized[A, List[A]]"<p>Oh sweet, this thing has all kinds of methods, i.e. ++, ++:, +:, /:, :+, ::, :::, :\<p>Reading further, I see section in the documentation called "Shadowed Implict Value Members". Wow, I have no idea what that is.<p>Looking back to the Go documentation, I immediately "relax" as another commenter put it.<p>For some reason, I think Scala will end up being the next Java. It has so much momentum, runs on the JVM, has seamless interop with Java code. Has the Play Framework, AKKA, and thousands of other awesome libraries written for it. And if Scala powers Twitter, then I think this answers the scalability and concurrency question.<p>While I'm bullish on Scala, at the end of the day, I find Go's simplicity make it more beautiful than any other language.

I am C and lisp fan and think OOP as non-sense. I used python a bit but hate its performance. Can I still get something from Go that can not be provided by C and lisp? Does go provide great flexibility by C and lisp? BTW, I think emacs is the best IDE so I do not care any tools/IDEs at all.

Thus far I feel that, if any language was ever going to replace C, it's probably Go. In a way I sympathize with Go. I like it for the compactness and simplicity. Those are two design decision which seem to be unique among modern languages and exactly the two things I like most about C.

Can anyone explain in less than ten words the most important reason to program in Go?

I prefer to use Hypescript for all my kickass cloud deployments.

His second point is, to me, the most important for would-be language designers:<p><i>Standardized formatting: A standard tool to enforce formatting rules that is not subject to change based on the team members' or leader's opinions is a welcome feature for lowering the "not my code" mental barrier.</i><p>This is a godsend. The best thing to have happened to our industry since a very long time.<p>But his first point is oversimplified:<p><i>The compiler not only checks for code that can theoretically result in a runnable program...</i><p>It's not exactly as if Go did solve the halting problem or we'd <i>ALL</i> be using Go. So I think a bit more in-depth explanation would have been welcome.

It feels like Go is the new Fortran.

We don't care you why program in Go.