[ANN] go-librato and go-metrics - golang-nuts

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion [ANN] go-librato and go-metrics
Received-SPF: pass (google.com: domain of rogpe...@gmail.com designates 209.85.216.41 as permitted sender) client-ip=209.85.216.41;
MIME-Version: 1.0
In-Reply-To: <CANLtmk35EvkcuWDqpYrMOahpN+d5cCvhspsLFLJ2Ja5k7Zg0WA@mail.gmail.com>
References: <CANLtmk19+mquvm5egCp6aH6McnjhPJ3ZqJ+keixg=eaM--v...@mail.gmail.com>
	<CAJhgaciC+BtpsM2-cEoweHuqwSidmCmQaQ4fF=4AEvMSCTf...@mail.gmail.com>
	<CANLtmk35EvkcuWDqpYrMOahpN+d5cCvhspsLFLJ2Ja5k7Zg...@mail.gmail.com>
Date: Wed, 23 Nov 2011 12:38:29 +0000
Message-ID: <CAJhgaciCk5rt=YjKR7e5+ek=vLUZ5-Pi=76w7WFKhZ+NBPx...@mail.gmail.com>
Subject: Re: [go-nuts] [ANN] go-librato and go-metrics
From: roger peppe <rogpe...@gmail.com>
To: Richard Crowley <r...@rcrowley.org>
Cc: golang-nuts <golang-nuts@googlegroups.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 23 November 2011 05:46, Richard Crowley <r...@rcrowley.org> wrote:
> Thanks for all your comments, Roger! =C2=A0See answers inline:
>
>> Hi Richard,
>>
>> I've just had a very brief glance at your metrics package - I just
>> did goinstall github.com/codahale/metrics then godoc.
>> So these comments are a very shallow first reaction to
>> the API - please take with a pinch of salt.
>>
>> - There are no doc comments on any of the functions.
>> All exported functions and types should have some documentation.
>
> Caught me. =C2=A0I've added most of them.

cool.
point of information: function and type comments in Go
are conventionally written as complete sentences.
for instance "CaptureRuntimeMemStats captures new values for..."
rather than "Captures new values for...".

>> - it seems that Log and Syslog do very similar things and could
>> probably be merged (the disparity between log and log/syslog
>> doesn't make this very easy though, I agree).
>
> They are very similar in structure, yes, but the log format and API
> are different. =C2=A0This isn't a dig on Go but sometimes it's just easie=
r
> to almost duplicate code.

i agree that it's easier sometimes, but in this case it's fairly
trivial to make them both use the same code.
for example: http://paste.ubuntu.com/746937/

>> - in quite a few places you return interfaces, and it's not
>> obvious that it wouldn't be just fine to use static types instead
>> (for example Registry, Healthcheck, Timer)
>
> All of these were conscious decisions. =C2=A0Many objects in many program=
s
> have (some metric)-like behavior which I want to allow registering as
> metrics.

i see that there are some useful interfaces there - i'm not saying
that you don't want to define interfaces for the things passed
into Registry for example. but i think that things would
be more obvious if the New functions returned statically defined
types - for instance if NewRegistry returned *StandardRegistry
rather than the interface.

i wonder what kind of advantage you're seeing to having
Registry, in particular, as an interface. as it is, it's just
a repository for information. what other kinds of Registries
do you see being useful?

in fact, thinking about this a bit more, i am not sure that
i see how it is advantageous to have the Registry hold
all those specific types.

it seems to me that the only thing all those kinds of things
that can be registered need to have in common is the
ability to print their information to a log.
why not just something like this:

type Logger interface {
     Log(printf func(string, ...interface{}))
}

type Registry struct {
    mu sync.Mutex
    stats map[string] Logger
}

func (r *Registry) Register(name string, stat Logger)
func (r *Registry) Unregister(name string)
func (r *Registry) Get(name string) Logger
func (r *Registry) Each(func(Logger))

then each useful stats-related New function could just
return its static type (e.g. func NewHistogram()*StandardHistogram),
and if there are some useful interfaces in common they can be abstracted ou=
t
independently.

for example:

// writeHistograms writes SVG output to w for all the
// histograms registered with the Registry.
func writeHistograms(r *Registry, w io.Writer) {
    r.Each(func(l Logger) {
        if h, ok :=3D l.(Histogram); ok {
            p :=3D h.Percentile(...)
            // etc
        }
    }
}

by going this way you remove, i think, quite a lot of boilerplate
code without making things any harder to use or less general.
and interfaces are used in the way they work best - to express
commonalities of functionality.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
