14 ms·
Effective Go
- kgraves 5y agoI always refer myself and junior developers to Effective Go to sharpen their skills when working in our codebase. Are there other hidden Go gems/guides that exist that I happen to not know about as well?
- val_deleplace 5y agoYes, definitely dozens of pretty good online resources. Here are 3: - Tour of Go: https://tour.golang.org/ https://tour.golang.org/ - Practical Go: Real world advice for writing maintainable Go programs, by Dave Cheney: https://dave.cheney.net/practical-go/presentations/gophercon-israel.html https://dave.cheney.net/practical-go/presentations/gophercon... - Uber Go Style Guide: https://github.com/uber-go/guide/blob/master/style.md https://github.com/uber-go/guide/blob/master/style.md
- rob74 5y ago- Go Code Review Comments: https://github.com/golang/go/wiki/CodeReviewComments https://github.com/golang/go/wiki/CodeReviewComments
- rawoke083600 5y agoyes a talk from one of the big wigs in GO. Think its called 'Rethinking Conccurency' ?
- mhoad 5y agoNot a Go programmer but Dart also has something like this for a while which has been a pleasure to use, glad to see others can get the same benefits now. https://dart.dev/guides/language/effective-dart https://dart.dev/guides/language/effective-dart
- na85 5y agoI really liked using Go until I tried to publish a module with a version greater than 1. What kind of packaging system chokes on v2 of a module? What kind of language recommends[0] with a straight face that you just duplicate your entire codebase into a v2/ subdirectory? The module system is so obtuse and the documentation so poor that I will probably avoid go and choose other languages from now on. It really feels like they came to release time and someone in the meeting said "hey guys what if someone wants to release a new major version of their library?" and everyone else in the room had an "oh shit" moment because their amateur language design didn't address that corner case. [0] https://go.dev/blog/v2-go-modules https://go.dev/blog/v2-go-modules
- sudhirj 5y agoThe reason I like this is because of one of the principles that Go espouses pretty heavily - never break backwards compatibility. If I install v1 of your package, I want it never to break. You can always improve performance, add more methods, etc, but the normal Go upgrade does not involve any code changes at all. The tools formalise that for modules as well, and encourage building a new module altogether if backwards compatibility is being broken. If it’s not being broken, it’s not a major version update, and major breaking updates are better off as new separate modules.
- grey-area 5y agoExcept in practice in all real software (including the go language!) minor and patch versions break importers all the time in small ways, AND major versions are usually used to indicate significant new features, not just breaking changes. So your claim is reduced to ‘I don’t want v1 to break my software in ways that the dependency finds important enough for a major version’. Not quite as reassuring is it? Plenty of security fixes and undefined behaviour fixes break importers all the time, and often importers and exporters disagree about the severity of that. Sticking with v1 will not save you that pain. I preferred the situation before where there was strong social pressure never to break the main branch.
- hsn915 5y agoThis is a cultural issue. It's not inevitable that by developing a module over time that you constantly break compability AND you want all people that depend on you to upgrade version. Go encourages the opposite approach. If your API is not stable, don't publish a package for public consumption, or, make sure to clearly mark it as unstable, so people know what to expect. One of the absolute best features of Go is stability. If I have a project written a few years ago, I can always run it against the latest Go compiler and know that it will still work. Why does this matter? I'll give you a counter example. In 2016 I wanted to work on a mobile application project and I just picked React Native because I heard it lets you easily create cross platform applications. I worked on it for a few weeks, then left it for about two or three months. When I tried to pick it up again, I installed the latest versions of node and npm and upgraded all packages. The project stopped working. I had no idea what went wrong. The error messages were obtuse and several layers deep. I tried to debug it for weeks to no avail. As a result, I abandoned the project and built just an Android version using Kotlin and Android Studio.
- crecker 5y ago> Why is there no pointer arithmetic? Safety. Without pointer arithmetic it's possible to create a language that can never derive an illegal address that succeeds incorrectly. Compiler and hardware technology have advanced to the point where a loop using array indices can be as efficient as a loop using pointer arithmetic. Also, the lack of pointer arithmetic can simplify the implementation of the garbage collector. <3
- greyman 5y agoYes. And on the more general sense, I noticed Go tried to remove everything which can obfuscate the code and make it harder to read, or become junior-unfriendly. At least that's my impression.
- masklinn 5y ago> I noticed Go tried to remove everything which can obfuscate the code and make it harder to read, or become junior-unfriendly. That is unsurprising > 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.
- pjmlp 5y agoThe irony of that statement is that a language whose version 1.0 was pretty much Go in 1996, is now seen by them as a PhD level language.
- joconde 5y agoWhich language do you mean? Python 1.0 seems to have come out in 1994 (https://en.wikipedia.org/wiki/History_of_Python#Version_1 https://en.wikipedia.org/wiki/History_of_Python#Version_1).
- 5y ago
- noxer 5y agoStill has that political banner on top. Disgusting.
- deleted 5y ago[deleted]
- oxplot 5y agoA bunch of other docs I've looked up number of times and found handy: - Slice tricks: https://github.com/golang/go/wiki/SliceTricks https://github.com/golang/go/wiki/SliceTricks - Rest of the Golang Github Wiki: https://github.com/golang/go/wiki#additional-go-programming-wikis https://github.com/golang/go/wiki#additional-go-programming-... - Spec - very approachable: https://golang.org/ref/spec https://golang.org/ref/spec - Standard library source code - clean code with lots of idioms to learn from: https://cs.opensource.google/go/go/+/refs/tags/go1.17.1:src/ https://cs.opensource.google/go/go/+/refs/tags/go1.17.1:src/
- parhamn 5y agoHopefully, a ton of the slice tricks will soon be replaced with "container/slice" (although you'll still need a few)! [1] https://github.com/golang/go/issues/45955 https://github.com/golang/go/issues/45955
- louis-paul 5y agoAlso https://github.com/golang/go/wiki/CodeReviewComments https://github.com/golang/go/wiki/CodeReviewComments
- parhamn 5y agoCool I had never seen this before. All seem on point, but I have light disagreements with this one: > The basic rule: the further from its declaration that a name is used, the more descriptive the name must be. For a method receiver, one or two letters is sufficient. Common variables such as loop indices and readers can be a single letter (i, r). More unusual things and global variables need more descriptive names. In the tighter parts of some algorithms I love seeing more descriptive variables (obvious exclusions, as noted, are things like i, j, x, y). It's very common to see double letter variable names that become hard to track (plenty in the go source as well).
- google234123 5y agoSo why did we need go when Java already existed?
- matthewmacleod 5y agoBecause they're two different languages, tackling different problems, with entirely different sets of benefits and costs associated with their use.
- google234123 5y agoThat’s not enough to justify the (10s, 100?) millions of dollars of investment. Java is faster and safe and can do everything go can do. C++ can be even faster (at least there are no pauses from a gc) at the cost of some safety.
- kgraves 5y ago> Java is faster and safe and can do everything go can do. Including generating static binaries without the use of requiring to download a runtime?
- mindwok 5y agoThe fact that Go has gained so much adoption probably justifies that investment. They are completely different languages and much of it is personal preference.
- 5y ago
- abahlo 5y agoShameless plug on my opinionated [Go Styleguide](https://github.com/bahlo/go-styleguide https://github.com/bahlo/go-styleguide) – let me know what you think!
- greyman 5y agoI feel overall those are very reasonable rules. What I do differently: 1) Add context to errors - ok but sometimes the parent caller doesn't expect or wants that. 2) one-letter variables: I use them more, for example k,v for key,value loop through the map, n can be counter, or x is some value inside the loop.
- abahlo 5y agoYeah I actually agree, will make them sound less like a must. In early Go times people would use one-letter variables everywhere which was horrible.
- t8sr 5y agoSince you asked for feedback: Good style guides contain rationale, weigh pros and cons and then make a recommendation. For example, you say "use an assert library", but why? You make an assertion (har har) about consistent error output, but I've seen style guides that use the exact same rationale to ban assert libraries. This reads more like a list of things you wrote to remind yourself of, than something intended for consumption by other programmers. It's fine to be opinionated, but a normative document must explain itself, so people (1) learn something and (2) know when a rule isn't really a rule and (3) can make an informed decision to change something in 5 years when you no longer work there.
- abahlo 5y agoGood points, thank you!
- tomohawk 5y agoWhat's with the partisan advocacy prominently displayed as a banner? EDIT: I mean, it's hardly effective. Just like the downvotes.
- ihusasmiiu 5y agoWhen I look at a language I could not care less about the selection of keywords, the syntax used for a loop or the naming conventions. What I look for are the means of abstraction that the language provides, and Go gives nothing more than C.
- umvi 5y ago> Go gives nothing more than C. Huh? At the very least Go has a safe, robust string abstraction which C does not have. Not to mention slices, maps, range based for loops, a "batteries included" style standard library, and more...
- chubot 5y agoGo has strings, slices, maps / hash tables, channels, and interfaces. C doesn't have any of those things. (It has quirky string libraries, and string literal syntax, and that's about it)
- qbasic_forever 5y agoThat's an explicit feature and not a bug for the design of the Go language. They don't want it to be a kitchen sink of a language with everything for everyone.
- closeparen 5y agoI want to see an “Effective Go” about unit testing functions that call other functions, without devolving into meaningless mocking and error propagation boilerplate.
- morelisp 5y agoFor effective testing in Go: - Don't unit test so much (or expand your definition of "unit", or whatever semantic difference you prefer). Test functionality. (Unit tests can still be appropriate for large classes of complicated pure functions, e.g. parsers, but these don't require mocks.) - Don't mock so much; rather, stub (or mock if absolutely necessary) at lower levels. Use the httptest server; use the sqlmock or sqlite drivers; use a net.Conn with canned data; etc.
- closeparen 5y agoI would appreciate any resources you could point me towards to help make this argument against the Staff+ engineering leaders at my company who are pushing standards that say exactly the opposite.
- morelisp 5y agoThis sounds a lot more like company politics than a technical issue, but I would probably start with Mitchell Hashimoto's talk "Advanced Testing With Go" - along with the just, like, reading the tests / testing tools in stdlib. They didn't include httptest so you could spend time mocking away http.Client usage behind an interface! (I should add that this is explicitly contra to e.g sethammons's suggestion above, which seems to be relatively common in the part of the Go community that come from PHP. I inherited a couple large projects that did this. Today they use sqlite instead, and both the program and test code is ~50% the size it used to be.) For us, stub injection points come naturally out of 12-factor-style application design; the program can already configure the address of the 2-3 other things it needs to talk to or files it needs to output, etc, just out of our need for manual testing or staging vs. production environments. If you have technical leadership encouraging Spring-but-in-Go, you'll probably hit a wall here too though. It's also possible you're simply writing too many functions that can return errors. Over-complex code makes over-complex tests; always think about whether you're handling an error or a programming mistake - if the latter, panic instead of returning.
- awb 5y ago> Go is a new language It’s been 12 years next month. Might be time to change that?
- charles_f 5y agoAs languages go, both its age and spread still justifiably qualify it as "new"
- deleted 5y ago[deleted]
- dragonwriter 5y ago> It’s been 12 years next month. Since being announced, ~9 since 1.0. For comparison of some other currently popular languages (above it on the Tiobe Index), time from 1.0 (or something similar where typical modern versioning isn't applicable) is: Python 27 years, JavaScript 24 years, C 43 years (from K&R, realistically might count 1.0 earlier), C++ 36 years, Java 25 years, C# 19 years, Ruby 19 years, VB.Net 20 years, classic VB 30 years, Groovy 14 years. Go is a relatively new language. Not quite as young as Rust, but young for an industrially-popular language.
- deleted 5y ago[deleted]
- deleted 5y ago[deleted]
- rawoke083600 5y agoGo has warts and 101 faults (depending who you are and how hard you squint)... But what I absolutely love about Go is how easy(relative to other languages) it is to 'read' most of the Go code in the wild, including the std libs ! YMMV... Every tried reading C++ libs/header-libs ?
- msie 5y agoSame feeling I had about Python vs Ruby. When I was working on a Python script I had no qualms about diving into the source of libraries. Although I have been scared away from Python because of the many different ways that libraries can be included in a script.
- rawoke083600 5y agoAgreed and that is before you get to all the "function annotation" that ads some degree of magic.
- trey-jones 5y agoThis has always been my number one praise for Go as well. A lot of it has to do with gofmt I think.
- rawoke083600 5y agoJa I think you are absolutely right (go fmt) ! The tooling is fantastic and concise.
- mmargerum 5y agoAs a team lead I love go because no one can write clever code in it and even a bad coder can generally write somewhat working code in it.
- azth 5y agoC++ libs are an exception. I'd argue Java stdlibs are just as readable as golang's.
- charles_f 5y agoThis doc goes over pages of conventions, patterns, design advice, tips, explanations, etc. without once using the idiom "best practice". It is balanced and sometimes mention that advice can be taken too far. I salute you for that!