[kmontrose]

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

---

> Go programs are built from just their source, which includes all the information needed to fully build the program.

Still have to deal with GOPATH, vendor your dependencies, and have everything a `go generate` comment wants to invoke. It's certainly better than makefiles, but it's hardly just the source.

> C# is joined at the hip with Windows. Objective-C and Swift are for Apple. Java and Scala and Groovy might benefit from JVM bytecode and its independence… until you realize that Oracle isn’t interested in supporting Java on anything other than Intel hardware.

C# has Mono, you can use Objective-C with gcc, the JVM has a bajillion implementations. I suppose Swift is more or less unportable at the moment. 1 out of 4 ain't great.

> 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).

This never went away. Heck we were going over this in college, which for me was in Scheme, Java, C, and C#.

[Animats]

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.

[mpweiher]

> 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.

[bsder]

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.

[NateDad]

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?

[frou_dh]

> 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

[steveklabnik]

> 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).

[NateDad]

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

[Padding]

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.

[rakoo]

> 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.

[kmontrose]

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.

[NateDad]

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.

[misframer]

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

[kmontrose]

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

[misframer]

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

[TheDong]

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".

[kmontrose]

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.