12 ms·

Just tell me how to use Go Modules

331 points by boyter 8y ago

nstart 8y ago
Just going to share a sentiment I've felt while diving into Golang over several months. The canonical way to do things feels like it's all over the place in several areas of Golang. Not in the fundamental "this is how you should indent" bit but in the "this is how you should unpack dynamic json content" sense. I really wish golang had more canonical content. But at this point, I feel like I'm working against the grain. Golang doesn't feel like a language that wants to prescribe a lot more than fundamentals. How you structure your code beyond the src/git/path/your-code/ is completely up to you and every repo you visit could be different. It's not my thing personally, and I'm leaving this comment just in case any "want to try golang" folk stop by. This is something you should be aware of going in. Don't bang your head when you can't find a clear way of doing something that probably seemed simple in other languages. Embrace the new concept and see if you can get used to it. That said, if anyone ever breaks into the eco system with an es lint style tool that allows experts to share their best practices via plugins, that would be awesome. If that exists already, please do let me know. I'd love to give it a go.
- jzoch 8y ago
  To agree with you with a slight rephrase: what makes idiomatic go code is very murky lately. With new changes in the horizon (Go 2 proposals around error checking and generics) the current solutions just dont feel idiomatic. Before these proposals started coming in, people staunchly (and many still do) defended error checking and lack of generics. Now, it feels a bit weak. Why am I writing all this ceremony (comparatively little compared to other languages, but ceremony nonetheless) when the new, better way is coming? Additionally, I agree that the idiomatic design patterns of go aren't well defined beyond "use channels, share memory by communicating, handle errors, and dont ever use functional precepts". A lot of go feels really good which makes the not as good parts really stand out. Personally, I'd like to see small QoL improvements (beyond generics and error handling) like named arguments, native functional operators like map, reduce, filter that take advantage of go's great runtime, and something cool like kotlin's by keyword for delegating ( https://kotlinlang.org/docs/reference/delegation.html https://kotlinlang.org/docs/reference/delegation.html)
  - dcow 8y ago
    I would argue `by` and `data` are the two most powerful keywords from any of the modern languages (~last 10 years) maybe next to `go`.
    - dnautics 8y ago
      You should check out the "with" keyword from elixir, (but the #1 all time best elixir feature is the |> (pipe) operator combined with IO.inspect)...
    - ngrilly 8y ago
      What does `data` do, and in which language?
      - letientai299 8y ago
        I think he means `data` class in kotlin. https://kotlinlang.org/docs/reference/data-classes.html https://kotlinlang.org/docs/reference/data-classes.html
        ngrilly 8y ago
        Yes, it looks like this. Thanks!
    - bluk 8y ago
      IMO `async/await` (C# / JavaScript), `defer` (Go), and `guard` (Swift) have changed the structure and flow of programs and are commonly used in their respective languages. Why do you believe that `by` and curiously `data` are so powerful?
    - jstimpfle 8y ago
      > `data` > modern Everything old is new again.
      - dcow 8y ago
- Groxx 8y ago
  There are a couple implementations of this (e.g. staticcheck[1] is probably the biggest and most widely used), but none are really pluggable or easy to interact with. And nearly anything even slightly sophisticated needs to interact with the type checker, which has like one example repo[2] and no other documentation anywhere. There's a semi-recent experiment to try to make a pluggable lint system[3], but I'm not sure what the current status is. For my workplace, tbh I plan on making something semi-hacky just to get us off the ground + use real go plugins so we actually have some minor extensibility without reams of boilerplate. I've built several tiny things that just use the AST (which is not bad at all, and quite fast - several thousand source files take about 250ms), and they've been worth the effort like 100x over, but it's hard / impossible to do anything better without the type checker + significant amounts of work. [1]: very highly recommended, it has far more / better checks than others I've seen, but is also quite slow and hard to extend: https://staticcheck.io/ https://staticcheck.io/ [2]: it's honestly quite a good repo, but there needs to be more. it's a fairly unfriendly API and there are few helper libs as far as I've seen: https://golang.org/s/types-tutorial https://golang.org/s/types-tutorial [3]: https://docs.google.com/document/d/1-azPLXaLgTCKeKDNg0HVMq2ovMlD-e7n1ZHzZVzOlJk/edit#heading=h.yrkxrtoon8kq https://docs.google.com/document/d/1-azPLXaLgTCKeKDNg0HVMq2o...
  - Zach_the_Lizard 8y ago
    I second the comments about the various AST and type packages. They are just absurdly unfriendly. I've written a linter / code formatter / auto bug repair tool internally for my current company and it sucked. Still sucks. Comments doubly so. The examples are few, undocumented, and don't always work with the vendor directory concept. I had to write my own custom importer to get vendor support to be more reliable. I like the concept of shipping with an AST package; it's very forward looking and useful. I too hope the go/analysis package could be the answer. I believe it has not merged but has a prototype version that conflicts with master. Maybe they'll patch it up and get it landed soon. I hope, anyways
    - Groxx 8y ago
      AST for read access I find relatively decent. Straightforward and not complicated. For manipulating code tho (e.g. for code gen or rewriting), yeah - absurdly unfriendly fits pretty well, and comments only kinda sorta mostly work until you actually try to produce anything polished. It kinda feels like they prioritized forward-compatibility at the cost of usability (which could be a decent decision / a fair tradeoff, but it sucks as a user trying to do stuff now).
- weberc2 8y ago
  > How you structure your code beyond the src/git/path/your-code/ is completely up to you and every repo you visit could be different. This is an unusual criticism. Typically Go is faulted for being too opinionated, and it’s projects too predictable. In fact, this is why I took to the language—no need to see past every maintainer’s personal flourishes just to build the code or run the tests. No ceremoniously nested directory structure. No figuring out how to point the build tool to the source files or how to convince the build tool to output or run a test target. Everything is right there, rather plainly and consistently across all projects. This does mean I have less room for creativity which is an okay tradeoff for me because I have just enough creativity to spend on the application and its architecture and the rest should just work, but I recognize that some may disagree and that’s okay too.
  - Felz 8y ago
    This sounds like tooling and formatting consistency versus abstraction consistency. Go isn't great for building powerful abstractions, so at a higher level implementations will trend towards inconsistency, however consistent the low level syntax.
    - gcb0 8y ago
      in other words, it's consistent if you only look at it for a few minutes. use it for anything and it become an inconsistent mess.
      - kerng 8y ago
        Been trying it out and agree. I like it a lot for simple, stand alone tools. For more complex ones it appears strangely ill-suited and "messy".
    - jonathanstrange 8y ago
      As if powerful abstractions lead to more consistency...
    - weberc2 8y ago
      A few thoughts: 1. I don't think powerful abstractions are often that useful. I use Python in my day job, and we mostly don't use many high level abstractions. We never use monads, for example, and while we do use async futures, these are strictly worse than Go's concurrency features. 2. Pretty sure abstraction power drives _less_ consistency, not more. Effectually, it means there are more ways to do the same thing (and more ways to screw it up and make a mess), and consistency depends on organization discipline and less on the rails of the language. I don't mean to say abstraction is bad--only that consistency is one of the costs, not an advantage. I'm interested to hear your thoughts.
- sjellis 8y ago
  > Golang doesn't feel like a language that wants to prescribe a lot more than fundamentals. How you structure your code beyond the src/git/path/your-code/ is completely up to you and every repo you visit could be different. I only follow Go casually ATM, but I think that it might fairer to say that the core team wants to stay focused on delivering the language and implementations, so we get blog posts and conference talks, but not a big trove of guidance on patterns & practices. The best place to interact with the wider Go community is the Gophers Slack, and if you visit there, you will find that there's a lot of knowledge and thinking, but it's in scattered places. For example, this article will probably be cited in any discussion of application structure: https://medium.com/@benbjohnson/standard-package-layout-7cdbc8391fc1 https://medium.com/@benbjohnson/standard-package-layout-7cdb...
- jcelerier 8y ago
  > in the "this is how you should unpack dynamic json content" sense. I would be very wary of a language who has core features around such transient things than JSON unpacking.
- alias_neo 8y ago
  When i first started Golang professionally, over 3 years ago, my first gripe was the GOPATH. WHY SHOULD ALL MY CODE SIT IN ONE FOLDER? I say gripe, it was a huge annoyance. Why on earth, also, should i need to use the repo path in my structure and imports? It's obscene. My next annoyance was the utter inability to easily parse dynamic JSON. But you know what the JSON looks like? Great, you'll only have to wrap it in a few structs and check your capitalisation if you want it to parse at all, no problem you think before half a day has gone just parsing one response. The vendoring makes my month painful as I'm retooling the build system for the flavour of the month vendoring toy. Structuring large projects still causes me great pain. All of that said, Golang is now my favourite language to program in, and is my default for any new project.
  - dom96 8y ago
    I've had a similar reaction when trying Go. While I'm biased, I strongly believe Nim offers a much better alternative which solves all of the problems you mention in a much better way. In particular, parsing JSON is a breeze, just like in Python. And there is no GOPATH weirdness. Give Nim a try if you haven't already, it may just become your new favourite language :)
    - alias_neo 8y ago
      I'll look into it, thanks. I was planning on Rust being my next language but I'll see what Nim offers. I take it your bias is because your the/a creator?
      - dom96 8y ago
        I'm one of the core developers
        alias_neo 8y ago
        Ok! What's its standard library like compared to Go? I like that I can write powerful projects with few external dependencies. I don't like that C binding is slow and C++ binding is missing. How does it compare to Rust, which is currently top of my list to learn next? Can you suggest a reason, or a few why Nim should knock Rust from that spot?
- InGodsName 8y ago
  Our agency most mostly does SaaS apps. We use Rails and React. We tried Go for backend but Go is missing ActiveRecorss, payment gateway libraries, etc... Where is migration management like sqlachemy or activ records? For building SaaS product i think you should choose Rails. It takes only few minutes to creare subscription billling, team accounts, invoice etc.. functionality. I would like to know what you guys use.
  - bpizzi 8y ago
    Well, the comparison is not really fair, Rails is a framework for building webapp, whereas Go is a language with a standard library. To simplify a bit: Go is in the same bag as C++/C#/Java, Rails is in the same bag as PHP & [Symfony/Laravel]. If you're mass building CRUD web applications against customers requirements then, clearly, RoR is the best tool for the job (versus Golang).
    - lowercased 8y ago
      > Go is in the same bag as C++/C#/Java, Rails is in the same bag as PHP & [Symfony/Laravel]. Go is in the same bag as C++/C#/Java/Ruby/PHP (languages) Rails is in the same bag as Symfony/Laravel (frameworks)
      - bpizzi 8y ago
        I literally said 'Rails is a framework for building webapp, whereas Go is a language with a standard library'. what's your point?
        sixstringtheory 8y ago
        They moved PHP from framework to language, it’s a small nit but worth picking I suppose.
        lowercased 8y ago
        Ruby is a language distinct from the Rails framework. PHP is a language distinct from the other frameworks listed. Small nitpick, but I always hate to see conflation of languages and frameworks when making comparisons.
- Memosyne 8y ago
  I try to adhere to https://github.com/golang-standards/project-layout https://github.com/golang-standards/project-layout, but I find that most repositories just have their own way of doing things. I really wish Go provided a standard structure for organizing projects, as I find it increasingly difficult to understand dozens of different structures.
- AlexCoventry 8y ago
  > es lint style tool that allows experts to share their best practices via plugins, Have you seen gometalinter? Its defaults are way too computationally expensive for me, but it brings together reports from a lot of different linters. https://github.com/alecthomas/gometalinter#supported-linters https://github.com/alecthomas/gometalinter#supported-linters
- andreygrehov 8y ago
  > How you structure your code beyond the src/git/path/your-code/ is completely up to you and every repo you visit could be different. Erm...I'm confused. Why on earth every repo should have the same structure? I mean, I understand when you use a framework that prescribes you a layout, but even so, good frameworks try not to get into developer's way. Why the source code of a webapp should have the same structure as a, say, database? There were quite a few comments about standard project layout - I'm sure there is something similar for every language, but these things are just recommendations. And thank god they are not rules. Am I missing something here?
  - oblio 8y ago
    Yes. Having a common overall structure is good. When I open a Maven project, the Java sources are always (99,99% of the time) in src/main/java, the resources are in /src/main/resources, the Java test sources are in src/test/java, etc. Every project has to have source code, every project could have resources. Every project could have test sources, etc.
triodan 8y ago
Thank God, finally a proper "Getting Started" guide for Go Modules. The official docs and wiki page always felt so obtuse and unhelpful about how to actually use the feature, while dep at least offers the obvious "dep init then dep ensure and you'll be fine" solution.
shaklee3 8y ago
This site needs better formatting. It looks like the author has section titles, but they're the same font and style as the body.
- valtism 8y ago
  Also, the text being set at alpha of 0.5 makes it very low contrast and difficult to read, even as a nearly fully sighted person.
- roryokane 8y ago
  The section titles look different from the body text for me, on macOS 10.13 in both Firefox 63 and Chrome 70. Either the site was fixed or your browser is broken.
jfolkins 8y ago
Please understand that if you vendor your dependencies inside your go.mod project, you own them and will need to support and audit them in the future. The mod command does not vet any computed hashes of the dependencies found in your vendor directory.
- cyphar 8y ago
  Though of course if you don't use "go mod vendor" then "go build" will require an internet connection, which is a problem for most distributions (package builds generally don't have an internet connection).
  - jfolkins 8y ago
    Why aren't your go build tools pulling from the GOPATH/pkg/mod/cache directory? This would alleviate the need for your build to have a internet connection no?
    - cyphar 8y ago
      Fresh builds (in an "rpmbuild" for instance) don't use a cache, for obvious reasons.
- drvd 8y ago
  Running "go mod vendor" just populates the vendor folder which allows local development with all tooling. It does not force you to check in the vendor folder (you can even .gitignore vendor). Doing "go mod vendor" is not the typical "vendor", it does not make you the owner and you do not need to support and audit these packages (unless you actually vendor them in the sense of check them in).
- jerf 8y ago
  You own your dependencies and will need to support and audit them in the future. Note the lack of conditions on that statement, up to and including the fact this statement isn't even about Go, nor is it even about open source! It is simply a fact. You own your dependencies and you need to support and audit them. You are free to support and audit them by not supporting them at all, not auditing them at all, and blindly pulling in whatever random mutations they may go through in the future. You own the consequences of such terrible support. You own the consequences of good support.
maddyboo 8y ago
Something which isn't mentioned here and is difficult to find precise information even in the official docs is how versioning works - specifically, how do you specify what version your module is? Semver is mentioned, but not how to define your version. The short answer is to use git tags. You need to include the `v`, e.g. `v1.2.3`. If you don't use git, I don't know the answer.
- gcb0 8y ago
  versions? 2018 is the year of the evergreen module dependency injection!
  - alexandernst 8y ago
    Absolutely stupid... I don't want my poduction pipeline to be injecting evergreenshittery I haven't revised/tested.
    - bpizzi 8y ago
      Not sure if you were being sarcastic... But this is exactly what 'go mod' is NOT doing. It's called 'Minimal Version Selection'. Quoted right from the lead core dev's blog: ' For stable development, today's build list must also be tomorrow's build list.' (https://research.swtch.com/vgo-mvs https://research.swtch.com/vgo-mvs). From what I gathered, 'go mod' is the first mainstream tool which is going that way (but I would be glad to be proved wrong!). Other package manager are using lock files which have their caveats (see https://research.swtch.com/cargo-newest.html https://research.swtch.com/cargo-newest.html for an in depth examination of the revered cargo approach on low-fidelity builds).
      - greysteil 8y ago
        The version resolution algorithm is very similar to NuGet's "lowest applicable version" logic, which has been around since 2010. I've seen surprisingly little discussion of the fact they're so similar. https://docs.microsoft.com/en-us/nuget/consume-packages/dependency-resolution#dependency-resolution-rules https://docs.microsoft.com/en-us/nuget/consume-packages/depe...
giancarlostoro 8y ago
After half a decade of not touching Go I went back to learning it. This was the one thing tripping me up. Not because I didnt understand it but because I cant even compile or pull in packages without defining some compiler variable flag witchcraft. I miss how simpler Go was. The compiler UX there really needs more TLC. Otherwise I still love what I loved about Go: a really incredible out of the box standard library which I highly attribute to Go's success since it allowed people to hit the ground running with Go much quicker.
- yesimahuman 8y ago
  Was it ever easy? I remember hours trying to figure out what to set GOPATH and GOHOME to and how to get “go get” to actually work. I can’t help but think go is a wonderful language with a poor package manager unfortunately woven directly into the language. Really makes npm feel wonderful in comparison.
  - deleted 8y ago
    [deleted]
  - anonfunction 8y ago
    I found it quite easy to set two environment variables and never had issues with `go get` either.
    - nvarsj 8y ago
      "go get" is a disaster for any project of non trivial size. It was designed with the idea of a mono repo in mind - not a vast distributed network of independently evolving code repositories.
      - sethammons 8y ago
        Never had any issues with that as soon as vendoring was an option. I routinely had/have three or more different non-trivial projects I was/am working on, and I dont recall ever having issues with go get. I started around maybe Go1.2. At first, I set GOPATH per project, but as soon as vendoring was a thing, one GOPATH to rule them all. Now, vendor updates to existing dependencies, there is something that has been a complete and utter disaster that hopefully gets better under the mod system.
teknologist 8y ago
Go newb here but I personally found it easy to get started with Go Modules and migrate over a fairly large project using Dep. `go mod init` was very helpful here in picking up the Gopkg.toml and doing the magic to make it all work. No complaints at all.
raverbashing 8y ago
Thank you. Go Modules seems to suffer the same disease as emacs where people trying to explain it go on and on without getting to the point.
stubish 8y ago
For projects with all dependencies hosted on github. I still need to work out if I can use the new tooling with our internal repos. I imagine I'll need to be editing that go.mod file.
- josteink 8y ago
  So not only are modules tightly coupled to a specific version control system (git), it’s also tied to a single centralized online service of this decentralized VCS. Maybe I’m just old fashioned, but to me this is a code smell. It reeks of needless coupling, and I suspect one day (sooner rather than later) the golang designers will come to regret it. To top it off, despite being tied to a VCS, it seems to lack a useful means of enforcing versioned dependencies. This simply does not look like a good design. Is this really the new and improved version? If so, how god awfully bad was the previous iteration?
  - cube2222 8y ago
    I had no problems using it with self hosted gitlab.
  - jchw 8y ago
    It is not tied to Git nor GitHub.
    - e12e 8y ago
      So when you're building on a host without internet access, the "github.com" namespacing isn't an issue?
      - jchw 8y ago
        Depends. If you use vendoring, which is supported by Go modules, then you should be able to avoid needing any internet access. If you want to grab the dependencies fresh, then obviously if you have a github dependency, it will require git and the ability to access GitHub.com.
      - deleted 8y ago
whizzkid 8y ago
Golang's not being an opinionated software is the main reason I was not able to passionately start learning this software. Most of the engineers have a bit of a picture in their mind when it comes to implement a specific function. But when the question comes "what is the best way of implementing it in Golang?" then unfortunately the answer is "Do as you want". This prevents me learning the power of language from the beginning. Being opinionated is about onboarding people with the best experience from the experts of the language, then let people overwrite or choose their own way of doing things when they know what they are doing.
- pjmlp 8y ago
  Having learned to code in a time and age where being opinionated wasn't a thing, opinionated languages feel like golden cages.
- bpizzi 8y ago
  > Golang's not being an opinionated software [...] "what is the best way of implementing it in Golang?" then unfortunately the answer is "Do as you want". I'm really not sure. Idiomatic Go is something well covered. Gofmt is ensuring consistent formatting. The official docs have an entry dedicated to this: https://golang.org/doc/effective_go.html https://golang.org/doc/effective_go.html. And what would be an opinionated language if Golang is not?
  - kenhwang 8y ago
    Rust comes to mind. Almost all projects fetch dependencies and build the same way (cargo), with very similar looking project structures and entry point. The community has rallied around a set of libraries that's used by everyone. I couldn't care less about formatting differences between repos. Ignoring superficial formatting difference, Ruby's community also has one package manager (bundler) and build tool (rake) with a widely followed naming convention and directory structure and community consensus set of libraries. Both the above languages I can build a codebase I've never seen before and have it running within minutes even without README. Go feels like the wild wild west. Everyone has their own directory structure, with different ways of fetching dependencies (modules vs dep), building (seems to have consolidated around go build vs make), with everything hand rolled or whatever NIH selection criteria they used for their libraries.
bpizzi 8y ago
> Unfortunately, a quick guide like this doesn’t seem to exist, so I’m writing one here. You’re welcome. Well, `go help modules` is a good combination of exhaustiveness and conciseness, IMHO.
kishansh 8y ago
Do add the awesome "go mod tidy" command to your blog :-) This removes unused modules and adds missing ones.
ra7 8y ago
A more detailed intro to Go Modules: https://roberto.selbach.ca/intro-to-go-modules/ https://roberto.selbach.ca/intro-to-go-modules/
merb 8y ago
actually > go get -u ./... should probably be > go mod tidy
jonathanstrange 8y ago
One question not answered in this article is whether I will need to use modules in the future or not. I'm perfectly fine with not using them, but I've heard conflicting information about the future roadmap. If I have to use them later, I'd rather switch now, but if I don't have to switch even in 10 years from now, then I'd prefer not to switch to modules at all. Does anyone know more about this?
shanev 8y ago
Today I had to write some deployment scripts and the value of a fixed GOPATH really dawned on me. No matter which machine I use, I always know my code will be at GOPATH/src/... I didn't have to fiddle with any paths or env vars in my scripts. It made my day easier. This is an example of something that seems like a good practice only after you've gotten some gray in your beard.
- rauhl 8y ago
  Yup, that’s been my own experience too. I’ve really come to appreciate the virtue of GOPATH, and I honestly don’t understand the complaints about it. Why wouldn’t one want all of one’s code in a single place? What’s wrong with organisation? If one needs to work with different versions, then that’s what version control is for, isn’t it? Obviously I’m missing something, because my opinion seems to be in the minority. I wonder if it’s because most people are using GUI file managers, which make using directories of code more difficult, while I use emacs and the shell, and so can comfortably manipulate files & directories at scale.
  - _rs 8y ago
    Because different projects need different versions of their dependencies. Do I need a separate GOPATH for each of these projects? I haven't wrangled Go enough to know the right answer to that yet. In my experience with other languages: I'd really prefer to have the dependencies local to the project and not in some global folder that affects all of my projects. I want to be able to make a random project folder anywhere and have the entire thing be self-contained without worrying about anything outside of that folder.
    - wbl 8y ago
      That's what vendor and modules are for.
- kerng 8y ago
  These global predefined rules lead to long term (several years later) problems. I prefer it when things are configurable and flexible and a technology doesnt try to be the center of the universe. Think of versioning and running multiple versions on same machine. Its like Microsoft with their dll hell. One has to come up with some (undefined, no guidance or built in solution available) way to do it.
astockwell 8y ago
Is there a decent convention for naming your specifically-for-deps module? ‘go mod init vendored’?
- SamWhited 8y ago
  You should probably still be using a full module init path (eg. myrepos.example.com/mymodule) to make it go get compatible, and regardless of whether it will only be a dep for a single project or not, the name should be descriptive of what's in the module or package. Having a module that's "specifically for deps" sounds wrong to me in general, but without knowing what you're actually doing that is harder to give advise on.
dana321 8y ago
Two commands: go mod init mymodulename go build This will download all the dependencies needed automatically. You can also do this (from scratch as well): go mod init mymodulename go run main.go And it will still download the dependencies. If you use a modulename like github.com/dana321/test you can include a subfolder of your project by importing github.com/dana321/test/mysubfolder for example If you bring down the wrong version (ie. an older) version of a module, just edit the go.mod file and modify the version (after the space where the url is) and change it to master on the line where the module is. When you next run go build or go run it will re-download and re-populate the line(s) you've changed in go.mod with the latest version. There really isn't much else you need to know!
- kasey_junk 8y ago
  There is if you want to vendor your dependencies, which given my experience with golang dependency management over the years, I’ll be doing for the foreseeable future. This guide outlines the set of incantations required to accomplish that & frankly having fought through figuring it out myself from the doco, this would have saved me a bunch of time.
SaulOfTheJungle 8y ago
I am new to Go and I want to start a new project. In which cases should I adopt modules versus just sticking with $GOPATH?
- SamWhited 8y ago
  Everything is moving to Go modules; unless you need compatibility with legacy tools I'd start updating and go ahead and use modules whenever possible. It will make your life easier in the future when you have to transition fewer things.
laurent123456 8y ago
There should be a website like "justtellmehow.com" with useful articles like this. I found that lib and tool documentations written by their authors tend be to be too long. It's understandable since they are passionate about the subject and want to talk about every details, but it's not great when you just want to quickly add a lib to your project or use some tool.
- SlowRobotAhead 8y ago
  This can of course go beyond programming. But, yes, there is a major lack in CS and CE of relaying on the INTENT. - I can see the datasheet where this micro has 32 message objects and a FIFO mode - but please tell me how you INTENDED it to be used because after weeks of figuring out the obscure memory and buffer system it turns out you never INTENDED a fifo rollover. Ok, that would have been excellent info on Day1. - Your framework has a couple of examples and each function is documented. Great, but imagine my surprise when it turns out I can’t access a ‘global’ memory object outside of your function because you never intended that to happen - and never thought to let me know. - This is the entire concept of a WHY comment vs a WHAT comment. Don’t write //increments X+1 instead use //counter ticked here because new value is used during the loop, must be placed at the top, uint8 / rolls at 256 for an x++ example. WHY comments made a big difference in the readability of my code. The goal is to relay intent. The thing is, you don’t want to rigidly be stuck to someone else’s idea - but it’s extremely helpful to know how they planned for you use this because maybe the choices they made do make sense. Oh use an array of this memory type instead of casting it all to a class/structure! Yea, that’s fine and will be more efficient to search through etc etc. I don’t need know why but engineers are really bad at telling you what they intended when making the product.
- danesparza 8y ago
  For using Go specifically, there is https://gobyexample.com/ https://gobyexample.com/ which I have found to be a huge help. I'm not sure that's exactly what you're talking about, though.
- kiliantics 8y ago
  The title reminded me of the "explain deleuze to me" meme: https://twitter.com/helm_ll/status/991045671133351936 https://twitter.com/helm_ll/status/991045671133351936
vorpalhex 8y ago
Thanks for writing this! I just picked up go again after several months and I had to read the formal guide a few times to correctly figure out how to use modules. I do like the new modules system so far though!

331 points by boyter 8y ago

Just going to share a sentiment I've felt while diving into Golang over several months. The canonical way to do things feels like it's all over the place in several areas of Golang. Not in the fundamental "this is how you should indent" bit but in the "this is how you should unpack dynamic json content" sense. I really wish golang had more canonical content. But at this point, I feel like I'm working against the grain. Golang doesn't feel like a language that wants to prescribe a lot more than fundamentals. How you structure your code beyond the src/git/path/your-code/ is completely up to you and every repo you visit could be different. It's not my thing personally, and I'm leaving this comment just in case any "want to try golang" folk stop by. This is something you should be aware of going in. Don't bang your head when you can't find a clear way of doing something that probably seemed simple in other languages. Embrace the new concept and see if you can get used to it. That said, if anyone ever breaks into the eco system with an es lint style tool that allows experts to share their best practices via plugins, that would be awesome. If that exists already, please do let me know. I'd love to give it a go.

jzoch 8y ago
To agree with you with a slight rephrase: what makes idiomatic go code is very murky lately. With new changes in the horizon (Go 2 proposals around error checking and generics) the current solutions just dont feel idiomatic. Before these proposals started coming in, people staunchly (and many still do) defended error checking and lack of generics. Now, it feels a bit weak. Why am I writing all this ceremony (comparatively little compared to other languages, but ceremony nonetheless) when the new, better way is coming? Additionally, I agree that the idiomatic design patterns of go aren't well defined beyond "use channels, share memory by communicating, handle errors, and dont ever use functional precepts". A lot of go feels really good which makes the not as good parts really stand out. Personally, I'd like to see small QoL improvements (beyond generics and error handling) like named arguments, native functional operators like map, reduce, filter that take advantage of go's great runtime, and something cool like kotlin's by keyword for delegating ( https://kotlinlang.org/docs/reference/delegation.html https://kotlinlang.org/docs/reference/delegation.html)
- dcow 8y ago
  I would argue `by` and `data` are the two most powerful keywords from any of the modern languages (~last 10 years) maybe next to `go`.
  - dnautics 8y ago
    You should check out the "with" keyword from elixir, (but the #1 all time best elixir feature is the |> (pipe) operator combined with IO.inspect)...
  - ngrilly 8y ago
    What does `data` do, and in which language?
    - letientai299 8y ago
      I think he means `data` class in kotlin. https://kotlinlang.org/docs/reference/data-classes.html https://kotlinlang.org/docs/reference/data-classes.html
      - ngrilly 8y ago
        Yes, it looks like this. Thanks!
  - bluk 8y ago
    IMO `async/await` (C# / JavaScript), `defer` (Go), and `guard` (Swift) have changed the structure and flow of programs and are commonly used in their respective languages. Why do you believe that `by` and curiously `data` are so powerful?
  - jstimpfle 8y ago
    > `data` > modern Everything old is new again.
    - dcow 8y ago
Groxx 8y ago
There are a couple implementations of this (e.g. staticcheck[1] is probably the biggest and most widely used), but none are really pluggable or easy to interact with. And nearly anything even slightly sophisticated needs to interact with the type checker, which has like one example repo[2] and no other documentation anywhere. There's a semi-recent experiment to try to make a pluggable lint system[3], but I'm not sure what the current status is. For my workplace, tbh I plan on making something semi-hacky just to get us off the ground + use real go plugins so we actually have some minor extensibility without reams of boilerplate. I've built several tiny things that just use the AST (which is not bad at all, and quite fast - several thousand source files take about 250ms), and they've been worth the effort like 100x over, but it's hard / impossible to do anything better without the type checker + significant amounts of work. [1]: very highly recommended, it has far more / better checks than others I've seen, but is also quite slow and hard to extend: https://staticcheck.io/ https://staticcheck.io/ [2]: it's honestly quite a good repo, but there needs to be more. it's a fairly unfriendly API and there are few helper libs as far as I've seen: https://golang.org/s/types-tutorial https://golang.org/s/types-tutorial [3]: https://docs.google.com/document/d/1-azPLXaLgTCKeKDNg0HVMq2ovMlD-e7n1ZHzZVzOlJk/edit#heading=h.yrkxrtoon8kq https://docs.google.com/document/d/1-azPLXaLgTCKeKDNg0HVMq2o...
- Zach_the_Lizard 8y ago
  I second the comments about the various AST and type packages. They are just absurdly unfriendly. I've written a linter / code formatter / auto bug repair tool internally for my current company and it sucked. Still sucks. Comments doubly so. The examples are few, undocumented, and don't always work with the vendor directory concept. I had to write my own custom importer to get vendor support to be more reliable. I like the concept of shipping with an AST package; it's very forward looking and useful. I too hope the go/analysis package could be the answer. I believe it has not merged but has a prototype version that conflicts with master. Maybe they'll patch it up and get it landed soon. I hope, anyways
  - Groxx 8y ago
    AST for read access I find relatively decent. Straightforward and not complicated. For manipulating code tho (e.g. for code gen or rewriting), yeah - absurdly unfriendly fits pretty well, and comments only kinda sorta mostly work until you actually try to produce anything polished. It kinda feels like they prioritized forward-compatibility at the cost of usability (which could be a decent decision / a fair tradeoff, but it sucks as a user trying to do stuff now).
weberc2 8y ago
> How you structure your code beyond the src/git/path/your-code/ is completely up to you and every repo you visit could be different. This is an unusual criticism. Typically Go is faulted for being too opinionated, and it’s projects too predictable. In fact, this is why I took to the language—no need to see past every maintainer’s personal flourishes just to build the code or run the tests. No ceremoniously nested directory structure. No figuring out how to point the build tool to the source files or how to convince the build tool to output or run a test target. Everything is right there, rather plainly and consistently across all projects. This does mean I have less room for creativity which is an okay tradeoff for me because I have just enough creativity to spend on the application and its architecture and the rest should just work, but I recognize that some may disagree and that’s okay too.
- Felz 8y ago
  This sounds like tooling and formatting consistency versus abstraction consistency. Go isn't great for building powerful abstractions, so at a higher level implementations will trend towards inconsistency, however consistent the low level syntax.
  - gcb0 8y ago
    in other words, it's consistent if you only look at it for a few minutes. use it for anything and it become an inconsistent mess.
    - kerng 8y ago
      Been trying it out and agree. I like it a lot for simple, stand alone tools. For more complex ones it appears strangely ill-suited and "messy".
  - jonathanstrange 8y ago
    As if powerful abstractions lead to more consistency...
  - weberc2 8y ago
    A few thoughts: 1. I don't think powerful abstractions are often that useful. I use Python in my day job, and we mostly don't use many high level abstractions. We never use monads, for example, and while we do use async futures, these are strictly worse than Go's concurrency features. 2. Pretty sure abstraction power drives _less_ consistency, not more. Effectually, it means there are more ways to do the same thing (and more ways to screw it up and make a mess), and consistency depends on organization discipline and less on the rails of the language. I don't mean to say abstraction is bad--only that consistency is one of the costs, not an advantage. I'm interested to hear your thoughts.
sjellis 8y ago
> Golang doesn't feel like a language that wants to prescribe a lot more than fundamentals. How you structure your code beyond the src/git/path/your-code/ is completely up to you and every repo you visit could be different. I only follow Go casually ATM, but I think that it might fairer to say that the core team wants to stay focused on delivering the language and implementations, so we get blog posts and conference talks, but not a big trove of guidance on patterns & practices. The best place to interact with the wider Go community is the Gophers Slack, and if you visit there, you will find that there's a lot of knowledge and thinking, but it's in scattered places. For example, this article will probably be cited in any discussion of application structure: https://medium.com/@benbjohnson/standard-package-layout-7cdbc8391fc1 https://medium.com/@benbjohnson/standard-package-layout-7cdb...
jcelerier 8y ago
> in the "this is how you should unpack dynamic json content" sense. I would be very wary of a language who has core features around such transient things than JSON unpacking.
alias_neo 8y ago
When i first started Golang professionally, over 3 years ago, my first gripe was the GOPATH. WHY SHOULD ALL MY CODE SIT IN ONE FOLDER? I say gripe, it was a huge annoyance. Why on earth, also, should i need to use the repo path in my structure and imports? It's obscene. My next annoyance was the utter inability to easily parse dynamic JSON. But you know what the JSON looks like? Great, you'll only have to wrap it in a few structs and check your capitalisation if you want it to parse at all, no problem you think before half a day has gone just parsing one response. The vendoring makes my month painful as I'm retooling the build system for the flavour of the month vendoring toy. Structuring large projects still causes me great pain. All of that said, Golang is now my favourite language to program in, and is my default for any new project.
- dom96 8y ago
  I've had a similar reaction when trying Go. While I'm biased, I strongly believe Nim offers a much better alternative which solves all of the problems you mention in a much better way. In particular, parsing JSON is a breeze, just like in Python. And there is no GOPATH weirdness. Give Nim a try if you haven't already, it may just become your new favourite language :)
  - alias_neo 8y ago
    I'll look into it, thanks. I was planning on Rust being my next language but I'll see what Nim offers. I take it your bias is because your the/a creator?
    - dom96 8y ago
      I'm one of the core developers
      - alias_neo 8y ago
        Ok! What's its standard library like compared to Go? I like that I can write powerful projects with few external dependencies. I don't like that C binding is slow and C++ binding is missing. How does it compare to Rust, which is currently top of my list to learn next? Can you suggest a reason, or a few why Nim should knock Rust from that spot?
InGodsName 8y ago
Our agency most mostly does SaaS apps. We use Rails and React. We tried Go for backend but Go is missing ActiveRecorss, payment gateway libraries, etc... Where is migration management like sqlachemy or activ records? For building SaaS product i think you should choose Rails. It takes only few minutes to creare subscription billling, team accounts, invoice etc.. functionality. I would like to know what you guys use.
- bpizzi 8y ago
  Well, the comparison is not really fair, Rails is a framework for building webapp, whereas Go is a language with a standard library. To simplify a bit: Go is in the same bag as C++/C#/Java, Rails is in the same bag as PHP & [Symfony/Laravel]. If you're mass building CRUD web applications against customers requirements then, clearly, RoR is the best tool for the job (versus Golang).
  - lowercased 8y ago
    > Go is in the same bag as C++/C#/Java, Rails is in the same bag as PHP & [Symfony/Laravel]. Go is in the same bag as C++/C#/Java/Ruby/PHP (languages) Rails is in the same bag as Symfony/Laravel (frameworks)
    - bpizzi 8y ago
      I literally said 'Rails is a framework for building webapp, whereas Go is a language with a standard library'. what's your point?
      - sixstringtheory 8y ago
        They moved PHP from framework to language, it’s a small nit but worth picking I suppose.
      - lowercased 8y ago
        Ruby is a language distinct from the Rails framework. PHP is a language distinct from the other frameworks listed. Small nitpick, but I always hate to see conflation of languages and frameworks when making comparisons.
Memosyne 8y ago
I try to adhere to https://github.com/golang-standards/project-layout https://github.com/golang-standards/project-layout, but I find that most repositories just have their own way of doing things. I really wish Go provided a standard structure for organizing projects, as I find it increasingly difficult to understand dozens of different structures.
AlexCoventry 8y ago
> es lint style tool that allows experts to share their best practices via plugins, Have you seen gometalinter? Its defaults are way too computationally expensive for me, but it brings together reports from a lot of different linters. https://github.com/alecthomas/gometalinter#supported-linters https://github.com/alecthomas/gometalinter#supported-linters
andreygrehov 8y ago
> How you structure your code beyond the src/git/path/your-code/ is completely up to you and every repo you visit could be different. Erm...I'm confused. Why on earth every repo should have the same structure? I mean, I understand when you use a framework that prescribes you a layout, but even so, good frameworks try not to get into developer's way. Why the source code of a webapp should have the same structure as a, say, database? There were quite a few comments about standard project layout - I'm sure there is something similar for every language, but these things are just recommendations. And thank god they are not rules. Am I missing something here?
- oblio 8y ago
  Yes. Having a common overall structure is good. When I open a Maven project, the Java sources are always (99,99% of the time) in src/main/java, the resources are in /src/main/resources, the Java test sources are in src/test/java, etc. Every project has to have source code, every project could have resources. Every project could have test sources, etc.

triodan 8y ago

Thank God, finally a proper "Getting Started" guide for Go Modules. The official docs and wiki page always felt so obtuse and unhelpful about how to actually use the feature, while dep at least offers the obvious "dep init then dep ensure and you'll be fine" solution.

shaklee3 8y ago

This site needs better formatting. It looks like the author has section titles, but they're the same font and style as the body.

valtism 8y ago
Also, the text being set at alpha of 0.5 makes it very low contrast and difficult to read, even as a nearly fully sighted person.
roryokane 8y ago
The section titles look different from the body text for me, on macOS 10.13 in both Firefox 63 and Chrome 70. Either the site was fixed or your browser is broken.

jfolkins 8y ago

Please understand that if you vendor your dependencies inside your go.mod project, you own them and will need to support and audit them in the future. The mod command does not vet any computed hashes of the dependencies found in your vendor directory.

cyphar 8y ago
Though of course if you don't use "go mod vendor" then "go build" will require an internet connection, which is a problem for most distributions (package builds generally don't have an internet connection).
- jfolkins 8y ago
  Why aren't your go build tools pulling from the GOPATH/pkg/mod/cache directory? This would alleviate the need for your build to have a internet connection no?
  - cyphar 8y ago
    Fresh builds (in an "rpmbuild" for instance) don't use a cache, for obvious reasons.
drvd 8y ago
Running "go mod vendor" just populates the vendor folder which allows local development with all tooling. It does not force you to check in the vendor folder (you can even .gitignore vendor). Doing "go mod vendor" is not the typical "vendor", it does not make you the owner and you do not need to support and audit these packages (unless you actually vendor them in the sense of check them in).
jerf 8y ago
You own your dependencies and will need to support and audit them in the future. Note the lack of conditions on that statement, up to and including the fact this statement isn't even about Go, nor is it even about open source! It is simply a fact. You own your dependencies and you need to support and audit them. You are free to support and audit them by not supporting them at all, not auditing them at all, and blindly pulling in whatever random mutations they may go through in the future. You own the consequences of such terrible support. You own the consequences of good support.

maddyboo 8y ago

Something which isn't mentioned here and is difficult to find precise information even in the official docs is how versioning works - specifically, how do you specify what version your module is? Semver is mentioned, but not how to define your version. The short answer is to use git tags. You need to include the `v`, e.g. `v1.2.3`. If you don't use git, I don't know the answer.

gcb0 8y ago
versions? 2018 is the year of the evergreen module dependency injection!
- alexandernst 8y ago
  Absolutely stupid... I don't want my poduction pipeline to be injecting evergreenshittery I haven't revised/tested.
  - bpizzi 8y ago
    Not sure if you were being sarcastic... But this is exactly what 'go mod' is NOT doing. It's called 'Minimal Version Selection'. Quoted right from the lead core dev's blog: ' For stable development, today's build list must also be tomorrow's build list.' (https://research.swtch.com/vgo-mvs https://research.swtch.com/vgo-mvs). From what I gathered, 'go mod' is the first mainstream tool which is going that way (but I would be glad to be proved wrong!). Other package manager are using lock files which have their caveats (see https://research.swtch.com/cargo-newest.html https://research.swtch.com/cargo-newest.html for an in depth examination of the revered cargo approach on low-fidelity builds).
    - greysteil 8y ago
      The version resolution algorithm is very similar to NuGet's "lowest applicable version" logic, which has been around since 2010. I've seen surprisingly little discussion of the fact they're so similar. https://docs.microsoft.com/en-us/nuget/consume-packages/dependency-resolution#dependency-resolution-rules https://docs.microsoft.com/en-us/nuget/consume-packages/depe...

giancarlostoro 8y ago

After half a decade of not touching Go I went back to learning it. This was the one thing tripping me up. Not because I didnt understand it but because I cant even compile or pull in packages without defining some compiler variable flag witchcraft. I miss how simpler Go was. The compiler UX there really needs more TLC. Otherwise I still love what I loved about Go: a really incredible out of the box standard library which I highly attribute to Go's success since it allowed people to hit the ground running with Go much quicker.

yesimahuman 8y ago
Was it ever easy? I remember hours trying to figure out what to set GOPATH and GOHOME to and how to get “go get” to actually work. I can’t help but think go is a wonderful language with a poor package manager unfortunately woven directly into the language. Really makes npm feel wonderful in comparison.
- deleted 8y ago
  [deleted]
- anonfunction 8y ago
  I found it quite easy to set two environment variables and never had issues with `go get` either.
  - nvarsj 8y ago
    "go get" is a disaster for any project of non trivial size. It was designed with the idea of a mono repo in mind - not a vast distributed network of independently evolving code repositories.
    - sethammons 8y ago
      Never had any issues with that as soon as vendoring was an option. I routinely had/have three or more different non-trivial projects I was/am working on, and I dont recall ever having issues with go get. I started around maybe Go1.2. At first, I set GOPATH per project, but as soon as vendoring was a thing, one GOPATH to rule them all. Now, vendor updates to existing dependencies, there is something that has been a complete and utter disaster that hopefully gets better under the mod system.

teknologist 8y ago

Go newb here but I personally found it easy to get started with Go Modules and migrate over a fairly large project using Dep. `go mod init` was very helpful here in picking up the Gopkg.toml and doing the magic to make it all work. No complaints at all.

raverbashing 8y ago

Thank you. Go Modules seems to suffer the same disease as emacs where people trying to explain it go on and on without getting to the point.

stubish 8y ago

For projects with all dependencies hosted on github. I still need to work out if I can use the new tooling with our internal repos. I imagine I'll need to be editing that go.mod file.

josteink 8y ago
So not only are modules tightly coupled to a specific version control system (git), it’s also tied to a single centralized online service of this decentralized VCS. Maybe I’m just old fashioned, but to me this is a code smell. It reeks of needless coupling, and I suspect one day (sooner rather than later) the golang designers will come to regret it. To top it off, despite being tied to a VCS, it seems to lack a useful means of enforcing versioned dependencies. This simply does not look like a good design. Is this really the new and improved version? If so, how god awfully bad was the previous iteration?
- cube2222 8y ago
  I had no problems using it with self hosted gitlab.
- jchw 8y ago
  It is not tied to Git nor GitHub.
  - e12e 8y ago
    So when you're building on a host without internet access, the "github.com" namespacing isn't an issue?
    - jchw 8y ago
      Depends. If you use vendoring, which is supported by Go modules, then you should be able to avoid needing any internet access. If you want to grab the dependencies fresh, then obviously if you have a github dependency, it will require git and the ability to access GitHub.com.
    - deleted 8y ago

whizzkid 8y ago

Golang's not being an opinionated software is the main reason I was not able to passionately start learning this software. Most of the engineers have a bit of a picture in their mind when it comes to implement a specific function. But when the question comes "what is the best way of implementing it in Golang?" then unfortunately the answer is "Do as you want". This prevents me learning the power of language from the beginning. Being opinionated is about onboarding people with the best experience from the experts of the language, then let people overwrite or choose their own way of doing things when they know what they are doing.

pjmlp 8y ago
Having learned to code in a time and age where being opinionated wasn't a thing, opinionated languages feel like golden cages.
bpizzi 8y ago
> Golang's not being an opinionated software [...] "what is the best way of implementing it in Golang?" then unfortunately the answer is "Do as you want". I'm really not sure. Idiomatic Go is something well covered. Gofmt is ensuring consistent formatting. The official docs have an entry dedicated to this: https://golang.org/doc/effective_go.html https://golang.org/doc/effective_go.html. And what would be an opinionated language if Golang is not?
- kenhwang 8y ago
  Rust comes to mind. Almost all projects fetch dependencies and build the same way (cargo), with very similar looking project structures and entry point. The community has rallied around a set of libraries that's used by everyone. I couldn't care less about formatting differences between repos. Ignoring superficial formatting difference, Ruby's community also has one package manager (bundler) and build tool (rake) with a widely followed naming convention and directory structure and community consensus set of libraries. Both the above languages I can build a codebase I've never seen before and have it running within minutes even without README. Go feels like the wild wild west. Everyone has their own directory structure, with different ways of fetching dependencies (modules vs dep), building (seems to have consolidated around go build vs make), with everything hand rolled or whatever NIH selection criteria they used for their libraries.

bpizzi 8y ago

> Unfortunately, a quick guide like this doesn’t seem to exist, so I’m writing one here. You’re welcome. Well, `go help modules` is a good combination of exhaustiveness and conciseness, IMHO.

kishansh 8y ago

Do add the awesome "go mod tidy" command to your blog :-) This removes unused modules and adds missing ones.

ra7 8y ago

A more detailed intro to Go Modules: https://roberto.selbach.ca/intro-to-go-modules/ https://roberto.selbach.ca/intro-to-go-modules/

merb 8y ago

actually > go get -u ./... should probably be > go mod tidy

jonathanstrange 8y ago

One question not answered in this article is whether I will need to use modules in the future or not. I'm perfectly fine with not using them, but I've heard conflicting information about the future roadmap. If I have to use them later, I'd rather switch now, but if I don't have to switch even in 10 years from now, then I'd prefer not to switch to modules at all. Does anyone know more about this?

shanev 8y ago

Today I had to write some deployment scripts and the value of a fixed GOPATH really dawned on me. No matter which machine I use, I always know my code will be at GOPATH/src/... I didn't have to fiddle with any paths or env vars in my scripts. It made my day easier. This is an example of something that seems like a good practice only after you've gotten some gray in your beard.

rauhl 8y ago
Yup, that’s been my own experience too. I’ve really come to appreciate the virtue of GOPATH, and I honestly don’t understand the complaints about it. Why wouldn’t one want all of one’s code in a single place? What’s wrong with organisation? If one needs to work with different versions, then that’s what version control is for, isn’t it? Obviously I’m missing something, because my opinion seems to be in the minority. I wonder if it’s because most people are using GUI file managers, which make using directories of code more difficult, while I use emacs and the shell, and so can comfortably manipulate files & directories at scale.
- _rs 8y ago
  Because different projects need different versions of their dependencies. Do I need a separate GOPATH for each of these projects? I haven't wrangled Go enough to know the right answer to that yet. In my experience with other languages: I'd really prefer to have the dependencies local to the project and not in some global folder that affects all of my projects. I want to be able to make a random project folder anywhere and have the entire thing be self-contained without worrying about anything outside of that folder.
  - wbl 8y ago
    That's what vendor and modules are for.
kerng 8y ago
These global predefined rules lead to long term (several years later) problems. I prefer it when things are configurable and flexible and a technology doesnt try to be the center of the universe. Think of versioning and running multiple versions on same machine. Its like Microsoft with their dll hell. One has to come up with some (undefined, no guidance or built in solution available) way to do it.

astockwell 8y ago

Is there a decent convention for naming your specifically-for-deps module? ‘go mod init vendored’?

SamWhited 8y ago
You should probably still be using a full module init path (eg. myrepos.example.com/mymodule) to make it go get compatible, and regardless of whether it will only be a dep for a single project or not, the name should be descriptive of what's in the module or package. Having a module that's "specifically for deps" sounds wrong to me in general, but without knowing what you're actually doing that is harder to give advise on.

dana321 8y ago

Two commands: go mod init mymodulename go build This will download all the dependencies needed automatically. You can also do this (from scratch as well): go mod init mymodulename go run main.go And it will still download the dependencies. If you use a modulename like github.com/dana321/test you can include a subfolder of your project by importing github.com/dana321/test/mysubfolder for example If you bring down the wrong version (ie. an older) version of a module, just edit the go.mod file and modify the version (after the space where the url is) and change it to master on the line where the module is. When you next run go build or go run it will re-download and re-populate the line(s) you've changed in go.mod with the latest version. There really isn't much else you need to know!

kasey_junk 8y ago
There is if you want to vendor your dependencies, which given my experience with golang dependency management over the years, I’ll be doing for the foreseeable future. This guide outlines the set of incantations required to accomplish that & frankly having fought through figuring it out myself from the doco, this would have saved me a bunch of time.

SaulOfTheJungle 8y ago

I am new to Go and I want to start a new project. In which cases should I adopt modules versus just sticking with $GOPATH?

SamWhited 8y ago
Everything is moving to Go modules; unless you need compatibility with legacy tools I'd start updating and go ahead and use modules whenever possible. It will make your life easier in the future when you have to transition fewer things.

laurent123456 8y ago

There should be a website like "justtellmehow.com" with useful articles like this. I found that lib and tool documentations written by their authors tend be to be too long. It's understandable since they are passionate about the subject and want to talk about every details, but it's not great when you just want to quickly add a lib to your project or use some tool.

SlowRobotAhead 8y ago
This can of course go beyond programming. But, yes, there is a major lack in CS and CE of relaying on the INTENT. - I can see the datasheet where this micro has 32 message objects and a FIFO mode - but please tell me how you INTENDED it to be used because after weeks of figuring out the obscure memory and buffer system it turns out you never INTENDED a fifo rollover. Ok, that would have been excellent info on Day1. - Your framework has a couple of examples and each function is documented. Great, but imagine my surprise when it turns out I can’t access a ‘global’ memory object outside of your function because you never intended that to happen - and never thought to let me know. - This is the entire concept of a WHY comment vs a WHAT comment. Don’t write //increments X+1 instead use //counter ticked here because new value is used during the loop, must be placed at the top, uint8 / rolls at 256 for an x++ example. WHY comments made a big difference in the readability of my code. The goal is to relay intent. The thing is, you don’t want to rigidly be stuck to someone else’s idea - but it’s extremely helpful to know how they planned for you use this because maybe the choices they made do make sense. Oh use an array of this memory type instead of casting it all to a class/structure! Yea, that’s fine and will be more efficient to search through etc etc. I don’t need know why but engineers are really bad at telling you what they intended when making the product.
danesparza 8y ago
For using Go specifically, there is https://gobyexample.com/ https://gobyexample.com/ which I have found to be a huge help. I'm not sure that's exactly what you're talking about, though.
kiliantics 8y ago
The title reminded me of the "explain deleuze to me" meme: https://twitter.com/helm_ll/status/991045671133351936 https://twitter.com/helm_ll/status/991045671133351936

vorpalhex 8y ago

Thanks for writing this! I just picked up go again after several months and I had to read the formal guide a few times to correctly figure out how to use modules. I do like the new modules system so far though!