
A Grumpy Guy Complains About Complaining - martinp
http://go.c800colon5.com/blog/2014/01/09/a-grumpy-guy-complains-about-complaining/
======
ekidd
From the article: _This is like finding a new alloy of steel and then building
a bridge out of it to see if its any good. If Go doesn’t have generics, and
you know you need generics, why the fuck did you bother with Go? These details
are widely, exhaustively documented; they are not surprises._

Well, I took a good hard look at Go, and I said, "There's a lot of stuff here
that's really, really sweet, but error handling is going to require 600 gross
conditional statements, and I'm going to have to rewrite common algorithms
over and over and over because there are no generics."

But lots of people in Go community kept saying, "Yes, it looks a little
unusual, and it doesn't have all the features you'd expect, but you need to
give it a fair chance, and try writing a real project or two in it. Don't be a
blub programmer, afraid to try out strange new abstractions."

So I wrote a couple of medium-sized programs in Go, including a server which
broke simple substitution ciphers (to help perform OCR on subtitles). This
involved a lot of tweaking of algorithms and optimizing. This was maybe my
second or third medium-sized Go program.

And maybe about the third time I had to tear apart the server and rewrite it,
and said, "This whole experience is actual incredibly painful. Why does this
code keep hurting me every time I need to redesign something?" So I paid
closer attention, and I said, "You know, my code is buried under error-
handling conditionals and lots of stupid little subroutines that should be in
standard library—but which can't be there, because there are no generics."

Seriously, if Go had Erlang OTP-style error-handling and some ruthlessly-
simplified generics, I would use it all the time. The type system rocks, the
basic data structures are excellent, and the standard library is good. It's
clearly well-optimized for writing certain types of programs. It's just I
don't write those programs very often.

It turns out what I want is a lot closer to Elixir: Erlang concurrency
semantics, decent Unicode string handling, some light metaprogramming and a
Ruby-like syntax. Too bad Elixir is still so young and obscure.

~~~
mahmoudhossam
If you know Go doesn't have what you need, then why did you use it?

Sometimes, a language isn't a good fit for what you're building, and you said
that yourself, you don't write those programs very often.

And some other times, a language just isn't for you, it doesn't match the way
you think about programming.

For example, I tried to learn Scala a lot and it just didn't work, so I
stopped trying because there are better uses of my time than saying: "I wish
language X had feature Y" or "I wish language A was more like language B"

If Elixir has what you need, then by all means use it. Nobody knew Python
before Google started using it, didn't stop them from doing great things with
it.

~~~
jws
A language with everything would be a nightmare. To program efficiently you
need a balance between capability and mental footprint. If I have to write
large amounts of code to accomplish a task, that is bad for me and the
eventual reader. If I use some feature so esoteric the read has to stop and
research, or worse, misunderstands that is also a problem.

The Go promise is that they don't have some things, but you won't miss them.
Some are deliberate omissions, some are deferred until they decide if they are
required and can sanely be implemented. How those impact you is going to
depend on what problems you are solving.

The danger is to end up wanting language casserole with bits and pieces from
everywhere. It might be what you want, but by the time you union that with
everyone else it is too big to know.

You don't go in saying "I need exceptions. I will use Go!" You start down the
road saying, "I used to use exceptions, but in Go I will explicitly check all
the errors." Only with experience can you look back and see what the cost was.

~~~
malkia
A library for what you need - e.g. language features in library... but then
that would be some form of lisp :)

------
joshuapants
>I think of these languages, these tools, as something akin to violins and
cellos. They’ve been around, virtually unchanged, for several hundreds years.
They are an absolutely gigantic pain in the ass to play- they haven’t got any
frets, they have tiny fingerboards designed to be played by scrawny,
malnourished 15th century musicians. They’ve got tuning pegs designed for
strings made out of animal guts and which rely on friction alone to stay in
tune. They’re freaking baroque. And yet, they get played a lot. You might
argue that their design actually encourages mistakes.

