
A Farewell to Go - Hates_
https://www.churchwood.at/posts/a-farewell-to-go/
======
setheron
This was a terribly worded blog post. The problems the author faced with go
were so paper thin -- I don't think they warranted claiming "every line of go
i've written is now deprecated".

It's pretty clear going into go from the initial HelloWorld -- that you are
expected to:

1 - use gofmt 2 - won't have inheritance 3 - Drudge your way through a
solution for dependency versioning

To complain about it so late into a project really speaks poorly to the
author.

~~~
djrogers
> To complain about it so late into a project really speaks poorly to the
> author.

There's really no need for such a personal attack here - why do you feel a
need to lash out at this author?

It is entirely reasonable to start a project knowing of limitations, and
finish that project with a better understanding of how those limitations
affect your productivity in the real world. That's what we call _experience_ ,
and learning from it is a critical element of personal growth.

~~~
zemo
> There's really no need for such a personal attack here - why do you feel a
> need to lash out at this author?

the whole blog post is lashing out at something. You reap what you sow.
There's no "these are the tradeoffs, and this is why I disagree with those
tradeoffs"; every argument goes like this:

\- I have an expectation

\- that expectation is informed by my priors, not by Go

\- Go didn't meet my expectations

\- even though Go never made or promised to meet those expectation, I'm going
to be mad that it didn't do something that I wanted that was never promised

the whole article is structured like "Go wants me to think in a different way
than I already think and I refuse to think in a new way".

~~~
emperorcezar
That's not it at all. He attacked your chosen tribe, now you're responding
with personal attacks. The correct response would be, "I didn't mean to
personally attack him, what I meant was X"

Go is a language, attacking Go is not justification for you to attack the
author. Replace Go with a rant about Ford trucks and you'll see how silly you
are being.

------
majormjr
I disagree with the authors feelings on code formatting. Gofmt is one of the
best features of Go, especially when reading others code.

~~~
alekratz
I can agree with gofmt being great, but I can't agree that a simple newline
before a brace should be treated as a syntax error. You're forced to use
Google's coding style, whether you like it or not. Preferred coding style is
subjective, and Go ignores the fact that not everyone works for Google.

~~~
adrianlmm
I don't know why they are modding you down, but is true, code formatting is
subjetive and Google enginers do not hold universal truth.

------
y0ssar1an

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

gofmt is the best part of Go. Everybody's code looks the same.

    
    
      Broken Package Management
    

This is a solved problem with dep. Switch your Go projects to dep today.

    
    
      In the documentation there is no mentioning of those missing things, you expect from a modern HTTP library.
    

Go's philosophy is "less is more." This is the journey of every Go programmer:

    
    
      What?! Go doesn't have X??? This is an outrage!
      * figures out how to do it without X *
      I guess I didn't need X after all. I just had to write a bit of code.

~~~
matthewmacleod
_This is a solved problem with dep. Switch your Go projects to dep today.

This never works correctly for me and I have no idea why. I haven't written
enough Go lately to get this sorted – but it's definitely not quite so
obvious.

_This is the journey of every Go programmer:*

There are steps after that though:

    
    
      Oh, I guess I have to copy that code from before. No big deal.
      Oh, right. I have to copy it again, with some changes? I guess that's okay.
      Wait, did I fix this bug in the other copies too?
      fire and burning pain.

~~~
lowmagnet
No offense intended, but in those steps, I'd have probably lifted some of that
work into a closure or other higher-level function. Go behaves a lot like a
hybrid of functional and objective programming.

------
pmarreck
[http://www.golang.sucks/](http://www.golang.sucks/) is both a better and a
more comprehensive critique of Go.

Rob Pike's quote about "They’re not capable of understanding a brilliant
language" is extremely unfortunate, and a missed opportunity to elevate the
art/science of programming and the much larger understanding of information
theory in general for all programmers, instead of trying to appeal to the
lowest common denominator. My first question would be "why would anyone pick a
language that is _designed out of the box to ultimately limit the depth of
their understanding_?

~~~
Qworg
"Because many developers have a limited depth of understanding and no desire
to increase it" is the pithy but correct answer.

~~~
pmarreck
Sham developers accelerating technical-debt spaghetticode, then. ;)

------
jgrant27
Go is a lowest common denominator language designed by a large company to make
programmers expendable. It's ironic though because we all know how that worked
out after Sun tried it with Java and what we now have some 20+ years later.

~~~
zemo
> It's ironic though because we all know how that worked out after Sun tried
> it with Java and what we now have some 20+ years later.

