Hacker News Reader

This oversells golang's simplicity I think. Not a lot, but enough to rub me the wrong way a tiny bit.

True. Go is a good language for server-side web stuff. That alone is enough to make it very useful. It is a good language for when you want to get server stuff done and it has to go fast. That's enough. It doesn't need to be overhyped.

Go is helping pioneer a command-line renaissance that reintroduces a generation of programmers to the idea of writing tools that fit together like segments in a pipe (the original Unix philosophy).

That's inherently a batch processing approach. The "strings through a one-way pipe" approach was never that great. It's brittle. If anything goes wrong, the options are to abort the whole thing, or print a message to stderr which will probably be ignored.

Better ways to plug programs together are needed, but Go doesn't do much new in that direction. Today, plugging programs together probably involves a number of programs which use protocol buffers to communicate, running on, say, Amazon AWS. There's much work going on in tools for doing that. They aren't typically pipe-oriented.

> Better ways to plug programs together are needed

Yes! Maybe a language with direct support for software architecture, such as defining + (re-)using your own connectors.

I like the fact that the Go guys continue to avoid talking in detail about Rust and Clojure.

That tells me that the don't think they can win the comparison.

Who can win against lisp anyways?

The reasons we aren't seeing more lisp/clojure are not technical/objective ones but attitude, social and nework factors - which are just as relevant though.

The core goals behind Rust and Clojure are very different from those behind Go. This article/presentation would not be appropriate for those languages. I don't think anyone would say that Rust or Clojure are simple languages, or that simplicity is a core goal for them. Rust's core goals are performance, memory safety, and lack of race conditions (AFAICT). And clojure is a LISP which puts it in its own category, really.

It's like saying a jeep can't compare to a ferrari or a minivan - other than having 4 wheels, they're really not at all designed to do the same kinds of things... Sure, maybe driving to the corner store they're all pretty much the same, but which do you want in 8" of mud? Which do you want in a car chase on the highway? Which do you want to bring your 4 kids to soccer practice?

> Rust's core goals are performance, memory safety, and lack of race conditions (AFAICT)

We usually formulate this as "memory safety without garbage collection," which has secondary implications on speed and concurrency, but yes. (Also, 'data races' rather than 'race conditions,' technically).

Thanks for clarifying :) Yes, I should be more careful about specifying data races vs. race conditions :)

> I don't think anyone would say that .... Clojure is simple language, or that simplicity is a core goal for it.

Good god you are so wrong.

Watch yourself some of Rich Hickey's trove of excellent presentations, including the one where he breaks down the detailed etymology of the word "simple" and how much he strives for that.

http://www.infoq.com/presentations/Simple-Made-Easy

> Still have to deal with GOPATH

Once, when you install Go.

Then for each project, put your stuff where you want and symlink from $GOPATH to where it is. Once per project.

There really is minimum hassle to integrate the recommended flow.

note that symlinking is not actually the recommended flow ;) Just put everything in gopath.... I even put non-go code in my gopath... it's just a nice way to organize - by the VCS url.

You also install runtimes once for other languages.

GOPATH isn't awful, but it's something more than "just source" as claimed in the article; which is my point. Go is simple, but not as simple as claimed.

Package users should not have to run "go generate". It's mainly for package writers to generate code and then distribute it.

And? Presumably some of these packages get updated, handed off, or are collaborative in the first place. Re-generating is part of continuing development.

Sure, but that's not specific to any language. Is it Go's fault that package writers work a certain way?

Go encourages working in that way, so yes, it is.

With other languages, you might do code generation through powerful macros (e.g. as rust has) or some other tooling which is not literally just "run a program in the user's path".

My point is that `go generate` requires more than just source, and thus isn't "simpler" in the manner claimed in the article.

I'm not judging the existence of `go generate` or it's merits relative to some other environments. Except makefiles. Makefiles are worse.