5 ms·

So now that go has generics and modules, is there an up-to-date intro for writing cutting-edge Go code for people who are already pretty familiar with the older

by maxk42 5y ago

So now that go has generics and modules, is there an up-to-date intro for writing cutting-edge Go code for people who are already pretty familiar with the older styles?

makeworld 5y ago
I wrote a tutorial on Go Modules, hope it's helpful. https://www.makeworld.space/2020/11/go_modules.html https://www.makeworld.space/2020/11/go_modules.html Looking for a tutorial on generics myself.
mseepgood 5y ago
There is lots of tutorial-style documentation on modules: https://go.dev/doc/#developing-modules https://go.dev/doc/#developing-modules There is also a tutorial on generics: https://go.dev/doc/tutorial/generics https://go.dev/doc/tutorial/generics
- maxk42 5y ago
  I tried doing the modules tutorial a while back but had difficulty with the directory structure. At some point I think the "recommended" directory structure became mandatory and I don't think my personal dev environment ever quite lined-up with it. Perhaps I should wait another year then buy a book.
  - mseepgood 5y ago
    Modules don't require any particular directory structure, just a go.mod at the root of your project.
    - hamburglar 5y ago
      That’s “a particular directory structure” that conflicts with many already-existing projects. What if I have a mostly-java project that has a couple bits of go code buried in it that I want to use as modules? Break it up into multiple repos for no good reason? No single tool should be acting like it owns the root directory of my repo.
      - mseepgood 5y ago
        The root of the Go project with the go.mod file doesn't have to be the root of the repository.
        hamburglar 5y ago
        Doesn’t it? Is this new?
        mseepgood 5y ago
        As far as I know this was always possible since modules were introduced. You just have to prefix the version tags for Go with the subdirectory in the repo: "my/sub/directory/vX.Y.Z"
        hamburglar 5y ago
        I swear it didn’t always work this way, but I’m happy to be wrong.
        echlebek 5y ago
        The only difference is that you are expected to tag differently. For instance if you had reporoot/hello/go.mod, you would create tags like hello/v1.2.3
        deleted 5y ago
        [deleted]
        chrsig 5y ago
        For that matter, you can have multiple modules in a repository.
      - zemo 5y ago
        I hate this pattern too but there's not "no good reason", there's a specific reason why it's like this, and it's a conscious design choice. When you call `go get somedomain.com/whatever/thing`, what it does is makes an HTTP request to that URL, then looks for a `<meta>` tag on the page telling it where to download the module. Check out the source of any Go project on github and you'll find the relevant `<meta name=go-import ...>` tag. Here's the meta tag for the gorilla router, a common http routing library: <meta name="go-import" content="github.com/gorilla/mux git https://github.com/gorilla/mux.git"> The tool is designed so that you can serve modules directly from version control repositories, because the goals were to avoid having any central authority on modules. It turns out this is a huge win in terms of making it dramatically easy to empower people to release modules, AND a huge win for decentralization: if you can host a git repository, the git repository is the module source, and that's the entire system. Just use Go as normal and make a public github repo and it's automatically importable through `go get`. No central registry required. It's a tradeoff. In making it "one module per repo", it dramatically lowered the barrier to entry for producing modules that other people could adopt right away, but it requires that you have one module per repo, because the versioning scheme is based on tags having semver version strings in them. Could they have made it something like "a tag can specify a directory and a version"? Hahha, yeahhhhhhhhhhh probably. But they didn't. In any case, you can also serve modules out of a go module proxy directly, but then you have to set that up yourself. That would free you of the "one module per repo" thing, but now you don't get "a repo is automatically accessible as a Go module". You'd have to implement the Go module proxy protocol yourself. I'm ... doing this now in my spare time but it's not really ready to share yet. The protocol is actually super easy to implement. It's described here: https://go.dev/ref/mod#goproxy-protocol https://go.dev/ref/mod#goproxy-protocol
vlunkr 5y ago
While it's good to get up-to-date, I don't think anyone should go re-write code or radically change their programming style to use generics. There's no need to over-complicate things. Anywhere that you're either copy-pasting a bunch, or using code generation might be a good fit for generics.
- jcadam 5y ago
  Just you try not being up-to-date in a coding interview.
  - saagarjha 5y ago
    I’ve found out that it’s possible to be too up-to-date for some coding interviews.
    - dilyevsky 5y ago
      Lol so true, go a little overboard with fancy language features and people think you’re a cowboy coder
      - catillac 5y ago
        I was in an interview not long after format strings in Python came out (for example, print(f”Hello, {name}”) rather than print(“Hello, %s”, name)) and the interviewer thought I was confusing languages and features, asserted this fact strongly, and was pretty surprised when it worked, but I think overall I lost points because the interviewer lost face. C’est la vie.
        vlunkr 5y ago
        As a very casual Python user, I didn't know about that! that's great.
        _whiteCaps_ 5y ago

