
Go is boring - swah
http://aerokode.com/blog/go-is-boring
======
Arnor
I had to hack the CSS a bit to make it readable, but I agree with the author.
Particularly, I like his comments on Go's attitude towards OOP.

As a Ruby hacker, I find that everyone on my team really likes to build a
class and think of the instances as real physical objects. That's to be
expected because it's how we were all taught to think of classes/objects/OOP
in general. Objects in your code are not physical objects. You don't have to
carry them around with you and pass them back and forth and up and down. You
can build new objects that are specific to your functions.

I find that Go encourages me to build structures that are relevant to the
situation instead of classes that are broadly scoped concepts. I also feel
this way when I work with C, but I like it better in Go due to the receiver
syntax.

It's true that my problems in my Ruby apps are my own (and my team's) damn
fault. We should be better at single responsibility. Still, Go's approach to
OOP encourages single responsibility and other good practices. I don't
understand what's boring about that. I for one get a real thrill when I write
some Go code then go over it and think "damn, that's just not going to
break..."

------
wyager
Go is poorly designed.

It has a mediocre type system, bad support for genericism, too much reliance
on non-extensible language keywords (range, make, etc.). Want to range over a
tree? Too bad. Or maybe wrap the tree with a chan and watch performance and
simplicity go out the window.

I mean, come on, what modern language actually recommends casting to the top
type? That would be like if idiomatic C++ involved casting things to void*, or
if idiomatic java involved casting things to Object, just so you can write
generic functions and types.

~~~
cnbuff410
Lot's people don't care if language x is "poorly" designed or language y has
"perfect" design. They evaluate language using two things:

1 Is it joyful to write without too much cognitive load? 2 Is it getting
things done?

Go fits both for them.

~~~
st2p
In 2 or 3 years when you move a few notches up on the developer continuum look
back on this comment and reflect.

~~~
pstuart
It's blub all the way up.

------
nly
> Nouns are things, nouns do verbs.

Of course, not _all_ nouns "do verbs", which is why we end up with warped
associations between particular language utilities, like classes, with notions
from one philosophy taken to weird limits.

Circles and Ellipses, for example, don't _do_ anything. They're data
structures. They're nouns, but they have no functionality. They have no verbs.
The correct solution to the Circle-Ellipse problem, the most famous
demonstration of one flaw with OOP, can be expressed elegantly and correctly,
in C++ and other "C++ style languages", using _classes_. Doing so doesn't make
anything object oriented, and we shouldn't associate giving things names with
a requirement for any particular set of associated verbs.

All language features are tools, and while I'm not saying Go is an inferior
tool if you're satisfied, we shouldn't make blunt instruments, or carry fewer
tools, just because some people don't know what they're doing. I'm currently
not satisfied with the set of features Go provides... but then I also want to
see some Go features in C++. Let's not get hung up on it.

------
bigdubs
Clickbait headline aside, I think Go threw some baby out with the bathwater in
the march to simplicity.

An example; try to sort a slice of runes.

~~~
arnehormann
The setup needs a little boilerplate, but it's definitely possible. And it can
support different sort orders after writing the boilerplate once. For those
wanting to test drive it:
[http://play.golang.org/p/I_Vu34hUoV](http://play.golang.org/p/I_Vu34hUoV)

~~~
fizznab
Interesting! Could you explain why []rune needs to be wrapped in a
struct{Runes []rune}? Rather then just calling "type Runes []rune"?

~~~
arnehormann
It doesn't need to. You could also write type Runes []rune but the struct
variant has the advantage that you can get the array back without any
conversions - it's pretty cheap. And you can embed it. That's an advantage if
you e.g. don't define Less on Runes but define it on RunesAsc and RunesDesc.
See [http://golang.org/pkg/sort/](http://golang.org/pkg/sort/) -> Examples
(SortWrapper)

~~~
arnehormann
The costs: allocating the memory, having it set to zero values and keeping the
garbage collector a little busier. All of that more than once if you don't
keep the conversions down. Profile and disassemble your program, Go comes with
pretty great tools!

~~~
dvisher
The Go runtime sets all memory to zero at the start of the program's
execution, meaning there is no overhead for 'setting the zero values'. The
amount of extra memory allocated is minimal (probably zero). Records/structs
tend to be figured out at compile time so no 'extra' information needs to be
stored in it. And since we are storing a pointer (a slice) the struct is
already aligned so no extra storage is needed there. What it might cost is one
extra level of indirection per array access, but due to the simplicity of the
program, I would not be surprised if this was removed at compile time or
cached (in hardware). Looking at the disassembly itself, they seem to optimize
out that extra layer of indirection as well (for the most part in Swap, Len,
and Less).

The real cost of this is definitely the verbosity for something that could be
much simpler.

------
adamnemecek
Since it seems down, here's the post:

Go is boring

Go has nothing new. Go has nothing special. You've see all of Go before.
You're right. I get it. But what you haven't seen is all these things together
in a single language. Where they all come together to make a really damn
useful core.

You've used channels before, cool. You've used the pure bliss that is the
slices efficiency in a couple of other places and grew to expect the behaviour
in new languages. You're proficient with threads, coroutines, actors, futures
and promises. You've quacked and walked and talked like a duck. But you've
never (probably) done all these things together. And that's what Go is. Go is
all the things that we've always known are good, smushed together. Go tries to
remove all the things that are bad about languages and erases the majority of
it (or at least does a good try to give you a decent alternative).

Static typing, with all it's greatness, can make for some damn verbose code.
You sit and type at the compiler what each and every variable is, you
painstainkingly explain (to a computer) explicitly what each part accepts and
returns. It's annoying, and mostly avoidable. There are several basic types
which have literal syntax, or functions which create those types. Or special
syntax. So why do we need to use the special syntax to create those types
along with telling the compiler which type it is? We don't. Type inference. Go
has a kind of type inference operator (:=) which will deduce the type at
compile time and save you precious keystrokes. This isn't anything new, tonnes
of languages do it.

Useful but light object oriented programming. There are tonnes of C++ style
languages which make classes seem like the final boss of programming. Where
all yours types have to be carefully categorized and laid out in neat little
ways in order to create a taxinomal tapestry, a kind of zoological museum of
each working object in your code. It's weird the kind of gradiose ceremony we
give to the simple act of giving stuff... stuff to do . Nouns are things,
nouns do verbs. That's simple as that. There should be nothing special about
that style of programming. It allows certain gains. It has wonderful
encapsulation of methods which operate on the same data (verbs acting on parts
of the noun), it has a nice semantic use (x is a y) but it certainly doesn't
have a use everywhere. Hell, I've been writing a lot of backend stuff for the
web and I've not written a Python class in about... 3 months. Many languages
bring OOP back down to the level of "just another paradigm", where it should
be. This is nothing new.

Concurrency is a first-class citizen. This is awesome. No longer do I have to
search through the standard library only to be met with an aging, creaking
model which doesn't quite fit my needs. Nor do I have to use the same tired
methods for making my applications concurrent. With annoying models like
threads and joins and crufty things like that. Go just goes. I ask for a
concurrent routine, I get a damn concurrent routine. It makes concurrency feel
solved for a lowly programmer like myself. This is nothing new.

I guess my point is that, whilst on paper (and I felt like this myself) that
Go may look like nothing new. Where it looks like you could get those features
elsewhere and not have to care about learning yet another new-school language.
You've not had them all together. Or at least this baked-in to the language.

------
hmgibson23
I don't think Go's concurrency model is as successful as others.

~~~
camus2
Go concurrency is great! but in a future a less rigid type system would help.

