
My Opinionated Guide To Go - lateefj
http://blog.hackingthought.com/2014/05/my-opinionated-guide-to-go-golang.html
======
rthomas6
Why does this article only compare Go with interpreted languages at the top?
Go is a compiled language; wouldn't it be more fair to compare it with other
languages that can be compiled, like C++, Rust, Haskell, or Lisp/Scheme?

I mention this because the article acts as if getting rid of abstraction
layers between the OS and the code is a new idea. No, that's how all compiled
languages are... that's the point of compiled languages. I suppose Go's most
common _use case_ lines it up against a bunch of slow interpreted languages,
but really there's no reason except good libraries that you can't use the
other compiled languages I mentioned for web apps.

~~~
lateefj
Author here. I was comparing things that I have developed software in. It
would seem unfair to compare things that I have not actively contributed
production code and deploy. I mainly write web applications (services) of
which C++, Rust, Haskell or Lisp/Scheme are not languages I find compelling to
write web applications with. Would love to hear if you find this otherwise.

~~~
rthomas6
No, I honestly know next to nothing about web apps programming. I do know
there exists decent-looking support for web apps for Rust, Haskell, and Scheme
(Racket, but Racket isn't compiled to a binary), but I don't have the
knowledge base to assess how good web programming is in these languages, if
it's even good at all. I know this website is written in Arc (a Lisp).
[https://github.com/wting/hackernews](https://github.com/wting/hackernews)

------
sergiotapia
I just wish Go would let me compile and run with a flag -allowing- unused
imports. I find myself wasting a lot of time hunting down unused imports or
variables and commenting them out.

Maybe that'll be a non-issue the more I use Go, but so far it's a bit of a
time waster.

~~~
AYBABTME
[https://github.com/bradfitz/goimports](https://github.com/bradfitz/goimports)

~~~
jerf
To explain to those who may not know what's going on here:

Go forbids importing modules that you then don't use in the source code. This
is particularly annoying with the "fmt" module, which contains things like
Printf that are useful for debugging, but you may only be using fmt.Printf for
one debugging statement in the code. Consequently, if you're developing, and
you're adding and removing it over and over you also have to add and remove it
to and from your import list over and over, which is very annoying since it's
likely to be relatively distant from your use location, and it's mandatory
that all imports are listed at the top of the file. (So, you can't do what you
can do in perl and say "use Data::Dumper; print Dumper($debugging_stuff);" all
on one line, without even being concerned about whether Dumper may already be
imported.)

goimports is a source filter that cleans out any unused modules, and tries its
best to add modules that you only reference. It's pretty good. You can confuse
it if you have two modules with the same last bit of the name, but the
standard library doesn't have that anyhow, and for the most part you can deal
with that. Since it also runs gofmt for you on save, it's also a drop-in
replacement for gofmt, which you should configure your editor to run on every
save even if you for some reason don't want the goimports functionality.
(Seriously. Just do it. There's no excuse not to. There's no excuse to ever
commit code that was not gofmt'ed.)

If you do that, the problem goes away. Typing "fmt.Printf" pulls fmt in
automatically, removing the one line removes it automatically, the import list
is always accurate, and it's smart enough that if it isn't the only usage it
doesn't remove it.

That said, I also strongly recommend setting up automatic syntax checking by
compilation (flymake in emacs, don't know what in vim, etc), so that you also
avoid the "Save -> switch windows to terminal -> compile -> get smacked in
face with an error that feels stupidly persnickety" psychological torture. If
the errors highlight in your editor on save or something, you go through that
much less. Those who lived in the C#/Java etc world have long had this... a
lot of people coming from the scripting side would be advised to pick up a bit
more of the helpful tools the static side has to offer.

~~~
mediocregopher
> flymake in emacs, don't know what in vim

[https://github.com/scrooloose/syntastic](https://github.com/scrooloose/syntastic)
for vim.

------
paukiatwee
"Go: Code -> Operating System -> Hardware"

Is there any reason to use RVM, PVM on production while Go does not required
one?

I believe should be install one and only one Ruby/Python version on
production.

Why Ruby/Python does not required application server like unicorn/wcgi, etc?

The article clearly try to make other deployment more _complicated_.

~~~
treystout
A lot of python shops I've come across don't use the system installed python
or ruby. In python land at least it's exceedingly common to deploy a
virtualenv with a separate python runtime and isolated 3rd party libs. This
makes pinning your version deps easier and doesn't matter if the underlying
server is ubuntu or centos or whatever.

~~~
paukiatwee
That is true, what if in future ubuntu/centos include Go by default (which
might not the version you use)? I believe then will have some GVM or similar
tool to solve the problem.

Edit: As others pointed out, Go is compiled binary and does not required
runtime (like JVM) so versionning is not issue. Thanks for clearing up.

~~~
Supermighty
There won't be a need for a GVM as Go is not a stand-alone runtime. Once
compiled for a specific platform it will just run. You don't even need it
installed on the server. You can cross-compile on your DEV machine and move
the binary LIVE. Then it just runs. It doesn't need any libraries on the
server.

~~~
kasey_junk
Does Go not have the concept of linking? If you are deploying several Go
applications on the same server that each use libraries, does it include
duplication of libraries in every binary?

~~~
Supermighty
There is no linking. Each Go binary has all of the libraries it needs baked
into it.

So if you have multiple different Go applications on one server, and they use
some of the same libraries, then each application's binary will contain a copy
of that library.

It makes things a little redundant, but also simplifies the deployment
process.

edit: The only exception is if you are using cgo and liking to existing C
libraries. In pure Go there is no linking.

------
cmhamill
Not entirely on-topic, but the mention of the various language "stacks" at the
beginning of the article reminded me of something I've been wondering.

Why does the de facto standard for web apps in Go-land seem to be using the
built-in HTTP server provided by net/http, or otherwise having the program
server as its own HTTP server?

Most other languages seem to have converged on FastCGI or some similar model
({W,P}SGI, Rack, etc.).

It irks me a bit because I don't understand why you'd want to do it this way;
it seems preferable to have a dedicated HTTP server in pretty much every way I
can think of.

Does anyone have any insight there?

~~~
kyrra
For Go, you probably don't want to use their net/http server if you will also
have it doing SSL/TLS. Go's TLS implementation doesn't support a lot of older
cipher suites which could be a problem for some clients. As well, it is not as
hardened as OpenSSL and others (such as possibly being vulnerable to timing
attacks[0]).

[0]
[https://code.google.com/p/go/issues/detail?id=2445](https://code.google.com/p/go/issues/detail?id=2445)

~~~
zsombor
OTH there was no Heartbleed bug in the SSL implementation of Go's net/http. So
much for hardened implementation. Secondly you can use go behind a http proxy,
or even in an FCGI etc environment with minimal change to the code.

~~~
icebraining
It's to be expected that different implementations will have different bugs;
that doesn't mean the Go's is better.

That said, it's an advantage of heterogeneity; you get some security by being
a small target in a sea of OpenSSL servers.

------
icebraining
_Docker - > Operating System_

This makes no sense. The runtime of Docker _is_ the Operating System. There's
no extra layer, as it's being implied.

And there's no difference between Go and the other languages that makes Docker
more or less useful. You can have separate Python processes without Docker,
just like you'd have separate Go processes.

I like Go, but this article just sets up strawmen to bring down.

~~~
regularfry
The question he's addressing isn't what you _can_ do, but what is commonly
being done. You don't _need_ RVM, you don't _need_ Docker. Hell, you don't
_need_ Rails. But those are the idiomatic layers of the stack, for a non-
trivial part of the Ruby development community.

~~~
lateefj
Sorry for the confusion JVM = Java Virtual Machine, RVM = Ruby Virtual
Machine, PVM = Python Virtual Machine. What I was trying to point out the
layers of vitalization just to run an application. Docker is yet another layer
on top of the operating system (a virtual machine running inside an operating
system inside an operating system possible ect).

~~~
regularfry
Ah, ok. I can see where you're coming from, but I don't really think of Docker
as being an extra layer on top. It's more a way of rearranging the OS layer
itself along a certain axis. The cognitive overhead is similar to a
virtualisation layer though, so that point stands.

------
ZenoArrow
Have noted this 'opinionated' trend going for quite a while, so this comment
isn't about this article in particular, but can someone break down why an
opinionated guide to something technical would be preferable to an impartial
one? The only thing it seems to imply is that bias adds value in its own
right.

~~~
lmm
It's a pre-emptive disclaimer "I know this isn't objective, don't complain
about that". And it tells you that the guide isn't going to offer you
confusing choices, it's going to tell you one way to do things. For some
people that's an advantage.

~~~
ZenoArrow
Thanks for your reply lmm. I can see what you mean. However, I do think it has
a high risk of building new dogmas without the understanding of when these
dogmas should be broken.

