
A Farewell to Go - luksch
https://www.churchwood.at/posts/a-farewell-to-go/
======
jayflux
> According to my opinion, a programming language should let a developer use
> his or her style. A heavy influence on the programmer’s style is okay, but a
> fanactic, religious-like enforcement is inacceptable.

As someone who has wasted many hours debating which JavaScript style guide to
follow I disagree with this. Go have quite frankly put to bed any debates or
arguments over "curly brace on same line or below" by setting a style and
having it policed by the compiler. When working in a team it's good to have an
official style guide that's enforced, in the long run this is a good thing.

I don't think this was done because Go's developers are opinionated, I think
they looked at other languages and seen the mess that can happen when you
don't set a style guide and thought "we're not doing that"

~~~
Graziano_M
Also his one example:

> For example placing an opening curly bracket on a new line causes the
> compiler to emit a syntax error.

That's actually part of the syntax, not the style. The compiler adds an
implicit semicolon at the end of every line, and if there is one before the
block of a switch, if, for, etc, then it looks like it's missing (and the next
line's curly braces is just a new block.

------
blowski
> According to my opinion, a programming language should let a developer use
> his or her style.

Fine if you work on your own. But if you work in a team, whose style do you
use? I much prefer Go's "stop wasting time on things that don't matter and
just use this style" approach.

~~~
ozfive
I am going to chime in and second the team argument here. Being stubborn on
style tells me a person is going to be inflexible on a myriad of other things
as well.

~~~
fithisux
I do not agree. What google did here is to liberate us from style fascists.

~~~
cweagans
I dunno. It kind of looks like they just unified everyone against a new style
fascist?

------
matt_wulfeck
> _According to my opinion, a programming language should let a developer use
> his or her style._

Please no. Never. moving to enforced styles freed me from having to think and
debate about them. I think go set a precedent here that every new language
should follow.

~~~
infogulch
(good enough & coordinated) >>> ("beautiful" & custom)

I think people underestimate the enormous cost of custom. Once style can be
customized it opens up a whole universe of costs: compatibility, learning
curve, project onboarding, tooling complexity. These are hours upon hours of
human lives that just vanish into the abyss of pointlessness. Not just during
the a style debate itself, but the _mental energy_ it consumes at all times
when "you know this specific situation would look nicer if we just made this
one tweak to the style" is a possibility.

The standardized style is one of the best things about Go and one of the
things I miss the most when working in other languages.

The usual thing to say at this point would be "To be fair there are some
things I don't like about Go format, but the social benefit is worth it" but
I've moved past even that. At this point _I don 't even give a shit about
style_. As long as it has _something_ reasonable and it does it automatically.
And before you write me off as never caring, I used to be that person that
spends hours aligning things until they look just right, adjusting spaces to
align mid-line, debating on brace & bracket placement. But it's all garbage
now. Just make it good enough to read and get it out of my way.

I don't like playing Microsoft Word layout games in my text editor anymore.

------
flavio81
Everytime I read somebody pushing for the Go language, i recall this
interesting, funny piece written about it.

[http://cowlark.com/2009-11-15-go/](http://cowlark.com/2009-11-15-go/)

------
sdfg35y345y
EDIT: I don't think its fair to give this blog/author this amount of feedback.
Clearly he has no idea what he is doing:
[https://github.com/agentS/pq/commit/c8f9125577fc92985e4b85d8...](https://github.com/agentS/pq/commit/c8f9125577fc92985e4b85d84929f449e99255e3)

> According to my opinion, a programming language should let a developer use
> his or her style. A heavy influence on the programmer’s style is okay, but a
> fanactic, religious-like enforcement is inacceptable.

I believe the OP exhibits a fanatic, religious-like enforcement of how he
wants to format his code. If he would use gofmt, he would not have this issue:

> For example placing an opening curly bracket on a new line causes the
> compiler to emit a syntax error.

Because gofmt will fix it for him.

> The same goes for string concetanations that start on a new line.

Not even sure what OP means here. There are both the `` string escaping for
multiple lines, and you can perfectly fine split up expressions over multiple
lines, like so:

s := "aaa" +

    
    
       "bbb"
    

> the linter displayed so many warnings due to my code style, that I turned it
> off.

Way to go, cowboy.

> Broken Package Management

See gb, govendor, glider etc. Many languages can be critized for the same, but
there are solutions. Use them.

> A possible mitigation strategy is shown by the Kubernetes project whose
> creatores store their application’s dependencies in their repository.
> However, this is an anti pattern of using a VCS.

No, this is not an anti-pattern, it is a perfectly valid solution to vendoring
dependencies.

> No Inheritance, Missing Generics

Please learn the language better.

> Feature-Lacking HTTP Library

So, use one of the _many_ http libraries around that suits your need better.
How many languages even ship a http library in std lib?

~~~
paulddraper
You have good point. I take issue with only a couple.

> No, this is not an anti-pattern, it is a perfectly valid solution to
> vendoring dependencies.

I'm not going t to tell you it won't work, because it will, but this very
rarely done, particularly if you use a DCVS like git. When's last time you saw
a Java Maven project do this. Almost never. Why? Because there is a very
standard, robust way to vendor dependencies.

> Please learn the language better.

How is learning go better going to help you make a useable skiplist? What non-
novice wisdom would help out?

------
senko
I'm curious about what the author chose instead. Sadly, it is not mentioned in
the post (maybe for the better - it'd lead to an inevitable flamewar about Go
vs whatever his new choice is).

~~~
romanovcode
Probably Kotlin :')

~~~
fithisux
I believe he is with the Swift/Kitura cult now.

------
WHI
Package Management and Generics are the two big ones that I agree with here.
Inheritance, when used correctly, is really useful but is too often abused and
for that reason alone I cool with it's omission. I'd add that the error
handling, while readable, feels a little clunky when I'm writing it.

`if err == nil` (am I right!?)

Importing Gorilla really doesn't seem like it should be a deal breaker however
I understand why someone fond of Python would lament not having everything
built into the language ;).

------
lobster_johnson
Dupe has more comments:
[https://news.ycombinator.com/item?id=14970256](https://news.ycombinator.com/item?id=14970256)

------
dvfjsdhgfv
Most of the arguments against seem like either personal-taste things or
something that will or at least can be fixed in one of the next releases
(maybe except inheritance).

~~~
willtim
It might be personal taste, but I'd prefer a language incorporating
innovations from the 1980's onwards. I doubt that will be fixed in the next
release.

------
fithisux
I agree only on the generics thing. The package management is out-of-scope for
me. However rudiments of genericity should be there. I do not aim for the full
thing.

