►
From YouTube: 2022-03-18 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
B
Yes,
I'm
sure
you
noticed
honorable
already
that
calendar
has
gone
into
the
trash
again.
C
B
B
C
B
We
talked
like
quite
a
bit
about
this,
just
the
whole
stable
instrumentation
stuff.
So
I
started
to
reply
to
surreal
here.
B
But
basically
that
just
the
idea
that
I
was
going
to
clarify
with
surreal
that
stability
means
kind
of
three
things:
the
production,
ready,
api
stability
and
telemetry
stability,
and
so
telemetry
stability
is
the
one
that
we
would
need
to
think
about
for
the
maven
extension.
B
And
if
we're
not
going
to
spec
it,
then
I
think
it
was
jack's
proposal.
Suggestion
that
we
could
add
the
schema
you.
The
schema
file
for
the
maven
extension
into
the
contrib
repo.
E
Yeah
not
sure
who
brought
it
up
originally
might
have
been
metage
but
yeah.
Just
just
generally
one
one
is
something
spec
worthy
versus
one
is
something
just
something
that
you
can
document
directly
in
the
repository,
and
I
was
thinking
about
that
a
bit
and
if
there,
if
there's
only
one
implementation
anticipated,
you
might
not
need
more
than
you
might
not
need
to
spec
it
in
the
semantic
conventions.
C
C
I
mean
the
only
point
of
a
scheme
was
if
we
then
implement
schema
conversion
code
ourselves
when
we
change
the
schema,
which
is
something
I
don't
think
we
want
to
do.
Maybe
cyril
does
I
don't
know,
but
like
going
schema,
having
a
schema
versus
not
having
a
schema.
That's
really
the
only
difference
whether
we
take
on
the
maintenance
burden.
B
C
Or
also,
maybe
just
like
adding
a
schema,
isn't
just
a
magic
potion
to
remove
the
alpha
word,
because
it
does
commit
us
to
doing
schema
translation
if
we
want
to
so
it's
more.
Are
we
comfortable
enough
with
the
telemetry
that
it's
stable?
That's
a
more
important
question.
I
think,
because
if
we
expected
to
change-
and
we
wanted
to
do
a
schema
transition
later,
that'd
be
quite
annoying
for
us,
I
think,
would
we
need
to.
D
B
C
C
Okay,
I
didn't
know
that
so
then
it
seems.
Okay,
then.
B
C
C
C
Like
definitely,
of
course,
if
we
only
expect
one
implementation,
we
wouldn't
need
to
be
as
strict
about
your
respect
and
that
sort
of
thing,
but,
like
I
feel
as
if
it's
a
bit
premature,
to
go
stable
without
at
least
some
discussion
about
the
concept
of
instrumenting
build
systems
as
a
general
concept
in
hotel,
which
I
don't
think
ever
happened,
it
would
be
nice
if
that
could
happen.
C
First,
probably
in
my
general
recommendation
I
mean
I
wouldn't
force
it
or
anything,
because
I
know
it's
just
a
big
thing,
but,
like
I
like
maven
jenkins
and
basil,
like
all
these
build
systems,
there
must
be
some
common
aspects
as
well,
so
at
least
having
a
discussion
to
explore
the
topic
better
before
committing
there's
a
general
good
practice.
I
think.
B
Yeah
because
possibly
some
of
these
could
be
moved
to
top
level,
build.
B
C
C
And,
like
I
understand
that
I
wanted
to
move
off.
The
word
alpha
sooner
than
later,
having
a
little
beta
could
be
a
good
option
for,
like
the
sdk
repo.
I
don't
know
if
it
has
a
use
case
for
that,
but
the
any
instrumentation
might
have
this
use
case
where
we
go
ahead
and
mark
the
public
api
as
doable.
B
Stability
and
telemetry
stability:
do
you
think
api
beta
would
just
mean
production
ready,
not
api
stability.
C
B
C
B
B
Be
present
yeah.
This
is
a
little
tricky,
though,
for
us
in
the
instrumentation
repo,
at
least,
because
we're
sort
of
tying
the
attributes
extractor
names
to
the
semantic
attributes.
C
B
C
E
Yeah
sorry,
just
chiming
in
on
this
late,
I
like
this
idea.
Is
there
any
situation
where
the
telemetry
would
be
stable,
but
the
api
would
still
be
instable,
like
you
know,
is
this:
is
this
purely
like
a
an
additive
process,
alpha
beta,
stable
or
is
the
alpha
and
beta
designations?
Are
those
kind
of
independent.
C
E
C
B
Yeah,
I'm
not
really
worried
about
telemetry
being
the
semantic
converge
conventions
being
stable
and
us
not
having
instrumentation
like
having
api
stability
problems
still.
C
B
Cool,
I
will
I'll
comment
for
cyril
and
maybe
I'll
open
an
issue
in
the
instrumentation
repo
just
to
document
that
for
and
get
feedback
from
others.
E
E
So
the
the
first
item
is
we
have
this.
This
metrics
comment
package
which
just
contains
two
enumerations
instrument,
type
and
instrument,
value,
type
and
yeah.
I
think
we
should
get
rid
of
it,
but
it's
a
it's.
It's
a
breaking
change
for
any
any
user,
because
it's
a
package,
that's
being
moved,
but
I
don't
think
it
provides
organizational
value
and
or
any
sort
of
like
visibility,
value.
E
C
E
B
C
E
Great
I'll
get
rid
of
that
and
you
know
that's
kind
of
related
to
another
item
I
have
on
here.
So
that's
like
technically
a
breaking
change.
E
For
because
there's
gonna
be
a
handful
of
breaking
changes
that
are
coming
before
metrics
stabilize.
C
E
If
we
don't
need
an
rc,
then
the
changes
that
I'm
proposing
in
to
get
rid
of
the
you
know
metric
producer
metric
fact,
reader
factory
pattern.
Those
can
go
without
a
deprecation
cycle
and
you
know
it
simplifies
this
pr
quite
a
bit
or
a
little
bit.
B
E
Got
it
exciting
yeah
and
there
would
be
then
like
a
handful
of
breaking
changes
that
shouldn't
affect
many
people
and
should
be,
I
guess,
for
the
most
part.
You
know
package
reorganizations
and
other
minor
things,
but
it
won't
be
completely
like
clean,
so
some
people
may
experience
some
incompatibility.
I
have
to
do
minor
fix
ups.
C
D
C
E
So
there's
one
of
the
things
I
was
doing
was
I
was
looking
taking
a
close
look
at
the
exemplar
spec
in
the
sdk,
and
so
the
exemplars
are
going
to
be
the
only
part
of
the
sdk
that
are
not
going
to
be
marked
stable
in
the
initial
stabilization
they're
going
to
be
marked
as
feature
freeze
and-
and
I
think
that
the
java,
our
implementation
is
probably
the
most
complete.
E
I
think
we
probably
like
modeled
it
or
josh
modeled
it
for
the
most
part,
but
there's
some
parts
of
it-
of
our
implementation
that
aren't
kind
of
explicitly
specified
that
I
kind
of
think
we
should
be
careful
of
before
publishing.
So
one
is
that
sdk
media
provider
has
a
configuration
option
to
configure
an
exemplar
filter
and
that's
not
actually
explicitly
stated
anywhere
in
the
specification.
So
example,
our
filters
are
talked
about,
but
it's
never
talked
about
where
you
actually
use
them.
E
It's
kind
of
an
assumption
that
we've
made
by
allowing
those
to
be
configured
on
an
sdk
meter
provider
and
so
there's
a
question
of
like
whether
we
expose
this
interface
and
whether
we
make
it
configurable
for
the
meter
provider.
C
E
The
default
implementation,
basically,
what
does
it
do
it
samples
exemplars
if
the
trace
is
being
sampled
and
so
that
that
I
think
works?
E
What
we
would
want
to
do
is,
I
think,
is:
maybe
you
know
if
we're
going
to
default
exemplars
to
on
enabled,
then
we
need
to
have
users
have
the
ability
to
turn
them
off
and
if
we're
gonna
default
them
to
off,
then
we
should
have.
You
know
at
least
some
way
to
turn
them
on.
So
we
can
continue
to
collect
data,
and
you
know
help
to
stabilize
it
sooner
than
later,.
E
To
change
in
113,
so
that's
a
question.
You
know
it's
kind
of
what
should
we
do
given
that
they're
not
going
to
be
stable
in
the
spec.
C
E
E
So
maybe
we
keep
the
exemplar
filter
interface
available,
but
follow
the
the
aggregator
or
aggregation
pattern
of
just
having
it
being
an
empty
interface.
Until
we
add
methods
later
that
would
allow
you
to
implement
your
own,
and
so
you
know
you
could
configure
an
exemplar
filter
on
your
sdk
meter
provider
using
a
couple
of
built-in
options,
but
we
don't
give
you
any
ability
to
configure
your
own
so
that
we're
taking
a
bet
that
example,
our
filters
are
going
to
be
in
the
the
spec.
E
But
we're
not
you
know
tying
ourselves
to
the
api
that
is
defined
today
in
the
spine.
C
E
Okay
and
then
like
what
we
could
do,
then
is
we
could
have
an
internal,
an
internal
thing
that
uses
reflection
that
allows
you
to
change
it.
The
default
setting,
for
example,
our
filters,
something
like
that.
E
Example,
our
reservoirs
are
in
the
same
boat,
so
that's
another
concept,
that's
talked
about
in
the
sdk
and
the
place
that
those
make
it
into
the
api
is
in
views.
Your
the
view
allows
you
to
configure
an
example.
Our
reservoir,
supposedly
it's
kind
of
confusing
and
in
a
bit
contradictory
actually,
but
we,
our
views,
don't
allow
you
to
configure
example
our
reservoir.
So
we
have
this
public
interview,
interface
right
now.
Example,
our
reservoir,
that
you
can't
actually
configure
anywhere,
and
so
you
know,
I
think,
that's
kind
of
an
easy
solution.
C
E
Would
you
would
you
still
want
to
default
exemplars
to
enabled
or
whatever
the
default
option
is
with
sampled
trace?
That's
the
default
filtering
option,
or
would
you
want
to
turn
them
off
by
default
and
force
folks
to
opt
in.
B
Yeah
yeah
we
haven't
yeah
we've
had
a
good
good
experience
in
terms
of
not
many
user
problems
on
the
or
working.
C
The
one
that's
weird
yeah,
I
think
the
performance
and
on
the
flip
side
I
think
we
would
have
to
do
some
significant
rewrite
to
make
it
so
that
it's
the
performance
isn't
affected
if
it's
turned
off.
Our
implementation
currently
doesn't
seem
to
do
that,
because
I
think
we
do
get
the
current
context,
no
matter
what
I'm
not
mistaken.
I
think
I
did
a
quick
skim
when
I
came
to
that
conclusion.
C
D
C
E
Okay,
moving
on,
we
talked
about
another
deprecation
cycle
or
release
candidate.
The
answer
is
no.
I
like
that
answer
and
then
there's
this
question
you
I
saw
that
you
responded
to
this,
but
it's
about
you
know,
use
it
for
instrument
selector.
Do
we
use
in
slash
view?
Do
we
use
a
an
interface
or
the
abstract
class
with
auto
value?
E
Yeah,
I
I
so
I
I
I
saw
this.
What
you're,
what
you
point
out
here,
a
bit
later,
the
hidden
capabilities
of
attribute
processors
to
pen
baggage
keys
or
a
pen
baggage,
and
so
what
I
was
kind
of
wondering
is
like
do
you
know
of
any
user?
Any
use
cases
for
that
today.
D
E
C
You
know
if
we're
okay,
with
this
approach
of
using
reflection
to
access
internal
stuff,
then
of
course
that
could
just
be
our
general
like
then
this
doesn't
have
to
be
interface.
We
could
use
reflection
to
modify
baggage
settings
just
like
we
do
for
other
things
or
this
just
at
least
we
propose
for
this
other
example.
Our
filter
feature
as
well.
C
C
E
Yeah,
the
the
the
thing
that
jumps
out
to
me
is
with
an
interface.
You
can
provide
your
own
and
you
can
have
an
implementation
whose
answer
replies,
whose
answer
varies
with
time,
and
so
you
know
these
are
just
supposed
to
be
static.
Data
carriers.
C
C
E
Well
then,
I
guess
we
got
to
think
about.
You
know
what
technique
we
use
to
still
allow
this,
this,
the
baggage
of
banners.
C
Yeah,
and
so
reflection
is
also
fine.
Yes,
we
already
do
that
for
retry
policy.
I
think
yeah
I
forgot
about
it.
If
I
remember
that
at
the
time
maybe
I'll
just
come
back
instead
of
changing
her
face,
so
that
seems.
Okay,
like
I
never
love
reflection,
but
it's
of
course.
Okay
and
people
use
jackson
and
their
final
reflections.
C
C
E
In
my
plan,
so
I'm
gonna
sleep
on
it
and
see
if
I
can
come
up
with
anything
better
yeah.
E
C
E
Okay,
yeah
I'll
give
it
some
thought
yeah.
What
what
if
the
v,
never
mind,
I'm
just
I'm
gonna
sleep
on
it
and
think
about
it.
A
bit
more.
I
don't
have
any
good
ideas
right
now.
B
That's
nine
nine
o'clock
for
you,
yeah
8,
30.,.
A
Oh,
are
we
in
the
east
coast,
I'm
on
central
time,
so
chicago
chicago.
E
All
right:
well,
that's
all
the
stuff
that
I
found
that
I
had
some
issue
with
with
the
metrics
sdk.
I
think
it
looks
pretty
good.
C
I've
been
sort
of
titling
like
ali
to
ask
me
basically
every
day
now
one
is
the
metrics
sdk
stable,
and
I
always
give
the
same
answer.
If
we
have
a
week
between
our
standard
release
date,
first
of
friday
of
the
month
and
the
metrics
being
expect
being
stable,
that
would
be
enough
buffer
is
what
I
always
try
and
I
think
that's
true.
Yeah.
E
E
Yeah
yeah,
it's
got
all
the
check
marks
yeah.
So
the
implication
of
this
is
that
metric
exporter
loses
its
get
preferred
temporality,
you
know
whatever
method,
and
so
so
we'll
have
to
get
rid
of
that
and
then
metric
reader
gains
two
additional
methods
or
capabilities.
E
E
So
I
have,
I
have
like
an
implementation
of
this
locally,
but
when
this
gets
merged,
we'll
have
to
make
that
change
to
our
sdk
and
that
that
is
going
to
be
breaking
for,
in
fact,
some
of
our
stable
apis.
Actually,
so
the
what
is
it?
The
logging,
the
json
logging
exporter,
implements
a
metric
exporter
and
we're
going
to
be
changing
the
we're
going
to
be
changing
the
api
of
metric
exporter
so
that
that
changes
a
bit.
B
Has
there
been
any
discussion
of
I
remember
previously
when
like
tracing
was
going
1-0,
there
was
supposed
to
be
some
kind
of
review
process
by
the
the
tc.
B
C
E
Yeah
he
has
a
there's,
an
old
issue
where
he
was
saying
that
the
registration
of
a
metric
reader
factory
is
confusing
yeah.
C
E
C
E
So
the
the
idea
is
so
right
now
metric
reader
has
a
method
called
get
preferred,
temporality
and
largely
just
a
pass-through
to
whatever
exporter
you
have.
So
the
idea
with
that
is
that
an
exporter
can
influence
a
metric,
reader's
temporality.
E
But
it's
not
it's
not
explicit
that
it
has
to
be
the
concern
of
the
exporter
as
well,
because
you
know
that's
kind
of
left
is
a
is
a
is
a
detail
that
sdk
authors
can
decide
whether
they
want
to
like
explicitly
have
that
connection
where
metric
all
metric
exporters
have
to
express
a
preferred
temporality,
and
that
has
passed
it
through
to
the
reader
or
not.
E
You
know
basically
josh
mcdonald
and
c
joe
say
it
much
better
than
I
did
just
now,
but
they
talk
about
that
exact
thing.
At
the
end
of
this
conversation,.
C
E
Well,
yeah
that
that's
true
actually,
but
the
metric
reader's
temporality
method
is
a
bit
different.
It's
not
just
like
a
you
know,
a
preferred
temporality,
it's
a!
What
is
your
preferred
temporality
for
this
specific
instrument,
so
it
can
vary
on
an
instrument
by
instrument
basis,
so
it's
kind
of.
If
we
wanted
to
retain
that
on
an
exporter,
we
should
arguably
change
it
to
accept
an
instrument
type
and
return.
A
temporality.
C
E
Well,
the
main
one
is
that,
and
that
prompted
this
whole
thing
is
that
you
know
for
delta,
back-ends
and
there's
three
or
four
vendors
that
have
quote-unquote
delta
back-ends
yeah,
opt-out
counters
in
general.
C
E
Temporality
and
so
that's
kind
of
what
spawned
this
whole
thing
so
giving
you
a
five-way
function
to
say
on
a
per
instrument
basis
where
how
you
want
your
temporality
is
it's
kind
of
a
neat
way
to
solve
that
problem?
And
you
know
the
otlp
exporter
has
two
preferred
temporalities:
it's
not
like
a
rigid
temporality,
it's
what
you
prefer
delta
or
cumulative,
and
if
you
choose
delta,
you
get
delta
for
counters
and
histograms
and
cumulative
for
everything
else.
C
Okay,
I
got
it
so
that's
supposed
to
be
sort
of
the
default
for
delta
yeah
for
otp.
That's
the.
E
C
E
C
E
Well,
the
default
will
be
cumulative,
oh
for
all,
the
instruments
for
for
yeah
the
default
for
all
instruments
is
cumulative,
but
if
you,
if
you
choose
your
preferred
temporality
to
be
delta,
then
you
get
this
kind
of
mixed
mode.
C
E
So
the
so
the
way
that
it
will
end
up
work
so
the
the
name
of
the
environment
variable
that
allows
you
to
specify
whether
you
prefer
cumulative
or
delta,
has
changed,
and
so
it
it
it
has
this
preference
suffix
in
it
now
to
make
it
explicit
that
this
is.
This
is
not
that
this
does
not
mean
that
you're
going
to
get
this
temporality
in
all
situations.
E
It's
it's
what
you
prefer,
with
this
notable
exception,
that
if
you
choose
delta,
you're
still
going
to
get
cumulative
for
up
down
counters,
and
so,
if
you
wanted
to,
if
you
wanted
to
have
well
so
arguably,
what
we
should
do
is,
like
you
know,
have
a
five-way
function
that
is
configurable
as
part
of
the
reader
and
an
exporter.
When
you
configure
an
exporter
with
the
periodic
metric
reader,
you
know,
maybe
we
can
have
helper
functions
that
allow
you
to.
E
C
E
I
think
it
helps
to
imagine
the
the
prometheus
reader
as
well.
The
prometheus
http
server,
which
is
like
you
know,
we
implement
poll
based
readers
as
poll-based
exporters,
as
readers
and
you
know
prometheus,
for
example,
always
prefers
cumulative,
and
so
it
implements
this
five-way
method.
It
always
returns
cumulative,
regardless
of
what
the
instrument
type
is,
and
you
know.
E
The
delta
flag
isn't
global,
it's
actually
only
for
the
otlp
exporter,
so
this
environment
variable
has
otlp
in
its
name.
So
if
you
wanted
to
have
specify
a
preference,
you
know
via
environment
variable
for
a
different
exporter,
you'd
have
to
come
up
with
a
new
environment,
variable
that,
like
included
that
exporter
in
its
name,
so
this
this
is
just
like
a
shortcut
to
dictate
the
behavior
of
the
otlp
exporter,
in
particular,.
C
B
E
C
E
Yeah
and
that's
our
choice,
we
can
do
that
if,
if
we
think
that
that's
something
that
all
exporters
would
benefit
from.
C
B
I
I
will
probably
ask
for
it,
but
I'm
good
with
as
long
as
you
don't,
I
would
say,
just
remove
what
you
have
today,
so
that
we
can
do
the
five.
We
can
add
the
five-way
function
later.
C
B
Probably
want
the
same
behavior
as
the
otlp
preferences.
C
So
that's,
I
think,
if
there's
a
simple
way
like
it
seems
like
really,
those
are
the
only
two
patterns
and
then
anything
so
I'd
like
that
to
be
the
easy
thing
and
we
might
not
even
need
anything
more
fight
grade
than
that
unless
someone
asked
for
it
later.
C
E
I
I
could
imagine
you
know
when
you're
creating
a
periodic
metric
reader.
You
know
right
now.
The
one
required
argument
is
your
exporter.
We
could
have
two
required
arguments,
be
your
exporter
and
your
five-way
function
and
your
five-way
function
could
be.
You
know
we
could
have
helpers
for
that
that,
indeed,
that
you
know
follow
this
behavior,
so
you
could
implement
your
own
if
you
wanted
to-
or
you
could
just
you
know,
use
one
of
the
two.
B
B
B
I
wouldn't
want
that
five
way
to
be
required,
because
I
mean
a
lot
of.
C
C
C
C
C
E
I
think
so
yeah
yeah
and
they
the
plan-
was
to
merge
this
on
tuesday
after
the
spec
meeting.
But
somebody
made
a
last-minute
comment
and
you
know
here
we
are
on
thursday
night
and
it
still
hasn't
merged.
So.
C
Yeah,
I
mean
okay,
our
last
release
was
14
days
ago,
so
technically
march
1st.
So
now
we're
at
the
situation
where
there's
only
one
day
of
that
month
in
the
in
the
first
week,
so
we
either
march
first
or
march
8th,
would
be
valid
days
first
release.
I
think,
just
depending
on
how
we
feel-
and
maybe
if
we
need
that.
B
D
C
B
B
Monthly
yeah.
B
I
don't
think,
let's
see
thanks
for
continuing
to
purge
groovy,
I
should.
C
B
I
should
chart
you
know
the
language
bar.
C
C
And
yes,
I
think
my
current
task,
like
my
highest
priority,
is
getting
rid
of
groovy
hacks,
where
possible.
I
guess
so.
We
have
one
hack
for
a
scala
test
where
we
change
the
ordering
of
compilation
so
that
they
can
be
referenced
or
something,
and
so
I'm
just
trying
to
remove
hacks
by
putting
stuff
away
from
groovy.
That's
been
sort
of
the
ordering
of
that.
So
the
reason
I
did
the
executor's
instrumentation
test
strategy,
because
we
have
the
scala
executor
test.
Also,
I'm.
C
D
C
D
D
B
C
E
Is
all
the
scala
in
groovy
code?
Is
that
all
carryover
from
the
initial
donation,
or
was
there
some
really.
C
E
B
Used
spock
previously
to
this,
he
actually
liked
like
the
spock
and
the
the
table
driven
stuff
and
and
the
conciseness,
and
you
know
it
didn't
frustrate
him
the
way
it
frustrated.
C
C
C
B
The
the
the
java
stuff
is
getting
a
lot
better
with
the
that
has
attributes
satisfying
exactly.
C
B
C
Yeah
the
assertions
are
looking
better.
I
really
wish,
unfortunately,
there's
no
way
still,
I
think,
where
you
can
define
an
interface
so
that
kotlin
will
treat
the
lambda
argument
as
this
just
transparently
like
it
becomes
it
like
that.
I
t
variable
so
when
rewriting
our
code
into
kotlin,
it's
still
not
beautiful,
because
you
have
to
write
the
if
dot
when
generally
in
cotton.
You
wouldn't
expect
that
you
just
write
the
methods
directly
into
the
lambda,
because
it
would
be
implicit
this
or
something,
but.
C
No,
but
I
just
wish
the
kaufman
experience
was
awesome.
Just
out
of
the
box
like
that
was
my
initial
goal,
and
so
I
tried,
but
I
couldn't
there
didn't,
seem
to
be
a
way
to
accomplish
that.
Like
gradle
has
it
because
gradle
does
have
to
when
they're
compiling
their
code,
they're
they're,
compiling,
because
they're
gradle
so
they're
able
to
hack
it
so
that.
D
C
C
B
Yeah
yeah
from
gradle,
okay
yeah,
because
that's
what
I
was
like
also
part
of
the
problem
with
the
scala
code
in
the
tests
is
that,
where
we're
calling
java
framework
stuff
like
the
interrupt
between
java
and
scholarly.
C
C
C
C
B
E
There's
a
movement
at
my
old
employer
to
switch
to
scala,
and
I
I
gave
it
a
genuine
chance.
I
read
the
book
I
I
spent
like
a
month
or
or
two
you
know
scratching
around
with
it,
but
it
was
just
too
esoteric,
and
so
my
team
and
a
few
other
teams
were
the
holdouts
and
eventually
I
I
don't
think
scala
is
going
to
gain
adoption
at
this
point
at
least
massive
adoption.
So
I
think
the
the
momentum
is
going
back
in
favor
of
java,
so.
E
From
hiring
or
just
like
code,
productivity.
C
E
Yeah,
you
don't
think
about
that
type
of
stuff.
That
much
I
suppose,
but
when
you're
choosing
core
technologies
for
a
huge
company
that
stuff
really
matters,
you
know
the
design
decisions
of
the
language
and
how
dedicated
they
are
to
backwards
compatibility.
C
B
Yeah
I'm
putting
a
snapshot
of
our
language
breakdown
to
our
slack
chat,
so
we
can
see
that
later.