Notes from GopherCon "kick off" sessions

[Paul Jolly]

https://docs.google.com/document/d/1lB49VLzDrRd3wbXP1uLf-bHQyJRmH_Dc36JeEBlK-1Q/edit#

For those who were unable to make GopherCon 2018, I’ll provide a bit of background as to how theses sessions came about. Apologies for the length and format of this document; it’s tricky trying to cater for the varying levels of context that people will have, from those here at GopherCon that I’ve spoken to at length, to those who unfortunately couldn’t be here and might be seeing this for the first time.

I went along to Monday’s Go Contributor Summit with the hope of having a session where we could discuss go modules tooling and editor/IDE support. Then Marcel, Ian and Robert rained on my parade :)

But I got chatting to Ian Cottrell about go/packages, tooling, editor/IDE support for Go amongst other things, and thought it would be useful to gather interested parties at GopherCon to talk about all of these topics in the context of Go modules, but also generally where things are heading.

I did a best-efforts job of gathering a list of folks I thought would be interested in such a session. I also augmented that list with folks I know would also be interested but were unfortunately not at GopherCon. These notes are being shared with that wider, all-encompassing list, a list that is now defined by membership of https://groups.google.com/forum/#!forum/golang-tools. All are welcome and should just join that list.

Any errors/omissions/etc with anything in the doc, please comment as appropriate and I’ll fix things up.

Thanks,

Paul

[Dmitri Shuralyov]

Thank you Paul for starting this and for sharing the notes. I’m very glad to see this, it’s incredibly useful. Thanks everyone who is involved.

(Unfortunately I couldn’t join in person because of pressing prior commitments.)

Dmitri

--
You received this message because you are subscribed to the Google Groups "golang-tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-tools...@googlegroups.com.
To post to this group, send email to golang...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-tools/c8f409cf-4df6-4e02-b72c-eeefbaaa9797%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nate Finch]

Really glad to see this. Somehow I missed this going on at Gophercon.  While speed is always an issue, as is go modules support, one thing I'd really like to see the team do is make it easier to write tools that inspect the code.  

Right now, it's exceedingly hairy due to the way the code inspection packages are laid out... and god help you if you don't have an example tool to crib from.  

Using go/types and go/ast is an exercise in printf debugging and repeated casting and hoping you don't miss any edge cases. And for all your efforts, you end up with this glorious mess:

    for _, t := range p.Types {

        for _, s := range t.Decl.Specs {

            if id, ok := s.(*ast.TypeSpec); ok {

                if sel, ok := id.Type.(*ast.SelectorExpr); ok {

                    if ident, ok := sel.X.(*ast.Ident); ok {

Maybe this is unavoidable with Go's poor support for dynamic data... and maybe the new x/tools/go/packages will simplify the UX for setting up code inspection (I hope so).

But I think it's important to think about. How many great linters and tools are out there that never made it into reality because it was too difficult to go from idea to execution? I know I have several ideas that I have wanted to implement, but the difficulty of actually getting working code was too high (and I've written multiple code-inspection tools in my career already).

Another thing I'd like to see from this group is blog posts about how to write these things, best practices, gotchas, etc.  

We all know the tooling is half of what makes Go so great.. let's encourage people to write more of those.

[Ian Cottrell]

The new packages API definitely makes it easier to get the types and AST data, but it does nothing to make it easier to work with that data.

We have a prototype for a higher level API, and are exploring what the lint and vet tools would look like in terms of that package. If it works out, it will make writing most code analysis tools much easier, removing all the framework code you normally have to write. It will still require you to understand and use the types and AST correctly though.

Without re-writing the ast and types package there is a natural limit to how nice we can make it. Note that packages like astutil smooth over some of the ugly edges, we could possibly add more helpers in packages like that if you have concrete examples of common tasks that take way too much code.

--

You received this message because you are subscribed to the Google Groups "golang-tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-tools...@googlegroups.com.
To post to this group, send email to golang...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-tools/d7bb8241-5d14-48c7-be3a-e30b9a728e76%40googlegroups.com.

[Marwan Sulaiman]

Ian,

Is the packages API still "not ready for widespread use"? This is what the docs still say but I got the sense at GopherCon that it's mature enough at this point. 

go/packages has been a much easier way to build a Go tool for myself (combined with astutil). See  https://github.com/marwan-at-work/mod for an example of a use case. 

In that sense, I believe packages should have better documentation in all the use cases that it can cover. 

For example I didn't know how one can get the local path on disk of an *ast.File without having to ask the Go Team and the answer is not easy to figure out on your own: https://github.com/marwan-at-work/mod/blob/master/major/major.go#L138

Therefore, I encourage people to share their use cases and we can help with documentation in that way. 

But if there's an even higher level abstraction that makes it easier to build tools, then I am very excited to see that! And maybe it's worth putting a note in the go/packages docs that this is a low level API and we should use whatever abstraction you guys are building instead. 

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-tools/CAA%3DsxTib9KRniN%2Bwh-rmvhPdQMrDmpVynaudfzHXSQtdDQgTxA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Marwan Sulaiman

Software Developer

Mobile: 203-722-5772

[Fatih Arslan]

Thanks, Paul for the notes. Much appreciated. 

I added some comments to the document. 

--

You received this message because you are subscribed to the Google Groups "golang-tools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-tools...@googlegroups.com.
To post to this group, send email to golang...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-tools/c8f409cf-4df6-4e02-b72c-eeefbaaa9797%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Fatih Arslan

[Paul Jolly]

Hi Nate,

> Really glad to see this. Somehow I missed this going on at Gophercon.

Mea culpa, as I point out in more detail in the preamble to the
session notes. It was very much an ad hoc thing to be honest with you
that rather snow-balled. The incompleteness of the invite list was
entirely my fault though, apologies you (and probably others) got
missed off.

Good to meet briefly at GopherCon nonetheless!

Thanks,


Paul