
Reasons for using Golang - jemeshsu
http://programmers.stackexchange.com/questions/82179/examples-of-beautiful-go/82307#82307
======
sid0
The only reason to use Go is if you've fallen victim to the Google hype.
There's no reason to use a slightly less shitty version of C with most of its
fundamental problems (shared mutable state, nullability by default...) fully
intact but orders of magnitude fewer programmers when you can _just use C_.

~~~
derefr
> fundamental problems (shared mutable state, nullability by default...)

Those aren't the "fundamental problems of C", those are the _reasons people
use C in the first place_. The point of "systems languages" like C and Go is
that they directly expose a (standardized interface to) the Von Neumann
architecture your computer actually implements, which allows for arbitrary
references to memory that may be uninitialized, multiply-aliased, etc. This is
what allows for the efficient implementation of such things as garbage
collectors, process schedulers, virtual memory managers, IPC libraries,
network stacks, and so forth, that the runtimes for higher-level languages
rely upon as fundamental abstractions.

So, given the assumption that such code is necessary to write, why shouldn't
we try to have a better language to write it in than C? I'm not suggesting
that Go is such a language, but your argument seems to be that it's pointless
to try to do better than C (because every language, no matter how good, starts
with no one using it, and thus necessarily will have fewer programmers than C
does.)

~~~
JulianMorrison
Well, no, the state that's shared, is shared across goroutines in Go, or
across Posix threads in C. Those are not directly exposing the machine, those
are exposing a particular type of abstract machine over the actual machine.
Contrast Erlang processes which are built on the same machine but have
different assumptions (message passing by copying, no shared state)

In fact there are hardware models that fit Erlang better, such as non-cache-
coherent NUMA. So from a certain perspective, it's not that C is low level,
it's that the CPU was designed to execute C. And the CPU is anyhow general
enough to be used in non-C-like ways.

I personally think Go missed a trick when it didn't require channel data to be
provably impossible to alias across goroutines. (It could be immutable, pass-
by-value, or "unique" such that aliasing is disallowed.)

As for nulls, Go actually doesn't really have them, the poster above is
mistaken - Go has zeroed values, and you are encouraged to make them valid-
but-empty. That includes zeroed pointers.

~~~
sid0
_Go has zeroed values, and you are encouraged to make them valid-but-empty.
That includes zeroed pointers._

Is there a material difference between that and null? I don't care what I'm
"encouraged" to do -- does the language force you to opt in to null?

~~~
JulianMorrison
<http://golang.org/doc/go_spec.html#The_zero_value>

Yes if you're using pointer-like things, but at least in Go it's an
unsurprising thing, all uninitialized data is zeroed. And Go permits you to
work with by-value structs and arrays if you want.

~~~
sid0

      t.next == nil
    

I don't give a fuck whether it's called null or 0 or nil or whatever, or
whether it's amazing or surprising or shocking. Every single pointer has null
as a possible value, which means Go suffers from what I think is the biggest
possible mistake a (non-scripting) programming language could make (and I'm
not alone -- Tony Hoare thinks the same). The worst thing about all this is
that we already _have_ a well-known and well-studied solution in the Maybe
monad, yet the Go designers buried their collective heads in the sand here.

~~~
JulianMorrison
On the upside, Go does not suffer from the common Java anti pattern of
returning a semantically meaningful null. Its multiple return means that while
it can't return "Maybe Foo", it usually returns something like "Either Error
Foo", with the multiple assignment taking the place of a rather primitive
pattern match. Also a go function is typically structured like a primitive
Either monad - it returns with an error immediately if it gets one, or else it
returns from the end with a value.

~~~
sid0
Tons of functions in most imperative languages are structured in an early-
return-on-error style, with exceptions simply being a special case of that.
That is neither novel nor uncommon.

~~~
JulianMorrison
But not with multiple return where (as an idiomatic design pattern) the _same_
error object is passed up through the call stack until something decides to
handle it, which is what the Either monad does. (And unlike exceptions, the Go
way and the Either monad are both explicit, there are no unmarked returns.)

The C way with single return means that it's generally impossible to just
forward the same error object - the caller has a different type from the
callee, so where one returns null another has to return -1, and so forth.