by maxk42 5y ago

So now that go has generics and modules, is there an up-to-date intro for writing cutting-edge Go code for people who are already pretty familiar with the older styles?

makeworld 5y ago

I wrote a tutorial on Go Modules, hope it's helpful. https://www.makeworld.space/2020/11/go_modules.html https://www.makeworld.space/2020/11/go_modules.html Looking for a tutorial on generics myself.

mseepgood 5y ago

There is lots of tutorial-style documentation on modules: https://go.dev/doc/#developing-modules https://go.dev/doc/#developing-modules There is also a tutorial on generics: https://go.dev/doc/tutorial/generics https://go.dev/doc/tutorial/generics

maxk42 5y ago
I tried doing the modules tutorial a while back but had difficulty with the directory structure. At some point I think the "recommended" directory structure became mandatory and I don't think my personal dev environment ever quite lined-up with it. Perhaps I should wait another year then buy a book.
- mseepgood 5y ago
  Modules don't require any particular directory structure, just a go.mod at the root of your project.
  - hamburglar 5y ago
    That’s “a particular directory structure” that conflicts with many already-existing projects. What if I have a mostly-java project that has a couple bits of go code buried in it that I want to use as modules? Break it up into multiple repos for no good reason? No single tool should be acting like it owns the root directory of my repo.
    - mseepgood 5y ago
      The root of the Go project with the go.mod file doesn't have to be the root of the repository.
      - hamburglar 5y ago
        Doesn’t it? Is this new?
        mseepgood 5y ago
        As far as I know this was always possible since modules were introduced. You just have to prefix the version tags for Go with the subdirectory in the repo: "my/sub/directory/vX.Y.Z"
        hamburglar 5y ago
        I swear it didn’t always work this way, but I’m happy to be wrong.
        echlebek 5y ago
        The only difference is that you are expected to tag differently. For instance if you had reporoot/hello/go.mod, you would create tags like hello/v1.2.3
        deleted 5y ago
        [deleted]
      - chrsig 5y ago
        For that matter, you can have multiple modules in a repository.
    - zemo 5y ago
      I hate this pattern too but there's not "no good reason", there's a specific reason why it's like this, and it's a conscious design choice. When you call `go get somedomain.com/whatever/thing`, what it does is makes an HTTP request to that URL, then looks for a `<meta>` tag on the page telling it where to download the module. Check out the source of any Go project on github and you'll find the relevant `<meta name=go-import ...>` tag. Here's the meta tag for the gorilla router, a common http routing library: <meta name="go-import" content="github.com/gorilla/mux git https://github.com/gorilla/mux.git"> The tool is designed so that you can serve modules directly from version control repositories, because the goals were to avoid having any central authority on modules. It turns out this is a huge win in terms of making it dramatically easy to empower people to release modules, AND a huge win for decentralization: if you can host a git repository, the git repository is the module source, and that's the entire system. Just use Go as normal and make a public github repo and it's automatically importable through `go get`. No central registry required. It's a tradeoff. In making it "one module per repo", it dramatically lowered the barrier to entry for producing modules that other people could adopt right away, but it requires that you have one module per repo, because the versioning scheme is based on tags having semver version strings in them. Could they have made it something like "a tag can specify a directory and a version"? Hahha, yeahhhhhhhhhhh probably. But they didn't. In any case, you can also serve modules out of a go module proxy directly, but then you have to set that up yourself. That would free you of the "one module per repo" thing, but now you don't get "a repo is automatically accessible as a Go module". You'd have to implement the Go module proxy protocol yourself. I'm ... doing this now in my spare time but it's not really ready to share yet. The protocol is actually super easy to implement. It's described here: https://go.dev/ref/mod#goproxy-protocol https://go.dev/ref/mod#goproxy-protocol

vlunkr 5y ago

While it's good to get up-to-date, I don't think anyone should go re-write code or radically change their programming style to use generics. There's no need to over-complicate things. Anywhere that you're either copy-pasting a bunch, or using code generation might be a good fit for generics.

jcadam 5y ago
Just you try not being up-to-date in a coding interview.
- saagarjha 5y ago
  I’ve found out that it’s possible to be too up-to-date for some coding interviews.
  - dilyevsky 5y ago
    Lol so true, go a little overboard with fancy language features and people think you’re a cowboy coder
    - catillac 5y ago
      I was in an interview not long after format strings in Python came out (for example, print(f”Hello, {name}”) rather than print(“Hello, %s”, name)) and the interviewer thought I was confusing languages and features, asserted this fact strongly, and was pretty surprised when it worked, but I think overall I lost points because the interviewer lost face. C’est la vie.
      - vlunkr 5y ago
        As a very casual Python user, I didn't know about that! that's great.
        _whiteCaps_ 5y ago