The Zen of Go

https://dave.cheney.net/2020/02/23/the-zen-of-go

by sagichmal • 6 years ago

328 263 6 years ago

dave.cheney.net

pansa23• 6 years ago

The article mentions “Simple is better than complex”, but not the next line of the Zen of Python, which I think tells us a lot about that language’s philosophy: “Complex is better than complicated”.

Looking closely, that line says “(not simple) is better than (not easy)”, or more clearly, “easy is better than simple”. Python definitely lives up to this - it’s easy to get started with, but if you look deeply it’s a very complex language.

Go’s philosophy is probably the opposite - that simple is better than easy. This is similar to the philosophy of Clojure, as explained by Rich Hickey in “Simple Made Easy” [0].

[0] https://www.infoq.com/presentations/Simple-Made-Easy/

bjornjajajaja2• 6 years ago

It would be nice to have “elegance” brought into the picture too. Code is an art as well!

aequitas• 6 years ago

Unless your building a user facing frontend please keep art out of your code. Just like a bridge internal's concrete structure doesn't need decoration so does your backend's plumbing. Writing elegant and artful code that is hard to understand and debug does not make you a clever developer. Keep that stuff for the demo-scene or 99-bottles-of-beer. Go is an language for engineering software, not crafting.

todotask• 6 years ago

I just read Eric update quite recent on CSP. https://gitlab.com/esr/reposurgeon/-/blob/master/GoNotes.ado...

"Translation from Python, which is a dreadful language to try to do concurrency in due to its global interpreter lock, really brought home to me how unobtrusively brilliant the Go implementation of Communicating Sequential Processes is. The primitives are right and the integration with the rest of the language is wonderfully seamless. The Go port of reposurgeon got some very large speedups at an incremental-complexity cost that I found to be astonishingly low. I am impressed both by the power of the CSP part of the design and the extreme simplicity and non-fussiness of the interface it presents. I hope it will become a model for how concurrency is managed in future languages."

d0mine2• 6 years ago

dreadful language to try to do concurrency in due to its global interpreter lock

don't take it too seriously. GIL has its issues and it would be nice to see it gone but "dreadful" is an overstatement. Python wouldn't be so widely used as a back-end language otherwise. Concurrency is not parallelism.

On "it [Go] will become a model for how concurrency is managed in future languages." -- it is not as clear cut as it appears at the first glance: "Notes on structured concurrency, or: Go statement considered harmful" https://vorpus.org/blog/notes-on-structured-concurrency-or-g...

cannabis_sam4• 6 years ago

Go community’s practice for grounding language enhancement requests not in it-would-be-nice-to-have abstractions but rather in a description of real-world problems.

jfc, the arrogance of this asshole. Seems like a decent fit for Go though, considering that language’s history of ignoring PL research..

I mean, Go is awesome for containers, and it’s awesome if you have a lot of junior devs and a decent amount of churn.

But the amount of anti-intellectualism by big shots in the community is seriously depressing.

masklinn5• 6 years ago

Don't forget this absolute banger:

Obviously Go chose a different path. Go programmers believe that robust programs are composed from pieces that handle the failure cases before they handle the happy path.

A function which only returns an error can have its result ignored without any warning.

throwaway89434511• 6 years ago

I don’t think that paragraph was referencing compiler guarantees.

tomlu• 6 years ago

A function which only returns an error can have its result ignored without any warning.

It should perhaps be an error to not assign an error to a variable. Internally, Google has linters that enforce this.

closeparen5• 6 years ago

Any serious Go shop would have errcheck as one of the linters in CI.

jpgvm4• 6 years ago

These are great idioms for writing code in any language.

I'm no longer a fan of Go but still a fan of many of the people the work with it because they also value many of these things.

mongol• 6 years ago

Did you use to be a fan? What happened?

toolslive• 6 years ago

IMNSHO: experience.

jpgvm4• 6 years ago

I was a fan in the past and still think the language has niches it's good at. I just no longer think it's a good general purpose language - more correctly I think there are languages that are better than Go in every metric that counts for general purpose use cases.

I invested a lot of time and work in the language (about 4 years professionally) but become disillusioned with it over time.

The big reasons for no longer liking the language stem from decisions made around the type system (this being the main reason), tooling (namely packaging, vendoring/modules bleh) and weariness with the verbosity and logic per line density.

So when would I still pick it?

I would pick Go if I specifically need to shuffle bytes between sockets with high I/O concurrency and don't need access to C libraries or any complex logic at all. The moment there is business logic I don't want to be writing Go anymore.

mxschumacher2• 6 years ago

The principles and origin of Go are dear to me, I feel philosophically aligned. Focus on: Dev tooling, simplicity, large scale collaboration, networked services and readability

pansa23• 6 years ago

It’s interesting that you and I have chosen the same language for completely different reasons. I’m interested in static binaries, “batteries included”, better-than-interpreted performance, and parallelism.

apta8• 6 years ago

