Hacker News Reader

Comment by jlarocco | Hacker News Reader

Articles on Go are getting a little boring. The majority are written by people who've spent an afternoon looking at Go and decide to rehash the same 5 bullet points. In the time it takes to read their "article" I could learn the same stuff, better, by reading the official Go tutorial.

Some in depth reviews based on actually using it for an extended period of time on a large project would be nice...

View on HN

I agree about the articles themselves but vote them up because I tend to learn things on the resulting threads.

Go threads aren't as fun to read without uriel scolding non-believers for their bad taste.

As non-believer I miss my discussions with him.

I still wonder why Go is so prone to religious fanboys, though.

The problem is that even those are boring. I've used Go for an extended period of time on a large project and there's nothing to report. It works just like what everyone else already says.

I'm a Python guy, and there's something in this, I think. One of Python's underrated virtues is how uncontroversial a lot of Python idioms are. The "only one way to do it" attitude helps there.

In my (limited, biased) experience, there's three camps among the Python community:

1. people who want principle-of-least-surprise: there's a lot to be said for boring languages (if the language is the most interesting thing about your product...). Often the systems engineering/service engineering crowd.

2. people who want it to be more functional – the Haskell/Scala/ML crowd. (I guess the overlap between camp 1 and camp 2 is Erlang...)

3. people who want access to the library ecosystem, particularly the Numpy/Scipy/Pandas/Theano stack (the scientific community, latterly data scientists). This is my tribe.

So you've got three crowds here, at least, unified by a language. Where are they going to head?

Go has nothing for the second crowd; they're all going to go to a purer FP language sooner or later. It doesn't have much for the third (no IPython, LAPACK bindings, Fortran bindings, stats libraries, machine learning, etc...); we all have an eye on Julia. But for the first: great deployment story, small language, decent standard libraries, markedly better performance than Python, much better parallelism story...

As someone else noted below, it's also like "static typing lite." It has most of the advantages of static typing with much less of the bookkeeping involved.

ML-style languages go much further with this, while also having richer type systems that both let you write code more easily and do more compile-time safety verifications.

may i know what other languages interests you?

That's what's awesome about it! Everybody who uses it gets the same impressions of it (EDIT: and those impressions are 95% good). What other language has that going for it?

I think there's a survival-bias/selection-bias here.

Those who tried Go and came from a background of more advanced languages just threw it away quickly and wrote nothing about Go.

I've seen a few Haskellers finding similarities and praising Go[1]. Go is just meant to be practical and familiar to most working engineers and all the articles are going to reflect that. Most of the people coming from "advanced languages" are looking for new paradigms to move forward. When it comes to Go, there really isn't much to talk about besides the maturation of the toolchain.

[1] http://www.starling-software.com/en/blog/my-beautiful-code/2...

The plenty of Haskellers I know have all expressed disinterest in Go as a poorly designed language.

The linked post seems to be a very superficial take of Go. I wonder if he'd keep his opinion of Go after learning about lack of generics, error product types, nulls, mutability of concurrent messages, and all the other show stopper design mistakes...

As an aside, that article says that Haskell can't guarantee Monads to also be Functors. Is that a language problem or library problem?

That's purely a library oversight which has become mired in backwards compatibility (don't track any of that onto my carpet :P).

It would be trivial to specify that all Monads are also Functors by changing the definition of the Monad class a little bit:

    class Functor m => Monad m where

It's a library/compatibility problem, and it's (finally) being addressed now (will take years until the change takes place, need deprecation warnings for a loong time).

I think Peaker is right, I think a lot of us who are coming from Clojure/Scala/Haskell/Ocaml/etc don't bother writing blog posts that we're unimpressed.

What? Everyone coming from python/ruby/javascript maybe, but there's also a heck of a lot of us who wanted to like go but find it too primitive and inexpressive. I tried go while I was still a confused haskell noob, and I still had to go back to haskell. I can't imagine how bad go must feel to an experienced haskell dev.

In my case at least, this article spawned a little personal research that has me now giving Go a serious try. With all of the new-ish languages and databases popping up, it can be difficult to choose which ones to try for a new project, or seek solutions for a new problem.

There is something in the initial life of a new technology that determines if the adoption rate will result in success or failure, where failure is abandonment and an end to development. If this sort of interest keeps Go going, then maybe some repetition is a good thing.

You should look on the bright side. Every time one of these "Impressions of Golang" articles hits the front page, we get pages of bike-shedding in the comments.

I sorta like them for two reasons:

1. It's interesting to see what people struggle with or like about it, having written a lot of Go. That gives me some perspective, I guess.

2. The comments usually have these little gems of tips and tricks, like one I found here.

That said, #1 is getting a bit old.

I like these articles, because I like learning from other people's real-world experiences with various tools. He spent years using C++ at Google, yet decided not to use it for his own business even though he, presumably, wasn't one of the "junior developers" who couldn't handle memory management. He used mainly Ruby on Rails at his post-Google company and had a very negative experience. He says he'll write more about the naked emperor Rails. I'd love to read that article.

And if Haskell is so much better for real business infrastructure in practice, and not just a "more interesting language" in its own theory, I'd like to read more articles about companies that use Haskell, not fewer articles about companies using Go.

I've done lots of C++, and memory management has become much easier since shared and scoped ptrs have entered the std lib.

But still, going back to it now for a new project seems highly unlikely to me, it's like moving from a feature phone to a smartphone and then back. I just can't go back now. I'm a server guy so Go really hit the spot for me, despite having its shortcomings.

This is better than the average such article.

I get the sense that many of us are just waiting for a few improvements (like generics and better GC/performance) before using Go for real work, but it seems mature enough for many uses already.

Reply on news.ycombinator.com