Things which may be of interest in Go v1.4

Fri Dec 12 13:17:10 UTC 2014

On Thu Dec 11 2014 at 7:04:50 PM Katherine Cox-Buday <
katherine.cox-buday at canonical.com> wrote:

> 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?
>

It's not that I don't like it. Code generation is the only sane way to
solve some common problems, and as I mentioned I'm using it in gl, for
example, to avoid having to tweak a very large API surface across several
versions all by hand.

The reason I'm slightly worried about "go generate" is that people are too
excited for a feature that is basically just a way to run an external
command. That means we'll start to see solutions which lack a problem, such
as people using dozens of incompatible and slightly broken generics-like
implementations based on code generation because they missed the benefit of
not having them.

The reason we all came to Go dies if the community at large adopts
practices which corrupt too much the shape of the language like that.

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?
>

It's not about whether you wrote it by hand or not. It's about me having to
learn another language which is not Go or anything else I have ever seen to
understand how you've put your set in place so I can work with it, and when
you come see my code, you'll see I built my own set type too, with a
different macro language which you have never seen either, and have to
learn just so you understand and maintain my code.

Instead, what if we use this:

    s := make(map[Foo]bool)

That's pretty well understood, right?  It solved the problem with pretty
much no additional boilerplate every time I needed a set, and this is
generally inside a higher level construct rather than a "Set" type, with
richer operations than the trivial union/intersect/etc.

>
>
> 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/20141212/4738aeec/attachment.html>