large scale collaboration

What does golang have to facilitate large scale collaboration that isn't done better in languages such as Java or C#?

tsimionescu13• 6 years ago

Even more, what does Go have better in terms of dev tooling than Java or C#?

tmountain• 6 years ago

Not a Golang expert or zealot, but a few things come to mind that make it suited for large scale projects and collaboration:

1) Extremely fast build times (even for large codebases).

2) The package system plugs directly into Git/Github.

The second reduces friction for distributed/large teams to share packages with a lower administrative burden.

I can't compare to modern Java/C# because I haven't used either for quite some time.

mxschumacher2• 6 years ago

The simplicity of the language means no gigantic class hierarchies. Theres are fewer ways to do something.

Since engineers spend most of their time reading and debugging, readability and low abstractions facilitate collaboration: it should be relatively straightforward to jump into any Go codebase.

People often laud the relative ease of picking up the language. They're productive quickly, that's not by accident.

svat• 6 years ago

See https://talks.golang.org/2012/splash.article "Language Design in the Service of Software Engineering" for some of the design goals of Go and how they led to its current design. (For example, gofmt/gofix make automated refactorings across a large codebase (different teams) easier or more pleasant.)

chucky_z• 6 years ago

As someone who has written more C# and Java than Go... I can read Go much easier than most other languages. I can step into a huge codebase and usually quickly reason what/where I need to make my changes without too much effort. This can be the case with C# and Java, but it seems to almost always be the case with Go.

twistedpairs• 6 years ago

I mean it is beyond madness to even think that Go's dev tooling compares favourably to Java tools & ecosystem on the friggin' JVM.

Dev tooling surrounding the JVM blitzes pretty much everything both in terms of dev(maybe code reloading could be improved for Java ala Clojure) & operations.

Lightyears ahead of Go.

papito7• 6 years ago

Go didn't even have dependency management until only recently. Readability... 2/3 of Go code is error handling, by design.

vijaybritto3• 6 years ago

Yes and it has worked well for large projects like kubernetes

saagarjha2• 6 years ago

In Java, and Ruby, and Smalltalk, the core value that everything is an object drives the design of programs around message passing, information hiding, and polymorphism.

This is certainly not an accurate description of Java…

skrebbel• 6 years ago

Why not? Seems apt to me.

saagarjha2• 6 years ago

Java has Simula-style OOP. The characteristics used there are often used to describe Smalltalk style OOPs: note that Java does not have message passing, and it has primitive types.

superkuh• 6 years ago

Like others that have been downvoted to invisibility in this thread I'm a bit upset about the namespace conflicts between the new computer language and the old but highly active game. This "Zen of Go" has to be an intentional overloading of the traditional meaning.

dkarl• 6 years ago

Also, the use of "Zen" to refer to anything intuitive or aesthetic.

Zen itself is pretty fascinating. It sucks to see it invoked as an excuse for "I'm going to go on at great length and at the end still ask you to take everything I said on faith because it's simply too profound for argument."

getpost• 6 years ago

Not Zen! Go Kant!

georgehm2• 6 years ago

What if, instead, we take a position that rather than enhancing components, we replace them. Then the best way to know when something needs to be replaced, is when it doesn’t do what it says on the tin.

This is something that I have had trouble reaching a balance. Replacing components could be costly and therefore it makes sense to design components that are extensible (and seem over engineered) especially when the requirements aren’t known completely? What are your thoughts on this

mtzet• 6 years ago

Not the author, but I'd prefer rewriting the code as the requirements become clear rather than building something unspecific. In my experience the benifits to code reuse are vastly overstated and the costs of added complexity vastly understated.

njharman2• 6 years ago

YANGNI

You've replaced a "could be costly" (rewrite if we need to) with a always costly (over engineer for expansion).

Also, when you don't know the requirements completely is the prime time to do/write as little code as possible. You can't know future and guesses are more often wrong.

You should really push back on teams managers that ask you to write code without telling you what that code should do.

Learned over 25+ years of professional dev xp. Coding for 39yrs.

georgehm2• 6 years ago

Thanks @njharman , how does one consider between rewrite vs expand when it is known that some requirements will be true not for the current release but 2 or 3 releases down the line. Would you still prefer rewrite vs expansion? The reason I ask is I got severe pushback recently where I proposed building generic enough components and infra to go along with it that could have satisfied the requirements for the next 2 or 3 releases

SPBS• 6 years ago

If you can, don’t reach for a goroutine, or a channel, or embed a struct, anonymous functions, going overboard with packages, interfaces for everything, instead prefer simpler approach rather than the clever approach.

This reminds me of an interview I had with a company recently. I mentioned that although I was using go for my current pet project, I had hardly touched goroutines because net/http automatically spins off a new goroutine for every request so I don't have to think about it. The interviewer was incredulous and said that every database call should be put behind a goroutine so that it's not slow. He said the point of go is to leverage its powerful concurrency mechanisms. What I wanted to say was that I believed go's selling point was its simplicity and not its concurrency mechanism, and that it would be more idiomatic to keep it simple first and refactor only if there's performance issues. But he was the senior and I was the new job seeker, so I just ended up agreeing with him.

