Hacker News Reader

Comment by reallyRaoul | Hacker News Reader

Your concept of pleasant / your uses of Go must drastically diverge from mine! :-} I find Go to be needlessly obtuse in the language, the configuration, the tools, and the documentation. This is turning into another horror: it used to be that lots of jobs required javascript; now I fear the kool aid is making people push for Go. Note that I have not used Go for the concurrency stuff. Some might say that means I'm not allowed to have an opinion ;-) whereas I think it means I see the crappy foundation more clearly exposed.

View on HN

What language is simpler to setup?

1. Download tar.gz (or zip) 2. Extract to <place> 3. export GOROOT=<place> 4. export GOPATH=<some_other_place>

... if you want to get fancy and make sure all your binaries are automatically in your path

5. export PATH=$PATH:$GOPATH/bin

... at this point setup is done, to build your first project using an external library

6. go get github.com/<user>/<library> 7. code, code, use <library>, zug, zug... save code in $GOPATH/src/<your_package> 8. go install <your_package> 9. $ <your_package> # runs it

this package can be shared because it is a static binary -- share with your friends, run on other servers, heck -- even cross-compile for other platforms with ease. Working on Linux -- but want to ship a utility to do X for a friend on Windows, no problem!

I dont think there is any configuration?

Building your own working Go installation from source is one command, then building a Go project, yours or someone else is one more command.

Except for how that didn't work for me. Yes, I have a "reverse midas touch" when it comes to technology, but I think that makes me a good UX critic. :-) And even if/when it does work, I detest the whole GOPATH idea. I know the alternatives are not perfect. I know. But still...

So the extent of the obtuse configuration you are talking about is a single environment variable?

curious then, what in your opinion solves these "ux" problems better?

> I detest the whole GOPATH idea

Maybe (or maybe not) you'll find this[0] useful: touch .gopath in some project directory, your GOPATH and PATH will be set automatically upon cding inside.

Then, work straight on the root for simplest projects or prototyping, or inside src for multi-package projects. In any case, deps will go in src, and you can readily vendor them, or use git submodule, or a simple shell script containing a sequence of "git clone", or not at all. No tool like godep, no import rewriting, no global workspace, per project dependencies, zero overhead.

[0]: https://github.com/lloeki/dotfiles/blob/master/shell/go

I concur. This is an easy and efficient solution. We do that in my company with one difference: instead of setting the GOPATH depending on the current working directory, we use a Makefile.

Having coded in more than a dozen different languages, I think the Go ecosystem is the easiest I've used - when you look at the entire development and deployment stack.

You're right that GOPATH needs to be set, but is that really any different to having Python, Perl, Ruby, etc JIT's in your PATH env var? And GOPATH is certainly more convenient when it comes to the distribution of program (ie copying the compiled PE / ELF) than having to ensure that you have a Perl et al run time environment (and particularly any required non-standard imports) installed on the destination system.

But Go isn't a JIT / scripting language, so that's probably not a far comparison. So let's compare it to it's closer relatives: C# and Java. Java is just a mess from a UX perspective. It's a mess to install, it's a mess to redistribute. It's just a complete mess compared with Go. C#, however, is a very friendly language to approach as a new developer - if you're writing applications on Windows and for Windows. I will grant you that .NET is open source and cross platform, and that recent reports suggest .NET projects will become more portable in future years, but you still need a Mono runtime on non-Windows platforms. Go compiles it's dependencies into it's binary (hence the size of the binary).

I'm by no means saying Go is perfect, but lots of people have tried to solve the problem you're raising and more often the case is their attempts are less user friendly than Go. Which leads me to think that maybe the minor inconvenience of having to define GOPATH (and it really only needs to be defined once in the entire lifetime of your Go development machine) is a pretty good usability solution.

Have you tried modern Java development and deployment lately?

It's really not that bad -- projects like https://github.com/puniverse/capsule, Oracle's http://openjdk.java.net/jeps/208 and reference implementation of such JEP, http://docs.oracle.com/javase/8/docs/technotes/guides/deploy... have made Java deployment a breeze.

Last, but certainly not least, the state of the art tooling for Java, the world class GC (and advanced ones like G1), the breadth and depth of its incredible ecosystem, the performance monitoring and extension API, the innovative Quasar library (https://github.com/puniverse/quasar) for concurrency alongside the features and additions in Java 8 pretty much make Java a serious contender for new projects.

If you haven't explored modern Java, I suggest you give it another look.

I haven't, and that's good to hear. But it's still more complicated than Go if just in regards to how you need to be aware of these tools to begin with. Where as Go's behaviour is out-of-the-box.

This is purely from a "this is my first language" angle though. So I'm not to say that the aforementioned Java tooling isn't better than Go's, and in many other ways too.

Reply on news.ycombinator.com