I wish people wouldn't make analogies about things they don't understand.
Frets do not make string instruments automatically better, in fact they limit
you in terms of intonation and vibrato. The fingerboards are exactly the size
they need to be, and would be less ergonomic if they were simply made wider
(every attempt at an ergonomic violin I've seen has involved changing the body
shape to make it easier to hold, not widening the neck. Widening the neck
substantially on a bass would just be completely unhelpful) and a lot harder
to bow. Friction pegs were certainly designed for gut strings, and that's why
you'll find geared tuners on many instruments that use steel strings (and
sometimes even on ones that use guts).

I just find it funny that he doesn't like it when people who don't understand
Go try to criticize it, and then criticizes something he doesn't understand in
an effort to strengthen his argument.

~~~
jodrellblank
The analogy communicates fine to me, someone who doesn't play a violin.

It doesn't matter at all how accurate his criticism of a violin is, any more
than it matters that C has nothing analagous to 'tuning pegs'.

Your wish that people wouldn't communicate in a way in a way that is effective
but you don't like, is therefore silly.

~~~
joshuapants
I don't think you read my comment in full. I said nothing about how effective
his analogy was, just that it was obviously misinformed, to a laughable
degree.

~~~
jodrellblank
Of course I read it in full. You write a lot about how his comments on violins
are wrong (which I say is irrelevant) and then say "I wish people wouldn't use
analogies about things they don't understand" (which I say is also irrelevant,
because it's _effective_ ).

You then misrepresent what he doesn't like, which I ignored because one can
only pick on so many annoyances in one post, then you suggest he was
criticizing violins (which he wasn't) in an effort to strengthen his argument
(which he wasn't, and he isn't arguing anyway he's describing his viewpoint).

~~~
joshuapants
I'm going to go with my original comment before I changed it for something
more polite. Your comments are like the Go language: weakly typed and useless.

Hey, you're right, being intellectually lazy is effective!

------
bcaffrey
Yes, because everyone knows the full requirements for a project up front.
That's why we all still use waterfall, right?

------
nakkiel
Hum wow. So there's at least one guy on the internet trying to make sense. And
the pop-software culture thing also had to be coined.

------
norswap
The problem with Go it that it is fundamentally non-exciting. It brings very
little to the table, when compared to C.

On the top of my head: \- GC (which some people find to be actually a cons) \-
Some more modern ammenities for debugging. \- Coroutines (this is really where
go shines)

On many other fronts, Go is actually a regression from C, because it favors
being "safe" over being expressive. Goodbye macro, pointer arithmetic, etc.

Omitting exceptions is a moronic decision. In a program that does its fair
share of I/O, this means that error checking will end up taking a huge % of
the code written (easily 30%). It will naturally push people to either eschew
error checking, or to write huge methods to dilute the error checking code.

So in the end, I'll use C with a coroutine library. It'll feel (and be) more
hackish, but I'll be more productive and my code will be easier to understand.

Now, that's my opinion. Maybe other people have different sensibilities and Go
is just fine for them. But I think it's pretty obvious that Go is not right
for a lot of people, and nothing's wrong with them. It's unfair to pretend
they haven't a point. Go is not for everyone.

~~~
burntsushi
> Go is not for everyone.

Yes. The OP agrees with you.

> Omitting exceptions is a moronic decision.

They didn't. Go has panic/recover. It isn't idiomatic to expose a panic in a
library, but if you know you're going to be doing a lot of error handling,
then you can utilize panic/recover to make error handling much terser. I do it
frequently when writing parsers[1] or web applications.

[1] -
[https://github.com/BurntSushi/cif/blob/master/parse.go#L56](https://github.com/BurntSushi/cif/blob/master/parse.go#L56)
(Every panic with a `cifError` will be automatically translated into a regular
Go `error` value.)

~~~
norswap
That's very interesting, thanks!

------
Dewie
> So here we find ourselves in a world with various better choices than C and
> C++, yet they still get used for a pretty significant chunk of all the
> coding that goes on in the world. Why is this?

Isn't the emergence of relatively many system programming languages in recent
years partly a reaction to there indeed _not_ being many viable choices? I
mean, I guess you have all the languages that are C-level (or Go-level) that
were simply out-competed by C in the mainstream software world for whatever
reasons, but people don't seem willing to go and program in languages like Ada
and seeing if it's a better fit (or at least I haven't heard much of it). It
seems more like, "every other decently mainstream language has mandatory
garbage collection → therefore C/C++".

