Things which may be of interest in Go v1.4

Katherine Cox-Buday katherine.cox-buday at canonical.com
Thu Dec 11 21:04:47 UTC 2014


Good point Gustavo; generating code was all doable before Go v1.4, go
generate just bakes it into the development process.

Can either of you go into some detail as to why you don't like code
generation?

To start off, a thought experiment: if I were to generate a new Set type
for my Foo struct, how would you know I didn't write it by hand?


On Thu, Dec 11, 2014 at 1:33 PM, Tim Penhey <tim.penhey at canonical.com>
wrote:

> I also couldn't help but read through the release notes of Go 1.4 last
> night.
>
> I agree with Gustavo that we should avoid code generation unless
> absolutely necessary.  I have a strong feeling that it won't be
> necessary given how far we have come without it.
>
> I did like the internal packages, however these are only enforced in the
> Go standard library with 1.4, and other packages with 1.5.  Still a good
> idea though.
>
> Tim
>
> On 12/12/14 06:56, Gustavo Niemeyer wrote:
> > Thanks for the write up Katherine, and I agree these are all very nice
> > improvements.
> >
> > On this list, the one I find slightly less exciting is "go generate".
> > This is essentially a standard way to run external processing tools,
> > which might already be done before anyway via standard practices. For
> > example, the gl package in Go QML was already being generated via a
> > Makefile before, and it's nice that we can now give a hint about how to
> > re-build the generated sources, but it's a nice convenience rather than
> > an enabler.
> >
> > I'm also slightly worried about all the excitement that has surfaced in
> > the community with "go generate". Generating code is very useful and
> > powerful, but comes with a price (debugging, readability, etc). I'd
> > rather NOT generate code whenever possible.
> >
> >
> >
> > On Thu Dec 11 2014 at 2:21:20 PM Katherine Cox-Buday
> > <katherine.cox-buday at canonical.com
> > <mailto:katherine.cox-buday at canonical.com>> wrote:
> >
> >     Hey All,
> >
> >     I just got done reading through the Go v1.4 release-notes[1], and
> >     these are some high-level thoughts about what pieces may be of
> >     interest to Juju development. This is certainly not comprehensive,
> >     but I thought you all might be interested. Happy release day :)
> >
> >       * *go generate
> >         *https://golang.org/doc/go1.4#gogenerate
> >         This is *very* powerful and could reduce the number of
> >         copy/paste snippets, or unsafe reflection code we have to write.
> >         For those of you who are familiar with the lisps, this is
> >         essentially macros. You write code that examines Go expressions
> >         and does something. This code is triggered by ///go:generate
> >         command arg/ comments in the code. As a quick example, our
> >         StringSet type could be generated and even expanded to encompass
> >         any type.
> >       * *New func TestMain(m *testing.M)
> >         *https://golang.org/pkg/testing/#MainStart
> >         Since we use gocheck and gocheck requires you to register the
> >         testing subsystem, this now looks like the best place to do
> >         this. Without this, you can run into difficult to debug behavior
> >         when filtering to certain subsets of tests, or duplication of
> >         registration.
> >       * *Canonical Import Paths*
> >         https://golang.org/doc/go1.4#canonicalimports
> >         This helps out when using the gopkg.in <http://gopkg.in>
> >         pattern. For libraries that are specific to Juju, we may want to
> >         specify this to help enforce the notion that we want to use
> >         gopkg.in <http://gopkg.in> and not github.com/*
> >         <http://github.com/*> or launchpad.net/* <http://launchpad.net/*
> >.
> >       * *Internal Packages*
> >         https://golang.org/doc/go1.4#internalpackages
> >         Just what it sounds like. We can now hide implementation details
> >         from importers. Probably more useful for the ancillary Juju
> >         packages as Juju Core is probably not imported very much.
> >
> >     -
> >     Katherine
> >
> >     [1] https://golang.org/doc/go1.4
> >     --
> >     Juju-dev mailing list
> >     Juju-dev at lists.ubuntu.com <mailto:Juju-dev at lists.ubuntu.com>
> >     Modify settings or unsubscribe at:
> >     https://lists.ubuntu.com/__mailman/listinfo/juju-dev
> >     <https://lists.ubuntu.com/mailman/listinfo/juju-dev>
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20141211/39cbb321/attachment.html>


More information about the Juju-dev mailing list