a tremendous number of production systems written in Java, being used by a
tremendous number of people, and making a lot of money for corporations?

That's the goal of Go. It's not for research, it's not for discovery: it's for
dominating the marketplace. If Go replicates Java's fate, it will have
succeeded at its goals, because it's goals are to be used in production
systems run by corporations.

------
matthewmacleod
I also disagree on the code formatting front – once you get used to it, gofmt
really is the best thing ever.

However, all the rest of the points are pretty valid. Go has the potential to
be an awesome language and environment, and minimalism as a language attribute
is attractive. But it's so frigging annoying to use in practice.

------
cft

        Interfaces help to solve the   problem with methods of objects, but not with data members. 
    

I wonder if the author knows about structure embedding in Go at all.

~~~
samuell
I guess the author meant that interfaces are defined by methods, not data
members. Thus, you can't have an interface that describes you should have a
member field "Foo", but instead will need to create a "getter" Foo(), for it,
if you want it to be part of an interface definition.

~~~
cft

         Go willingly chose to not support this behaviour causing me to write a lot of duplicated code. For example, my SAP analysis web interface uses three different product group structures, as the required amount of details varies between user stories. Go forces me to maintain the same code in three different places.
    

I think his reference to "duplicated code" means that he has the same data
members in different structures, and that he duplicated those members, instead
of using structure embedding. He then looked for a solution in interfaces, and
_naturally_ did not find it there. If so, he is at a very basic level of Go
knowledge. Having dealt with complex Go codebases, I have never seen "code
duplication"

~~~
samuell
Aha, yes, I see now.

------
davidw
He doesn't mention what he's using instead, which doubtless has problems of
its own. I'm not much of a Go user, but its community seem fairly forthright
about what it does, how, and its tradeoffs. I didn't learn anything by reading
this.

~~~
hardwaresofton
I wonder if the author has gotten a chance to use Java or C++ for any extended
period of time. While I don't think Golang is the greatest language ever
invented, the trade-offs it offers for the productivity it provides is
paramount to me.

I think an appreciation for Go and the choices it makes can only be fully felt
once you've spent a significant amount of time in another less
expressive/convenient/simple language.

------
luord
From everything I'd read about it, I idealized Go and it sounded, on paper,
like an awesome language.

Actually _writing_ it felt like a true dose of reality after such built-up
expectations. It's... ok, I'd say I like it better or at least as much as any
other static language, but damn it feels clunky at times. Specially the error
handling; the `if err != nil {...}` _everywhere_ is basically built-in
verbosity and isn't very expressive.

------
vbezhenar
What I really miss with Go is a proper error handling. First of all: in my
opinion exceptions are vastly superior to return values. But even if I can
live without exceptions by adding `return err` everywhere, Go lacks proper
framework for error construction, all it provides is strings as errors and
stacktraces are not even provided. Third-party libraries can solve this
problem, but only partially.

------
roguecoder
The verbosity of error handling is what frustrates me most. If errors are
supported as a first-class citizen, handling them should be too.

I'm still happy to employ it for what it does well, but using it feels a lot
like using Java circa 1997.

------
crb002
Go's most impressive feature to me is it's build ecosystem. Took one of Tyler
Treat's experiments and had it running within 30 minutes, no real previous Go
build experience.

The language itself? Meh. Python/Haskell/C/LLVM IR cover my use cases. I see
Go as another wrapper on top of LLVM IR when it is convenient and that is it.

~~~
didibus
I thought go compiled to native directly? Does it use LLVM under the hood?

~~~
tcard
The official compiler doesn't. Then there's llgo [0] and gollvm [1].

