►
From YouTube: 2020-07-23 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hey
everybody
welcome
to
the
meeting
we'll
probably
get
started
in
a
few
minutes
waiting
on
more
members
to
join,
but
please
open
up
the
attached
document
and
make
sure
to
add
yourself
to
the
attendees
list.
And
if
you
have
anything
you
want
to
talk
about,
even
if
it's
minor
or
massive,
please
add
it
to
the
agenda
as
well.
We'll
get
it
going
in
just
a
little.
B
A
I'm
liking
steve's
already
jumping
in
there.
A
Yeah,
I
guess
we
could
probably
get
started
so
one
of
the
can
you
all
hear
me
by
chance
to
stop
checking
yeah,
you're,
good
cool
yeah,
having
issues
with
my
ex
lately
so
kind
of
just
jumping
in
I
was
talking
with.
Who
was
I
talking
with
talking
with
some
aws
interns?
I
think
a
few
and
they've
been
working
on
a
cortex
exporter
and
they've
been
in
the
channel
a
little
bit
and
they
wanted
to
jump
in
today.
We
wanted
to
talk
a
little
bit
about
the
project
itself.
A
A
Otherwise
we
could
probably
hand
it
over.
I
don't
know
connor,
I
know
you're
on
the
call.
I
know
that
you
had
been
mentioned.
I
thought
there
was
somebody
else,
but
maybe
I'm
not
remembering.
D
Yeah,
I
don't
have
anything
specific
at
the
moment.
I
think
one
of
the
big
things
that
we're
looking
at
is
so
we're
planning
on
also
creating
a
collector
to
cortex
exporter,
and
we
were
running
into
some
issues
with
how
so
the
go.
Fck
already
does
the
processing
so
that
we
have
a
cumulative
aggregation,
which
is
what
prometheus
and
cortex
are
expecting
right,
but
that
isn't
implemented
currently
at
the
collector.
D
A
No,
that's
that's
fine
looks
like
josh
just
joined
as
well,
but
yeah.
If
you're
gonna
meet
up
with
josh,
I'm
sure
you
can
more
than
adequately
answer
your
questions
on
that
one.
It's
yeah,
I
think,
there's
definitely
multiple
approaches
to
that,
and
it's
something
that
we've
been
trying
to
work
on
in
the
metrics
world
for
quite
a
few
months
now
and
you're,
not
alone.
There's
also
people
like
me
who
work
in
the
relic
where
we
can't
take
any
cumulative
values.
We
need
deltas,
and
so
it's
a.
D
A
A
Me
up
no
worries,
so
the
people
have
been
reaching
out
about
the
cortex
exporter
design
at
their
building.
The
aws
interns
are
building
sorry.
A
Yeah
yeah,
so
just
kind
of
yeah
there's
a
lot
of
names
more
than
I
think
they're
in
the
beauty.
But
yes,
the
design,
I
think,
is
kind
of
one
of
the
things
that
we're
looking
for
feedback
and
guidance
on,
and
I
had
said
absolutely,
and
so
I
don't
know
if
we're
just
kind
of
jumping
into
that
it
sounds
like
later
this
afternoon,
josh
you
were
going
to
meet
with
connor
to
talk
more
about
some
of
the
the
details
of
converting
to
cumulatives.
E
Yeah
I've
been
meeting
with
alolita's
group,
including
conor
and
yang,
and
a
few
others
just
four,
I
believe,
and
so
I'm
planning
to
meet
them
later
today,
just
because
this
is
a
very
important
development.
I'm
also
planning
to
make
a
20-minute
section
of
the
the
metric
fig
in
an
hour
talk
about
this
topic.
So
maybe
we
shouldn't
do
that
here
and
just
to
just
to
because
it's
an
otlp
question:
it's
a
it's
a
metrics
infrastructure
question
more
than
it
is
a
go
question.
E
E
A
Yeah,
I
think
that's
probably
a
good
suggestion
cool.
I
don't
know
if
you
guys
wanted
anywhere
in
front.
Does
that
sound
good
to
you
all
on
the
aws
side,
yeah,
I'm
good
with
that:
okay,
cool
yeah!
So
just
moving
on
the
agenda's
pretty
light
today,
and
so
we'll
probably
get
out
of
here,
pretty
quick
make
sure
we
get
back
to
not
doing
this.
A
So
one
of
the
things
I've
noticed,
there's
been
a
few
pr's
in
the
contrib
repo
for
instrumentation
and
they're
fantastic,
adding
a
lot
of
really
great
instrumentation
across
a
lot
of
different
open
source
projects.
So
definitely
if
you've
submitted
one
of
those
and
you're
on
the
call.
Thank
you
very
much
for
doing
that.
That's
it's
been
awesome.
Seeing
that
and
the
added
support
means
that
the
adoption
vocabulary
is
definitely
going
to
be
great
once
we
do
have
a
general
release.
A
So
definitely
applause
goes
to
all
of
you
guys
for
sure,
and
one
of
the
outstanding
ones
was
for
go
cql
for
cassandra.
It's
a
little
bit
of
a
larger
pr
could
use
more
eyes
on
it.
I
think
reg
yeah
regis
on
the
call-
and
I
think
he's
the
one
that
submitted
that
I
don't
know
if
you
had
anything
you
wanted
to
say
about
that.
Oh.
F
No
thanks
for
the
shout
out,
tyler,
not
too
much.
I
I
didn't
realize
that
there
were
the
strict
naming
conventions.
That's
actually
totally
my
bad,
so
I'm
right
now
just
refactoring
to
make
sure
that
all
the
naming
convention
like
it
follows
that
doc
that
you
linked.
So
that
was
super
helpful.
I
did
want
to
ask
if
they
were,
they
were
the
same
naming
conventions
from
the
metrics,
because
I
would
like
to
just
kind
of
do
a
bulk.
F
Do
it
for
the
metrics
as
well
to
make
sure
it's
all
kind
of
and
like
integrated
with
them.
So.
A
Yeah,
that's
a
great
question
and
you're
finding
a
sore
point
of
failure
on
our
part
of
the
project.
We
wanted
to
make
sure
we
had
those
enemy
conventions
complete
before
you
guys
had
started,
but
we
haven't
and
so
they're
not.
However,
you
should,
if
you're
reading
the
doc,
you
should
probably
get
a
really
good
understanding
of
what
those
metric
naming
conventions
are
and
if
you
try
to
do
that,
there's
a
really
good
chance
that
what
you
do
will
become
the
metric
gaming
conventions,
because
it
will
be
a
nice
proof
of
concept.
A
A
Side
of
things,
but
I
think
if
you
try
to
match
that
and
there's
also
another
otep
that
was
just
recently
merged
about
metric
gaming
guidelines
itself,
it's
not
about
the
labels,
but
I
imagine
it
should
be.
Has
a
little
bit
about
the
labels
in
there.
I
can.
I
can
probably
link
that
to
you
as
well,
but
it's
I
think
that
if
you
follow
the
the
naming
guidelines
for
the
existing
attributes
for
spans,
you
should
you
should
do
just
to
find
jobs
for
the
labels.
F
A
F
Yeah,
thanks
for
the
comments,
learn
a.
E
Lot
a
related
question,
I
think,
is
again
not
a
go
specific
issue.
That's
going
to
come
up
in
the
next
hour.
This
metrics
take
about
error
status,
which
is
then
debated
heavily
recently
and
tracing
side
of
the
spec
here,
and
I
I
feel
like
we
have
there's
sort
of
a
idea
that
we
want
to
do
something
for
the
metrics
semantic
convention
that
would
be
different,
potentially
or
maybe
even
steer
that
conversation.
E
A
Issue
well
cool
yeah
and
for
other
people
on
the
call,
please
be
sure,
to
go
and
check
out
that
pr,
I
think,
the
more
eyes,
the
better
more
quality.
A
So
moving
on
to
the
last
thing,
I
kind
of
wanted
to
more
muse
about
these
sort
of
things,
and
so
I
was
wondering,
maybe
just
pause
for
a
second
and
make
sure
that
there's
nobody
else.
That
has
any
like
direct
actionable
thing,
tasks
that
we
need
to
address
in
the
project
before
we
move
on
to
the
next
one
cool
yeah.
So
after.
A
Yesterday,
last
week's
meeting
we
had
a
few
people
come.
D
A
Talk
a
little
bit
about
some
ideas
for
structural
redesign
and
just
some
feedback
in
general
about
the
ghostly
project
itself,
and
it
kind
of
got
me
thinking
about
some,
maybe
some
some
changes.
A
lot
of
the
things
that
were
addressed
are
in
a
google
doc
and
it
hasn't
been
released.
A
Yet
so
that's
something
that
I
think
we're
kind
of
still
waiting
on,
but
there
were
some
some
points
that
were
being
made
in
passing
it's
hard
to
tell
without
reading
a
lot
of
the
details
that
I
think
have
kind
of
been
long-standing
issues
that
people
have
kind
of
been
working
around.
So
maybe
it's
something
we
kind
of
want
to
talk
about,
they're
related
to
the
usability
of
the
actual
projects,
and
I
think
that
that's
probably
something
that
maybe
we
can.
I
just
wanted
here.
A
If
anybody
else
had
some
other
people
or
some
other
thoughts
on
it,
it
was
really
impactful
for
me.
I
would
think
about
it
a
lot
over
the
past
week
playing
around
with
some
prototyping,
but
nothing
concrete.
Yet
one
of
the
top-level
issues
that
came
to
mind
was
the
fact
that
we
also
recently
had
a
issue
that
came
in
and
asking
for
a
separation
of
the
sdk
for
the
api
package,
and
I
wanted
to
also
double
check
and
follow
up
on
that
because
I
think
josh
might
you
might
have
a
misunderstanding.
A
I
want
to
make
sure
that
we're
clear.
I
don't
think
that
issue
is
asking
for
two
separate
repositories.
I
think
it's
just
asking
for
the
packaging
so
having
two
different
go:
mods,
one
for
the
sdk
okay,.
A
Yeah
yeah,
and
so
for
the
people
that
weren't
on
the
call
the
idea
is,
is
that
if
you
import
the
hotel
api
now,
it
also
includes
the
sdk,
which
includes
things
like
the
grpc
library
and
a
bunch
of
other,
like
things
that
make
your
binaries
quite
large
for
projects
that
are
not
instrumented
to
actually
run
the
sdk,
like
that's
kind
of
an
issue
when
you're
bringing
all
that
baggage
in,
and
so
I
think
that
there
was
also
another
question
as
to
like
from
the
review.
A
Last
week
we
have
a
sub
package
called
api,
and
that
may
not
be
the
most
intuitive
to
new
people
to
the
project
is
to
ask
like
well,
if
I'm
using
open
telemetry,
why
is
there
an
api
and
like
how
do
I
find
the
api
sub
directory
out
of
the
whole
host
of
other
directories
and
how
do
I
find
from
there,
maybe
like
metrics
and
tracing
like
so
I
think
that
we
should
probably,
at
the
very
least,
have
I
think,
maybe
some
better
directions
as
we
go
towards
ga.
A
But
I
think
that
there
may
also
be
some
structural
things
that
we
could
probably
change.
I
know
at
the
top
level
we
have
an
opensource.go
file
itself
and
there's
a
aliasing
of
the
tracer
and
then
I
think
a
few
other
things,
but
it's
the
metric
meter
and
then
the
propagators,
but
it's
very
light,
and
so
I
was
kind
of
thinking
about.
A
If,
if
that's
something
we
wanted
to
try
to
move
more
towards
where
we
have
directly
the
api
at
the
top
layer,
which
means
all
of
the
interfaces
at
the
top
layer,
I
don't
know.
I
think
that
we've
had
a
lot
of
discussions
about
this
in
the
past,
but
I'm
not
remembering
all
of
them.
So
I
don't
know
if
anybody
had
any
thoughts
on
this.
G
I
I
wasn't
clear
because
I
haven't-
I
just
saw
this
document
for
the
first
time,
so
I
haven't
read
enough
of
it
yet
you
know.
Are
we
talking
about
trying
to
move
or
copy
a
bunch
of
types
into
this
api
package
so
that
that's
the
main
package
that
users
would
focus
on
introducing
more
like
a
tree
where
more
packages
would
sit
below
a
path
component
of
the
of
the
import
path
called
api.
A
It
keep
that
in
mind
was
that
the
api
package
itself,
the
directory
of
api,
is
misleading,
because
it's
in
a
sea
of
other
directories
pull
it
up.
Really
quick.
If
you
have
example,
exporter
instrumentation,
sdk
tools,
all
these
other
directories,
which
are
not
necessarily
the
most
intuitive
it
should
be.
A
I
think
pretty
obvious
once
you
understand
the
concepts
of
open
source,
but
the
thing
is
you
have
a
lot
of
people
that
are
going
to
start
wanting
to
instrument
their
code
and
they're
going
to
come
to
this
thing,
not
quite
understanding
that
open
source
entry
is
structured
with
an
api,
an
sdk
exporters,
processing
in
the
middle.
You
know
all
these
other,
like
components
free
and
what
they
really
want.
Is
they
just
want,
as
we've
seen
in
the
metrics
world?
A
They
just
want
their
counter
gauge
and
I
think
the
histogram
or
something
like
that
like
that's
all
they
want.
A
To
know
how
they
can
get
those
equivalents
right,
and
so
I
think
that
the
and
traces
right,
how
do
I
get
my
traces
started?
And
I
think
that
the
easier
we
can
make
it
discoverable
for
how
instrumenters
or
people
that
want
to
use
this
library
can
just
find
those
structures
or
those
those
objects.
I
think
the
more
intuitive
it
is
going
to
be
to
explain
to
people
making
things
like
the
sdk
and
the
api
equivalent
in
the
same
packages.
It
structures
it
in
a
way
and
the
exporters
in
the
same
packages.
A
It
doesn't
really
show
the
hierarchy
there
and
I'm
not
too
sure
it
needs
to
show
the
hierarchy,
but
I
think
that
it
needs
to
show
the
important
things
first.
I
I'm
I'm
wondering
if
we
could
better
do
that
by
bringing
the
api
itself
out
of
the
api
subdirectory
and
put
that
at
the
top
level.
I
think
is
the
idea
that
I've
had.
E
Yeah,
I
think
that
was
why
I
I
might
have
thought
or
taken
away
from
that
discussion
last
week
that
that
it
would
be
nice
to
just
have
the
api
in
its
own
repository,
because
then
it's
naturally
gonna
be
up
one
level
for
the
godoc
I
mean
the
primary
concern
was
the
godox
are
really
bad
here,
because
you're
gonna
dig
down
two
levels
before
you
get
to
any
useful
apis,
and
so
we
could
fix
that
by
putting
them
at
the
top
of
the
directory
structure,
and
I
think.
D
E
Probably
is
okay,
if
from
you
know,
jana
and
feedback
to
if
the
sdk
is
still
nested,
underneath
that
so
we
don't
have
to
split
the
repository.
A
Yeah,
that's
kind
of
what
I
was
thinking
I
think
like.
Maybe
in
a
world
where
we
could
just
make
repositories
willy-nilly
or
like
it
was
like
the
only
sdk
like
that
might
work,
but
I
think
that
yeah,
I
think
you
hit
the
nail
on
head
like.
I
don't
think
that
the
people
who
are
having
the
problem
or
the
discoverability
question
is
muddy.
A
A
Yeah,
it's
one
for
the
whole
repository.
That
was
the
initial
issue.
I
was
just
talking
about
to
start,
which
was
a
complaint.
I.
A
That
as
well,
I
think
the
sdk
needs
to
be
its
own.
Go
have
its
own
good
mod
file,
so
it
could
be
its
own
package.
G
Yeah
and
at
that
point,
there's
strong
strong
reasons
to
split
the
repository
because
having
them
having
more
than
one
module
coexist
in,
one
repository
gets
difficult
to
develop
against
both
of
them
together.
E
G
E
A
Did
that's
if
you
go
look
at
the
maker
file,
it
is
doing
exactly
that.
It's
just
trying
to
work
around
all
of
these
things
and
if
you
do
have
a
new
package,
that's
one
of
the
gotchas
is
because
yeah
all
of
the
exporters,
all
of
the
examples
those
are
all
of
their
own
packages.
Actually
so
they're
they're,
all
in
their
own,
go
mods
and
so
yeah.
You
are
correct.
It
does
add
layers
of
complication
that
we're
we've
built
some
tooling
around.
It's
not
perfect,
but
it's
it's.
It's
working
currently
yeah.
B
Yeah
I
was
saying
what
josh
says
that
we've
already
gotten
several
go
mods.
I'm
also
wondering
whether
at
least
perhaps
as
a
first
step,
hoisting,
the
global
package
out
of
api
up
to
the
top
level
might
be
useful,
because
that
provides
a
nice
set
of
entry
points
into
the
api.
That
could
be
a
good
stepping
stone
without
having
to
refactor
everything.
E
Although
that
was
one
of
the
names
that
was
targeted
by
the
feedback
as
being
too
general,
so
it
conflicts
with
other
packages
in
the
world
right.
E
The
hotel
that
that's
probably
true,
yeah
there
was
a
technicality
there
as
well,
though,
which
has
is
very
old
at
this
point.
But
if
you
wanted
to
go
the
global
package
to
automatically
load
an
sdk,
it
has
to
be
a
different
package
than
the
api
itself,
so
it
shouldn't
go
into
the
api.
It's
just
what
I'm
trying
to
say.
E
Well,
I
mean
this
is
sort
of
maybe
a
future
potential
that
I'm
trying
to
preserve
here,
but
early
on,
I
did
a
proof
of
concept
that
you
could
use
the
go:
plugin
module
or
what
plugin
package
to
load
some
code,
and
you
can
do
it
automatically
as
long
as
there's
a
different
package
between
the
api
and
that
kind
of
global.
E
So
and
this
and
this
what
this
would
result
in
is
to
load
the
sdk,
just
set
an
environment
variable
and
put
a
binary
somewhere
and
then,
whenever,
whenever
the
global
package
first
initializes,
it
will
go
and
find
an
implementation.
But
you
can't
do
that
if
you're
in
the
api
dependency
already,
you
have
to
have
separate
packages,
I'm
not
sure
if
I'd
explain
that
very
well.
In
other
words,
the
api
can't
auto
load
an
implementation
of
itself,
but
another
package
can
auto
load
an
implementation
of
the
api.
Oh
there's,
I
think.
E
Yeah
and
and
when
they
run
and
the
fact
that
you
and
and
this
can
be
disregarded
because
last
week,
gianna
said
that
nobody
should
ever
be
using
the
plug-in
package,
it's
not
used
or
developed
and
or
maintained,
which
is
unfortunate.
I
think
the
reason
it
does.
It
doesn't
work
on
windows
and
but
whatever
the
case
may
be,
it's
not
recommended,
and
so
this
is
not
really
a
viable
sort
of
path
forward.
Anyway,.
G
Was
the
idea
there
to
do
something
I've
I've
asked
liz
is
not
on,
but
I've
talked
about
this
in
the
past,
how
to
mimic
what
we're
used
to
from
things
like
jdbc,
where
you've
got
like
a
connection
string
that
nominates
a
driver
by
yeah.
It's
like
dependency
injection.
E
Go
doesn't
really
have
it
and
if
it
did
we'd
be
using
it
and
and
that,
basically,
if
you
want
the
dependency
injection
to
work,
you
need
a
separate
package
that
the
global
will
cause
dependencies
to
be
resolved
and
if,
if
you're
already
using
the
api,
it's
too
late
to
resolve
your
globals,
I
guess
what
I'm
trying
to
point
out,
but
yeah
you've
got
it.
It's
like
a
dependency
injection
problem,
if
only
go
have
better
dependency
injections.
E
E
A
Okay,
it
sounds
like
there
may
already
be.
I'm
gonna
look
a
little
bit
further
into
restructuring
moving
some
things
at
the
top
level.
I
think,
like
it's
a
really
good
point
to
make
that,
like
the
goal,
is
the
go
doc
needs
to
a
new
user
should
understand
how
to
use
the
library
when
they
first
come.
I
think
that's
really
critical
and
then
maybe
we
can
move
some
coding
objects
around,
but
maybe
it
just
is
about
the
docs
themselves
or
aliasing
or
something
that
we
can
address.
E
With
the
global
stuff,
we
have
added
some
helpers
in
the
past
week,
thanks
to
several
of
you
that
do
help.
That
was
one
of
the
pieces
of
feedback
that
we've
already
done,
something
about
the
last
one
that
sort
of
stuck
in
my
head
is
this
kv
package,
which
you
know
I
I
certainly
approved
the
change
because
it
was,
it
was
improving
the
situation
with
the
core
package,
but
I
don't
believe
kb
is
really
ideal.
It's
just
that
it
was
better
than
what
we
had.
E
So,
if
I
don't
know
like,
I
feel
like
this
is
the
sort
of
thing
where
you
need
to
sort
of
sit
in
a
quiet
place
and
actually
write
a
lot
of
code
that
uses
this
api
before
you
start
to
realize
what
the
names
ought
to
be.
That's
how
I
would
approach
it,
but
I
don't
have
that
time.
Right
now,.
G
Yeah,
I
think
my
impression
of
this
project
so
far
is
that
it's
very
granular
with
its
packages
so
that
so
the
package
names
appear
a
lot
in
your
code,
and
so
you
get
things
like
kv.string
makes,
makes
sense.
If
it
was
part
of
a
package
you
were
already
using,
you
might
expect
it
to
be
like
string
key
or
whatever
it
was
before
you
know,
but
we're
sort
of
borrowing
the
the
package
is
implying
something
about
the
name.
G
So
if
we
were
to
force
more
of
them
together
in
a
way
the
style
of
using
it
would
change,
you
know
the
style
of
the
code,
the
way
that
the
names
read,
but
so,
if
I
understand
it
correctly,
just
to
go
back
to
the
question
I
asked
before.
I
think
we're
not
necessarily
talking
about
taking
what
are
many
desperate
packages
right
now
and
combining
them,
but
rather
just
kind
of
moving
the
root
of
the
subtree.
That
starts
with
api
upward,
to
make
it
easier
to
find.
Is
that
correct,
so.
A
I
was
envisioning
and,
like
I
said,
like
it's
still
a
proof
of
concept
sort
of
thing,
so
I'm
more
looking
for
really
strong
objections.
I
don't
have
a
clear
direction
on
this
one,
but
I
was
thinking
not
the
entire
api
package
and
moving
it
up,
because
there
are
things
in
there
that
I
think
are
are
common
things
like
the
kv
package
or
something
like
that.
Like
I
don't
know
if
that
should
belong
in
the
top
level,
but
what
I
was.
A
Was
more
looking
at
the
specification
and
seeing
things
like
you
know,
you
have
a
tracer,
a
trace
provider
span
context
and
a
span
to
find
at
the
api
level,
like
maybe
those
those
interfaces
that
we
have
somewhere
deep
into
the
api
package.
Those
just
get
moved
to
the
top
level
package
itself
same
for
the
metrics,
like
maybe
they're,
just
metrics
should
be
up
there.
A
That
actually
gets
exposed,
like
are
those
aliases
that
are
wrapping
an
internal
interface.
Are
they
something?
That's?
Maybe
they
stay
in
the
api
package,
but
they
just
get.
You
know
alias
like
we
already
have
with
metric
or
the
tracer,
the
meter
and
the
provider
already
in
the
open
source
package,
like
I'm.
A
Looks
like
I
don't
think
that
taking
the
entire
api
package
and
just
deleting
the
folder
api
is
going
to
work.
I
mean,
I
know
it
won't
because
there's
still
a
trace
in
a
metric
subdirectory,
and
so
that's
you'd
still
have
the
discoverability
problem.
Where
it's
you
know
another
one
layer
deep
into
you
know.
I
don't
know
yeah.
G
Well,
I
understand
that
the
whole
point
of
this
the
set
of
packages
that
they're
supposed
to
not
have
much
in
the
way
of
implementation
in
them.
When
you
do
split
up
packages
into
little
pieces,
you
wind
up,
leaking
more
details
between
them,
because
we
don't
have
to
friend
packages
and
go.
You
know
it's
in
order
to
be
able
to
reach
across
them.
Sometimes
you
leak
things
that,
while
they
make
sense
within
the
api
itself,
you
really
didn't
intend
to
expose
them
to
outside
consumers.
A
Yeah,
I
think
that
was
another
point
that
was
in
that
doc.
I
I
didn't
realize
that
it
had
been
released,
so
I'm
super
excited,
I
think,
anthony
posted
the
link.
So
thanks
for
doing
that,
I
don't
know
how
he
found
it,
but
yeah
I'm
excited
that
was
evan,
oh
evan,
even
better.
Sorry,
yeah
thanks
for
posting
that
yeah,
I'm
really
excited
to
kind
of
read
through
that
again
but
yeah.
I
think
that
you
steve
you're
right
like
there's.
A
I
think,
there's
improvements
that
we
could
make
here
and
I
think
it's
it's
probably
late
in
the
game,
but
I
I
think
that
tomorrow's
worse
than
today
kind
of
thing,
so
I
kind
of
wanted
to
spend
some
time
thinking
about
it
now
and
then
the
last
thing
that
kind
of
came
to
mind
after
hearing
a
lot
of
that
feedback,
the
initial
was
our
exporters.
A
Right
now
are
defined
as
interfaces,
and
I
don't
know
I
wonder
I
I
had
a
conceptual
idea
of
the
fact
that
I
don't
in
go:
there's
really
good
concurrency
patterns
around
channels
and
they're,
pretty
solid,
actually
and
they're,
pretty
fast
and
they're
pretty
low
overhead.
Because
of
that-
and
I
think
they're
they're
even
doing
some
really
quick
benchmarking
they're
lower
overhead
than
a
lot
of
the
interface
design
that
we
have
like
if
you
were
just
to
pass
a
channel
instead
of
having
to
register
your
your
function
that
implements
an
interface.
A
I'm
sorry,
your
structure
that
implements
an
interface,
I
think,
if
that
might
actually,
I
think
it
would
be
more
idiomatic
of
go.
I
know
it's
not
in
it's.
It
would
be
contrary
to
the
specification.
The
specification
I've
also
read
is,
I
don't
think,
is
overspecified,
but
that's
kind
of
a
separate
point.
I
think
I'm
more
asking
the
question
like
idiomatically
and
go:
did
we
want
to
restructure
because
it
I'd
be
worth,
I
think,
pushing
this
back
up
to
the
spec
level
and
saying
like
hey
spec,
people
like
you
should
provide.
A
You
know,
guidance
on
functionality,
maybe
not
implementation
itself,
but
that's
kind
of
maybe
for
a
different
venue
for
that
discussion.
But
I
was
kind
of
wondering
what
people
thought
about
that,
because
steve
steve
sounds
like
a
question
around
this,
because
you
had
already
thought
about
something
like
this
yeah.
G
It
might
be
crossing
paths
or
this.
The
thing
that
I
brought
up
is
actually
not
not
related
to
the
concerns
that
you're
raising
separate
problem.
I
see
yeah,
okay,
so
go
ahead.
Sorry,
my
my
knee-jerk
response
without
seeing
a
proposed
change
is
just
that
we
we
hear
advice
frequently
that
says
that
keep
your
channels
out
of
your
interfaces
and
I
don't
mean
go
interfaces.
G
I
mean
out
of
the
boundaries
of
your
packages
and
such
because
the
moment
that
you
introduce
them,
they
raise
all
kinds
of
questions,
whether
they're
being
returned
or
consumed
about
you
know
who
closes
them
and
who
who
feeds
them
and
how
to
use
signal
when
you're
done
with
this,
and
it
introduces
a
whole
lot
of
implied
contract.
That
needs
to
be
documented.
G
So
I
know
that
it's
you
know
one
of
these
frequent
stories
of
like
you,
you
hear
about
channels,
you
get
excited
about
them.
You
start
using
them
all
over
the
place,
and
then
you
realize
wow.
This
is
totally
ambiguous.
There's
the
only
way
that
somebody
can
use
this
correctly
is
if
they
study
the
implementation
and
even
then
they
might
still
be
hamstrung.
G
E
G
There's
a
there's,
a
great
talk
by
brian
mills
from
about
two
and
a
half
years
ago,
it's
like
like
advanced
concurrency
patterns,
and
even
without
watching
the
talk
you
can
spend
some
time
with
his
pdf
slides
and
it's
like
120
pages
or
something,
but
he
shows
a
lot
of
nice
patterns
and
walks
through
some
of
these
problems
that
I'm
discussing.
I
don't
remember
right
now
how
how
well
he
tells
you
good
ways
to
work
around
them,
but
I
think
it's
it's
great
reading
on
the
subject.
A
Cool
yeah,
that's
really
great
feedback.
I
I
think
it's
I've
heard
very
similar
yeah.
I
think
josh
is
100
hitting
the
nail
on
the
head,
because
I
heard
the
same
complaints
about
people.
You
know
when
you
pass
interfaces.
You
know:
go
interfaces
as
your
boundary
to
your
program
as
well,
like
people
are
going
well.
A
How
do
you
handle
like
people
calling
this
in
weird
ways
like
how
do
you
guarantee
concurrency
across
those
calls,
which
I
think
is
a
its
own
can
of
worms?
And
maybe
it's
just
that
we've
chosen
our
own
can
of
worms
at
this
point
so
yeah.
Thanks
for
the
link,
I'm
gonna
read
through
that
that
looks.
Awesome
did.
A
G
A
A
Yeah,
that's
exactly
cool
yeah.
I
think
that
was
it
for
me
for
things
I
wanted
to
talk
about
today.
I
definitely
want
to
go
through
the
doc
as
well.
I
don't
know
if
evan
you
so
you
might
have
already
read
through
the
doc.
Is
there
anything
that
you
wanted
to
kind
of
bring
up
about
that,
or
are
you
just
unimpressed
in
general.
C
No,
no,
I
think
you've
actually
covered
quite
a
lot
of
it
because
I
think
you
remembered
it
from
when
they
talked
about
it.
Yes,
definitely
the
things
like
the
separation
of
the
api
from
the
sdk
is
another
thing
they
mentioned
there
again.
C
A
Well,
cool,
I
think,
we'll
pause
for
five
seconds.
If
anybody
has
had
other
agenda
items.
A
Cool
otherwise,
I
think
we
could
probably
end
it.
We
got
a
release
out
this
past
week
to
encapsulate
a
lot
of
the
changes.
Oh
that's
another
really
great
thanks
evan
for
taking
care
of
the
go
proto
generation
stuff
that
was
yeah,
definitely
complicated,
and
thanks
for
waiting
through
it.
I
really
appreciate
that
yeah.
C
I
I
really
really
really
appreciate
that.
Okay
thanks,
I
did
want
to
thank
steve,
though,
because
I
remember
stephen
talked
about
the
issues
with
gazelle
and
basil.
Once
you
have
those
generated,
maybe
steve
you,
and
I
can
talk
about
that
offline
sometime
about
whether
you
still
be
problems
with
ways
done.
G
C
Yeah
I
mean
I,
I
did
check
through
the
gazelle
stuff
and
I
saw
it
at
least
it
seemed
like
there
was
some
place
where
you
could
even
turn
off
the
auto
creation
of
the
pb.go
files
in
a
in
the
bazel
build
if
you
need
to
so
that
was
another
thing.
I
thought.
Okay.
E
I
was
doing
some
benchmarking
and
it
becomes
really
difficult
to
to
work
with
protocol
generated
files
whenever
you
want
more
than
one
of
them.
It
made
me
think
that
the
bazel
system
does
actually
allow
you
to
do
something.
Fancy
like
that
that'd
be
cool
like
compare
two
versions
of
a
protocol
that
have
the
same
name
because
you've
mapped
them.
I
think
that
I
think
it
can
do
that
never
mind,
maybe
maybe
not.
A
Well,
cool
thanks
everyone
for
joining.
I
think
that
we
probably
have
hit
all
the
agenda
items
if
you
have
anywhere,
please
make
sure
to
add
them
for
next
week
and
or
just
get
her
set
us
up
and
we'll
see
you
probably
mostly
in
like
25
minutes,
talk
to
you
later.