►
From YouTube: 2021-04-16 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
Our
waiting,
please
open
agenda
dogs
and
put
your
name
on
the
attendees
I'm
going
to
share
my
screen.
A
A
So
what
we're
about
to
start?
First,
I
want
to
warn
everyone
here,
like
this
meeting,
we're
going
to
talk
about
the
names
and
this
very
hard
subjective
topic
so
trying
to
set
some
context
here.
We
talked
about
the
matrix
instrument
on
one
extreme.
We
could
just
argue
like.
Let's
just
have
one
single
api
that
that
just
report
anything
like
you
can
report
a
value
with
just
a
bunch
of
key
value
pairs.
A
But
when
you
look
at
the
well
established
matrix
et
premises
and
micrometer,
they
give
the
api
with
some
semantic,
like
the
customs
like
counter
and
when
you
use
counter,
they
give
you
a
specific
guarantee,
like
it's
monotonicity
or
better,
that
that
thing
can
be
accumulative
or
something.
So
here
I
think
the
api
design
goal,
like
a
lot
of
folks
already
like
like
mentioned
this
in
the
previous
meeting.
We
want
to
design
the
api,
not
for
the
matrix
experts,
but
it's
for
the
user
and
we
focus
on
the
scenario.
A
So
we
designed
api
to
cover
the
major
scenario
to
make
make
people
feel
easy
to
use
for
the
corner
cases.
We
might
have
some
some
api.
That
is
very
generic
and
they
can
we
can
make
it
a
little
bit
hard
for
them.
That's
probably,
okay
and
another
thing
we
try
to
consider
is
we
try
to
avoid
using
the
same
name
that
has
been
well
established
in
some
system
like
premises
but
give
a
totally
different,
meaning
that's
very
hard
for
people
to
understand.
A
A
So
so
we
can
take
this
offline
and
I'll
I'll
try
to
improve
the
pr
based
on
the
feedback
and
hopefully
before
next
tuesday
we
can
close
on
it
and
if
not,
then
we
probably
need
to
do
some
vote
because
we
realized
we
won't
be
able
to
have
a
perfect
answer.
Makes
everyone
happy
so
we'll
make
some
something
that
makes
most
of
us
unhappy.
A
I
think,
okay
with
that,
I'm
I'm
sharing
this
pr
and
let
me
share
the
document
first
to
give
you
a
whole
idea,
because
I
I
guess
there
are
folks
who
joined
this
recently.
So
what
we
currently
have
is
we
have
the
counter
and
the
the
counter
func
api.
A
The
counter
func
name
was
was
a
stolen
from
the
the
premises
api
and
with
that
we
basically
covered
the
synchronous,
like
one
synchronous
and
one
asynchronous
api,
and
now
we're
trying
to
expand
the
scope
to
cover
all
the
major
scenarios.
A
And
if
you
look
at
this,
we
have
the
sorry
we
have
the
meter
provider
which
has
a
responsibility
to
give
meter,
and
then
you
have
meter
which
is
responsible
for
creating
the
instrument,
and
we
have
two
instruments.
This
one
is
a
synchronous
one.
This
one
is
the
asynchronous
one
and
my
hope
is
once
we
figure
out
the
rest
of
the
instruments.
We
can
simply
copy
the
existing
wording
with
very
minimum
change,
then
we'll
be
done,
but
the
naming
is
hard
and
also
there's
a
question.
What's
the
difference
between
counter
and
gauge?
A
That's
like
this
monotonicity
really
important
for
the
api,
or
we
just
have
one
thing
that
covers
both
the
up
down
counter
and
the
ever
increasing
counter.
So
this
is
where
we
are,
and
this
pr
is
trying
to
add
three
additional
things
which
I
I
guess
is
a
very
like
commonly
used
thing
based
on
my
research
on
premises
and
micrometer.
B
C
I
have
one
like
regarding
regarding
that,
so
if
it
so
what
block
density
is
a
gauge
doesn't
mean
that
it
is
a
sum,
but
should
it
be
a
sum
I
mean
like?
C
To
me
I
agree,
I
I
agree
with
the
sad
part
like
to
me.
That
is,
that
is
the
essence
of
a
gauge,
but
like
to
me,
a
gauge
doesn't
exclude
having
a
increment
or
decrement
value,
because,
but
it
is
I
I
agree
that
it
it
it's.
It
looks
like
a
sum,
but
if
I
want
to
like
set
a
value
to
me,
if
I
want
to
just
like
set
it
to
the
the
next
value
like
plus
one
plus
one
increment,
I
think,
if
I
have
an
increment
for
that,
that's
mine,
but
if.
B
I
yeah
just
got
it,
but
you
apply
that
it's
a
plus
operation
there.
So
if
you
say
increment
with
one,
you
apply
that
the
operation
that
applies
it's
plus
so,
like
sum
so
so
again,
not
trying
to
to
say
to
not
have
a
gauge
but
trying
to
say
that
it's
super
weird,
because
prometheus
started
this
or
or
or
micrometer.
C
C
To
me
that
that's
that's
the
classic
gauge
increment
decrement,
I'm
happy!
If
it's
there,
if
it's
not
it's
not
a
big
deal.
A
Okay,
so
so
I
want
to
pull
this
back
a
little
bit,
so
I
want
to
exercise
like
when,
when
people
instrument,
what's
the
number
one
thing
that
pops
up
in
your
mind
when
you
try
to
emit
metrics
like
when
you
imagine,
there's
a
some
metrics
api
and
you
want
to
decide
which
one
you
use.
What's
the
number
one
question,
and
I
would
put
my
number
one
question
my
number
one
question
is:
do
I
report
the
data
in
the
synchronous
way
or
asynchronously
and
there's
a
multiplication?
A
The
asynchronous
way
means
I
don't
have
access
to
the
contacts.
If
I
have
something
like
in
the
baggage
or
the
contacts,
I
won't
be
able
to
access
that
if
I
use
the
async
and
also
in
async,
that
means
I
can
save
energy.
If
nobody
is
using
that
data,
I
don't
even
have
to
call
the
underlying
like
data.
So
if
I
want
to
consult
the
operating
system
to
get
the
memory
usage,
I
can
save
the
calls
if
nobody
is
listening
on
that.
A
So
I
would
say
think
and
async
is
my
first
question
and
then
when
we
talk
about
sync
core
async,
I
can
have
multiple
questions
about.
Do
we
want
the
statistics
like
histogram
or
summary,
then
we
can
go
down
and
figure
out
which
instrument
do
we
need
so
just
want
to
understand
like
what's
the
number
one
thing
from
your
mind
when
you
pick
this
instrument,
is
that
async
or
something
else.
B
By
the
way,
I
think
I
would
not
describe
the
way
how
you
described,
I
would
describe
more
of
do.
I
have
access
to
the
raw
measurements
to
individual
measurements,
or
do
I
have
access
to
an
already
aggregated
metric
like,
for
example,
the
kernel
exposes
your
cpu
usage.
B
You
don't
have
access
whenever
the
kernel
says,
plus
something
minus
or
whatever
it
says,
the
the
raw
measurements
of
adding
individual
small
usages
of
cpu.
You
have
access
only
to
read
it,
so
this
is
how
I
would
describe
dancing
now
for
me.
I
I
still
believe
the
same
thing
applies,
I
think
versus
think
is
the
first
question
and
the
second
question
is:
what
kind
of
operations
do
I
want
to
do
on
that?
B
So,
if,
if
I
have,
if
I,
if
I
need
a
synchronous
instrument,
I
need
to
think
do
I
need
to
do
add
and
increment
and
decrement
do
I
need
to
do
only
increment.
Do
I
need
to.
D
Can
I
challenge
that
go
ahead,
yeah
so
so
to
me,
synchronous
asynchronous
is
dependent
on
your
language
of
choice,
your
programming
model
of
choice,
your
pattern
of
choice
and
all
of
those
things
that
are
unreal
in
my
mind,
unrelated
to
what
you're
trying
to
do.
Or
am
I
not
right
in
thinking
about
that
because
you
know.
F
You
think
we're
using
async
and
sync
is
not
that
think
of
synchronous
as
inline
and
a
request
flow
and
asynchronous
as
being
something
that
is
not
within
a
request
flow.
So,
like
riley
says,
does
it
have
access
to
the
context
from
that
request,
or
is
it
something
that
is
not
associated
with
the
request.
G
Yeah
like
another
way
to
think
of
it
as
a
cron
job
versus
something
that's
like
pushed
right,
so
async
is
more
like
cron
is
the
way.
F
I
think
of
it
I'd
like
to
challenge
both
of
these
bogdans
and
riley's
assertions,
because
I
think
you
two
have
been
working
in
this
business
too
long.
I
think,
as
someone
who
goes
into
looking
at
like
I
want
to
measure
stuff,
I
want
to
time
something
I
want
to
count
something
or
I
want
to
report
something
that's
happening
in
the
from
like
from
jmx
or
from
some
other
thing
like
something
that's
out
of
band
like
those
are
the
three
things
that
I
think
about.
F
I
don't
think
about
synchronous,
async
or
how
I
want
to
aggregate
it.
I
don't
think
about
that
kind
of
stuff
at
all.
I
think
about
the
job
that
I'm
trying
to
accomplish.
Am
I
counting
something?
Am
I
timing
something,
or
am
I
reporting
something
that
is
coming
from
an
external
source,
ike
I've
seen
yeah,
I
mean
that's
what
we're
calling
async
yet
yeah?
Okay,
I
don't
think
about
the
kind
of
aggregation.
Really,
that's
not
what
I
do.
I
want
to
time
something
I
want
to
count
something.
A
I
see
okay,
so
then
we
look
at
the
like
following
what
john
mentioned,
I
think
that
makes
sense.
So
this
is
my
understanding.
I
want
to
get
feedback
so
so
I
I
would
think
if
this
is
something
that
that
I
want
to
count-
or
this
is
something
I
want
to
get
statistics
like.
A
G
Can
I
can
I
ask
john
a
question,
because
I
really
like
how
you
phrase
that
when
you
say
yeah,
okay,
you
want
to
time
something
right
now
I
want
you
to
think
about
how
you
want
to
look
at
it.
So
do
you
want
the
maximum?
Do
you
want
to
see
like
a
distribution?
Do
you
want
the
99th
percentile?
Do
you
want
the
average
or
do
you
want
to
not
care
so.
F
I
think
when,
when
I'm
a
developer,
when
I'm
someone
who
would
be
using
this
api,
that's
something
that
the
back
end
figures
out,
like
the
back
end,
provides
all
sorts
of
visualizations
to
me.
Like
I
don't
know,
I
don't
know
exactly
how
it's
going
to
work.
If
I
pointed
new
relic,
it
might
do
one
thing
if
I
pointed
splunk,
it
might
do
another
thing.
If
I
point
at
my
own
back
end
that
I
built
in
my
garage,
it
might
do
something
else
like
that's,
not
as
a
user
of
of
some
sort
of
metric
instrument.
F
B
Which
is
which
is
very
close
to
what
we
try
to
do
here,
fyi,
because
we
try
to
couple
the
instruments
of
whatever
the
developer
is
going
to
do
or
wants
to
report
versus
what
is
going
to
end
up
in
the
back
end,
which
is
a
separate
discussion.
So
so,
but
by
the
way
measure
is
not.
The
measure
was
not
one
of
the
things,
so
it
was.
B
F
H
I
kind
of
view
it
the
same
way.
John
does
but
slightly
differently.
I
think
that's
all
one
operation
right,
I'm
recording
a
value
and
how
I
decide
to
look
at
that
later
on
may
may
decide
what
I
want
to
do
with
that
value.
But
if
I've
got
you
know
a
gauge
and
I
want
to
increment
or
decrement
it.
I
record
a
value
of
plus
one
or
negative
one
right.
H
If
I'm
recording
a
timer,
I
record
a
value
of
how
many
seconds
have
elapsed
since
I
started
recording
that
timer
and
it's
all
one
operation
on
the
instrument,
I'm
recording
a
value,
and
then
I
decide
later
on.
Do
I
want
the
sum
of
that
for
a
gauge,
whereas
plus
one
minus
one?
The
sum
gives
you
the
current
state.
Do
I
want
to
histogram
the
distribution
out
of
it?
Then
I
get
a
distribution.
B
Out
of
those
values
that
are
recorded,
it's
very
interesting
because
this
was
the
census
idea.
The
open
census
idea
that
you
have
only
one
record
with
the
value
and
nothing
else.
B
The
downside
anthony
with
that
is
that
there
has
to
be
a
kind
of
a
contract
between
the
developer
and
the
sre
or
whoever
decides
whatever
they
want
to
see
in
the
back
end
or
with
the
back
end
itself
to
to
tell
more
about
that
number.
Not
just
that
not
just
that
is
is
just
a
value.
So
that's
why
that's
why
we
we
want
to
to
have
you
and
also
we
don't
try
to
limit.
If
you
say
this
is
a
counter,
because
by
choice,
I
think
this
is
gonna.
B
G
So
can
I
can,
I
add,
to
something
there.
I
think
this
is
really
important
to
call
out
from
a
user
standpoint.
So
john,
I
totally
agree
with
you.
You
don't
give
a
crap
about
any
of
this
stuff
when
you're
a
user
instrumenting.
I
just
want
to
show
values
out
and
I
don't
want
to
have
to
think
about
it.
My
backend
should,
let
me
think
about
it.
The
problem
is
in
practice.
G
We
have
a
huge
scale
problem
around
the
amount
of
data
people
push
naturally
and
the
getting
it
to
the
back
end
and
the
user
has
to
unfortunately,
learn
about
telemetry
really
early
to
deal
with
this
problem,
like
I
know
as
a
build
tool
owner
in
the
past,
nobody
wants
to
know
how
build
tools
work.
They
want
to
copy
paste,
crap
and
just
have
it
work.
We
have
this
issue
where
fundamentally
sending
out
that
raw
stream
of
data
is
just
not
practical.
You
can't
delay
the
decision
to
the
back
end.
G
We
need
to
do
some
kind
of
aggregation
in
a
lot
of
cases
to
get
this
data
out
the
door
efficiently.
So
people
see
it
and
that
has
to
be
done
in
process
in
practice
in
a
lot
of
cases,
so
we
have
to
make
some
decisions
here.
The
question
is:
how
much
can
we
push
on
the
developer
when
they
don't
give
a
crap.
F
Yeah,
I
wasn't
implying
that
I
thought
that,
should
the
back
end
should
just
get
a
stream
of
measurements.
What
I
was
saying
is
when
I'm
trying
to
when
I'm
trying
to
measure
something
like.
I
want
my
back
end
to
to
give
me
the
visualizations
that
I
want,
and
maybe
that
requires
somebody
to
configure
that
on
my
when
I
actually
install
things.
But
what
I
really
care
about
is
timing,
something
or
measuring
the
size
of
something
or
counting
something
that
happens.
F
G
B
But
but
wait
doesn't
matter
so
josh.
I
don't
think
at
this
point
it
matter,
because
this
is
an
api
correct.
Behind
the
behind
the
implementation
of
this
api
can
do.
Aggregations
can
can
even
talk
to
the
back
end
and
pull
the
aggregations
from
the
back
and
apply
the
aggregations
that
the
backend
tells
you
to
do
whatever
we
crazy
things
we
want
here
is
just
more
or
less
about
the
api.
It
does
not
imply
anything
from
the
things
on
the
wire,
and
I
think
I
agree
with
your
point
like
from
this.
B
Api
is
only
consumed
and,
like
99
of
the
time,
is
consumed
by
the
developer,
who
is
instrumenting
grpc
or
whatever?
Whatever
is
instrumenting
that
developer,
and
that's
the
main
user
of
this
now
when
it
comes
to
to
doing
aggregations
in
in
the
library
or
or
in
the
process
and
stuff,
that's
the
sdk
discussion,
and
we
all
know
that
we
will
not
send
raw
measurements
unless
user
really
wants
to
send
wrong
measurements.
But
that's
that's
a
separate
discussion.
A
Yeah
so
I'll
give
one
one
example,
and-
and
hopefully
that
can
clarify
like
why
we're
thinking
like
this
api
should
be
separate.
So
imagine
if
you
have
a
store
where
people
like
that's
in
the
old
tab,
like
metrics
scenario,
you
have
a
store
where
you
sell
stuff
and
people
come
here.
They
buy
something
and
for
every
transaction
you
want
to.
A
You
want
to
report
how
much
value
like
how
much
money
people
spend
on
on
these
goods
and
and
by
default.
You
probably
won't
say,
oh,
I
only
need
this
aggregate
value.
So
in
the
end,
I
know
how
much
money
I
got
before
I
close
the
store,
but
on
the
other
part
you
might
have
the
question.
I
want
to
see
the
distribution
to
see.
A
What's
the
typical
amount
of
transaction
you
want
to
see,
are
people
always
spend
like
a
very
little
amount
of
money
to
buy
some
stuff
or
there's
like
a
particular
set
of
customers
who
throw
a
huge
amount
of
money
with
this
instrument?
You
don't
even
know
if
people
want
to
get
the
count
like
to
just
add
all
the
transactions
together
or
they
want
to
see
distribution.
A
So
so
my
take
here
is
whatever
instrument
we
give
to
the
user.
It
is
for
the
common
case.
We
try
to
make
it
straightforward
for
them
to
use
like
if
they
come
from
the
english
world.
They
can
usually
translate
the
scenario
into
this
api,
but
ultimately
there
has
to
be
flexibility
to
allow
them
to
take
one
instrumentation
and
do
whatever
aggregation
they
want.
A
They
might
take
a
counter
and
and
consume
that
as
a
histogram,
or
they
want
to
take
a
histogram
and
force
that
to
be
a
counter
or
they
can
do
one
instrument
and
and
have
three
different
ways
of
interpreting
that
that
like
people
would
agree
and
also,
I
think,
based
on
that.
If
we
have
the
instruments
we
got
to
give
the
user
that
operation
they
would
need.
A
For
example,
if
we
tell
the
user,
it's
just
one
function,
you
report
something
then
there's
a
confusion
if
they
want
to
report
something
to
report
the
delta
value
or
they
report
the
absolute
value,
and
we
can
do
that.
We
can
do
the
easy
job.
By
saying
you
have
to
always
report
the
absolute
value
like
if
you
got
the
number
of
incoming
http
requests,
you
have
to
create
your
own
integer
and
keep
track
of
that.
A
Every
time
you
got
new
requests
increase
that
number
and
then
you
report
me
the
absolute
number,
but
that
seems
to
be
pushing
the
entire
matrix
aggregation
logic
to
the
user.
So
we
don't
want
to
do
that.
We
want
to
give
them
some
api
that
allows
them
to
simply
call
add
and
report
the
delta
value.
Meanwhile,
there
are
scenarios
where
we
want
people
to
report
the
absolute
value.
So
that's
that's
what
drives
us
to
think
about.
Instead
of
having
one
single
api,
we
want
to
have
multiple
instrument
tailored
for
the
scenario.
Does
that
make.
C
Sense
also,
can
I
just
share
like
what
is
my
like
decision
tree,
which
is,
I
believe
I
I
hide
you
creep
this
vitijon
and
when
I,
when
I
instrument
something
this
is
the
first
thing
I
check
it
is,
it
is
not
even
like.
Is
it
like
sync
racing?
What
I
check,
if
is
it
a
counter
or
gauge
or
a
timer,
and
I
believe
the
the
the
rule
I
usually
apply,
or
the
mantra
is
like
never
gauge
something
that
you
can
count
and
never
count,
something
that
you
can
time
or
like
measure
the
e.
C
I'm
not
sure
what
is
the
right
word
for
this,
but
you
get
the
gist
of
it.
So,
basically
it's
kind
of
like
a
fallback
like
can
I
can
I
like
time
this
and
if
not,
okay,
can
I
count
this
and
if
not,
I
should
be
able
to
gauge
it.
If
I
yeah,
if
I'm
not,
then
that's
something,
I'm
not
not
able
to
measure,
and
after
this
yeah
just
good.
I.
A
C
Yes,
yes,
so
it
it
is
the
it
is
the
like
the
latency,
but
you
are
applying
the
latency
over
distribution.
So
it
is.
A
I
would
just
say
there
are
a
lot
of
like
distribution
things
that
are
not
related
to
the
time.
For
example,
if
you
open
the
store
and
there
are
different
transactions,
you
simply
want
to
see
what
what
are
the
transactions
that
are
smaller
like
like
than
ten
dollars?
What
are
the
transactions
that
are
even
like
higher
than
a
thousand
bucks
and
those.
C
C
A
C
A
F
A
C
So
what
I,
what
I
was
trying
to
say
with
this
is
that
I
am.
I
am
not
saying
that
we
don't
need
a
timer,
I'm
saying
we
do
need
it.
It's
it's
like
a
very,
very
like
important,
but
implementing
a
timer
cannot
happen
without
implementing
a
distribution,
so
we
need
both
because
both
have
their
own
use
case.
And
to
me
I
would
say
that
timer,
at
least
by
my
experience,
timer
is
used
even
more
than
just
a
pure
distribution.
A
B
I
would
call
them
or
some
some
sort
of
you
you,
you
thought
already
about
how
to
visualize
that
I
want
to
visualize
this
as
a
distribution
you
didn't
so
so
am
I
wrong,
but
but
kind
of
like
you,
you
when
you
when
you
say
counter,
you
already
think
about
and
always
incrementing
always
increasing,
some
essentially
and
stuff
like
that.
So
so
I
I
feel.
B
I
feel
that
not
seeing
that
your
opinion
is
not
good,
but
I'm
seeing
that
you
are
coming
from
the
same
place
as
I
am
coming,
where
which
you
have
about
a
bunch
of
history
with
metrics,
so
you
think
in
aggregations
and
stuff
instead
of
thinking
of
pure
user,
which
doesn't
really
need
to
care
about.
This
will
end
up
being
a
distribution
or
something.
C
Yeah,
my
my
mind
is
is
is
also
like
spoiled
with
with
these
things,
but
I
I
remember
those
times
when
I
like
started
on
matrix,
and
I
don't
really
know
where,
where
I
saw
this
first,
maybe
it
was
drop
wizard
matrix
that
has
this,
like
rule
set
that
don't
gauge
something
that
you
can
count
and
don't
count,
something
that
you
can
time
or
like
measure
the
distribution
of
it.
But
this
I
I
remember
that
this
really
helped
me
to
apply
these
without
really
knowing
what
will
be
the
aggregation
behind.
C
A
Yeah
so
jonathan,
you
can
see
here,
I'm
I'm
trying
to
put
something
similar,
just
trying
to
guide
the
user
instead
of
letting
them
just
struggle
with
this
and
their
their
questions
about
it.
So
just
time
control,
I
I
think
these
are
the
discussion.
It
seems
we're
a
little
bit
stuck
here.
I
won't
know
like
what
are
people
thinking
about
the
next
step.
A
B
Let's
not
call
for
friends
and
vote
things
unnecessary.
I
mean
we.
We
need
to
to
get
to
a
conclusion
without
having
to
do
things
like
that.
I.
A
Agree
so
my
suggestion,
like
we
call,
we
call
the
end
of
discussion
on
this
topic
for
now
and-
and
please
put
your
like
put
as
much
as
comment
you
can
like-
I,
I
think,
without
your
perspectives,
we
won't
be
able
to
make
a
reasonable
matrix
api.
There
is
a
combination
of
the
history
and
also
we
want
to
do
something
correct
here.
So
in
the
end,
I
think
we're
going
to
compromise
and
fund
fund
some
middle
ground.
A
So
please
put
your
comment:
how
consolidate
them
and
try
to
see
where,
where
in
general
like
we
agree
on,
and
then
I'm
going
to
move
forward
on
the
next
topic,
and
if
this
pr
is
turned
out
to
be
too
noidy
like
I'll
I'll,
just
put
a
rough
number,
there
we're
getting
more
than
100
comments,
I'll
call
for
another
meeting,
so
we
we
can.
B
A
A
Yeah
so
we'll
get
we'll
meet
soon,
probably
like
on
friday,
okay,
so
so
going
to
the
next
topic
so
like
after
this,
like
naming
thing,
I
think
we're
ready
to
move
to
the
sdk
spec.
These
are
the
current
top
things
in
my
in
my
mind,
so
I'll
I'll
either
find
the
existing
issue
or
create
a
new
issue
just
to
pull
this
and
and
make
make
them
in
the
product
board.
So
people
can
see
that
and
I'll
I'll
share
the
the
board
next
time.
A
So
we
understand
the
scope,
just
a
heads
up,
so
meanwhile
it
is,
if
you
have
anything
that
I
I
haven't
captured
here.
Just
I
edit
later
or
just
put
a
comment
here,
I'll
I'll
try
to
collect
those
feedback
just
to
help
us
to
define
the
scope
and.
A
Seems
very,
very
active
discussion,
okay,
I'll
I'll-
ignore
this
for
now
we'll
catch
up
later
so
now
coming
to
the
topic
where
john
mentioned
so
so
here
I
I
think
we
target
the
experimental
release
of
the
spike
by
end
of
may,
which
is
the
official
signal
that
all
the
language
6
should
start
to
implement
that
as
a
preview
like
release.
So
don't
ask
this
question
because
in
java
there's
already
a
like
a
preview
version
of
the
metrics
available
and
a
lot
of
folks
are
already
using
that.
So
what's
the
suggestion
like
how?
A
How
do
we
do
the
new
matrix
api
and
I
isdk-
do
we
do
a
separate
package
or
we
remove
the
current
thing
completely
and
and
then
like
add
the
new
metrics
api
again?
What's
the
model,
so
I
I
know
what
download
is
doing-
and
I
am
the
maintainer
of
c
plus
plus,
so
we
implement
everything
based
on
the
previous
version
of
the
spec.
A
I
can
share
my
idea,
but
this
is
more
like
collecting
the
idea
from
from
the
language
sex
and
just
try
to
get
the
initial
thoughts
once
I
got
this
I'll
bring
this
back
to
the
maintenance
meeting
and
we
can
collect
more
feedback
from
other
languages
who
who
are
not
here
or
just
give
people
recommendation.
This
is
what
we
discussed
here
so
with
that.
I
want
to
see
if
anyone
has
opinion
on
their
language.
A
Like
said,
if
not
either
cgo
or
I
can
talk
about
donald
and
I
can
talk
about
c
plus
fast,
okay,
so
I'll
stop
here
and
john.
If
you
have
anything
to
add
here,
no,
it's
mostly.
F
That
I
think
we
should
like
there
are.
We
have
metrics
libraries
experimental
in
a
number
of
languages.
Now
I
know
there's
one
you
go,
I
don't
I
assume,
there's
something
in
python.
No,
because
I
know
there
were
prototyping
going
on
in
python.
It
sounds
like
there
was
one
in.net
and
java.
Obviously,
and
for
all
of
these
things
I
mean
they're
all
tagged
as
not
stable
right.
So
legally
we
can
go
and
do
whatever
we
want
with
them.
F
A
Yeah
I
like
seizure.
If
you
want
to
share
what
was
thinking
from
donald
go
ahead,
I
can
talk
about
c
plus
plus,
and
I
guess
we
have
folks
from
the
goal
as
well.
I
believe,
like
josh
and
tyler
probably
can
talk
about
the
goal
see
you
want
to
talk.
About.Net.
J
Yeah
sure
I
mean
just
like
john
mentioned
like
since
we
never
released
metric
as
a
stable
thing,
and
we
put
like
a
big
warning
like
pretty
much
everywhere,
saying
that
this
is
not
recommended
for
production.
I
think
we
would
be
like
going
and
breaking
with
the
new
api
whenever
we
are
ready
and
like
one
additional
thing
in
dot
net,
is
we
also
promise
that
the
apa
would
eventually
move
to
the
dot
net
runtime
itself,
so
you
would
be
required
to
reinstrument
anyway.
J
B
By
the
way,
john,
so
far,
we
we
had
only
renames
and
a
couple
of
things
which
I
don't
think
it
will
imply
completely
wipe
out.
There
will
be
a
couple
of
changes
that
you
need
to
do,
but
I
don't
think
it
will
be
a
completely
wipeout,
but
in
that
regard,
reusing
the
same
package
name
or
a
new
package
name,
it's
a
good
question
for
for
backwards
compatibility.
F
I
don't
know
I
mean
we
could.
In
java
we
could
publish
two
modules
with
the
same
package
structure,
and
just
people
will
not
be
able
to
use
both
of
them
and
they
never
should
be
able
to
use
both
of
them
at
the
same
time,
and
we
can
start
by
just
copying
what
we
have
over
to
a
new,
a
new
module
and
just
very
loudly
deprecate
everything
in
the
old
module
and
mark
it
and
and
trumpet
from
the
rooftops
that
this
thing
will
no
longer
be
maintained.
B
F
B
F
B
B
A
I
can
share
c
plus
paths,
so
c,
plus
five
is
currently
released,
that
has
a
source
package
and
for
source
like
we
only
have
the
tracing
api
available
by
default.
All
the
metrics
and
the
logging
api
are
protected
by
micros,
so
the
if
devs,
and
only
if
people
enable
that
explicitly
during
compile
time.
F
Yeah,
I'm
here
from
go.
This
is
going
to
be
a
really
disruptive
change,
the
prototype
for
the
existing
metrics
specifications
written
to
go
and
there's
a
lot
of
probably
extensions
and
additional
ideas
that
are
existing
in
there.
Additionally,
like
we
have
instrumentation
that
uses
this,
these
metrics
libraries,
both
in
our
contrib
repos,
as
well
as
in
like
the
wild
and
I
know,
there's
a
lot
of
other
people
that
have
already
like
experimented
with
this
so
yeah.
F
The
idea
of
just
ripping
it
out
and
not
having
a
path
forward
is
not
the
not
unacceptable
like
it
obviously
is
listed
as
experimental
and
something
that,
like
is,
is
you
know,
been
communicated
to
the
users,
but
it'd
be
ideal
to
not
do
that
and
to
try
to
make
some
sort
of
migration
path.
F
We've
also
kind
of
described
in
our
sig
meeting
two
hours
ago.
You
know
like
how
do
we,
if
we're
going
to
be
moving
after
this,
like?
What's
the
what's
our
plan
for
instrumentation?
You
know
if
you
have
instrumentation
that
is
just
set
on
metrics
like
our
host
instrumentation,
we
migrate.
You
know
to
the
new
api
as
that
comes
out,
and
then
what
happens
for
mixed
instrumentation
that
is
tracing
and
metrics
so
yeah.
H
H
One
of
the
things
we
have
done,
though,
is
we.
We
have
a
very
fine-grained
module
structure
and
we're
trying
to
ensure
that
our
stable
modules
only
depend
on
stable
modules
and
experimental
modules
can
depend
on
stable
modules.
So
we
should
be
able
to
take
the
tracing
api
and
tracing
sdk
to
a
stable
status
and
leave
the
metrics
api
and
sdk
at
an
unstable
status
and
not
promote
them
to
1.0.
B
I
also
think
you
can
do
tricks
with
replace
statement
in
go
mode
for
four
packages,
so
there
is
another
option
where,
where
you
can
trick
with
replaces
stuff,
I
may
be
wrong,
but
I
I
think
you
can
do
a
trick
like
you
can
clone.
You
can
keep
this
module
and
user
will
just
replace
to
this
one.
F
And
that's
just
a
yeah.
I
don't
think
if
that
actually
solves
the
problem.
You
just
push
the
solution
to
a
different
spot
but
yeah.
I
we've
talked
a
lot
about
this.
I
don't
want
to
bore
the
metric
sig
with
go
internals
but
yeah.
It's
it's
a
tough
one.
Okay.
A
Or
any
other
language,
not
I
I
think
here
like
it,
it
seems
like
different
language.
Sakes
are
at
different
states,
but
in
general
I
think
we
can
categorize
that
as
three
the
languages
that
doesn't
have
any
like
matrix
implementation
today,
then
they're
fine
and
for
things
like
c
plus,
plus
or
don't
add
they
have
something.
A
But
there
there
hasn't
been
a
lot
of
external
dependency
and
then
there's
java
and
gold
who
are
in
that,
like
limbo
stage
where
a
lot
of
external
dependencies
or
integration
or
like
country-
and
that
makes
sense
so
I
think
it
might
make
sense
for
java
and
gold
to
sort
of
like
align
and
and
figure
out
a
path,
probably
like
a
like
a
migration
path.
Instead
of
like
just
wipe
out
things
and
surprise
people
for
the
other
languages,
I
think
they're,
probably
fine,.
A
A
F
H
H
I
think
for
some
of
those,
if
we
want
to
call
them
stable
with
traces,
we
may
have
to
pull
out
that
functionality
and
add
it
back
in
later,
but
we'll
we'll
look
for
a
way
to
do
that.
That
provides
users
who
want
to
keep
using
the
metrics
api,
as
it
is
some
option.
G
Can
I
ask
a
question
that,
because
I'm
a
go
noob
if
the
telemetry
that
comes
out
of
that,
instrumentation
is
the
same,
so
it
produces
the
same
gauges
sums
histograms
whatever?
Is
it
observable
to
the
go
user?
If
you
swap
out
the
metrics
implementation
behind
them,.
H
H
I
think,
there's
the
the
scenario
where
the
user
does
configure
the
metrics
sdk,
which
means
that
they've
then
imported
unstable,
metrics
sdk
packages,
because
those
are
also
not
stable
and
so
they've
got
to
be
taking
on
a
an
unstable
dependency
as
part
of
a
stable
package
that
you
know
that
that
telemetry,
that
instrumentation
otherwise
would
be
stable
and
that's
the
thing
I
kind
of
want
to
avoid
is
having
direction
dependencies
flow
in
the
direction
of
from
stability
to
unstability.
F
I
think
it
also
mixing
in
the
import
of
an
experimental
package
like
the
metrics
api
also
means
that
instrumentation,
I
think,
can't
be
stable,
because
there
just
is
inherently
like
a
dependency
on
an
experimental
package
is
what
some
of
the
other
problems
that
we
have
but
yeah
that's
I'll,
get.
A
Points,
okay,
so
I'll
I'll
report,
this
back
to
the
maintainers
meeting
and
also
guys
some
stakeholder
from
python.
So
we
can
get
some
alignment
here.
So
my
idea
is
I'll:
try
to
push
hard
on
us
to
align
the
names
and
once
the
names
are
sorted
out,
then
the
api
part
should
be
almost
done.
A
Besides
the
hinting
api
we
decided
to
come
back
later
after
the
sdk
and
and
then
we
can
figure
out
how
we're
going
to
align
these
language
clients,
and
with
that
I
think,
later
next
week
we
should
have
clarity,
and
I
can
I
can
send
a
blog
post
just
to
update
the
community
where
the
the
progress
of
the
metrics
and-
and
we
can
also
cover
like
each
language.
If
you
have
something
as
a
maintainer,
you
want
to
communicate.
A
A
Some
sounds
good
and
or
anything
you
think
you
want
to
cover
like
ping
me
and
I'll
try
to
facilitate
that.
A
Okay,
I
start
go
ahead.
I
just
guess
it
sounds
good.
Okay,
thank
you,
tyler,
okay,
so
the
last
one
I
feel
bad
about
like
coming
back
and
forth
on
the
name,
but
there's
a
one
feedback.
I
got
from
the
donut
folks
when
they
revealed
the
api.
They
they
questioned
me
why
it's
called
contour
funk.
It
seems
like
a
function
from
the
net
perspective
and,
as
probably
people
know
like,
if
you
search
for
like
search
for
funk,
funk
and
action,
they
are
the
established
concepts
in
the
donate
ecosystem.
A
Although,
like
noah
originally
commented,
he
believes
it's
fine,
but
there
seems
to
be
different
voices,
so
I
won't
want
to
see
like
given
we
have
more
folks
here.
Do
people
feel
strong?
You
don't
have
to
struggle
with
the
counter,
because
we're
going
to
figure
out
the
name
during
the
pr
like
we
can
decide.
What's
the
name,
but
if
there's
something
asynchronous
the
general
thing
is
we
want
to
keep
the
asynchronous
api
with
the
same
word
like
if
there's
a
counter,
the
asynchronous
version
should
be
called
counter
func.
A
So
the
idea,
currently
we
have
multiple
options
like
function,
counter
counter
function
using
counter
those
things,
but
I
want
to
know
like
do
people
feel
okay
with
this
name.
I
know
a
lot
of
folks
already
said
they
feel.
Okay.
Well,
bogdan
was
away
so
bogdan,
like
now.
You
have
chance
to
revisit
that
and
when
proposal
was
going
back
to
the
observable
counter,
I
can
link
the
pr
there.
A
There
have
been
a
lot
of
discussion,
but
just
won't
let
people's
feeling
do
you
want
to
revisit
this
or
you
think
it's
fine,
you
just
leave
it
in
goal.
B
Will
also
be
interesting,
I
mean
anthony
and
and
tyler
can
confirm,
but
funk
in
goal
means
this
is
a
function.
B
You
can
look
at
http
package
that
has
a
handler
func
and
couple
of
other
things.
So
funk
means
this
is
the
function
pointer.
Essentially,
that's
that's
what
means
in
goal.
So
I
would
also
say
that
is
not
appropriate
in
goal
for
to
be
called
fun.
H
Yeah,
I
I
would
say
the
opposite
for
the
same
reason:
right
because,
like
the
http
handler
func,
I
view
that
as
something
that
takes
a
function
and
turns
it
into
a
handler.
We've
got
option
func
through
our
functional
options,
all
over
the
place
that
takes
a
a
function
and
turns
it
into
an
option,
something
that
satisfies
the
option.
Interface
right-
and
I
would
read
this
as
something
that
takes
a
function
and
turns
it
into
a
counter.
F
Yeah,
it's
it's
a
it's
a
pretty
common
thing.
You
go,
I
think
the
naming
actually
matches
based
on
my
understanding.
I
could
be
wrong,
but
yeah
when
you
have
a
type
that
is
an
underlying
type
of
a
function.
This
is
usually
how
you
name
things,
but
I
think
one
of
the
one
of
the
questions
I
have,
though,
is
that
like
is
this
a
requirement
that
sigs
name
things
this
way,
because
that
seems
unneeded.
B
F
I
don't
know
I
always
have
this
idea
when
we
come
to
like
naming
in
the
specification
like.
I
think
that
we
really
want
to
make
sure
that
requirements
are
compatibility
or
security
or
something
that
like
is,
is
like
if
it's
not
there
like
this
thing's
not
going
to
function,
and
I
think
that
like
having
recommendations
for
naming
is
a
really
good
idea
for
that
exact
reason
that
you're
describing
like
you
want
to
have
some
sort
of
uniformity.
F
But
I
just
definitely
know
that
there
are
many
many
times
in
like
other
parts
of
the
specification
where
we
go
and
we
make
things
and
go
that
are
just
they're,
not
as
idiomatic,
but
we
have
to
do
it
that
way,
because
it
is
a
requirement
at
that
point.
So
I
I
don't
know
I
that's
kind
of
what
I'm
saying
is
like
you
should
have
a
really
good
reason.
If
you're
not
following
a
recommendation
but
like
there
may
be
the
good
reason,
because,
like
somebody,
who's
really
used
to
writing
in
java
would
never
write.
B
So
my
point
my
point
on
this
was
indeed
that
was
the
case,
and
I
still
believe
that
is
the
case.
But
but
there
are
some
couple
of
critical,
not
critical.
Couple
of
major
components
of
these
apis
like
for
the
same
reason
as
anyone
calls
that
thing
a
spam
and
don't
call
it
on
operation
in
some
of
the
languages.
I
think
so
so
for
some
of
the
names.
I
really
believe
that
the
names
are
are
meaningful
to
to
stay
like
this.
B
This
consistency
across
languages
will
make
people
more
from,
I
mean,
will
will
help
their
their
life.
F
A
F
A
I
I
like
it
and
I
I
think
in
this
way
we
can
go
without
approach,
but
we
need
to
give
some
room
because
in
some
languages
the
typical
suggestion
is,
if
you
have
the
overloaded
function,
they
should
return
the
same
type.
If
they
return
things
very
differently,
then
they
should
have
different
function.
Names.
F
I
mean
I
mean
I
think
they
should
have
different
function
names
anyway,
like
one
of
the
way
that
they're
created
should
be
two
different
things.
One
of
them
will
take
a
parameter,
that's
a
callback
of
some
sort,
and
one
of
them
will
take
a
I
don't
know
something
else,
and
so
naming
them
naming
them
different
for
languages
that
are
required
to
have
different
names
and
can't
do
overloads
also
seems
completely
reasonable
and.
A
F
In
my
head,
there's
no
like
we,
we
shouldn't
talk
about
classes
necessarily
because
not
all
our
languages
are
ooo
right,
but
also
like
for
the
async
case.
I
don't
think
there's
a
thing
like
you
give
that
you
give
your
api
a
callback
and
you
don't
get
anything
back.
It
just
will
handle
the
calling
back
like
there's,
not
a
there's,
no
room
to
give
back
at
that
point
right.
There's
no!
Like
a
class.
I
need
to
return
or
anything
like
that.
A
A
C
Can
I
can
I
quickly
just
send
my
two
cents
to
this,
so
I
I
really
like
the
idea
of
having
just
like
one
counter
and
basically
like
that-
could
handle
both
cases,
but
if
we
would
like
to
like
separate
it
and
have
two
separate
entities
to
me
like
the
entity,
naming
usually
works
like
if
I
have
a
entity
called
something-
and
I
have
a
special
something:
that's
name
is
it's
not
something
special,
it's
special,
something
like
in
this
case.
F
A
About
absorbable
counter
like
this
one
that
puzzles
me,
this
is
the
one
that
I
originally
put
in
the
spike
here
and
then
we
decided
to
change
to
counter
funk
and
if
you
want
to
change
back,
I'm
happy
to
do
that,
but
like
I,
I
only
need
one
input.
So
if
I'm
going
to
rename
this,
this
will
be
the
last
rename
I'm
not
going
to
rename
this
again
does
it
need
a
name.
G
E
B
You
do
need
a
name
because,
because
there
are
languages
where
you
don't
have
function
overloads
and
there
are
languages
where,
for
example,
in
java,
you
want
to
return
a
builder
for
for
this,
because
you
don't
wanna
have
all
the
parameters
passed.
So
you
cannot
do
function
overloading.
So
you
need
to
to
know
which
builder
to
return
you,
you
can
still
have
that
thing.
Be.
G
A
counter
like
so
in
java,
you
can
have
the
builder
itself
have
a
different
name,
but
from
a
conceptual
point
we
still
call
the
thing
a
counter
right
like
you
would
still
call
on
your
meter.
You'd
call
create
counter
from
and
like
build
up
the
things
that
you
use
for
asynchronous
right,
but
you
can
still
call
the
thing
a
counter.
It's
just
there's
a
different
function,
name
on
meter
to
get
the
async
versus
the
synchronous,
counter
that
that's
fine
as.
B
B
That
function
name,
I
I
do
agree
that
it
shouldn't
return
an
object
and
probably,
but
that
function
name
is
gonna,
be
the
name
of
that
thing.
So
so,
if
that
function
name
trust
me
will
be
how
people
will
refer
to
this
pattern,
even
though
you
don't
return
an
object
that
function
name.
B
Whenever
I'm
gonna
tell
you,
I'm
gonna
tell
you
I'm
using
counter,
for
whatever
is
going
to
be
the
name
of
that
function
in
my
code
like
or
you
can
use
a
counter
foo
instead
of
a
counter,
that's
how
I
would
refer,
or
I
would
explain
to
users
how
to
to
distinguish
between
them.
So
so
by
having
by
having
these
two
names
of
the
the
meter,
slash,
meter,
dot,
dot,
create
counter
and
meter
that
create
counter
foo
or
whatever
you
call
it.
B
Or
that
way
I
mean,
if
you,
if
you,
if
you
tell
me
that
the
the
difference
on
the
meter
will
be
create
counter
that
doesn't
accept
anything
and
create
counter
that
accepts
a
callback.
Yes,
that's
how
I
refer
to
user.
I
will
say:
use
create
counter
with
no
parameters
or
use
the
create
counter
with
the
callback
and
so
hence
the
name.
The
name
will
become
counter
with
callback
more
or
less
that's,
that's
kind
of
becoming
the
the.
B
A
A
D
D
The
point
of
these
different
names
is
to
distinguish
the
type
of
data
that
we
want,
whereas
you
know
you
know
for
for
a
counter
versus
counter
func.
When
you
report
the
number
one
is
you
know,
one
is
a
you
know,
delta
and
one
is
accumulative.
D
B
D
D
B
Makes
a
lot
of
sense
for
me
the
vote,
maybe
because
I'm
and
I
didn't
design
the
name
of
some
observer,
but
I
really
like
that
thing
with
observer
observer
observable
counter.
Whatever
you
want
to
call
it,
I
think
it
makes
more
sense
the
fact
that-
and
it
explains
better
to
the
user-
what's
happening-
that
the
fact
that
they're
gonna
observe
something
a
counter
that
from
somewhere
else
so
anyway,
my
two
cents
on
that
will
be
to
to
use
the
observable
thing.
A
Okay,
so
so,
since
we're
running
overtime,
sorry
for
the
time
control
here,
so
I'm
going
to
send
two
pr.
One
is
just
to
propose
observable
counter
another
one
is
just
to
use
counter
and
let's
vote.
I
think
it's
a
simple
thing.
A
F
F
Is
to
have
two
functions
with.
A
The
same
name
am
I
understanding
that
correctly?
I
think
one
is
have
that
observable
counter
concept,
just
flip
the
the
pr
to
the
original
state.
Another
one
is
to
just
have
one
single
concept
counter
and
we
explain
in
the
counter.
There
are
actually
two
different
things:
one
is
the
contour
without
the
callback
another
with
the
the
control
risk
callback,
I'm
a
little
bit
worried
about
that.
It
seems.
Bogdan
is
also
a
little
bit
consistent.
H
B
B
I
don't
know
if
you
still
have
time
guys,
but
I
really
like
victor's
point
of
the
fact
that
it
does
the
name
if
we
use
this,
the
name
does
not
imply
the
main
difference,
which
is
the
fact
that
we
are
observing
an
external
counter
versus
we
are
calculating
a
counter
or
or
aggregating
a
counter.
So
so
so
I
think
I
think
to
that
point,
and
thanks
victor
for
pointing
that.
B
I
I'm
really
happy
with
the
more
or
less
the
observable
part
or
having
some
kind
of
in
the
name
of
this
method
that
creates
and
again
the
method
should
probably
not
return
anything
as
we
discussed,
but
that's
that's
a
separate
concern,
but
but
I
think
the
having
something
that
signals.
The
fact
that
this
is
observed
from
somewhere
else
is
very
important
for
users
to
understand.
John
jonathan,
do
you
have
any
feedback
on
this?
Because
I
know
you
don't
like
the
observable
part,
but.
C
It
just
it
just
puzzles
me.
I
I
like,
like
counter
funk
a
little
bit
better
than
observable
counter,
but
I
believe
the
the
the
thing
I
like
the
most
is
is
having
like
one
counter
and
being
able
to
use
it
like
as
a
synchronous
or
an
asynchronous
one,
depending
on
which,
which
method
you
do
you
call,
but
but
the
problem.
B
C
So
to
me
it
would
be
like
when
you,
when
you
have
a
a
counter,
then
you
will
have
something
that
creates
a
counter
for
you.
B
C
B
B
Okay,
so
then,
then,
then,
essentially,
what
you
are
seeing
is
we
have
two
patterns
to
create
different
two
different
things.
One
one
is,
we
will
get
in
hand,
a
counter
that
has
and
and
one
that
doesn't
give
us
anything
exactly
what
we
want
exactly
what
we
say
like
now.
Now
what
you
are
seeing
is
should
be
the
builder
who
who
has
in
at
the
end
of
the
builder,
has
creates,
create
and
returns
a
counter
or
create
with
callback
and
returns,
nothing
kind
of
like
that
or
build
and
build
build
and
build
with
con.
B
It's
even
either.
If
you
have
it
on
the
builder
side
or
here
or
you
have
it
from
the
beginning.
It's
for
me.
It's
the
same
thing.
I
will
ask
the
same
question:
how
would
you
name
these
two
things
create
with
counter
or
create
observer
observable,
and
you
pass
a
callback.
So
it's
exactly
the
same
discussion
of
naming.
What
would
be
those
two
to
function
that
will
one
would
return
something
and
one
will
not
return
something.
C
And
you
need
like
different
names,
because
there
are
languages
which
cannot
do
not.
C
So
we're
not
on
the
return
type
on
the
on
the
parameter.
Oh
like
is
it
is
it?
Is
it
a
lambda
that
you
pass
in
or
is
it
like
nothing
something
else
yeah.
B
But
even
that
okay,
so
there
are
languages
like
go
which
doesn't
have
this,
so
we
still
need
to
come
up
with
a
name.
So
we
still
have
to
define
this
concept.
C
Yeah,
I
I
believe
I
would
be
fine
with
like,
create,
create
counter
and
create
counter
from
callback
or
from
function.
B
D
Observable
so
I
I
think
that
there
may
be
some.
You
know
interesting
things
about.
You
know
micrometer
in
the
sense
that
the
gauge
allows
for
both
add
delete.
I
mean
add,
decrement
and
set
so
that
difference
of
you
know
when
you
report
the
number,
whether
you'll
be
from
async
or
synchronous,
and
that
concept
of
whether
you're,
giving
it
a
delta
versus
a
cumulative
that
gets,
I
think,
mixed
up.
D
You
know
from
from
you
know,
micrometer.
I
guess
in
this
case,
so
maybe
they
don't
see
that
distinction.
C
C
It
cannot
have
because
the
counter
is
is
monotonic
in
micrometer,
so
it
it
doesn't
really
make
sense
to
have
us
have
a
set.
It's
just
an
increment.
How
do.
B
C
C
I
B
I
see
naming
is
the
hardest
part
of
programming.
I
I
I
don't
know
I
will
let
others
native
speakers
tell
me
if,
if
other
english
options
we
have
in
this
case,
but.
B
Seriously,
I
don't
have
any
any
any
problem
with
any
of
them
as
long
as
it's
clear
that
one
is
observed
from
somewhere
else,
one
is
calculated
by
us,
so
that's
the
only
thing
as
jonathan
as
you
mentioned
in
micrometer
is
the
same
thing.
You
have
two
options.
You
either
observe
it
for
build
like
calculated
by
other
source
or
you
calculate
it
in
micrometer.
So
that's
exactly
the
distinction
we
want
to
make
here.
A
Seems
funny
yeah,
so
I
I
put
a
link
here.
You
can
see
the
like
all
the
conversations
in
in
the
pr
about
the
names.
Originally,
it
was
called
observable
counter
and
later
changed.
It
seems
like
like
gmacd,
has
a
has
a
feeling
that
we
shouldn't
use
observable
because
observable
has
special
meaning
in
some
language.
It
seems.
Jonathan
prefers
the
the
function
counter.
So
in
that
in
that
direction
he
also
prefers
counter
func,
but
nobody
has
super
strong
reason
why
the
other
name
wouldn't
work.
A
So
it's
it's
more
like
we
try
to
find
find
a
name
that
makes
sense
to
most
of
the
folks,
not
something
like
if
we
pick
one,
the
other
will
die
so
I'll,
send
the
pr
on
this
and
based
on
the
vote,
we
see
where
we
go
in
this
discussion.
I
I
think
this
is
really
helpful,
because
the
api
design
is
a
matter
of
taste
and
sometimes
it's
very
subjective.
So
getting
those
feedback
is
very
helpful.
B
Would
not
throw
away
the
previous
option,
which
was
some
observer
or
or
the
fact
that
that
that
is
a
monotonic
song,
maybe
because
essentially,
that
will
describe
the
best
what
you
are
actually
observing.
Maybe
maybe
it
was
not
the
best
because
confused
people
what
the
heck?
I
have
a
counter
in
the
sum,
but
that
also
had
the
advantage
that
it
explained
what
you
are
actually
observing.
A
It
is
so
this
is
what
we
discussed
last
week.
It
is
very
precise,
but
it
is
hard
for
most
of
the
people
to
understand,
so
we
we
tend
to
give
people
something
that
is
easy
for
them
to
understand.
Although
academically
it
might
be
wrong
like
if
you
ask
a
phd,
it
might
be
mathematically
wrong
definition,
so
this
is.
E
A
And
that's
where
we
won't
have.
If
you
have
a
counter
and
the
asynchronous
part,
although
it's
taking
the
sum,
we
still
call
it
a
counter
just
to
give
that
correlation,
so
people
can
understand
their
from
the
consumption
side.
They're
the
same
okay,
so
I'll
also
know
one
or
two
small
pr.
Just
that
part
should
be
easy,
and
my
ask
is:
please
look
at
that,
like
the
instruments
and
the
name,
that
part
is
hard
so
so
help
help
out,
and
hopefully
we
can
close
this
in
a
week
center.