[0] [https://github.com/go-llvm/llgo](https://github.com/go-llvm/llgo) [1]
[https://go.googlesource.com/gollvm/](https://go.googlesource.com/gollvm/)

------
savethefuture
Did the author even learn Go?

Gofmt is for consistency for all devs to be on the same page, the format and
structure is part of the language.

Are they complaining about the inheritance and generics, again did they learn
Go? Stop thinking in about other languages when you are writing Go code, think
the Go way.

~~~
mrkgnao
What is the Go way to implement a generic data structure that can't be
trivially realised by wrapping a couple maps and arrays into a struct (without
using interface{} and throwing away the safety Go's type system, such as it
is, provides)?

~~~
verroq
You first reconsider your need to make a generic data structure and evaluate
on a case by case basis.

~~~
matthewmacleod
That's a glib answer. You end up with a bunch of duplicated code when you do
this.

~~~
verroq
How often do you implement generic data structures in your code? The last time
you wrote one was probably in your data structures class.

~~~
mrkgnao
There are many, many, _many_ "legitimate" "real-world" situations where you
need data structures ouside of the two or three Go gives you by default.
Queues? Dequeues? _Trees_ , for the love of $DEITY? Tries? Sets?

Effective use of Golang is really teaching yourself to think that anything
beyond the language is a useless distraction or some kind of academic
pretension. I won't go so far as to call it S________ S_______, but this is
textbook Blub.

------
skynode
I'm learning Go for working with distributed systems and blockchains, but I'm
basically another C#/.NET dude. Apart from the requirements to follow and
maintain certain Google Guidelines, I don't mind the language to be honest.
Looks neat to me.

~~~
skynode
Interestingly, I've been learning Go by reading the goethereum codebase. Any
more awesome codebase pointers would be appreciated too. Thanks all.

------
Shywim
I would agree that go has many flaws, but the formatting and gofmt is not one.
I welcome a language that enable me to not care at all about the formatting,
and just focus on programming.

\- Write a messy formatted code \- Run gofmt \- Commit

------
perpetualcrayon
I might as well use this thread as an announcement that I'm extremely excited
to be working in Go in the near future.

Go appears to have all but monopolized most of the really exciting / modern
Cloud Infrastructure open source projects, and from what I can tell it's going
to be a joy to work with given the number of solid web frameworks that exist.

------
brianolson
Inheritance and Generics: How's the discussion for Golang 2 going? Do we get
_some_ code reuse mechanism? Macros? Anything?

~~~
tcard
At the very least, you get as code reuse mechanisms: functions, ad hoc
polymorphism via interfaces, struct and interface embedding, and reflection.

------
spraak
No new arguments here, and the author doesn't share what they'd rather use
instead.

------
warent
1\. Strict Enforcement of the Google Code Guidelines

People who are undisciplined typically don't like discipline when they first
encounter it. This doesn't restrict "Coding style" like the author suggests.
Coding style and code format shouldn't be conflated.

2\. Broken Package Management

It's not broken; it's intentionally limited. A "vendor" directory is natively
supported by Go to account for this; use Glide or similar for more complex
use-cases.

3\. No Inheritance

It's a pattern of programming just like any other. In return you get first
principles code and tiny lightning fast binaries.

4\. Missing Generics

While I agree this isn't awesome, you can resolve this using Reflection.

5\. Feature-Lacking HTTP Library

??? The author is missing the point of Go here entirely.

~~~
concede_pluto
Go binaries are small and don't do much initialization work but they don't run
especially quickly, mostly due to GC and value->interface conversion and
dynamic dispatch.

~~~
warent
> and value->interface conversion and dynamic dispatch

Thank you for the reply. Where can I learn more about that?

------
palerdot
Nitpick/Off-topic: typo in the following line for the word 'lightweight' >
Go’s capabilities of utilizing leightweight thread

------
hsnewman
So everyone is entitled to their own opinion. And one person's opinion is no
different than any others.

That said, I absolutely love go and wouldn't consider any other language for
my development. I like the strict coding guidelines. Some of the things listed
are bugs/issues that can be fixed in later releases (Feature-Lacking HTTP
Library & Broken Package Management to be specific).

------
sergiotapia
Haven't used Go in about a year and change, is Google going to pull an Angular
and pull the rug out from under developers for Go 2.0?

~~~
scallycat
Go 2 considered harmful?

~~~
roguecoder
I now really, really hope that when they originally named the language it was
exclusively to set up this pun. Well played, friend, well played.

------
renownedmedia
"Strict Enforcement of the Google Code Guidelines ... According to my opinion,
a programming language should let a developer use his or her style."

This is one of the better language features, IMO. No more maintaining
massively complex inherited eslint rulesets. One style and you're done.

------
adrianlmm
I almost picked Go for a project, I've read so many complains about it that I
feel like I skiped a bulled.

~~~
owenmarshall
You can find complaints that range all the way from "spot on" to "wildly
inaccurate" for any tool.

What project did you have in mind? What specific complaints did you see that
made you think "this isn't a good fit"? And what did you pick instead?

------
zac123
I am not surprised you mention "missing generic". It can be done by using
interface. As "no inheritance", you can use encapsulation. As "broken package
management", you can use "vendor". Above are all about how to engineer
application. There is no only one way to solve it. (if you are from java/C++,
I don't think those OOP concepts are the king rules) As of "Google
Guidelines", I would judge you just entered the beginning level of software
engineering. (You dont know how much pain without those)

In conclusion, I think you blog title is just making horrible attention.

