►
Description
In this lecture Connor will talk to us about the road to Nix at Replit.
Special thanks to the NLnet Foundation, the European Commission, the NixOS Foundation, and Tweag for making this event a reality!
The continued discussion for the lecture series is happening over here:
https://matrix.to/#/#son2022-lectures:matrix.org
More information about the Summer of Nix can be found on the website:
https://summer.nixos.org
A
A
I've
had
a
lot
of
fun
organizing
this
I
wanted
to
thank
Brian
for
moderating
all
the
lectures
up
to
now
he's
taking
a
very
well
deserved
week
off
today
is
also
this
week's
also
the
last
last
week
for
summer
of
next,
so
everybody's
been
working
hard
on
their
projects.
I
hope
all
the
participants
enjoyed.
It
learned
a
lot,
please
feel
free
to
give
us
as
much
feedback
and
as
much
kind
of
things
we
can
do
to
improve
this
program.
A
Another
announcement
is
nixcon
is
happening.
It
will
be
October
20th
and
21st,
with
a
hackathon
on
the
22nd
I
believe
in
Paris,
so
check
out
the
announcement.
That's
linked
right
here,
I
hope
to
see
you
there
and
it'll
be
always
good
to
see
people
in
person
and
we'll
have
a
pretty
cool
list
of
lectures
announced
shortly.
A
So
moving
on
to
today's
lecture,
I'm
particularly
excited
for
this
one.
So
today
we
have
Connor
Brewster
who's,
a
software
engineer
at
replit,
a
small
company
you
may
have
heard
about
that-
has
been
using
NYX
to
deliver
a
product
that
is
really
unique
and
they've
been
shipping
like
there's
no
tomorrow
and
just
kind
of
delivering
this
product
that
no
one
really
thought
would
be
able
to
exist
and
Nyx
is
kind
of
an
important
part
of
how
they
made
that
happen.
A
So
you
know
we
talk
a
lot
about
Nick's
adoption
and
how
do
we
get
Nicks
in
the
hands
of
people
and
replit
has
millions
of
users
that
are
using
Nix
and
it's
not
obscured
from
them,
and
they
they
can
see
that
they're
using
mix
and
they're
getting
introduced
to
it.
So
I
think
you
know
we
should
really
pay
attention
to
this.
A
This
adoption
story
with
replica
because
I
think
it's
an
important
Vector
for
for
next
adoption
in
general,
so
you
know
feel
free
to
drop
questions
during
the
the
lecture
I'll
be
tracking
on
the
various
channels
we
got
going,
but
without
further
Ado
I
will
add
Conor
to
this
stream.
Hey
Connor,
hello!
All
right!
You
sound
good.
B
So
if
you
haven't
heard
of
replit
just
a
brief
overview,
we're
in
browser
collaborative
coding
environment,
you
can
use
any
language
framework
Library
you
can
build
whatever
you
want,
you
can
write
Bots,
you
can
host
web
servers
kind
of
do
whatever
you
want.
Our
goal
is
to
not
get
in
the
way
or
to
pick
certain
tools
that
you
should
use.
B
B
It
was
just
a
painful
experience
to
install
all
the
tools
before
you
could
even
start
writing
your
first
line
of
code,
so
the
first
Approach
at
this
was
you
know,
running
various
languages
client-side,
you
know
start
out
with
just
JavaScript
and
then
eventually
they
started
compiling
like
Python
and
Ruby
to
inscripted.
I
think
this
is
like
pre-web
assembly
days,
and
you
could
just
you
know,
write
some
Ruby
code
locally.
Here's
like
a
picture
of
what
that
looked
like,
and
this
was
perfect
for
a
side
project.
B
You
run
everything
client-side,
so
you
don't
have
to
pay
for
anything
to
host
the
service
other
than
just
like
static
hosting,
but
you
quickly
run
into
limitations,
at
least
for
your
users.
Do
you
have
limited
browser
apis,
especially
you
know
like
10
years
ago.
There's
a
lot
less.
You
could
do
with
the
browser
apis.
B
You
don't
have
like
true
access
to
the
network
in
the
file
system.
You
can
kind
of
emulate
some
of
this,
but
it's
just
not
the
same
as
like
running
on
an
actual
like
Linux
machine
and
then
there's
also
just
a
lot
of
work
that
goes
into
making
each
interpreter
or
compiler
work
in
this
way.
So
it's
just
not
always
going
to
work
out.
B
So
the
next
kind
of
natural
step
here
is
like
okay,
we
can
start
moving
things
to
the
server
side
and
start
using
Docker
containers
and
then
doing
code
execution
in
the
cloud.
Obviously
this
is
a
lot
more
expensive
and
a
lot
more
complicated
to
manage,
but
it's
kind
of
worth
it.
You
get
a
lot
more
freedom
and
a
lot
more
power
for
the
users.
B
But
you
start
running
into
some
issues
here.
There's
like
tons
of
Docker
images
to
manage
and
deploy.
If
we
have
like
you,
know,
50
60,
different
languages,
it's
it's
a
lot
of
management
overhead
and
then
there's
also
like
maybe
a
set
of
tools
that
we
want
available
in
every
image
and
making
sure
that
every
image
has
all
the
correct
tools
can
kind
of
become
a
lot
of
work.
You
could
maybe
like
have
a
base
image
and
have
them
all
share.
B
This
show
the
same
stuff,
but
then
you
can't
use
like
the
standard,
node
or
python
Docker
images.
So
it
gets
you
get
into
a
mess
pretty
quickly,
and
then
you
have
a
problem
where
maybe
somebody
wants
to
use
both
node.js
and
python
in
the
same
project?
Well,
you
have
a
node
image
and
a
python
image,
but
you
can't
like
just
merge
them
together
and
use
both
of
them.
So
the
next
iteration
was
this
thing
called
polygot,
which
was
like
okay.
B
Instead
of
having
a
Docker
image
for
every
language,
we'll
just
have
one
massive
Docker
image
that
has
all
of
the
languages
and
it
used
like
this
crazy
bash
scripts
and
Tomo
can
configuration
files
that
would
stitch
together.
This
massive
Docker
file
that
would
install
all
the
dependencies
for
all
the
languages
that
replica
supports,
and
this
was
an
interesting
idea
and
it
worked
okay,
but
I
had
some
like
pretty
big
problems.
First
off
nothing
was
pinned
or
not.
B
Everything
was
pinned,
some
things
were,
but
like
we're
pulling
things
from
apt
and
running,
you
know
various
scripts
from
the
internet,
and
so
every
time
you
build
this
image.
You
have
no
idea
like
what
you're
going
to
end
up
with
and
it
would
break
frequently-
and
you
just
didn't
know
it
was
going
to
change
every
time
you
rebuild
this
image.
The
image
is
also
really
massive,
so
it
took
a
really
long
time
to
to
sync
anywhere
and
then
we
also
like
had
this
problem
of
okay.
B
We
installed
node
in
this
image,
but
there's
lots
of
different
versions
of
node
and
we
were
stuck
on
like
node
version
12,
which
is
end
of
life
now,
so
we
were
kind
of
in
a
weird
spot.
We're
like
okay.
We
need
to
provide
a
newer
version
of
node,
but
we
can't
just
upgrade
it
in
the
base
image
because
and
that
would
update
the
base
image
for
everybody's
Rebels
and
it
would
probably
break
a
lot
of
rebels
that
were
relying
on
specific
behaviors
of
node
version
12..
B
So
we
didn't
quite
figure
out
how
to
like
solve
that
problem,
and
then
there's
also
this
High
barrier
to
adding
new
languages
or
tools
for
users.
You
have
to
come
and
learn
our
bespoke
tomal
configuration
format
and
open
a
PR
figure
out
how
to
test
it
and
run
this
thing
and
then
convince
an
engineer
to
land
the
pr
and
ship
a
new
version
of
polygot.
So
notoriously
this
is
like
a
really
slow
and
laborious
process.
So
I
did
want
to
kind
of
show
what
it
looks
like.
B
B
So
anyways
at
some
point,
one
of
our
colleagues
is
like
hey.
This
is
this
is
kind
of
all
the
twing
we
built
is
kind
of
like
NYX,
but
but
much
worse,
like
we
had
all
these
scripts
that
you
know
specify
how
you
install
the
tools
for
a
particular
language,
and
then
you
can
compose
them
all
together,
which
is,
you
know,
sounds
kind
of
similar
to
to
what
we
saw
with
NYX,
so
we're
like
okay,
NYX
looks
obviously
like
way
better
than
what
we've
been
rolling
ourselves
here.
B
So
there
were
a
couple
of
options
that
we
could
have
taken.
So
we
could
have.
You
know
kept
with
this
idea
of
polygot
having
this
massive
Docker
image
and
just
use
NYX
to
build
it
like
NYX
is
a
great
option
for
building
Docker
containers.
It
would
have
been
pretty
easy
to.
You
know,
pull
together
all
the
different
languages
that
we
want
and
build
one
Docker
image
for
it,
but
the
second
one
maybe
solve
some
more
problems
is
a
little
more
interesting.
B
Is
we
just
installed
NYX
inside
the
rebel,
and
then
let
users
use
NYX
to
install
the
packages
that
they
want.
So,
after
playing
with
the
second
approach,
it
was
pretty
clear
that
that
was
like
the
way
to
go.
It
was.
It
was
really
cool
experience
so
before
I
dive
into
like
how
we
make
all
this
work.
I
did
want
to
give
like
a
live
demo.
So
I'll
just
create
a
blink
Ripple
here.
B
So,
let's
see
so
inside
here,
it's
it's
pretty
empty
Rebel.
You
have
like
this
readme,
nothing
else.
If
you
run
you
see
it
just
has
like
this
cow
say
thing.
So
if
you
actually
look
at
how
this
Ripple
is
configured,
we
can
say
we
can
see
that
it
has
like
this
run
command.
That
runs
Cal,
say,
and
we
have
this
special
Replay
that
next
file,
so
you
know,
let's
say
I,
wanted
to
write
some
rest
or
something,
and
we
can
see
you
know
rust.
C
isn't
installed.
B
So
all
you
do
is
go
to
replicate.nix,
go
to
add
rest
C
and
then,
if
you
just
hit
enter,
it
will
just
automatically
detect
that
you've
changed
the
file
and
reload
the
environment.
So
now,
if
I
do
rest
C,
you
can
see
that
rest
is
now
available
in
the
environment,
and
this
is
pretty
cool,
but
we
also
added
some
like
special
Integrations
here.
So
you
know
maybe
I
want
some
to
write
some
JavaScript,
a
type
node
will
automatically
try
to
figure
out.
B
We
notice
that,
like
node's
not
installed
in
this
report,
we'll
try
to
figure
out
like
where
you
might
want
to
find
that
from
Nyx
and
then
we'll
automatically
add
it
to
the
replica.nix
file.
And
now
you
know
you
can
you
can
write
some
JavaScript
cool
and
just
for
fun.
You
know
you
can
start
like
Firefox
or
something,
and
we
do
some
special
stuff
we'll
detect
when
you
like,
open
a
window
and
automatically
set
up
some
VNC
stuff
and
automatically
show
it
in
the
workspace.
So
there
you
go
there's
Firefox.
B
B
We
have
a
very
generous
free
tier,
like
it's
our
goal,
to
allow
anyone
to
learn
how
to
program,
and
so
you
know
making
it
so
that
you
have
to
pay
to
use
the
product,
like
that's
a
really
big
barrier
for
a
lot
of
users.
So
ultimately,
we
want
to
do
our
best
to
have
a
free
tier,
and
so
that
means
that
we
need
to
keep
like
the
per
Rebel
cost
down,
and
so
that's
can
be
done
in
two
different
ways
like
we
can
share
as
much
as
possible
between
the
rebels.
B
On
the
order
of
like
a
few
seconds
and
as
cool
as
NYX
is
new
users
who
are
like
brand
new
to
programming
shouldn't
need
to
think
about
NYX
when
they're
just
getting
started,
so
they
should
be
able
to
just
start
learning
how
to
program.
That's
kind
of
the
whole
point
of
replit.
So
we
need
to
make
sure
that
we
retain
that
and
so
do
these
constraints.
Rebels
do
have
a
maximum
file
system
of
one
gigabyte.
So
in
our
first
like
prototype,
we
would
just
go.
B
Take
the
Nix
installation
script
run
it
inside
of
our
Rebel,
which
worked
if
you
use
like
single
user
installation
mode,
because
it
you
don't,
it
doesn't
require
any
privileges
or
anything
and
which
was
which
was
kind
of
cool.
So
you
could
use
like
Nixon
to
go
and
install
some
packages.
You
can
install
cow,
say
or
something
small
and
it
worked
well,
but
eventually
you
would
just
run
into
the
disk
quota
if
you
installed
anything
that
was,
you
know
larger
than
a
gigabyte
or
anything
in
all
of
its
dependencies,
we're
larger
than
a
gigabyte.
B
So
in
reality
this
meant
that
you
couldn't
really
do
anything
that
useful
just
having
NYX
installed.
So
we
kind
of
had
this
naive
idea,
it's
like
what,
if
we
just
like
pre-populate
a
Nick
store
with
everything
from
NYX
packages
and
then
Mount
that
in
a
rebel.
So
now
when
you
try
to
go
and
use
something
from
Nick's
packages,
it's
already
in
the
next
door.
So
essentially
this
is
kind
of
what
that
would
look
like,
and
this
is
very
similar
to
what
we
run
in
production.
Today
we
have
a
shared
persistent
disk.
B
B
One
important
like
caveat
here
is
that
the
writable
layer
is
on
like
a
scratch
volume
and
we
throw
it
away
every
time
your
session
expires.
So
this
means
that
if
you
make
any
modifications
to
the
next
store,
they're
not
persisted
between
fashion
boots.
So
this
is
why
this
cache
is
so
important
to
us.
We
need
to
make
sure
that,
like
most
things
that
users
are
using
are
actually
in
the
cache,
so
you
don't
have
to
like
download
anything
or
touch
the
next
door
when
the
Ripple
starts.
B
B
So,
with
the
cash
in
place,
you
can
now
use
like
Nix
end
to
install
whatever
you
want,
and
it's
kind
of
this
magical
experience.
You
can
pick
like
a
really
large
package
and
it
installs
almost
instantly
because
it's
already
like
available
in
the
next
store,
but
it
still
has
that
magical
experience,
but
user
experience
still
isn't
optimal.
Here.
Users
have
to
know
about
the
Nyx
tooling
to
install
packages.
B
Any
modifications
to
slash
Nicks
are
thrown
away
because
we
use
that
scratch
volume.
So,
even
if
you
do
install
something,
that's
actually
stored
somewhere
in
the
slash
Nix
directory,
so
next
time
you
can
come
to
your
Rebel.
Those
packages
would
be
uninstalled
and
in
general,
like
Nixon,
the
Nix
profile
are
not
really
like
the
Knicks
way.
B
Instead,
we
want
some
way
to
like
specify
the
dependencies
in
some
sort
of
a
file
or
something
so
so.
This
is
where
we
created
the
idea
of
the
replit.nix
file.
So
before
I
go
any
further.
I
do
want
to
go
on
a
tangent
here,
I'm
going
to
be
talking
about
a
thing
called
pid1,
it's
our
init
process,
hence
the
name.
So
it's
the
it's!
The
entry
point
into
the
Container
for
each
Rebel
and
it
just
facilitates
all
of
the
the
IDE,
like
the
browser
side,
workspace
stuff
to
The
Container
interactions.
B
So
with
that
in
mind,
we
needed
a
way
to
allow
users
to
install
NYX
packages
and
we
needed
to
make
sure
that
those
packages
were
available
when
they
ran
their
project
or
were
using
the
Shell.
So
we
created
this
new
file.
It's
really
similar
to
shell.nix
and
you
might
be
wondering
like
why
not
just
reuse
the
standard
ones,
but
it's
important
to
us
that
we
control
the
interface
here.
B
So
we
could
potentially
include
special
Integrations
with
replit
in
the
future
or,
if
like
for
some
reason,
you
know
shell.next
changed
I,
don't
think
it
would.
But
it's
just
nice
for
us
people
to
have
a
interface
that
we
control
and
then
we
also
removed
a
lot
of
the
standard
boilerplate.
So
this
is
what
like
a
replica.nix
file
looks
like
so
you
don't
have
to
have
the
import
next
packages
or
the
the
make
shell
or
anything.
B
B
We
need
to
like
run
the
Rebel
or
start
the
shell,
we'll
just
include
all
those
environment
variables
when
we
do
a
fork
and
exec.
So
you
know
when
you're
in
the
Shell,
you
just
have
all
those
environment
variables
from
the
environment
set
properly
so,
and
that
makes
it
you
know.
Those
things
are
now
installed,
I
guess
in
your
environment,
one
thing
that
we
did
run
into
is
invoking
Nick
shell,
like
container
startup,
was
slow.
It
was
adding
like
multiple
seconds
to
Rebel
start
times,
and
that's
that's
not
great.
B
So
there's
like
two
things
we
could
do
here.
We
could
try
to
figure
out
what
was
slowing
down
Nick's
shell,
and
we
we
looked
into
that
a
little
bit,
but
we
didn't
find
anything
super
obvious
right
away.
So
the
next
best
option
is
to
start
caching
things,
so
we
wanted
to
to
Cache
the
environment
variable
somewhere
on
the
disk
and
then
we'd
only
reload
the
environment
when
we
noticed
like
changes
or
something.
So
what
we
do
is
we
restore
that
environment?
We
just
do
like
a
quick
check.
B
B
Oh
the
command's
not
found,
and
now
it's
not
really
clear
like
what
to
do
at
this
point.
If
you
didn't
know
about
NYX
or
anything,
and
so
we
wanted
to
have
a
slightly
better
integration
here
and
so
I
had
seen
something
called
comma.
It's
a
really
cool
project.
Essentially
you
can
like
prefix
your
command
with
a
comma
and
then
it'll
automatically
find
the
binary
from
NYX.
So
you
don't
actually
have
to
install
the
tool
locally.
B
We
can
ask
you,
you
know
we
still
want
to
have
a
confirmation
step,
so
we
don't
just
start
running
random
stuff
and
so
It'll
ask
you
if
you
want
to
run
it
and
add
it
to
the
replica.next
file
and
more
recently,
we've
utilized
our
next
parser,
which
is
just
a
NYX
parser
written
in
Rust.
So
we
can
make
programmatic
edits
to
replit.nics
and
automatically
install
these
packages
when
we
hit
this
case
So.
Currently,
all
new
ripples
are
powered
by
NYX.
B
We
currently
have
roughly
like
eight
terabytes
worth
of
Nyx
packages
pre-cached
in
that
big
persistent
disk,
and
we
currently
offer
like
two
snapshots
of
of
Nyx
packages.
You
can
use
2111
or
2205,
so
we
do
plan
to
support
new
channels,
but
there's
there's
some
interesting
problems
that
we've
run
into
so
I'll
get
into
that
here
in
a
second
there's,
also,
a
blog
post
that
talks
about
the
you
know
powering
all
the
new
ripples
by
NYX
if
you're
interested
in
Reading
More.
B
If
you're,
like
really
buying
into
Nix
and
using
NYX,
to
build
your
your
package,
it
usually
requires
like
using
something
to
Nick's
tool
which
will
generate
a
bunch
of
mixed
derivations
based
on
your
language
dependencies
or
by
using
some
of
the
Nyx
packages
helpers
like
python3.withpackages,
or
something
unfortunately
like
this
doesn't
really
integrate
well
with
the
rest
of
our
tooling.
So
we
have
like
a
nice
packaging
sidebar
where
you
can
install
language
packages
and
we
use
it.
B
Every
time
the
container
starts
up,
and
you
end
up
with
like
really
slow
boot
times
and
starting
this
quotas,
and
we
also
don't
use
NYX
to
actually
build
the
user's
project.
We
just
use
it
to
get
the
environment
set
up.
We
could
maybe
explore
doing
that,
but
ultimately
our
goal
is
to
make
it
easy
for
users
so
like
if
they're
Googling
and
stuff
trying
to
figure
out
how
to
do
something
in
node
like
we
want
to
be
using
standard,
node
tooling,
instead
of
using
NYX.
B
So
that
you
know
they
can
find
the
the
resources
they
find
actually
apply
to
what
they're
what
they're
using
so
one
of
the
problems,
though,
is
avoiding
Nicks
for
language
dependencies
has
its
own
set
of
issues
as
well.
In
particular,
python
is
a
real
pain
with
this,
so
there's
a
lot
of
like
python
packages
that
require
native
dependencies
they'll,
try
to
like
load
a
shared
object
at
runtime
and,
if
that's
not
present
on
the
system,
it'll
err
out
and
it's
not
a
good
time.
You'll
get
a
nasty
error
message
in
the
shell.
B
So
currently
like
the
best
solution
we
have
here
is
by
using
LD
Library
path,
to
like
add
some
extra
libraries
when
we
when
we
run
the
python
interpreter.
So
if
you
look
at
replit.nix
inside
of
python
reple,
it
looks
something
like
this
and
anytime,
like
you're,
trying
to
use
a
native
dependency,
and
it's
missing.
You
just
have
to
know
to
go
to
the
reply.nics
file
and,
like
add
it
to
this
here.
So
it's
it's
really
not
great.
B
B
The
idea,
my
understanding
of
the
tool
is
it
handles
a
mapping
of
like
language
dependencies
to
system
level
dependencies,
and
so
you
can
use
Rift
to
install
all
of
the
Native
dependencies
that
you
need
to
to
build
or
run
your
program,
and
you
still
use
all
of
the
traditional
language,
tooling,
so
you're
not
having
to
completely
buy
into
Nix
and
use
NYX
to
actually
build
and
run
your
project
So,
currently
only
Russell
support
at
the
moment,
but
it
looks
like
more
languages
are
planned.
So
I
think
this
is.
B
B
Another
problem,
as
you
may
have
guessed
it
with
the
naive
approach.
Caching,
all
of
Nick's
packages
takes
a
fair
amount
of
disk
space
and
we
found
like
a
single
revision
of
of
Nyx
packages,
takes
like
500
gigabytes
to
a
terabyte
of
disk
space,
and
so
once
you
start
caching,
multiple
channels
and
multiple
versions
of
channels
like
this
adds
up
pretty
quickly
and
currently.
Google
cloud
has
a
maximum
persistent,
persistent
disk
size
of
64
terabytes
and
the
cost
scales
with
the
size.
B
So
things
get
pretty
expensive
and
then
also
like
most
users
are
only
using
a
tiny
fraction
of
this
I
I
think
we
ran
some
numbers
and
I
think
there's
something
like
99
of
users
only
use
six
gigabytes
of
this
cash,
and
so
there's
definitely
a
lot
of
room
for
optimization
and
improvements
here.
So
we
have
some
ongoing
ideas
and
projects
to
address
this,
but
we
don't
have
anything
that
we
can
share.
Quite
yet.
B
Another
issue
that
we
found
is
all
the
users
kind
of
share
the
same
Niche
channels.
So
so,
since
all
the
users
share
the
same,
the
slash
Nix
from
the
persistent
disk,
like
their
NYX
profiles
and
Nix
channels,
are
all
set
up
the
same
initially
and
So.
Currently
we
have
like
a
next
Channel
per
next
stable
release,
but
the
revision
of
each
channel
is
shared
amongst
all
the
users.
B
So,
unfortunately
we
found
out
that
we
can't
just
keep
updating
even
on
a
stable
Channel.
We
can't
just
keep
updating
these
channels
because
sometimes
things
break
so
an
example
of
this
is
we.
We
tried
to
update
21
11
at
one
point
and
at
some
point
the
Swift
package
stopped
building
for
some
unknown
reason,
and
you
know
that
deploys
continued
on,
and
so
we
updated
Nick's
packages
and
then
found
out
a
couple
days
later
that
all
Swift
repels
stopped
working
at
some
point.
So
ultimately
this
means
like
long
term.
B
We
need
to
a
way
for
each
Rebel
to
to
pin
to
specific
revision
of
Nick's
packages.
That
way
we
can
still
update.
You
know
non-swift,
Rebels
and
and
leave
Swift
ripples
pinned
to
a
version
of
Nick's
packages
that
actually
works,
and
another
problem
that
we've
run
into
is
like
maintaining
all
of
these
language
configurations.
B
So
for
some
context,
before
we
switch
to
Nyx,
we
maintained
a
Json
configuration
file
for
each
language
included
stuff
like
how
to
run
the
project,
how
to
start
the
language
server,
how
to
run
the
debugger
and
one
major
drawback
of
this
approach.
Is
users
had
really
limited
ability
in
overriding
any
of
these
settings,
so
especially
as
we're
adding
in
Nix
like
not
having
support
to
change
these
settings,
really
limits,
nyx's,
usefulness
and
Effectiveness.
B
If
you
can't
just
go
and
like
change
the
Run
command
to
run
something
from
NYX,
so
ultimately,
we
decided
we
needed
to
expose
all
of
this
configuration
via
a
special
file
called
the
replit
file,
and
here
you
can
set
up
like
how
to
run
the
rebel,
how
to
start
the
language
server.
How
to
do
the
do
the
debugger
and
anything
else
that
that
you
can
configure.
B
Users
have
a
lot
of
freedom
in
what
they
can
do,
but
if
we
make
changes
or
updates
and
improve
these
configurations,
it's
becomes
kind
of
difficult
to
apply
those
changes
to
pre-existing
Rebels
if
they
haven't
touched
these
files.
It's
it's
not
a
big
deal,
but
you
know
somebody
could
have
completely
Rewritten
their
next
file
and
now
it's
unclear
how
to
actually
apply
that
change.
So
again,
we
don't
have
like
a
amazing
solution
for
this.
Quite
yet
we
have
some
ideas
that
we're
working
on,
but
but
nothing
that
we
can
share.
B
Quite
yet,
and
here's
like
what
a
DOT
revlit
file
looks
like
you
can
see
you
can
you
can
pick
the
next
Channel
you
can
specify
how
to
run
the
project,
how
to
start
the
language,
server
and
stuff
yeah.
So
I
also
know
about
like
how
we
use
NYX
internally,
so
that's
kind
of
the
Nick
stuff
on
the
product
side,
so
unfortunately,
like
NYX
internally,
isn't
super
rights,
Pro
or
widespread
among
our
developers.
B
B
We
use
one
of
the
Nyx
wrappers
or
helpers
called
rap
program
to
set
some
environment
variables
before
pid1
is
executed.
So
this
includes
like
adding
stuff
to
the
path,
so
we
can
have
any
expected.
Binaries
are
always
available
to
pid1,
regardless
of
the
docker
image
it's
in
and
then
what
we'll
do
is
we'll
export
the
closure
of
pid1
to
a
compressed
tarball
and
so,
like
I
said
it
consists
of
pid1
all
its
runtime
dependencies.
B
Our
consumer
manager
VMS
will
pull
the
tarball
and
then
Buy
Mount
that
into
a
container
and
then
set
the
entry
point
to
pin
one
inside
that
next
door,
and
so
this
decouples
PID
one
from
the
actual
Docker
image
which,
for
the
most
part
like
most
use
cases
with
Docker
images,
doesn't
make
sense.
But
for
our
case,
where
pid1
is
separate
from
like
the
docker
image,
because
the
docker
image
is
more
about
like
the
development
environment
that
we
give
to
the
users,
it
makes
a
lot
of
sense.
B
It
has
a
have
this
separation
and
we
can
always
ensure
that
tools
like
like
silver,
Searcher
or
upm
and
pry
bar,
which
are
some
binaries,
that
we
have
internally,
but
those
are
always
available,
regardless
of
where
pid1
is
at.
So
this
is
really
useful.
When
we
have,
we
still
have
some
like
Legacy
Docker
images,
and
so
we
can
keep
updating,
pid1
and
adding
stuff
here,
and
we
don't
have
to
worry
about
updating
those
Legacy
Docker
images
to
make
sure
that
they
include
all
the
things
that
we
need.
B
So
with
this
process,
we
just
kind
of
forget
that
we're
using
Docker
images
under
the
hood,
we
don't
have
to
touch
them
very
often,
so
that's
that's
very
nice,
so
yeah.
So
that's
kind
of
a
brief
overview
of
like
how
we
use
Nixa
replit,
there's,
definitely
still
some
rough
edges,
both
with
the
Nyx
tooling
and
with
how
we
use
it.
B
But
we
definitely
think
that
NYX
has
a
bright
future
in
software
development
and
solves
a
lot
of
really
really
important
problems
both
in
software
development
and
deployment
and
I
do
want
to
plug
like
if
any
of
these
problems
sound
interesting
to
you
like,
let
us
know
we're
hiring
just
replied.com
careers
and
we'd
totally
love
to
have
more
Engineers
with
Nick's
experience.
I
also
put
some
links
here
that
to
some
of
our
blog
posts
that
talk
about
some
of
our
next
stuff
as
well.
A
B
So
currently
we
just
used
like
the
standard
NYX
Channel
tooling,
and
then
we
set
the
channel
to
a
specific
like
revision
of
Nick's
packages,
so
we're
just
pinning
it
at
that
level
and
since
our
persistent
disk
caches
all
of
Nyx
and
not
just
Nick's
store.
Basically,
when
we're
building
that
persistent
disk,
we
pin
the
channels
with
Nick's
channel
on
that
disk,
and
then
everybody
inherits
that.
So
we
don't
do
anything
super
special
there.
B
A
A
A
B
Yeah
so
I
think
one
thing
that
would
be
really
interesting
is
this
idea
of,
like
Nick's,
Union
stores,
I,
think
there's
a
GitHub
issue
about
this,
but
it'd
be
really
cool.
If
each
user
could
have
their
own,
like
private
Nick
store
that
maybe
they
could
share
among
all
their
Rebels
and
then
we
have
our
public
cache.
B
That's
like
has
all
of
the
like
pre-cached
stuff,
and
you
could
merge
these
together,
and
so
you
know
users
can
can
cache
stuff
in
their
own
next
door
that
might
be
private
to
them
like
it
might
have
their
own
source
code
or
Secrets
or
something,
and
it
separates
it
from
the
public
cache
that
everyone
else
shares.
So
I
think
that
would
be
something
that's
really
cool
that
doesn't
quite
exist
yet.
A
B
B
A
A
B
B
You
know
we've
gone
through
some
links
to
to
kind
of
hide
it
a
little
bit
from
like
very
new
users,
because
we
don't
want
to
overwhelm
them,
but
we
don't
want
to
keep
it
too
far
to
reach
that,
like
Advanced
users
can't
start
using
it,
but
like
it's
a
it's
a
very
it's
a
paradigm
shift
and
it's
a
new
language.
You
have
to
learn
it's
a
new
model.
B
You
have
to
learn,
so
you
know
we're
always
thinking
about
like
how
we
can
make
it
easier
for
people
to
jump
in
and
learn
how
it
all
works.
So
I,
you
know,
I,
don't
know
the
answer
there
and
I
know
there's
a
lot
of
work
going
on
in
the
next
Community
to
make
it
easier
to
learn
how
to
use
Nixon
onboard.
But
you
know
I
think
that's
like
one
of
the
biggest
the
biggest
problems
to
solve
for
Knicks.
A
Yeah
I
think,
like
you
know
what
you
guys,
what
you
showed
about
kind
of
just
taking
out
some
of
the
boilerplate
and
making
it
so
that
you
can
expose
this
replicas
file
that
users
can
actually
edit
and
having
the
the
shell
hook.
That
will
automatically
add
packages
into
it
is
super
elegant,
I,
actually,
hadn't
realized
that
you
guys
did
that
and
yeah
it's
like
it's
almost
it's
not
necessarily
a
there's
a
conceptual
Gap
to
fill.
A
B
Yeah
and
I
think
it's
like
it's
hard
to
sell
it
to
people
who
are
new
because,
like
they
haven't,
run
into
a
lot
of
the
problems
with
traditional
package
management
right,
you
know
it's
like
the
traditional
one.
You
just
run
a
command
and
you
have
the
thing
installed
like
how
how
can
it
be
any
simpler
than
that?
But
then
you
know
after
you
do
it
for
a
while.
You
end
up,
you
know,
dealing
with
all
sorts
of
weird
things
or
it
works
slightly
different
on
someone
else's
machine
and
stuff.
B
A
Right
right,
exactly
exactly
cool,
well,
I,
don't
see
any
other
questions
coming
in
so
I'm
happy
to
to
leave
it
here.
This
was
an
awesome
awesome.
Walkthrough
of
what
you
guys
have
done.
Super
excited
to
see
where,
where
replica
goes
from
here
and
this
lecture
is
recorded,
so
we'll
have
it
on
the
next
OS
Foundation
YouTube
channel
and
yeah
Connor.
Any
party
thoughts.