►
Description
Tentative title: "A high level perspective on Nix - where it came from, how it is positioned compared to other systems and where it is now". The idea is to have 30 minutes presentation and then 30 mins of interactive Q&A.
continued discussion about this lecture series is happening here:
https://matrix.to/#/#son2022-lectures:matrix.org
A
Anyways,
I'm
brian
I'm
a
software
engineer
at
tweek,
and
I'm
really
wondering
where
everybody's
from,
because
I'm
from
belgium
and
it's
hot
over
here.
So
it's
really
really
hot
in
my
room
at
the
moment,
which
is
annoying
but
we'll
manage,
I
see
that
we
already
have
quite
the
amount
of
viewers
which
is
pretty
exciting
for
me
and
I
guess
exciting
for
everybody.
A
So
I'd
really
like
to
thank
everybody
for
joining
first
and
foremost,
and
I'd
also
like
to
take
just
a
small
moment
to
do
some
housekeeping
and
give
a
little
bit
of
background
about
the
lecture
series.
So
last
year's
summer
of
nix,
I
was
also
a
participant
and
we
had
these
lecture
series,
but
they
were
private
to
the
participants
only
and
this
year's
we
really
wanted
to
push
it
forward
into
the
community
and
make
it
public
to
everybody.
A
Now
the
streaming
infrastructure
is
a
little
bit
of
a
gamble
so
to
speak,
because
we're
trying
it
out
to
also
try
out
at
the
nexcon
2022
in
paris.
I
do
hope
to
see
you
there
at
nexcon,
but
without
further
ado.
I
would
like
to
introduce
a
man
that
doesn't
need
introducing
at
this
moment,
because
I
think
most
people
know
who
he
is,
but
ilko
will
be
here
to
give
us
quite
an
interesting
lecture,
I'm
sure
for
a
continued
discussion.
B
All
right,
hello,
I
hope
you
can
all
hear
me.
I
will
assume
that
that's
the
case
and
if
it's
not
the
case,
somebody
will
ping
me
but
yeah.
I
hope
you're
all
keeping
cool
and
hydrated,
especially
if
you're
in
europe
at
the
moment,
but
we'll
try
to
like
survive
and
get
through
this
talk
yeah.
So
this
talk
is
about
yeah,
the
evolution
of
mix.
B
So
it's
it's
sort
of
a
look
back
at
the
past
of
nics
and
where
it
is
at
present
and
where
we
want
to
go
in
the
future.
So
it's
not
an
introductory
talk
about
mix
and
how
it
works.
So
I'm
assuming
a
bit
of
knowledge
about
mix.
So
I
apologize
for
that.
If
that's
not,
if
you
don't
have
that
yeah,
so
I
thought
it
was
interesting
to
kind
of
have
a
retrospective
because,
as
you
can
see
here,
mix
is
already
really
quite
an
old
project.
B
B
B
So
if
you
have
a
lot
of
build
actions
that
are
kind
of
similar
and
you
want
to
abstract
them
into
functions,
let's
call
them
and
make
has
fairly
limited
support
for
that
it
has.
These
things
called
pattern
rules
that
say
this
is
how,
if
you
want
to
produce
a
dot
o
file
from
a
dot
c
file
by
running
a
c
compiler.
B
B
So
so
I
thought
well
I'll
just
make
a
make
that
has
a
purely
functional
language
as
as
as
its
input
language
for
describing
the
dependency
graph,
because
yeah
here
in
utrecht,
we
were
are
very
much
into
functional
languages
like
haskell,
so
yeah.
That
seemed
like
the
natural
thing
to
do
so,
yeah,
that's
what
I
did.
I
made
this
tool
called
mac
and
yeah
it's
it's
kind
of
what
you
might
expect
from
a
functional
language
that
has
to
yield
a
dependency
graph.
B
You
might
say
mark
test
by
the
way.
Mark
is
the
dutch
word
for
make.
If
you
didn't
gather
that
so,
if
I
say
mark
test,
it
will
evaluate
this
dependency
graph
and
there's
a
call
here
to
a
function,
hello
that
takes
a
single
argument
and
it
will
compile
a
c
program
at
s.c
and
at
compile
time
it
will
pass
that
argument.
That's
defined
into
the
build
process.
B
Yeah
so
I
mean
that's,
that's
nice
and
then
there's
a
function
here.
Bison
that
runs
a
parser
generator.
So
yeah,
it's
pretty
nice.
So
you
can
define
all
these
these
little
functions
so
yeah,
it's
it's
it's
nicer
than
make,
but
it
still
has
the
the
overall
make
a
sort
of
process
in
the
sense
that
it
describes
actions
that
can
just
perform
arbitrary
actions
on
the
directory
in
which
you
run
this
command.
B
So
hopefully
you
specify
exactly
what
the
inputs
and
outputs
of
a
command
are,
but
there's
not
really
a
way
to
get
that
right.
So
if
say,
your
c
compiler
is
reading
some
arbitrary
stuff
from
other
parts
of
the
file
system,
or
maybe
it's
writing
other
output
somewhere
in
your
current
directory.
Then
mac
couldn't
prevent
that
just
like
make
and
there's
no
no
isolation.
B
I
got
a
paper
out
of
that
which
is
a
phd
student
is
still
the
main
thing
that
you
care
about,
but
I
was
also
interested
in
package
management
because,
while
I
was
a
phd
student,
I
was
also
I
had
a
side
gig
as
a
system
administrator
and
so
there
I
had
a
lot
of
exposure
to
package
management
tools
like
rpm
and
and
managing
linux
systems
and
yeah.
Those
tools
had
a
lot
of
problems
and
still
do
because
I
mean
they
haven't
really
fundamentally
changed.
B
So,
for
example,
you
have
the
problem
of
the
dll
hell
as
it's
called
on
windows,
but
well
on
other
systems
of
the
same
phenomenon,
which
is
that
you
upgrade
one
application
and
that
causes
some
shared
dependency
to
upgrade
it
and
that
breaks
some
other
part
of
the
system,
because
maybe
this
new
version
of
the
shared
dependency
isn't
perfectly
backwards
compatible
and
the
reason
why
this
happens
is
that
upgrades
are
destructive.
They
really
overwrite
part
of
your
system,
and
that
also
means
you
cannot.
Roll
back
upgrades
are
not
atomic.
B
B
And
those
dependencies
might
be
under
or
well
not
might
be,
they
actually
were
underspecified.
You
just
say
there
needs
to
be
a
dependency
like
lip,
xml
version
greater
than
something,
but
that's
not
very
good
for
reproducibility,
because
two
users
might
have
very
different
versions
of
those
dependencies.
So
if
they
build
an
rpm,
they
will
get
a.
They
may
get
a
very
different
result.
B
So
yeah,
so
I
started
making
nics
to
to
deal
with
that
again.
I
because
we
were
sort
of
a
purely
functional
cults
in
utrechts.
I
I
started
applying
a
purely
functional
mindset
to
package
management
and
nyx
is
really
purely
functional
in
two
different
ways,
and
probably
the
first
one
is
the
most
important.
B
So
we
never
change
a
package
in
place.
So
if
you
want
to
upgrade
the
package,
you
actually
have
to
build
a
new
copy
of
a
new
version
of
that
package
in
a
different
location
in
the
next
store
and
everything
that
depends
on
it
needs
to
be
rebuilt
as
well
and
yeah.
So
that's
that's
a
very
simple
id.
It's
just
immutable
data
structures,
look
just
like
in
git,
but
most
of
the
nice
properties
of
nics,
like
atomic
upgrades
and
rollbacks
and
reproducibility
they
they
follow
from
this
and
well.
B
Reproducibility
is
not
something
that
we
can
entirely
guarantee
here.
So,
for
example,
if
your
build
was
actually
depending
on
something
in
the
slash
bin
directory
or
slash
user
slash
bin,
we
couldn't
actually
prevent
it
back
in
2003,
because
we
didn't
have
sandboxing
and
name
spacing
and
all
those
cool
features,
but
at
least
it
prevented
undeclared
dependencies
on
other
packages
in
the
next
store.
So
it
was
actually
already
a
very
nice
improvement
to
reproducibility
now
and
then.
B
The
other
way
in
which
it
was
purely
functional
was
the
the
build
language
so
the
language
for
specifying
build
graphs
and
yeah
that
doesn't
actually
have
to
be
purely
functional.
You
could
also
use
now
python
for
for
for
describing
a
build
graph,
but
yeah
pure
imperial
functional
language
has
some
advantages,
and
it's
very
simple.
B
So
maybe
a
nice
historical,
footnote,
nyx
didn't
originally
have
a
real
language.
If
you
dig
really
deep
in
the
nix
packages,
commit
history
all
the
way
at
the
bottom,
so
you
probably
have
to
go
tens
of
thousands
of
commits
deep,
but
you'll
find
these
dots
descriptor
files,
and
that
was
how
we
encoded
packages
and
yeah.
There
was
no.
There
were
no
functions
or
variables
or
really
anything.
B
B
That
did
have
things
like
functions.
So
here
we
have
a
function
that
takes
some
arguments
and
it
returns
a
package,
and
it
has
a
bunch
of
attributes
here,
like
a
name
and
a
source
code,
and
the
source
code
is
a
call
to
another
function,
namely
fetch
url
dot
fix.
There
was
a
time
when
the
mix
language
was
called
fix
and
then
yeah.
Finally,
oh
yeah,
it
has
conditionals
and
variables
so
yeah.
This
was
already
a
purely
functional
language,
just
not
without
an
actual
syntax.
B
B
B
Originally,
it
was
for
building
package
dependency,
graphs
and
it
doesn't
really
have
a
lot
of
domain
specific
features.
So
it's
really
json
plus
lapdas.
So
the
basic
data
types
are
just
lists
and
attribute
sets
which
correspond
to
json
objects,
yeah,
and
then
it
has
functions
on
top
of
that
and
and
function
calls.
Obviously
now
it's
a
lazy
language
which
is
actually
an
important
feature
in
if
we're
talking
about
what
is
important
for
the
domain.
B
I
mean
it's
not
essential
because
you
can
always
express
laziness
in
another
way,
but
it's
it's
very
convenient
in
terms
of
language
features
that
are
really
useful
string,
so
domain
specific
language
features
that
are
really
useful
string.
Contexts
are
very
powerful,
so
those
are
those
dollar
brace
things
inside
strings.
B
B
So
if
I
have
this
string
that
depends
on
the
build
graph
of
the
foo
package,
I
don't
want
to
immediately
start
building
food
just
to
find
out
that
maybe
I
don't
actually
need
this
string.
So
what
this
does
is
this
string
will
actually
yeah
carry
the
fact
that
it
depends
on
the
dependency
graph
of
foo,
so
it
can
delay
building
full
until
it's
actually
necessary,
and
this
is
actually
a
very
important
feature
and
one
that
isn't
so
easy
to
to
do
in
another
language,
but
other
than
that.
B
B
So
yeah,
let's
go
down
the
time
timeline
so,
like
I
said
originally
nyx
was
for
building
packages,
and
so
we
had
the
nyx
command
for
for
installing
packages
and
upgrading
and
so
on
and,
like
I
said
we
so
nix
was
pretty
good
at
preventing
undeclared
dependencies
on
other
stuff
in
a
nick
store.
But
if
you
were
using
something
outside
of
the
nick
store,
so
if
you
had
a
say
a
build
script,
that
was
actually
calling
something
in
slash
user.
Slash
bin
nix
couldn't
actually
prevent
that
because
we
didn't
have
sandboxing
at
the
time.
B
So
we
thought
it
would
be
nice
to
actually
have
a
linux
distribution
where
we
didn't
have
slash
bin
and
slash
user,
slash,
pin
and
so
on
and
yeah.
That
was
mix
os,
which
are
mine,
haymold
created,
and
I
think
we'll
talk
about
it
some
more
next
week,
so
yeah
initially
it
wasn't
very
ambitious.
It
was
just
sort
of
an
experiment
in
verifying
build
purity
and
it
was
really
cool
when
we
we
got
that
working
and
pretty
much
the
way.
I
remember
it
pretty
much.
B
But
of
course
we
actually
wanted
to
use
nixos
as
a
as
a
real
system,
because
then
all
those
nice
features
of
nics,
like
atomic
upgrades
and
rollbacks
and
so
on,
would
propagate
to
the
system
as
a
whole.
So
you
will
be
able
to
atomically
upgrade
your
entire
system,
but
for
that
okay,
so
the
first
step
is:
you
need
to
build
other
stuff
than
just
packages,
because
there
are
other
things
that
go
into
a
linux
system
like
configuration,
files
and
boot
scripts
and
so
on.
B
But
that
was
not
a
problem
because
yeah
previously,
we
had
just
been
using
nick's
at
a
sort
of
big
granularity
where
every
derivation
in
the
nick
store
was
a
package.
But
nix
doesn't
really
care.
What
a
derivation
builds
it
can
build
chromium,
but
it
can
also
build
a
tiny
configuration
file.
So
yeah
mix
doesn't
care
about
what
you're
building
as
long
as
it's
pure,
but
we
still
needed
a
way
to
configure
the
system
so
and
initially
the
system
configuration
for
nixos
was
pretty
ad
hoc.
B
How
you
would
just
have
a
configuration.next
file
that
had
some
parameters
like
your
file
system
configuration
and
the
packages
that
you
wanted
to
enable
and
then
that
configuration.mix
attribute
set
will
just
get
passed
around
to
a
whole
bunch
of
functions
that
generated
configuration
files
and
boot
scripts,
but
yeah
it
wasn't
very
nice
and
was
not
discoverable.
It
wasn't
really
a
good
way
to
find
out
what
the
configuration
options
were.
B
B
So
we
finally
had
type
checking
in
a
language
that
previously
was
well
completely
dynamically
typed,
so
the
only
type
checking
was
a
a
type
error
all
the
way
at
the
end,
usually
not
at
the
point
where
you
get
a
decent
error
message
and
everything
was
overrideable
in
a
nice
way,
so
modules
could
override
stuff
in
other
modules,
users
could
override
stuff.
So
yeah,
it's
it's
wonderful,
but
this
thing
is
entirely
implemented
in
the
next
packages
library.
So
it's
not
a
language
feature
so
on.
B
B
It
took
a
long
time
for
that
to
emerge.
So
we
had
a
mix
build
program
since
2004,
but
nick
shell
really
only
came
about
in
2012
and
it
was
really
kind
of
a
a
random
id
in
an
afternoon.
I
I
kind
of
thought:
well,
wouldn't
it
be
nice
if
you
could
just
drop
into
a
shell
where
you
have
all
the
environment
variables
set
in
the
same
way
as
a
as
a
regular
derivation,
and
it
was
half
an
hour
to
implement
but
yeah.
B
B
Obviously
it
was
extremely
useful
and
lots
of
people
were
using
it,
but
there
are
also
a
lot
of
things
that
didn't
work
that
that
well,
so
one
was
just
that
the
nyx
command
line
interface,
I
mean-
wasn't
really
created
with
ux
in
mind,
so
a
lot
of
things
were
not
very
well
thought
out.
There
also
a
lot
of
things
that
kind
of
just
followed
the
structure
of
how
it
was
initially
implemented.
B
B
And
then
we
got
a
convenience.
Schematic
called
mix,
build
that
com
combined
nick
store
and
nix
instantiate.
But
of
course,
so
this
was
yeah
completely
unplanned
evolution.
If
you
created
these
things
with
the
end
user
in
mind,
you
would
never
do
it
that
way.
So
also,
there
were
a
lot
of
inconsistencies
between
commands
and
the
command
line.
Interface
was
not
very
discoverable,
so
yeah.
It
was
time
for
a
a
better
cli.
B
So
a
typical
thing
would
be
how
your
project
would
depend
on
mixed
packages,
so
most
mix
projects
need
mixed
packages
and
the
way
you
typically
did
that
was
by
setting
up
the
mixpath
environment
variable
to
to
point
to
it.
But,
of
course
that
means
that
if
two
users
have
a
different
version
of
mixed
packages,
they
will
they
will
get
a
different
result
so
yeah.
This
wasn't
a
very
good
situation.
B
There
was
also
no
real
support
for
multi-repository
projects
again
because
initially
nyx
wasn't
really
created
with
that
really
in
mind.
That
was
just
the
idea.
We'll
have
mixed
packages
we'll
have
this
one
repository
and
we'll
put
everything
in
there
and
yeah
how
you
would
deal
with
something
that
isn't
in
mixed
packages,
so
your
own
project
that
depends
on
mixed
packages
yeah,
you
kind
of
have
to
figure
it
out
for
yourself.
B
Maybe
that
project
wouldn't
have
a
default.next,
but
maybe
we
have
a
release.next
somewhere
buried
in
a
subdirectory,
and
maybe
it
had
a
lot
of
attributes
and
would
have
to
figure
out
what
attribute
actually
built
something,
and
there
was
a
lack
of
discoverability.
You
can
really
figure
out
yeah
what
the
project
provided
so
yeah.
So
since
2018
we
have
been
working
on
improving
those
things.
B
So
the
first
big
thing
was
flakes,
so
those
are
currently
still
marked
as
experimental,
but
I
really
hope
that
hopefully,
before
the
next
major
nexus
release,
we
can
make
flakes
non-experimental
and
because
there
are
already
a
lot
of
people
who
are
using
it
and
and
they're
actually
pretty
stable
at
the
moment.
So
we
don't
expect
that
we'll
be
changing
them.
Yeah
they're
very
useful.
B
B
B
B
B
I
know,
query
or
overwrite
a
nixos
configuration
from
the
comment
line,
because
the
mix
cli
still
doesn't
have
any
knowledge
of
these
kind
of
organically
grown
things
that
we
have
in
mixed
packages
like
the
module
system
and
all
these
override
mechanisms
so
yeah
that
that
that's
something
that
we
still
need
to
deal
with
so
yeah
cli
improvements.
So
we
have
this
new
mix
command,
which
is
also
still
experimental,
but
hopefully
just
like
flakes.
B
B
It
doesn't
have
any
sort
of
concepts
that
you
might
expect
like
configurations
or
even
package,
I
mean
mix,
doesn't
have
a
concept
of
a
package
I
mean,
maybe
doesn't
need
it,
but
it's
it's
still
a
bit
strange
that
that
there
are
concepts
there,
like
the
the
system
type
of
a
package,
or
maybe
you
want
something
for
to
support
cross
compilation
and
yeah
mix,
doesn't
know
anything
about
that.
So
all
these
things,
these
kind
of
ad
hoc
things
that
we
have
in
mixed
packages
for
overriding
something.
B
I
kind
of
wanted
to
show
that
a
lot
of
the
you
could
say,
limitations
or
problems
that
we
have
with
nix.
At
the
moment
they
kind
of
come
from
the
fact
that
yeah,
what
we
do
with
nix
now
like
have
declarative
system
configuration
bernder
at
the
beginning,
so
yeah
next
nix
needs
to
keep
evolving
to
support
those
use
cases
in
a
better
way.
B
So
currently
we
don't
actually
have
a
knicks
road
map,
yet
we
do
have
the
start
of
a
process
for
creating
a
road
map.
So
this
is
not
actually
the
road
map,
but
these
are
some
things
that
I
would
like
to
have
on
the
roadmap
once
we
have
it
now.
The
first
two,
of
course,
are
stabilizing
flakes
and
the
cli
well
and
then
get
a
mix
3.0
out
with
flakes
and
the
new
cli
stable
features,
but
a
couple
of
other
things
that
are
really
important
is
improving
documentation.
So
we
just
started
the
documentation
team.
B
B
B
B
How
one
could
actually
be
replacing
the
next
language
as
others,
nickel
another
could
be
adding
the
nexus
module
system
as
a
language
feature
and
using
it
for
next
packages,
or
maybe
another
one
could
be
less
ambitious
than
just
how
we
start
using
nixos
the
nexus
module
system
for
mixed
packages
everywhere,
and
so
there
are
a
lot
of
possibilities
there.
But
I
don't
really
know
what
the
best
solution
is
there.
A
B
B
A
B
A
B
So
it
all
comes
down
to
the
the
question
of
the
the
knicks
language,
so
I
always
go
back
and
forth
between
whether
it's
it's
a
good
thing
to
have
a
very
simple
but
generic
language
that
doesn't
have
a
lot
of
dsl
features
or
to
to
have
a
very
restrictive
language.
So
you
could
also
imagine,
having
I
know,
tomo
as
a
configuration
language,
because
so
for
a
lot
of
users.
Nyx
is
actually
pretty
frustrating.
B
They
had
their
co-worker
introduced
nics
and
they
they
clone
a
repo
and
they
run
into
a
problem
and
they
need
to
fix
it.
And
then
now
they
need
to
figure
out
what
all
these
kind
of
weird
idioms
that
this
particular
mix
expert
created,
which
looked
nothing
like
what
other
nyx
experts
do.
So
that's
the
risk
of
of
of
having
a
very
generic
language.
B
Whereas
if
I
mean
if
you
open
somebody's
random
terraform
file,
then
yeah
I
mean
it
might
be
very
large
and
bloated,
but
it
should
at
least
be
sort
of
easy
to
understand
what's
going
on.
But
I
I
still
think
that
you
probably
want
a
sufficiently
powerful
language
so
that
people
can
create
their
own
instructions,
but
you
should
provide
the
most
common
abstraction.
A
B
Well,
sorry,
I
really
hope
before
the
next
nyx
was
released,
or
I
realized
actually
getting
ready
in
july.
So
I
I
want
to
write
a
rfc
to
stabilize
flakes
and
and
and
other
than
that
implementation-wise
there
isn't
a
whole
lot
to
do.
I
mean
we
can
just
say:
okay,
it's
stable
now
and
yeah,
because
we've
been
using
it
both
flakes
and
the
new
cli
for
years.
So
yeah.
A
B
B
So
partially
they
are
implemented
in
the
mixed
language.
Well,
a
small
part
of
it.
So
there's
this
cold,
flake,
dot
mix
thing,
but
other
than
that
things.
Like
I
mean
the
main
complexity
in
flakes
is
stuff
like
updating
the
log
file
and
and
that's
a
very
imperative
action
that
would
be
hard
to
do
in
in
mix.
B
So
it
needs
to
be
done
somewhere
else.
So,
let's
see
and
then
there's
all
this
fetcher
infrastructure,
which
maybe
could
be
done
in
in
nix
code,
if
you
did
them
as
builders,
I
mean,
for
example,
there
is
a
a
gitzfetcher
and
you
could
probably
use
fetch
kit
from
expectations
from
that.
But
then
you
have
kind
of
a
kick
in
and
act
situation
because
to
get
that
fetcher,
you
need
a
way
to
fetch
a
bit
repository.
A
B
Yeah
yeah.
Actually
I
really
want
to
emerge
before
the
next
minor
release,
so
in
the
next
five
weeks
or
so
because
this
is
actually
the
big
blocker.
I
kind
of
I
said
that
we
don't
have
a
lot
of
issues
left,
but
this
is
actually
a
big
one
for
a
lot
of
users,
because
if
you
have
a
multi-gigabyte
git
repository,
it's
currently
not
very
usable
with
with
flakes
because
it
copies
everything
to
the
store.
B
A
B
B
Yeah
so
guidos
asks.
Is
there
any
plans
on
changing
the
flake.next
schema
and
maybe
having
a
top-level
system
attribute?
So
on
the
one
hand,
if
we
want
to
change
the
flake
schema,
we
should
probably
do
it
before
stabilizing
with
other
other
hands.
It
would
delay
stabilizing
a
lot,
so
I
would
say:
that's
probably
something
for
the
flakes
2.0
or
something
like
that.
A
B
It
makes
a
lot
of
assumptions,
for
example,
if
you're
doing
cross
compilation,
then
the
system
that
reviewed
is
probably
not
good
enough,
so
yeah
and
then
on
changing
the
flag.
The
next
scheme
I
had
so
there
are
also
possibilities
of
having
a
flake
dot
tommle
or
something
like
that.
But
yeah
I
I
mean
that's
too
destabilizing
at
the
moment.
So
let's
postpone
that.
A
B
B
B
People
who
want
to
just
get
on
with
the
work
open
somebody
else's
repository
and
figure
out
what
needs
to
be
done
if
they
yeah
first
need
to
figure
out
somebody's
scheme
code
but
yeah.
Obviously
there
are
a
lot
of
advantages
like
well.
You
get
a
scheme
interpreter
compiler
that
is
much
better
maintained
and
has
a
lot
more
engineering
in
it
than
had
the
mix
evaluator
and
has
much
better.
A
B
B
B
Who
can
truly
do
that,
so
the
the
number
of
people
who
contribute
to
nix
itself
or
really
the
c
plus
plus
code,
is
a
lot
smaller
than
the
number
of
people
who
contribute
to
mixed
packages,
but
yeah
there's
actually
a
fair
number
of
contributors.
So
thanks
for
the
next
2.4
release,
we
had
something
like
100
something
contributors,
although
that
was
over
two-year
period.
So
it's
not
really
representative,
but
there
are
actually
a
lot
of
people
who
contribute
to
this.
B
There
was
a
question:
do
you
see
any
merit
in
more
step?
Aesthetically
typing
nick's?
Currently,
typing
is
done
lazily
and
there
for
the
guarantees
so
they're
fairly
limited
yeah.
I
mean
obviously
as
moving
error
messages
forward
as
much
as
possible
is
really
useful,
because
yeah
often
currently,
you
get
some
very
mysterious
error
message
where,
if
you
pass
in
a
wrong
argument
somewhere,
it
will
blow
up
somewhere
deep
in
the
call
stack
and
the
sooner
you
can
get
a
sensible
error
message
to
better.
B
So
I
definitely
see
merit
in
that.
So
nickel,
which
is
kind
of,
is
essentially
the
next
language
with
gradual
typing.
So
it
doesn't
require
you
to
make
everything
statically
typed,
but
you
can
just
introduce
typing
for
some
functions
and
not
others,
so
you
can
sort
of,
for
example,
you
you
probably
want
to
statically
type
all
your
library
code,
which
you
might
not
care
about.
Statically
typing
your
bix
os
configuration
because
for
that
dynamic
typing
is
fine.
A
A
B
You
have
to
understand
that
unless
you
do
a
git
add
on
that
file,
it's
not
visible
so
that
that
that's
a
nice
one,
but
in
terms
of
the
evaluation
in
general,
I
don't
know
if
there's
sort
of
one
low-hanging
fruit
that
we
don't
already
have
quite
often
really.
The
problem
is
that
the
error
messages
become
too
big
because
you
get
a
giant
stack
trace
so,
but
it's
not
so
obvious
how
to
zoom
in,
on
the
the
most
useful
parts
of
the
stack
trace.
B
A
B
B
B
So,
for
that
reason,
in
flakes
the
packages
attribute
is
not
nested,
so
you
need
to
define
all
your
packages
at
top
level,
but
we
still
need
to
support
nick's
package.
So
the
nested
use
case
and
that's
why
it's
called
legacy
packages
and
a
command
like
knicks
flake
show
doesn't
recurse
into
it
by
default,
but
so,
but
it
doesn't
have
anything
to
do
with
making
mixed
packages
deprecated.
A
B
I'm
not
sure
what
is
meant
with
the
schema
here,
because
I
would,
as
far
as
you
know,
so
the
nixos
module
system
doesn't
have
a
lot
of
names
in
there
that
are
nixos
specific.
It
just
has
attributes
names
like
config
and
options,
and
so
you
can
use
the
nexus
module
system
for
for
anything
really
without
having
nixos
sort
of
leak
into
it.
B
But
maybe
the
question
is
more
about,
so
it
might
be
nice
to
reuse
parts
of
nixos
in
other
contexts
like
home
manager
or
defining
services
for
non-linux
systems
like,
and
maybe
you
want
to
have
some
modules
for
for
defining
services
on
mac,
os
or
whatever
and
right
now,
yeah.
All
the
nexus
modules
are
very
much
tied
to
nexus.
A
B
Yeah,
that's
very
hard,
so
that's
something
that
nobody
has
really
figured
out
yet
so
you
could
so
one
way
is
to,
for
instance,
if,
if
you're
talking
about
nickel,
you
could
have
some
way
to
call
out
to
nyx
to
be
able
to
include
mixed
packages
into
nickel
or
even
have
a
nyx
interpreter
embedded
into
nickel,
yeah
or
yeah.
You
could
have
a
tool
like
nick
will
generate
some.
B
I
know
json
file
that
then
gets
used
as
an
input
by
mix
to
call
mixed
package
or
some
sort
of
helper
function
in
nics,
but
yeah.
So
we
haven't
really
figured
out
how
to
have
a
nice
incremental
migration
and
because
yeah,
given
the
size
of
mixed
packages,
you
probably
want
an
incremental
migration.
You
can
just
throw
it
all
away
and
start
over
and
for
product
for
prototyping
that
that
would
be
fine
too
much
value
there.
A
A
Okay,
then,
then
I'd
like
to
say
one
more
thing,
I
did
a
small
mistake.
I
made
a
small
mistake
right
at
the
beginning:
it's
not
just
the
european
commission,
the
nexus
foundation
and
tweak
it's
a
lot
more
people,
of
course,
but
especially
an
elnett.
So
I'm
sorry,
I
know
that
I
added
you
to
the
to
the
banner
as
well.
A
That's
that's
my
mistake.
There
will
be
more
lectures.
The
speakers
and
the
topics
of
speakers
will
get
known
and
will
get
posted
on
social
media
as
well
as
the
matrix
channel.
When
we
get
more
information
about
them
as
well,
then
do
I
need
to
say
anything
else.
Let
me
think
yeah.
We
can
of
course
continue
discussion
over
matrix,
make
this
a
community
discussion,
and
that
would
be
it.
I
think
so.
I
thank
you
all
for
watching.
Thank
you
all
for
listening
and
until
the
next
lecture.