A Farewell to Go | Hacker News Reader

A Farewell to Go

churchwood.at

59 pointsHates_83 comments

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.

> 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.

> 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".

I don't think that's fair. More – "Go suggested I think in a different way, then I did it and it still wasn't good like it was advertised, and now I'm going"

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.

Yes, in go these things have solutions. Maybe not the best ones we can have, but there are ways to approach the problems beyond just giving up.

1 - Most editors automatically support that. I wouldn't say being forced to follow a certain code convention is bad, but it understandable that it may bother some people.

2 - You can still the code-reuse features of inheritance by using embedded structures with methods attached to them.

3 - There are many solutions which solve the problem without needing to commit the vendor directory to git like `glide`.

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

I think this is the thing I want most languages to adopt. As someone responsible for ensuring a team's work can be supported by new developers, gofmt is a life saver.

I don't use Go, but I agree with you. Style just shouldn't be an interesting topic, pick one and go. Best if the computer just handles it for you. Doing it this way gets everyone in the ecosystem on board with one style early on, and makes it much less of an issue going forward. This is the smart way to do it.

Indeed, forget goroutines and channels. The most innovative thing Go brings to programming is gofmt. Between that and the simplicity of the language, it makes it so easy to dive into large foreign code bases and actually understand what you're reading. That's one of Go's strengths.

This is, IMO, one of the things that makes Go exceptionally well suited to enterprise development: software tends to pass around multiple different teams with widely varying skillsets, and tends to have a surprisingly long shelf-life.

A simple language with enforced formatting means the code that I wrote several years ago looks much like the code I'd write today. Vendoring dependencies means I can ensure my environment works today as it worked when the application was being developed, and I don't need to go hunting for old dependencies that may not be there anymore. Lots of batteries included in a standard library that has a strong backwards-compatibility pledge means I often don't need libraries.

I've never worked with Go outside of an enterprise; I wonder if these pieces are maddening there.

> software tends to pass around multiple different teams with widely varying skillsets

I find this to be the most damning drawback: by design you can't ever get better with it, to cater to people who shouldn't be in the profession. There's a reason that using a spoken language clearly and eloquently is beyond the skill of a young child.

I agree that vendoring is the right solution for libraries that are not packaged for your target platform, in fact it's damn hard to reach truly deterministic offline builds without vendoring.

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.

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.

It's not subjective when the language dictates that's how it's to be done. Coding style changes based on the language you're writing in, Go just happens to have a very strict style.

  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.

Spot on.

Hopefully someday they build a monument to K&R with "less is more" written on it. As someone currently stuck in a Scala project, I'd donate a sizeable sum towards that goal.

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.

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.

> I guess I didn't need X after all. I just had to write a bit of code.

I guess I don't need functions and variables after all. I just have to write a bit of assembly code (for some definition of "a bit"). When the complaint is that a language is insufficiently expressive, noting that anything is possible at the cost of being more verbose isn't really a refutation.

> Everybody's code looks the same.

That is not a feature. Consistency and readability are not the same thing - it's a lazy substitute for readability, at best.

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

From a quick glance, `dep` seems to still be using source/repository URLs as dependency identifiers, which is a terrible idea. Other languages use a registry for a reason.

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?

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

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

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.

> 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.

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.

    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.

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.

Yes, that's annoying. Luckily though through embedded structs he could inherit all the methods to access each of those fields in whatever types he creates and make matching some interface easier.

     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"

Aha, yes, I see now.

Access to data members violates encapsulation. This is OOP 101. Complaining that a language doesn't allow declaration of data members in an interface declaration (and thus reliable direct access to data members) is basically complaining that the language enforces best practices for a 40 year old programming paradigm.

Go permits struct fields to be public. Ergo, Go doesn't care about enforcing the notion that field access violates encapsulation. It is up to the programmer to decide what is being encapsulated.

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.

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.

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.

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.

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.

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.

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

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

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

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.

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)?

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

Mhm, sure, I can go back a couple decades for the sake of argument.

Say I can make do with instances of my data structure for, I don't know, int8, int16, and strings.

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

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

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.

The last time I wrote one was a few weeks ago. I've written dozens of them during my career.

I needed a ListMultimap a couple of weeks ago. Fortunately it had already been implemented for me because my language doesn't prevent that.

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.

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

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

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.

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

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

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

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.

Except go does have inheritance... basically:

https://play.golang.org/p/yDejKzS4EQ

Thinking of that as inheritance is a Bad Idea. That's embedding. It looks like inheritance but really it's sugar for calling B.A.fn()

Composition over inheritance. A lot of developers use polymorphism as a crutch.

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.

> and value->interface conversion and dynamic dispatch

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

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

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).

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?

going to? Hard to say, doesn't sound like it at all though. They want a non-breaking release, to prevent the Python 2-3 debacle. However, what will happen only time can tell.

Go 2 considered harmful?

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.

One of the major focuses at Gophercon was on Go 2.0 being an _extremely_ incremental process. Go 1 development is planned to continue with backwards-compatible changes being incrementally added, and Russ Cox hoped Go 2.0 would happen when Go 1.n+1 would either:

* have no changes to be made from Go 1.n other than backwards-incompatible ones, or

* would have no backwards-incompatible changes at all.

I get the feeling that the developers have learned a great deal about not making large breaking changes & segmenting the language.

The fact that Go is small, has a large community (outside googlers), and has a completely open spec makes it one of the least likely languages to just fade into obscurity.

The Go language accomplishes some amazing things so far, and it a pretty decent choice in the systems-programming space. Even if google dropped it, there would almost definitely be another company or group willing to be it's benevolent dictator(s).

Isn't it somewhat problematic to consider Go as being in the systems programming space? A garbage collector seems like a pretty good disqualifying factor for that.

You're right -- I really considered putting systems programming-ish in my comment because of that. I talk my way around the limitation in my own head because it really depends on the system you're programming -- a lot of even lower level systems these days come with a lot more memory and resources to manage. Maybe I'm just warping what the term means to my own ends.

I certainly hope not.

Can't speak for Angular, but in Python land, ~9 years later, people are still cleaning up the fallout of the changes from Python 2 to Python 3.

It wouldn't bode too well for such a young language as Go to go through the same process.

My personal observations are that Go is gaining a lot of steam in many places. Announcing that they will break compatibility would make those places strongly reconsider their commitment to Go.

> Announcing that they will break compatibility would make those places strongly reconsider their commitment to Go.

Umm, they've actually announced the opposite. Not sure why you say that.

I meant hypothetically. Sorry if I wasn't clear.

As in, if in some hypothetical scenario, Google announced that they would break compatibility, it would be bad.

Definitely agree with that.

"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.

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

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?

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.

Reply on news.ycombinator.com