kenforthewin3• 6 years ago

You'd want to use db connection pooling for any nontrivial application, a goroutine per db request is a recipe for connection exhaustion. That being said, go's concurrency model is indeed a huge selling point of the language.

WaltPurvis• 6 years ago

OP doesn't say whether it was a SQL database, but Go's sql.DB automatically uses a connection pool. Naively using goroutines for every sql.DB operation is a good way to run into connection, deadlock, and other problems, so I think OP's approach of not using goroutines unless/until there's a demonstrated need (e.g., through profiling) is sound, and that interviewer might want to pump the brakes on the blanket prescriptions.

latchkey• 6 years ago

Maybe the person said that to test if you were the type that would just blindly agree with someone because they are "senior".

aganame2• 6 years ago

Giving yet another solid reason to not work there. Job interviews are not (supposed to be) mind games.

dana3216• 6 years ago

The multithreaded nature of the go http library makes it look simple, but in fact, its not. It won't show up problems until you use a specific tool to send concurrent requests.

Just a gotcha i want to mention to anyone reading. ApacheBench is a good first start.

nhooyr• 6 years ago

Could you elaborate on what you mean?

sagichmal9• 6 years ago

ab is broken by design.

wrk, h2load, boom, vegeta are more sound load testing tools.

crystaldev6• 6 years ago

Maybe he likes writing blog posts about how goroutines behave at scale ;)

stickfigure3• 6 years ago

Here's a hot take from a polyglot who does a fair bit of professional work in Go:

Go is a low-blub language whose advocates are proud of the fact that they never made it past 200-level CS courses. It's the computing equivalent of the blue-collar anti-intellectualism that is rampant in politics these days.

Yes, Go the language is simple - it pushes complexity off to your programs instead! Instead of functional expressions, Go programs are pages and pages of iterative loops and variable manipulation. Without generics, you can't use even the most basic functional constructs like map and reduce. The most boring mainstream languages like Java and Javascript are adopting functional paradigms, whereas Go is actively hostile to functional programming.

Nothing is more tiresome than the continuous prattle about exceptions. "How can you possibly write code that is robust in the presence of errors when you don’t know which statements could throw an exception?" Easily. That's the great thing about exceptions, you don't need to know about them to write robust code.

In general business processing, an exception thrown across a transaction boundary rolls back the transaction. In most cases that's pretty much all you need to know. In the case where you need to explicitly rollback a state change (extraordinarily rare in business processing), you add a try/catch/throw, and you don't even need to look at the exception!

The fact is, 99% of programs need only one exception handler. In webapps, it's the http processor that returns a 500 error. In GUI apps, it's the main execution loop that shows an error dialog.

Go's error handling not only requires endless tedious "if err != nil return err", but each one of those statements destroys stack information. Folks like to berate Java for long stacktraces, but those stack frames are valuable for debugging. By comparison, Go's errors are an opaque bit of text. Third-party libraries can help by wrapping errors in other errors (hand-building stacktraces), but this won't help you when using third-party libraries that don't use these wrappers.

I'll say something positive about Go, and why I still use it: It's a better C. For low-level-ish code that needs performance and fast startup time (CLIs, simple GAE services that scale to 0 and need immediate startup), Go fits the bill. Having concurrency built into the language is nice, although most other common languages have equivalent facilities in their libraries.

But as a language to take over the world: Not a chance.

nine_k• 6 years ago

But there is, and has for a long time been, a push for blue-collar "coding" jobs, because highly educated programmers are expensive. It dovetails especially well with the mentality where only the next quarter results matter, and software is a cost center, which is a lot of places.

Go is popular for the same reason PHP is popular, or why $0.99 goods are sold in huge quantities despite their quality.

To be fair, the implementation of the Go compiler and runtime is done by real experts, and is impressive. I suppose that nothing in Go is done by ignorance; everything is a conscious choice, to meet the bottom line: a person can learn enough Go in a weekend to be immediately productive.

kenforthewin3• 6 years ago

this is an unnecessarily divisive take from a "polyglot" (read: software engineer) who admits that Go has its place in a software engineer's toolkit. It seems that you're attacking a straw man who believes that Go should be the only language that exists, and is the right choice for every application? Who argues this?

K0SM0S3• 6 years ago

I find it's the strawman that many (most?) Go "opponents¹" respond to.

Every language has its die-hard cult of a few who claim it should be the one and true only language in the world (and the claim is always wrong). But Go is the only case I know where I see people actually respond to that. As if it were a real question.

I think it's a combination of many aspects:

- Go is quite opinionated as a technical object, thus polarizing; which attracts more contentious debate(-rs) than average.

