23 ms·

The Zen of Go

328 points by sagichmal 7y ago

pansa2 7y 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/ https://www.infoq.com/presentations/Simple-Made-Easy/
- bjornjajajaja 7y ago
  It would be nice to have “elegance” brought into the picture too. Code is an art as well!
  - aequitas 7y 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.
    - rat9988 7y ago
      I have seen uncharitable interpretations, but this one is one one of the worst.
    - crazyjncsu 7y ago
      > Writing elegant and artful code that is hard to understand and debug does not make you a clever developer The whole purpose, to me, of artfulness in code is to take unartful, hard to understand code and make it simple. What other objective is there?
    - skywhopper 7y ago
      You have a depressingly narrow view of what "art" can mean.
    - fastball 7y ago
      What exactly are you picturing when someone says "elegant" or "artful" code? To me, elegant code is DRY code. Elegant code is code with useful abstractions where needed, and no abstractions where they just complicate matters. Code that is succinct yet clearly communicates its purpose. From the sounds of it, you have an entirely different conception of what elegant code looks like.
    - gtf21 7y ago
      This seems to have totally missed the first half of the comment to which you replied: _elegance_ certainly has a place in programming, just as it does in mathematics and many other disciplines. Things that are elegant are often difficult to conceive, but easy to understand being simpler solutions to a problem than something inelegant.
    - tpmx 7y ago
      (I don't necessarily disagree, but...) It's probably changed a lot since, but at least back in the 90s demo-scene code was absolutely 100% written for the result alone, even perhaps when it should perhaps have been say 75% for the sake of reusability. Imagine "decent" 90s game code quality, then dial the qualitynotch down a bit, since it will only have to work once on a well-defined machine anway. I'm long since tuned-out. I do seem to remember Farbrausch making some waves when they started applying the concept of reusability and structure to their work in the early 2000s.
    - njharman 7y ago
      > Writing elegant and artful code that is hard to understand You do not know the meaning of elegant. At least in context of programming and maths.
    - Koshkin 7y ago
      > Unless your building a user facing frontend please keep art out of your code. Honestly, I had rather art be kept out of the user facing frontend. (Computer programming, on the other hand, is considered art by some computer scientists.)
    - bjornjajajaja 7y ago
      Honestly if a solution is too hard to understand and debug then it is not elegant. Elegance is turning a complicated solution into an easier-understood one. Clever solutions could be elegant but they could also be shortcuts that are confusing and cause more harm than good. There’s definitely a difference.
- todotask 7y ago
  I just read Eric update quite recent on CSP. https://gitlab.com/esr/reposurgeon/-/blob/master/GoNotes.adoc 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."
  - d0mine 7y 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-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
    - murphy214 7y ago
      Dreadful may be a little strong but anytime I've tried to implement something like asyncio for a non trivial piece of code it becomes pretty obtuse. (imo)
      - fjp 7y ago
        I’ve found asyncio to be a very simple model to understand, using the aio libs: aiohttp, aiopg, aiobotocore, etc. Basically just slap “async” or “await” in front of everything and understand that anytime there is a network connection being accessed, that method will release control of the main thread. You just have to pay attention to where something might block the thread for any significant amount of time - heavy calculation or lengthy file IO You can spawn a multitiude of async tasks on startup and have super basic “scheduling” by using asyncio.sleep with some jitter. The only time I have seen the performance limits of a naive asyncio app reached was in an auth app that sat in front of every API request for the whole company, and even then it was an obscure DB connection pool management issue deep in psycopg2.
- masklinn 7y 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.
  - throwaway894345 7y ago
    I don’t think that paragraph was referencing compiler guarantees.
    - coldtea 7y ago
      It should refer to them or address them. Since, given this, Go is no better than a language with unchecked expressions nobody handles...
      - stouset 7y ago
        There’s other reasons too! I’ve written the following: if v, err = func(); err != nil { nil, err } … and then went on to use `v`. Thanks to `v`s zero value being legitimate (and not nil like a pointer would be), the program continues on as if everything is okay. In case you didn’t catch it, I forgot the `return`. Rust takes a much better approach with Result, where the return value is either `Ok(v)` or `Err(e)`, and there’s no way to access a meaningless value for the other possibility.
        coldtea 7y ago
        Yeah, and this is so simple a change (compiler wise) and far more stronger a guarantee I don't see why Go didn't implement it... At least then errors as return values would be solid. Of course now they make programmers do all the extra error wrapping thing in 1.14 to pass "richer" errors...
        pm90 7y ago
jpgvm 7y 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 7y ago
  Did you use to be a fan? What happened?
  - jpgvm 7y 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.
    - kstenerud 7y ago
      I'm still using it daily, and I think it's a "nicer C", perhaps sometimes even a "nicer C++" or "nicer Java" in a few ways. But I agree that as a general purpose language it's definitely lacking. No other language has inspired me to fight against its design and philosophy or overcome its deficiencies as much as go has ([1] [2] [3]). But for many purposes it's "good enough", and at least it's simple enough to dig around in the guts when I have to. [1] https://github.com/kstenerud/go https://github.com/kstenerud/go [2] https://github.com/kstenerud/go-describe https://github.com/kstenerud/go-describe [3] https://github.com/kstenerud/go-subvert https://github.com/kstenerud/go-subvert
    - 7y ago
mxschumacher 7y 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
- pansa2 7y 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.
- apta 7y 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#?
  - tsimionescu 7y ago
    Even more, what does Go have better in terms of dev tooling than Java or C#?
    - deleted 7y ago
      [deleted]
    - vips7L 7y ago
      It doesn't.
      - helvetica2020 7y ago
        Comparing Go to the JVM for dev tooling not to mention the operational ecosystem is a bit silly. JVM is miles ahead.
    - kasey_junk 7y ago
      Go fmt Code formatters are available in Java/C# but not ones that have a default set in stone.
dx7tnt 7y ago
Great how the tech industry, and others, repurpose words so that now even a simple title like 'the Zen of Go' is neither about zen or the ancient boardgame of Go.
saagarjha 7y 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 7y ago
  Why not? Seems apt to me.
  - saagarjha 7y 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.
DarthGhandi 7y ago
When you can't compile because of one unused variable that was commented out there's a very good chance the meaning of the word Zen is being blatantly abused. Go is not simple, it's corporate behemoth. Go is absolute garbage, its creators openly say it's for dumb fresh out of college types rather than actual professionals. They have been on the record repeatedly saying this. If Google was not involved here whatsoever as opposed to backing it heavily what would you all actually think about the language?
- gnur 7y ago
  A language that young professionals can use right away and can even support complex projects like kubernetes, Prometheus, consul etc. sounds like an excellent choice for companies to adopt. It might not be as elitist as rust or clojure but if collaboration is important for your project I'd rather have simple without foot guns rather then amazing with dragons all over.
  - darkerside 7y ago
    There's a real analogy to be made here with mass production and it's impact on labor. We quickly went from a society that valued individual craftsmanship to one that valued the ability to treat people like cogs at the factory. I'm not even mad, mass production is a great thing that enabled access to goods that many people would never have otherwise had. But eventually there was a backlash, and handcrafted, high quality goods are preferred by many who can afford them. I'm not saying Go programmed products are lower quality, just that we've enabled certain types of organizations with the advent of greater process and rigor in languages. Someday the pendulum will likely swing again.
    - naringas 7y ago
      we even treat education like this. children are educated as mass produced laborers for the future
    - throwaway49872 7y ago
      > I'm not saying Go programmed products are lower quality I've met plenty of good developers that complain at how Go ties their hands and creativity. Unsurprisingly, the language has been designed for "cogs": --- The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike ---
superkuh 7y 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 7y 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 7y ago
Not Zen! Go Kant!
georgehm 7y 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 7y 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.
- njharman 7y 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.
  - georgehm 7y 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
    - bigato 7y ago
      In my experience, reality is unpredictable enough that no one actually know what the requirements will be two versions down the road. In practice you end up with code that is more complex than what the current problem needs, trying to solve a future need that you presume will happen but you don’t really know what it is and when it will happen.
SPBS 7y 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.
- saber6 7y ago
  Sounds like a douche.
- kenforthewin 7y 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 7y 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.
    - K0SM0S 7y ago
      I'm gonna say this with all the respect in the world for the technical view —I'm a nerd and I agree with you guys 100%, a huge upvote for the whole thread— but experience taught me something along those lines: There are such situations (people and places) that command one to put their mindset in "agreement mode", not because of logical reasons¹, but absent or even contrary to those, because of a need to reduce friction². In this meta-knowledge space³ lies the solution space⁴ for all your problems in a human environment. When you approach things like that, you tend to see where "tech" fits in a wider landscape, and it tells me when to speak and when to shut my big nerdy mouth (whenever it's counterproductive, e.g. premature abstraction⁵ is just as bad as premature optimization). It tells me which lines in the code are "political", "organizational", "structural" not to the tech but to the humans around; and by elimination, which lines are left for us nerds to think about deeply. It's a dance, really, there's no right/wrong/perfect, but there's a certain way to rise above these human contingencies and actually facilitate the path to market while having a blast — just set your expectations right as to what you can and can't touch, at least for now, reassess on a need-to basis. So when you see a dark "anti" pattern (OP's case), sure you naively ask 'why', but then if you see org/pol structure, if you see this rigid wall of "this is how we do it, this is who we are", you know it's not about tech anymore. It's personal. Don't hit there. People (especially when insecure, so all of us at times) tend to protect their knowledge like it's a judgment on themselves, like it's proof of their worth, and it's very hard but doable to notice when you're entering such territory with someone. ____ [1]: you might be smarter than your boss, you may be "right" technically [2]: "friction" in the economic sense, which includes overhead in your code as well as overhead from meetings. What stands between idea and productive execution. [3]: literally, larger than the technical, including all aspects of engineering, organization and market forces. [4]: the product that which you seek to make, i.e. that people use. The "internal" side of the product is the organization and codes that make it, that support its continued existence. [5]: in this case, we "abstract prematurely" when we presume to know a system better than their maintainers, or that our "outside looking in" "fresh" pair of eyes has all the answers already. There is often much more than the technical to consider.
stickfigure 7y 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 7y 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.
Koshkin 7y 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."
zxcvbn4038 7y 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 7y ago
  "The only Zen you can find on the tops of mountains is the Zen you bring up there." Robert M. Pirsig
  - zxcvbn4038 7y ago
    “He who makes mountain out of mole hill should open ski resort in Kansas” A. Nonymous :)