- In truth, Go was meant to be niche, and wants to remain so; it never actually tried to become as big as it is. The whole "take over the world" mantra is pretty much alien to its core design, its primary intent and, most likely, ultimate destination.

- Go has a few powerful traits (great at concurrency, great at scaling simple services, etc.), but people want to generalize, and indeed Go's not far from being quite more general (if it had generics, etc). There's no consensus as it's arguably hard to bring in more expressiveness while preserving the intricate mechanics of its elementary objects (each must respond to all others properly). This "in flux" situation has passionate advocates on all contentious sides.

- Google's weight behind Go makes it feared by some, but it's not like Google is trying to make Go "the one and only", even internally (that proposition doesn't make any engineering sense).

- Some hype, by 'influencers' in the space who fell in love with it, made Go a shining beacon of something— this elegance in simple abstractions (when it fits one's problem space well), its manageability by teams, ease of programming, etc. There's something to be said for these qualities, but again it was just wrong to generalize... it's just what people do. We move in cycle of hypes, trend-waves, it's best to keep a Bayesian mind through all of it.

So much ado about a niche.

[1]: wth with that even being a thing, it's a programming language for Turing's sake. Let us recall that languages are neither good nor bad, but shit-posting makes it so. Yes, even Rust: neither holy nor evil, I assure you.

gigatexal• 6 years ago

Did you just call Rob Pike, et. al idiots, dumb, and landing-on-the-moon-denying Trump supporters?[1]

Thanks for the good laugh. I like the simplicity. I like that it shuns the insane nested psycho-babble that heavily OOP natured codebases can get into.

[1] I am joking, but only to prove a point. Rob Pike is not some CS drop out.

finaliteration• 6 years ago

whose advocates are proud of the fact that they never made it past 200-level CS courses.

I agree with many of your points but is this kind of generalized ad hominem really necessary? There are many people (myself included) who don’t have CS degrees yet are still capable developers and programmers. I don’t see how criticizing someone’s lack of a formal CS education has anything to do with criticisms about Go as a language.

stickfigure3• 6 years ago

It's a deliberately provocative comment to be sure. But I'm not trying to demean people who don't have CS degrees, just the ones that are proud of it.

The Go community puts out a lot of smug articles like the OP bashing other languages for having features that Go lacks. Inside the community it's largely an echo chamber. When this stuff hits the broader community, I want pushback.

courtf• 6 years ago

A few hot responses! (all in good fun)

polyglot, blub, functional paradigms

Damn, one more I would have had bingo.

Go is actively hostile to functional programming

Well, it does have genuine first class functions, lambdas and closures.

you add a try/catch/throw, and you don't even need to look at the exception! 99% of programs need only one exception handler

pretty sure this is the exact reason Go does not have exceptions

It's a better C. But as a language to take over the world: Not a chance.

Oh, you sweet summer child.

Stratoscope• 6 years ago

Just a tip, code formatting does not work well for quotes because it often leads to unnecessary horizontal scrolling (especially on mobile). A common convention here is to use a leading > character and italicize the quote by enclosing it in asterisks, like this:

  > *This quote can be any length without horizontal scrolling*

which renders as:

This quote can be any length without horizontal scrolling

Update: Thanks for making that edit. Much easier to read on mobile now!

Aloha2• 6 years ago

As someone who fits this description "never made it past 200-level CS courses" how do I make the leap from interpreted basically procedural programming to a compiled language like Go, or C, or whatever else - the mental model seems very very different to me, and I have trouble understanding what the program is doing when I try to just read along.

kenforthewin3• 6 years ago

My advice is to ignore gatekeepers like OP and just start playing around with Go. The Go Playground is a great place to start, you can run it right in your browser. https://tour.golang.org/welcome/1

dleslie• 6 years ago

The lower you get the more your model of computation must understand the host system; but be careful, even C statements often compile into surprisingly unexpected machine code.

If you want to explore this route I recommend picking up an embedded hobby project; Ie grab an Odroid Go and write some fun little arduino games in C++ using the Esp-Idf toolkit. It's got two cores, some IO, and a slowish LCD; and so you'll have to understand async programming and have a mental model of the device's memory to get any satisfaction.

But that still doesn't require much beyond most 200 level computing knowledge. :)

pm905• 6 years ago

I think you are going in the opposite direction to which the OP seems to be lamenting.

First of all Go is not C; it’s much much easier to learn and write production grade services easily. There are a ton of free/ online resources to learn go; I’m self taught and have written production code in go for the past several years with no formal training. The godocs are great; YouTube has videos from gophercon and other conferences as well.

Second: OP is lamenting the lack of higher order programming paradigms like Generics; If you’re using an interpreted language it likely already has support for those things.

wtarreau• 6 years ago

You can try Pascal. I switched from BASIC to Pascal 30 years ago then to C 5 years later. And even though C has been my everyday language for 2.5 decades for all my projects, Pascal was still the one that provided me the most natural mental model and that was the easiest to learn by practicing without lessons. I used to code as I thought without being interrupted thinking about stupid stuff like "I need a buffer to store this argument and to verify its length, ah shit I then need the ability to return an error if it's too large". In TP7 you even had "break" and "continue" statements that were missing from previous ones, that made it closer to C and a real joy to work with. The code was quite clean and extremely readable even with few comments.

papito7• 6 years ago

Someone had to say it. My first impression of Go was that its creators have not worked on a modern, large scale system in decades. And they probably have not. Go skips about 40 years of advances in language design and code maintenance. We have stack traces for a reason. We have exceptions for a reason.

We came to it as software has become more complicated. The fact that you have to assemble the path to the root cause of an error yourself is completely bonkers.

kyrra• 6 years ago

The creators were working on Google Search and tired of various aspects of it, and tried to fix their annoyances with Go.

vijaybritto3• 6 years ago

Are you sure about this?? Go is being used to build some of the most important software in devops and databases today. Maybe its the thinking thats different but certainly it doesn't make codebases complex by itself.

nilkn3• 6 years ago

It can be difficult to reconcile comments like this with the reality that Go was designed at Google to address difficulties developing large-scale applications and even Kubernetes is written in it.

I agree with many criticisms of the language but sometimes that criticism seems to enter its own sort of echo chamber.

Matthias2472• 6 years ago

The fact is, 99% of programs need only one exception handler.

Maybe if you just write high level business logic and something else already handles exceptions for you. I think my Java code typically has 70% of the exceptions handlers that I also would need in Go. Need to close upstream connections, release resources like buffers, etc. If it’s not catch blocks, then it’s at least a finally block. And often it’s also a good idea to catch and transform an exception, so that the calling code doesn’t need to deal with exceptions that come from pure implementation details.

ickyforce• 6 years ago

Releasing resources is not error handling... And in Java you don't even need finally for that, there try-with-resource.

coldtea4• 6 years ago

Go is a low-blub language whose advocates are proud of the fact that they never made it past 200-level CS courses. It's the computing equivalent of the blue-collar anti-intellectualism that is rampant in politics these days.

You say that like it's a bad thing!

johnisgood• 6 years ago

What are your thoughts of Ada/SPARK as a replacement of C? In my opinion it is a better C. At times I wish it were not so verbose but I consider it a feature. It has everything you mentioned that made Go fit the bill, and so much more that makes it even better at both low-level programming and high-level programming. My main and only problem with Ada is that it lacks libraries, it needs a more vibrant community. This can be changed though!

arm64future2• 6 years ago

Much of your complaints simply do not apply to many use cases for people when developing a server side web application. Just because Go does not have such features you are used to using in your high level language does not make Go a bad language. I also find it funny that you dislike the simplicity of the language because it apparently empowers "blue collar" types (uhk, how gross!) to do the jobs you are used to doing.

A bloo bloo bloo!

jahaja• 6 years ago

To be unattractive to people that feels that simplicity insults their intelligence might be Go's greatest feature.

pm905• 6 years ago

Heh, good point.

Ingenuity in code for solving real problems is great. Often times I’ve seen those who know a language deeply write code in ways that makes it remarkably hard to read. Mostly it’s because language features are used in unexpected ways which the author feels is great for x reason, but reduces readability.

With Go, it’s actually really hard to write opaque code like that since the language is so laser focused on low level primitives. And honestly... for core systems, I think that’s an incredibly good thing to have.

mseepgood• 6 years ago

Go is a low-blub language whose advocates are proud of the fact that they never made it past 200-level CS courses.

One of them is Ken Thompson, Turing Award winner.

dang• 6 years ago

Please review the site guidelines and, when commenting on HN, do so more in their spirit. We don't want programming language flamewars here, especially after seeing what they did to other communities.

https://news.ycombinator.com/newsguidelines.html

Koshkin4• 6 years ago

Not sure if it was the intent, but Go's mascot has always reminded me of "When a man's got to go, the man's got to go."

zxcvbn40382• 6 years ago

This is a misnamed article. There is nothing zen about this article. A better title would be “I’m mad that no language is perfect” because that is really the gist of the article. Author has nit-picks with every contemporary computer language. “If only someone would write the one true language, here is why every other language fails to be that, blah blah blah.” Pure opinion piece.

raister• 6 years ago

"The only Zen you can find on the tops of mountains is the Zen you bring up there." Robert M. Pirsig

zxcvbn40382• 6 years ago

“He who makes mountain out of mole hill should open ski resort in Kansas” A. Nonymous :)

pansa23• 6 years ago

Author has nit-picks with every contemporary computer language.

Doesn’t everybody? Programming languages are so vast, and designing one involves so many trade-offs. It’s impossible to find one that’s perfect, where you agree with every decision made by the designers.

tsimionescu13• 6 years ago

The verbosity of

    if err != nil {
        return err
    }

> is outweighed by the value of deliberately handling each failure condition at the point at which they occur. Key to this is the cultural value of handling each and every error explicitly.

I've talked about this before, but it annoys me a lot that checking if an error exists and returning it is referred to as "handling the error". You are not handling anything - you're passing on responsibility up the stack just as clearly as if you had thrown an exception.

You're just doing it manually instead of letting the runtime do that for you. You're also making it much harder to tell the code that handles errors apart from the code which doesn't.

marklacey• 6 years ago

I think what people usually mean in these situations is that you’re forced to think about the error.

Programs in C (and many other languages) have the problem that you can ignore errors accidentally.

Exceptions “solve” this by forcing some level of your stack to at least acknowledge that an error occurred. The problem with that model is that you still don’t have to think at any given level of the call stack what the appropriate handling is for any kind of error. You can just let it propagate up further, deferring responsibility.

For some code that might actually be appropriate, but often it results in code higher up that cannot possibly know how to deal with every error that can happen farther down the call stack just swallowing errors.

One thing I frequently see is mixing validation code with processing logic. By separating the two you can have the validation code deal with errors and the logic simply assert that it’s input is good (because it should have been validated by the error handling code before being passed in).

I think models where you are forced to think about errors at each level but have a simple mechanism to make them propagate up are probably the best single model if you have to choose one model for a language.

In any event, error handling is difficult and frequently doesn’t get the attention it deserves in the design and implementation of libraries and large systems.

tsimionescu13• 6 years ago

In my experience, the vast majority of error handling has been essentially limited to bubbling the error up, cleaning up unmanaged resources, and either re-trying the operation with some back-out logic or giving some details to the user about what happened and letting them decide what the best thing is.

I have very rarely seen something useful to be done by code automatically to recover from an error, other then re-trying. As such, I feel that the way Go makes you constantly write error-handling code is counter-productive, since it forces you to think about something that really doesn't need that much thinking about.

And as I said earlier, the deluge of non-handling error handling code can serve to mask the rare cases where errors are actually handled in some tricky intelligent way.

crystaldev6• 6 years ago

You can ignore an error in Go simply by ignoring its return value. Sometimes it's difficult to tell a foot-gun and land-mine apart.

sagichmal9• 6 years ago

The snippet used in these examples is almost never what you actually write in real code. You will almost always annotate the error, e.g.

    result, err := computeVector(input)
    if err != nil {
        return nil, fmt.Errorf("error computing vector: %w", err)
    }

But that's a bit unwieldy to write in an article or talk.

tsimionescu13• 6 years ago

That's still not error handling.

Error handling would look something like this:

    for err := callService(); err != nil {
        logger.Info("Retrying...")
    }

    value, err := readValueFromFile("abc.conf")
    if err != nil {
        value = getDefault()
    }

etc.

jkachmar• 6 years ago

The snippet used in these examples is almost never what you actually write in real code.

This statement is categorically false, and I would encourage you to search GitHub for `return err` under the Go language.

There are 200k+ code results, and a quick survey of the first few pages shows plain ol' `return err` to be _quite_ common.

monocasa4• 6 years ago

You've just removed all of the machine parsable context of the error, guaranteeing that downstream code can't make an intelligent decision.

erik_seaberg5• 6 years ago

That can and should be generated; it's not as if the machine doesn't know which function failed. We don't force human beings to plow through all the rote instructions that set up a stack frame or invoke an object's implementation of a method, and for the same reason we shouldn't force them to plow through the rote instructions that bubble an error toward the handler. When errors exist in your problem domain, manipulating them becomes part of the language's job, and nearly every language from the last thirty years acknowledges that.

sagichmal9• 6 years ago

You're also making it much harder to tell the code that handles errors apart from the code which doesn't.

Error handling isn't distinct from, or less interesting than, the principal logic of a block of code. Error handling is frequently the most important part of a block of code, especially in the domains that Go targets.

tsimionescu13• 6 years ago

That's not what I meant.

Code that handles an error looks like this:

    if err! = nil {
        if fileErr,ok := err.(MissingFileError); ok {
           createFile(fileErr.FileName())
        } else {
            return fmt.Errorf(...)
        } 
    }

While code that does NOT handle an error looks like this:

    if err!=nil {
        return fmt.Errorf(...)
    }

fyfy18• 6 years ago

One of my pet peeves about Go is a lot of errors are not exposed as public variables, so your options of handling them are somewhat limited other than a generic "something went wrong". I've recently written a tool that classifies various http request errors (think SSL failure, not a 500 status code), and have had to have a deep dive into Go reflection as part of that.

I understand part of this is because they don't want to have to worry about making potentially breaking changes - but what I've had to do means my code will break if the internal API changes, and as it's using reflection the compiler won't catch it. It would be nice to have a "yes I know I shouldn't, but I really want to" (ala Ruby's send method) way of doing this that the compiler will still check.

dmit3• 6 years ago

Go was so obviously designed by Googlers, for Google. After the initial release, outside adopters would frequently report issues where Go undermined their productivity. And every time the core team's response was the same - complete disbelief.

"Dependencies? What? Do you not vendor every single library you depend upon in your monorepo?"

"Advanced type system? Why? Do you not hire thousands straight out of college, and expect employees to stay put for 2-3 years (give or take)?"

Every single issue that was raised in the past 10 years was met with such incredulity.

Rob Pike, Robert Griesemer, Russ Cox - they've done a tremendous job. A great, stunning achievement for their employer. The more of the infrastructure transitions to Go, the less money Google will need to spend on people in the long term. Those three have earned billions for their company, no doubt.

And none of that means Go is a great language for your 12-person team working on a CRUD web app.

The Zen of Go is not reducing your problem to "can it be put in an array?" or "can it be put in a hashmap instead?"

The Zen of Go is looking at individual persons and deciding whether it's net positive to cut them now, or 6 months from now, after their next performance review.

hellcow2• 6 years ago

Your comment is unfair.

I've been programming for more than 20 years. I've learned many languages including C, Objective C, Java, Python, Ruby, JS, and some Haskell. I've never worked at Google.

Go is my favorite language of them all and has been since I started using it almost a decade ago. I use it for personal projects, and I use it at my company.

It helps me and the teams on which I've worked write correct code quickly the first time. The code we write is incredibly reliable in production at scale. It's easy to read and debug years later. Binaries can easily be compiled and deployed on any system without messing with dependencies or cross-compiler toolchains.

The same properties of the language which helped Google have helped me and many thousands of others as well.

dmit3• 6 years ago

The same properties of the language which helped Google have helped me

To be fair, I don't think anything I wrote contradicts that. If your goals align with Google's, great.

innocentoldguy2• 6 years ago

I thought dmit's comment was fair. I've been programming for over 30 years now and Go is my least favorite language (actually, I absolutely hate it). The reasons for my distaste are basically everything dmit just mentioned (and more). I get that some people love Go but that doesn't mean the criticisms against it aren't fair.

yawaramin5• 6 years ago

I've learned many languages including C, Objective C, Java, Python, Ruby, JS, and some Haskell.

You've learned basically the same language over and over again: Algol-family imperative-OO-mishmash. Haskell is probably the most unique out of all of them, and I'm inclined to think you haven't gone too far with it. Perhaps you know SQL though and recognize how a relational (roughly, set-oriented) language can work.

My point is that I understand that Go offers you some compelling advantages. We're just saying that other languages offer some pretty amazing things too, and they are even better designed (as languages) than Go.

Check out this fantastic talk by Scott Wlaschin to get a sampling of truly different language paradigms and how they approach problems: https://youtu.be/0fpDlAEQio4

dx87• 6 years ago

That attitude is why I never bothered to learn it. Shortly after its 1.0 release, there were a bunch of "here's the good and bad about Go" posts. I remember seeing a post by Rob Pike on reddit where he said he was tired of people being on the fence about Go, and if they don't love it, they should just learn something else. That kind of "love it or leave it" attitude was prevalent everywhere, and it was a big turn off. It felt like instead of Go being designed as a tool for programmers to use, programmers were the tool, and Go was designed as a way to change them so they'd be better at what Google wants.

pm905• 6 years ago

That might be how you “feel” but it doesn’t reflect the facts. The go community has been incredibly welcoming, the process for introducing new features in go is fully transparent and in the open.

If you link to the reddit post we could all see what he actually said. Go is a very opinionated language for sure. Every language will be inundated with people who want their pet feature to be implemented in it and will hate on it otherwise. I am happy that the language development is not directed by such kinds of folks.

rlonn• 6 years ago

Golang chooses to avoid feature creep. This seems to annoy some people to no end and so these discussions always devolve into whining about feature X, Y or Z that would have made Golang soooo much better and OH how nasty are [Google or whomever] that blocks all these fantastic ideas from being implemented. If only they listened to all the smart people out there (especially me) it would have made Golang awesome and we'd see a million flowers bloom. Please stop, it's tiresome.

AnimalMuppet• 6 years ago

Well... Go is a language that wants to be something specific, rather than be something for everyone. That means that some suggestions just don't fit, not because they're hard to implement, but because they're wrong for the language. It is very appropriate for the language designers to say "If that's what you want, then you don't want Go. There are other languages that fit what you want better; go find one and use that." That's completely reasonable and proper.

It's also possible for the language designers to say the exact same words, and be ignoring real problems with the language - problems that could be fixed within the spirit of the language.

If you go to the Haskell people and say "This language would be so much more usable by so many more people with an Algol-like syntax", they're not going to listen to your helpful suggestion. What you're asking for is something that would not be Haskell. But to those asking, they think it's a perfectly reasonable request.

I don't have a great example of the second kind, because languages with those kinds of designers typically die early.

maximente• 6 years ago

my hypothesis was that as the world has moved forward, Google has accumulated legions of C++/to a lesser extent Java/C experts that they needed to corral into modern software engineering, to include programming languages. Go is exactly that - good enough - in part due to:

- has enough C-like syntax to keep the old "this doesn't look like C/C++" guard muzzled (as opposed to e.g. Java)

- avoids some of the huge C++ productivity land mines (no package management, divining which Boost version to use, build systems, etc.)

- has a 21st century standard library (net/http as a first class citizen as opposed to whatever the C/C++ ecosystem "offers")

- fast enough and memory performant enough, whilst exposing pointers, unsafe ops, and C interop should the need arise

i think most of the above are mind tricks to get the C++ crowd to complain slightly less while increasing productivity multi-fold.

jeremysalwen• 6 years ago

As someone working at google, I had never written go code, but I had read quite a bit about how how people didn't like it on places like hn. My impression was that even though personally I would strongly prefer a more typed language like rust, the deficiencies of go were probably overblown.

Then I recently had to write a small amount of go code... and I found out that go doesn't support enums....... what??? Just blew my mind.

0xFACEFEED4• 6 years ago

There's a huge discussion here, if you're interested: https://github.com/golang/go/issues/19814

TBH I thought adding enums was a cut and dried case until reading through some opposing opinions. Now I'm not so sure.

arm64future2• 6 years ago

The Zen of Go is looking at individual persons and deciding whether it's net positive to cut them now, or 6 months from now, after their next performance review.

Your conclusion is nothing more than a hilarious ad hominem attack on the language.

coryrc• 6 years ago

I think it was the easiest way to get around Google's line limit restrictions on Python.

Okay, that's probably not the real reason, but I'm not joking that this would be the easier way :).

erik_seaberg5• 6 years ago

Vendoring prebuilt deps (jar/so/dll files) is the Right Thing. Anything else creates an extra point of failure that could prevent you from going to prod or reproducing an old build. Some take this seriously enough to vendor the exact toolchain as well.

dmit3• 6 years ago

I meant vendoring the source code of dependencies when I wrote the parent comment, but it appears you feel strongly about going one step further? Vendoring arch-specific binaries? What is the benefit of doing that, in your opinion?

stevewilhelm• 6 years ago

Any suggestions of open source Go projects/services that exemplify the Zen of Go?

Bonus points if they are using Docker / Kubernetes for deployment and hosting.

sagichmal9• 6 years ago

HashiCorp stack is pretty good for this.

bigato2• 6 years ago

The standard library

monocasa4• 6 years ago

I get told all the time about how the standard library isn't a great example of go code, because of the backwards compat they have to do.

yawaramin5• 6 years ago

I'm told that Sanjay Ghemawat's Go code is beautiful (I'm not a Go expert though): https://github.com/ghemawat/stream/

More about him: https://www.newyorker.com/magazine/2018/12/10/the-friendship...

jb3689• 6 years ago

I think that we can all agree that when it comes to Go, simple code is preferable to clever code

What even is "simple code"? The problem I have with Go is when you need to do anything non-trivial the intent of the code quickly becomes lost in lots of for loops. You can try to abstract that away so that your program reads better, but in my experience that has always been a poor decision. I get the impression Go wants me to write big for loops that do lots of work and have lots of scope and that it doesn't want me to break my problems up into steps (like I might in a functional style by separating each stage of the computation). Go wants me to have mutable variables and mutable references. State management in Go is questionable and really left up to the programmer (mutable references and data hiding are too easy compared to functional languages where immutability generally forces you to think harder about your data's structure). Sure, this is usually going to lead to a more performant end-result, but it's not going to lead to the "simpler" result (in my eyes)

There's a lot about Go that I do like - the toolchain and docs are particularly good, and the standard libs are modern yet succinct. It is low-level enough when I want it to be and relatively high-level (nits above aside). The support for concurrency and distributed systems is also good. I can see how "simple" is exhibited there

If I had to guess at what "simple" means to Gophers (well, the Golang team at least) it would be using the fewest number of language primitives/features to get done what you want to get done. There are a lot of peculiar ways channels are used for example where other languages might prefer things like condition variables. The range keyword is overloaded and used different in several contexts but it does keep the number of keywords low. Most Go tends to look the same (low-to-the-ground, verbose)

Go is great until it isn't and when it isn't you have little choice but to brute force around some of Go's clunky pieces. Extracting high-level meaning out of Go source can be difficult because of how verbose it can be. I'm glad it's around and it's a good choice for a lot of projects, but I really wish we could have simple things like generics so we can write cleaner code

In short, Go as a language may be simple (and I think it is) but I need to solve complex problems - either Go helps me with that complexity or it leaves me on my own. Go has chosen the latter of those options and I'm not convinced that our Go code can be simple for many non-trivial applications

ed_balls• 6 years ago

Avoid package level state Seek to be explicit, reduce coupling, and spooky action at a distance by providing the dependencies a type needs as fields on that type rather than using package variables.

I can't parse it.

The Zen of Go

Related Stories