- pansa2 7y 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.
tsimionescu 7y 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 7y 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.
  - tsimionescu 7y 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.
dmit 7y 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.
- hellcow 7y 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.
  - dmit 7y 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.
stevewilhelm 7y 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.
- sagichmal 7y ago
  HashiCorp stack is pretty good for this.
- bigato 7y ago
  The standard library
  - monocasa 7y 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.
    - sagichmal 7y ago
      stdlib was once an exemplar of good, idiomatic Go code, but a lot of the idioms it uses haven't withstood the test of time, and it's less and less appropriate as an example.
      - 0xFACEFEED 7y ago
        This is true, but it's still worth poking around for pre-existing solutions to problems. My editor will jump to stdlib definitions so I've learned a lot just diving into various stdlib packages (I remember the JSON parser being a good one).
- yawaramin 7y ago
  I'm told that Sanjay Ghemawat's Go code is beautiful (I'm not a Go expert though): https://github.com/ghemawat/stream/ https://github.com/ghemawat/stream/ More about him: https://www.newyorker.com/magazine/2018/12/10/the-friendship-that-made-google-huge https://www.newyorker.com/magazine/2018/12/10/the-friendship...
jb3689 7y 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 7y 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.

328 points by sagichmal 7y 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/ https://www.infoq.com/presentations/Simple-Made-Easy/

bjornjajajaja 7y ago
It would be nice to have “elegance” brought into the picture too. Code is an art as well!
- aequitas 7y 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.
  - rat9988 7y ago
    I have seen uncharitable interpretations, but this one is one one of the worst.
  - crazyjncsu 7y ago
    > Writing elegant and artful code that is hard to understand and debug does not make you a clever developer The whole purpose, to me, of artfulness in code is to take unartful, hard to understand code and make it simple. What other objective is there?
  - skywhopper 7y ago
    You have a depressingly narrow view of what "art" can mean.
  - fastball 7y ago
    What exactly are you picturing when someone says "elegant" or "artful" code? To me, elegant code is DRY code. Elegant code is code with useful abstractions where needed, and no abstractions where they just complicate matters. Code that is succinct yet clearly communicates its purpose. From the sounds of it, you have an entirely different conception of what elegant code looks like.
  - gtf21 7y ago
    This seems to have totally missed the first half of the comment to which you replied: _elegance_ certainly has a place in programming, just as it does in mathematics and many other disciplines. Things that are elegant are often difficult to conceive, but easy to understand being simpler solutions to a problem than something inelegant.
  - tpmx 7y ago
    (I don't necessarily disagree, but...) It's probably changed a lot since, but at least back in the 90s demo-scene code was absolutely 100% written for the result alone, even perhaps when it should perhaps have been say 75% for the sake of reusability. Imagine "decent" 90s game code quality, then dial the qualitynotch down a bit, since it will only have to work once on a well-defined machine anway. I'm long since tuned-out. I do seem to remember Farbrausch making some waves when they started applying the concept of reusability and structure to their work in the early 2000s.
  - njharman 7y ago
    > Writing elegant and artful code that is hard to understand You do not know the meaning of elegant. At least in context of programming and maths.
  - Koshkin 7y ago
    > Unless your building a user facing frontend please keep art out of your code. Honestly, I had rather art be kept out of the user facing frontend. (Computer programming, on the other hand, is considered art by some computer scientists.)
  - bjornjajajaja 7y ago
    Honestly if a solution is too hard to understand and debug then it is not elegant. Elegance is turning a complicated solution into an easier-understood one. Clever solutions could be elegant but they could also be shortcuts that are confusing and cause more harm than good. There’s definitely a difference.
todotask 7y ago
I just read Eric update quite recent on CSP. https://gitlab.com/esr/reposurgeon/-/blob/master/GoNotes.adoc 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."
- d0mine 7y 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-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
  - murphy214 7y ago
    Dreadful may be a little strong but anytime I've tried to implement something like asyncio for a non trivial piece of code it becomes pretty obtuse. (imo)
    - fjp 7y ago
      I’ve found asyncio to be a very simple model to understand, using the aio libs: aiohttp, aiopg, aiobotocore, etc. Basically just slap “async” or “await” in front of everything and understand that anytime there is a network connection being accessed, that method will release control of the main thread. You just have to pay attention to where something might block the thread for any significant amount of time - heavy calculation or lengthy file IO You can spawn a multitiude of async tasks on startup and have super basic “scheduling” by using asyncio.sleep with some jitter. The only time I have seen the performance limits of a naive asyncio app reached was in an auth app that sat in front of every API request for the whole company, and even then it was an obscure DB connection pool management issue deep in psycopg2.
masklinn 7y 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.
- throwaway894345 7y ago
  I don’t think that paragraph was referencing compiler guarantees.
  - coldtea 7y ago
    It should refer to them or address them. Since, given this, Go is no better than a language with unchecked expressions nobody handles...
    - stouset 7y ago
      There’s other reasons too! I’ve written the following: if v, err = func(); err != nil { nil, err } … and then went on to use `v`. Thanks to `v`s zero value being legitimate (and not nil like a pointer would be), the program continues on as if everything is okay. In case you didn’t catch it, I forgot the `return`. Rust takes a much better approach with Result, where the return value is either `Ok(v)` or `Err(e)`, and there’s no way to access a meaningless value for the other possibility.
      - coldtea 7y ago
        Yeah, and this is so simple a change (compiler wise) and far more stronger a guarantee I don't see why Go didn't implement it... At least then errors as return values would be solid. Of course now they make programmers do all the extra error wrapping thing in 1.14 to pass "richer" errors...
        pm90 7y ago

jpgvm 7y 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 7y ago
Did you use to be a fan? What happened?
- jpgvm 7y 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.
  - kstenerud 7y ago
    I'm still using it daily, and I think it's a "nicer C", perhaps sometimes even a "nicer C++" or "nicer Java" in a few ways. But I agree that as a general purpose language it's definitely lacking. No other language has inspired me to fight against its design and philosophy or overcome its deficiencies as much as go has ([1] [2] [3]). But for many purposes it's "good enough", and at least it's simple enough to dig around in the guts when I have to. [1] https://github.com/kstenerud/go https://github.com/kstenerud/go [2] https://github.com/kstenerud/go-describe https://github.com/kstenerud/go-describe [3] https://github.com/kstenerud/go-subvert https://github.com/kstenerud/go-subvert
  - 7y ago

mxschumacher 7y 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

pansa2 7y 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.
apta 7y 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#?
- tsimionescu 7y ago
  Even more, what does Go have better in terms of dev tooling than Java or C#?
  - deleted 7y ago
    [deleted]
  - vips7L 7y ago
    It doesn't.
    - helvetica2020 7y ago
      Comparing Go to the JVM for dev tooling not to mention the operational ecosystem is a bit silly. JVM is miles ahead.
  - kasey_junk 7y ago
    Go fmt Code formatters are available in Java/C# but not ones that have a default set in stone.

dx7tnt 7y ago

Great how the tech industry, and others, repurpose words so that now even a simple title like 'the Zen of Go' is neither about zen or the ancient boardgame of Go.

saagarjha 7y 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 7y ago
Why not? Seems apt to me.
- saagarjha 7y 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.

DarthGhandi 7y ago

When you can't compile because of one unused variable that was commented out there's a very good chance the meaning of the word Zen is being blatantly abused. Go is not simple, it's corporate behemoth. Go is absolute garbage, its creators openly say it's for dumb fresh out of college types rather than actual professionals. They have been on the record repeatedly saying this. If Google was not involved here whatsoever as opposed to backing it heavily what would you all actually think about the language?

gnur 7y ago
A language that young professionals can use right away and can even support complex projects like kubernetes, Prometheus, consul etc. sounds like an excellent choice for companies to adopt. It might not be as elitist as rust or clojure but if collaboration is important for your project I'd rather have simple without foot guns rather then amazing with dragons all over.
- darkerside 7y ago
  There's a real analogy to be made here with mass production and it's impact on labor. We quickly went from a society that valued individual craftsmanship to one that valued the ability to treat people like cogs at the factory. I'm not even mad, mass production is a great thing that enabled access to goods that many people would never have otherwise had. But eventually there was a backlash, and handcrafted, high quality goods are preferred by many who can afford them. I'm not saying Go programmed products are lower quality, just that we've enabled certain types of organizations with the advent of greater process and rigor in languages. Someday the pendulum will likely swing again.
  - naringas 7y ago
    we even treat education like this. children are educated as mass produced laborers for the future
  - throwaway49872 7y ago
    > I'm not saying Go programmed products are lower quality I've met plenty of good developers that complain at how Go ties their hands and creativity. Unsurprisingly, the language has been designed for "cogs": --- The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike ---

superkuh 7y 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 7y 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 7y ago

Not Zen! Go Kant!

georgehm 7y 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 7y 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.
njharman 7y 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.
- georgehm 7y 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
  - bigato 7y ago
    In my experience, reality is unpredictable enough that no one actually know what the requirements will be two versions down the road. In practice you end up with code that is more complex than what the current problem needs, trying to solve a future need that you presume will happen but you don’t really know what it is and when it will happen.

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

saber6 7y ago
Sounds like a douche.
kenforthewin 7y 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 7y 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.
  - K0SM0S 7y ago
    I'm gonna say this with all the respect in the world for the technical view —I'm a nerd and I agree with you guys 100%, a huge upvote for the whole thread— but experience taught me something along those lines: There are such situations (people and places) that command one to put their mindset in "agreement mode", not because of logical reasons¹, but absent or even contrary to those, because of a need to reduce friction². In this meta-knowledge space³ lies the solution space⁴ for all your problems in a human environment. When you approach things like that, you tend to see where "tech" fits in a wider landscape, and it tells me when to speak and when to shut my big nerdy mouth (whenever it's counterproductive, e.g. premature abstraction⁵ is just as bad as premature optimization). It tells me which lines in the code are "political", "organizational", "structural" not to the tech but to the humans around; and by elimination, which lines are left for us nerds to think about deeply. It's a dance, really, there's no right/wrong/perfect, but there's a certain way to rise above these human contingencies and actually facilitate the path to market while having a blast — just set your expectations right as to what you can and can't touch, at least for now, reassess on a need-to basis. So when you see a dark "anti" pattern (OP's case), sure you naively ask 'why', but then if you see org/pol structure, if you see this rigid wall of "this is how we do it, this is who we are", you know it's not about tech anymore. It's personal. Don't hit there. People (especially when insecure, so all of us at times) tend to protect their knowledge like it's a judgment on themselves, like it's proof of their worth, and it's very hard but doable to notice when you're entering such territory with someone. ____ [1]: you might be smarter than your boss, you may be "right" technically [2]: "friction" in the economic sense, which includes overhead in your code as well as overhead from meetings. What stands between idea and productive execution. [3]: literally, larger than the technical, including all aspects of engineering, organization and market forces. [4]: the product that which you seek to make, i.e. that people use. The "internal" side of the product is the organization and codes that make it, that support its continued existence. [5]: in this case, we "abstract prematurely" when we presume to know a system better than their maintainers, or that our "outside looking in" "fresh" pair of eyes has all the answers already. There is often much more than the technical to consider.

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

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

zxcvbn4038 7y 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 7y ago
"The only Zen you can find on the tops of mountains is the Zen you bring up there." Robert M. Pirsig
- zxcvbn4038 7y ago
  “He who makes mountain out of mole hill should open ski resort in Kansas” A. Nonymous :)
pansa2 7y 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.

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

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

hellcow 7y 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.
- dmit 7y 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.

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

sagichmal 7y ago
HashiCorp stack is pretty good for this.
bigato 7y ago
The standard library
- monocasa 7y 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.
  - sagichmal 7y ago
    stdlib was once an exemplar of good, idiomatic Go code, but a lot of the idioms it uses haven't withstood the test of time, and it's less and less appropriate as an example.
    - 0xFACEFEED 7y ago
      This is true, but it's still worth poking around for pre-existing solutions to problems. My editor will jump to stdlib definitions so I've learned a lot just diving into various stdlib packages (I remember the JSON parser being a good one).
yawaramin 7y ago
I'm told that Sanjay Ghemawat's Go code is beautiful (I'm not a Go expert though): https://github.com/ghemawat/stream/ https://github.com/ghemawat/stream/ More about him: https://www.newyorker.com/magazine/2018/12/10/the-friendship-that-made-google-huge https://www.newyorker.com/magazine/2018/12/10/the-friendship...

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