►
Description
Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/what-would-solidity-10-and-20-look-like/
Solidity has quite a long history already, especially in terms of "crypto years". Yet, the project has not yet reached the "magical" 1.0 release.
This talk is discussing what the language could look like reaching 1.0; and going beyond reaching 2.0.
Speaker(s): Alex Beregszaszi
Skill level: Intermediate
Track: Developer Infrastructure
Keywords: solidity
Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/
Devcon is the Ethereum conference for developers, researchers, thinkers, and makers.
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/
A
A
A
and
in
the
past
year,
I've
been
kind
of
like
taking
a
break
and
did
write
a
lot
of
code
in
solidity
itself
and
I.
Think
some
of
this
is
like
a
culmination
of
of
you
know
my
experience
using
the
language,
but
I
hope
some
of
these
things
are
mentioning,
may
come
to
infusion.
Okay,
so
0817
is
the
latest
release.
It's
a
hundred
second
release.
We
already
had
more
than
100
releases.
A
A
In
some
of
the
years
we
had
releases
every
two
weeks,
I
think
lately,
it's
more
like
monthly
and
I
hope.
That's
going
to
come
to
you.
Maybe
you're
gonna
get
back
to
like
bi-weekly
releases
but
at
least
want
to
release
this
and
I'm
saying
this
just
to
show
that
how
active
the
development
of
solidity
is
I'm,
not
gonna,
go
through.
All
of
these.
You
can
find
this
really
nice
chart
on
the
solidlank.org
website
and
it
shows
you
all
the
interesting
milestones
we
have
accomplished
since
the
beginning.
A
However,
it
doesn't
show
anything
past
0.6
because
he
made
this
two
years
ago,
but,
as
you
can
see,
it's
it's
a
lot
of
stuff
going
on
and
based
on
like
having
over
100
releases.
You
may
ask
a
question:
when
do
we
actually
get
to
1.0,
and
you
may
not
be
alone
asking
that
question
we
do
get
that
question
super
frequently.
Last
year
there
was
like
this
big
debate,
this
particular
issue
I'm
looking
here,
the
issue
is
much
longer.
A
The
description
is
maybe
10
times
as
long
and
the
author
of
the
issue
provides
a
bunch
of
different
reasons
why
he
thinks
solidity
should
be
at
1.0.
I
summarize,
like
three
different
discussion
points
we
have
been
debating
on
this
issue,
the
others
that
or
had
the
opinion
that
the
current
scheme
doesn't
actually
allow
breaking
releases.
The
separation
of
breaking
release
and
non-breaking
releases
in
his
opinion
on
every
single
facility
release
is
a
breaking
release.
A
In
fact,
you
know
when
1.0
was
released,
we
never
signaled
a
0.1
was
released.
We
never
signaled
that
it's
ready
for
usage,
but
the
nature
of
blockchain.
It
just
started
it.
People
just
started
to
use
it
and
it's
there.
It's
always
going
to
be
there,
but
also
the
team
had
some
concerns
about
this
1.0
stuff.
Basically,
we
have
the
impression
that
1.0
kinda
implies
that
we
have
to
have
a
long-term
maintenance
of
that
version.
A
We
have
to
add
new
features,
non-breaking
features
and
all
kind
of
changes,
and
if
we
still
want
to
do
braking
changes,
that's
going
to
be
like
2.0
and
then
suddenly
we
have
to
like
maintain
two
versions
or
we're
not
gonna
make
breaking
releases
so
that
that
is
the
reason
we
kind
of
wanted
to
avoid
going
to
1.0
I'm,
not
sure
how
many
of
you
actually
know
how
the
versioning
system
works.
Do
you
want
to
like
give
hands
on?
Are
you
a
developer?
First
of
all,
so
many
of
you
are
using
solidity.
A
Are
you
using
anything
but
solidity,
not
many
any
other
language.
Besides
solidity,
nice,
so
I
think
you
should
you
ever
had
this
versioning
system
works.
We've
learned
the
impression
that
it
is
semantic
versioning
turned
out.
It
is
not
because
anything
below
the
major
one,
so
major
zero
is
a
breaking
change.
A
Here's
just
an
example.
You
know
how
this
would
look
like
and
now
suddenly
you
know
once
we
know
what
1.0
could
mean.
Maybe
we
should
talk
about.
How
could
we
get
there?
Here's
an
example
contract
with
the
latest
release.
This
is
actually
the
solidity
stocks
contract
which
is
on
mainnet.
You
can
use
it
to
make
socks
both
the
land
and
the
right
hand
side.
If
you're
lucky
you
can.
A
A
Okay,
so
that
was
the
the
non-changed
version
skipping
one.
Okay,
this
is
an
unchanged
version,
and
this
has
a
few
changes:
they're,
not
important
yeah.
Where
is
it
like
this
stuff,
this
stuff?
All
of
none
of
this
is
agreed
on,
but
there
may
be
tiny
changes,
but
I,
don't
think
they're
going
to
be
big
changes.
A
A
We
should
have
like
operator
operators
and
letters
to
use
the
defined
types
standard.
Library
generics.
You
know,
data
types
I
just
gave
you
a
few
examples
now,
but
actually
Daniel
from
this
already
team
had
an
extremely
good
talk,
which
you
should
watch
and
I'm
going
to
share
the
QR
code
for
the
video
as
well.
So
here's
an
example
of
user
defined
operators.
A
A
Another
major
thing
is
a
standard
Library
which
we
have
been
talking
about
for
years,
and
the
main
goal
of
the
standard
library
is
to
move
out
the
majority
of
the
compiler
code
into
solidity
itself,
but
it
is
also
really
good
exercise
doing
it,
because
it
shows
us
what
kind
of
language
features
are
missing.
So
here's
one
example
this
actually
doesn't
require
anything
major.
A
The
only
thing
it
requires
is
this
pragma
standard
lab
and
what
it
does
it
just
disables
the
built-in
functions,
because
if
you
don't
have
this
primary
standard
lib,
this
function
definition
is
going
to
fail
because
there's
already
a
shot
256
implicitly
in
the
language.
If
you
have
this,
it's
not
going
to
be
there,
so
you
can
define
it.
A
This
is
the
simplest
example
in
the
standard
library,
and
this
works
doing
anything
more
complicated,
going
to
require
a
lot
of
language
changes.
Here's
one
example
what
we
will
require
for
the
language
changes.
It
is
just
generics
there's
a
this
is
an
extremely
old
example
and,
in
fact,
I
copied
this
example.
From
my
talk
from
two
years
ago,
from
this
holiday,
Summit
you're
already
seeing
the
same
things
back
then
so
I'm
not
going
to
go
any
further.
If
you
want
to
take
a
a
photo
of
the
QR
code.
This
is
the
talk
from
Danielle.
A
It
is
a
full
30
minute
talk
and
it
did
a
really
good
job
at
explaining
the
reasoning,
Behind
These
features
and
how
they're
going
to
work.
Okay,
now
taking
a
tiny
break.
These
were
the
changes
the
team
wants,
and
the
team
agrees
on,
but
I
kind
of
want
to
ask
you
all
of
you
to
look
at
the
Repository
this.
These
are
all
the
it's
kind
of
hard
to
see,
but
these
are
all
the
issues
Tech
language
design
and
we
have
237
issues
open.
A
Those
are
the
issues
people
want
want
as
a
feature
and
I
think
many
of
them
actually
are
kind
of
obsolete.
At
this
point,
but
I
ask
you
to
look
at
this
repository.
Look
at
all
of
these
issues
or
you
know
a
tiny
subset
of
them
find
something
what
you
like
and
leave
a
comment.
If
you
want
to
have
it
or
leave
a
comment,
if
you
think
it
is
a
bad
idea,
you
know
besides
these
features
that
the
team
wants.
A
I
think
it
would
be
nice
to
know
what
you
guys
actually
want
so
I
think
that's
what
1.0
gonna
be
like.
Not
many
like
visible
changes
for
the
user
side,
if
you're
just
writing
like
a
token
contract,
NFC
contract
Etc.
But
if
you're
writing
libraries,
it's
going
to
be
entirely
different,
you
know
one
2.0.
A
That
is
a
crazy
topic
and
we
have
been
actually
talking
about
this
for
a
couple
of
months
at
this
point
on
and
off
and
actually
2.0,
it's
two
different
things
and
it
has
been
like
super
confusing
at
the
team.
Even
talk
about
it
because
you
know
some
people
meant
the
one
or
the
other
and
I
just
want
to
highlight
it
again.
You
know
nothing
is
decided
here.
A
lot
of
this
is
just
you
know
my
idea.
What
I
want
to
have,
but
I
hope
some
of
this
is
going
to
happen.
A
Not
many
of
you.
Basically,
a
compiler
has
multiple
stages.
You
know
we
take
like
the
source
code.
We
process
the
source
code
into
some
internal
representation.
We
do
a
lot
of
different
analysis
on
that
representation.
Once
we
are
happy
with
the
code
that
it
is
sound
that
it
works,
we
are
generating
some
kind
of
a
next
stage
in
the
first
version
of
the
compiler.
This
generation
was
directly
into
evm
in
the
current
stage.
We
already
have
we.
A
A
A
Then
we
have
this
separate
helper,
for
it's
called
language
utilities,
but
it's
really
just
helpers
for
the
parsers,
because
we
have
two
different
parsers.
We
have
the
solidity
parser
and
the
yield
so
Lang
duties
is
used
by
both
of
these.
The
Libya
has
a
parser.
Has
a
code.
Gen
has
another
kind
of
optimizer
and
then
lips
solidity
is
a
big
one.
It's
the
it's
a
monster,
it
is
it's
already
departure.
A
Does
all
the
analysis
I
mentioned
and
does
these
two
different
pipelines
for
code
generation,
and
then
we
have
two
smaller
libraries,
the
smt
library
is
just
for
the
SMD
subsystem,
but
I
think
that
that
is
also
split
up.
So
some
of
it
is
here
some
of
it
is
in
this
lip
solidity
directory
and,
lastly,
the
smallest
one
is
lips,
we'll
see,
which
is
a
tiny
binding.
That
is
the
only
Library
which
is
C
has
a
c
API.
A
Everything
else
is
C
plus
plus,
so
this
basically
is
a
wrapper
between
C
and
C
plus
plus,
and
that
is
what
is
compiled
to
M
script
and
into
JavaScript.
If
you
happen
to
use
any
kind
of
a
web
app
that
has
related,
it
would
be
used
few,
maybe
some
benefits
as
well.
But
you
know
one
of
the
bigger
problems
we
are
getting
into.
Is
these
libraries,
while
physically
separated
into
their
different
directories,
they
may
not
be
like
super
well
separated,
conceptually
or
even
like
interface
wise
one
example.
A
I
can
give
which,
which
is
I
kind
of
hit.
It's
not
like
a
you
know,
logical,
like
issue
in
there,
it's
more
like
just
a
source
code
issue,
but
we
have
a
a
loop
between
libu
leap,
evm,
ASM
and
the
front
end
they're
interdependent
on
each
other,
which
is
kind
of
bad.
If
you
want
to
separate
these
things
nicely
major
components,
they
do
have
some
kind
of
a
clear
boundary,
but
it's
everything
is
in
C,
plus
the
the
clearest
external
boundary
happens
in
two
places.
A
The
assembler
has
a
Json,
Import
and
Export
feature.
The
export
feature
has
been
there
forever.
The
import
feature
is
still
not
merged,
but
it
kind
of
works
and
then
solidity
itself
has
this
Json
AST
import,
export
I
think
some
tools
like
Scribble
may
be
using
it.
Basically,
you
can
skip
the
parser.
No
scribble
uses
a
typical
parser,
but
yeah
some
people.
We
wanted
people
to
use
it.
A
It
is
hard
to
integrate
with
with
like
JavaScript,
we
have
this
m
script
and
layer
and
we
have
the
C
wrapper.
It
is
hard
to
integrate
with
rust.
You
need
to
see
layer
as
well,
although
rust
does
have
like
a
C
plus
plus
binding
generator.
It
is
not
really
stable.
If
you
want
to
integrate
this
into
go
it's
the
same
case,
all
of
the
all
of
the
languages.
They
only
work
with
C.
They
don't
work
with
C,
plus
plus
so
I
have
a
few.
You
know
ideas.
A
A
Parallel
to
this,
because
this
this
can
happen
on
the
existing
code
base.
Prior
to
this,
we
could
start
working
on
components
in
Rust
and
we
in
fact
already
have
components
in
Rust
we
have
sources
rust,
which
is
used.
It's
used
by
Faye,
actually
and
I.
Think
at
some
point
fan
reused
it,
but
they
were
annoyed
by
by
the
size
of
the
binary
and
compilation
pipeline,
so
that
they're
not
using
it
anymore.
A
But
we
do
have
a
bunch
of
like
libraries,
new
libraries
in
Rust,
which
is
also
used
by
Faye,
and
some
people
in
the
team
now
are
working
on
some
crazy
features.
On
top
of
it,
the
first
useful
step
could
be
rewriting
the
assembler,
and
the
reason
behind
this
is
the
assembler
is
one
of
the
oldest
components
we
actually
never
changed.
A
It
would
be
a
really
good
task
to
rewrite
it
and
by
rewriting
it,
it
may
or
may
not
even
need
to
be
Rewritten
by
us,
but
we
could
use
an
existing
assembler
and
in
fact
etk.
The
evm
toolkit
evm
assembly
toolkit
I,
don't
know
the
what
the
acronym
is
for,
but
it
is
an
assembler
toolkit,
basically
for
evm
it's
written
in
Rust.
A
Well,
you
likely
don't
want
to
do
it
for
1.0,
but
you
want
to
do
it
for
something
else.
So
what
is
the
reasoning
behind
all
of
this?
The
main
reason
is
that
we
kind
of-
or
at
least
me
when
I
turn
solidity,
all
this
code
into
reusable
compiler
framework
I
want
to
make
sure
that
all
the
you
know
the
optimization
steps
we
have
all
of
these
features.
They're
not
just
wasted
they're,
not
just
there
for
solidity,
but
they
can
be
used
by
other
languages.
A
Imagine
if
we
would
have
had
like
this
compiler
framework
earlier
on,
you
know
it
came
to
like
llvm4
evm.
You
know
how.
How
long
would
it
have
taken
to
Forfeit
to
to
come
to
fruition
or
like
half
for
any
of
these
other
languages?
If
you
could
just
use
any
of
these
components,
I
listed
a
bunch
of
different
projects
which
are
already
in
the
evm
space
working
on
Rust
compiler
components.
So,
of
course,
we
have
fa.
A
A
A
S-Lang
is
a
project
by
hardhead
they're,
trying
to
write
a
compiler
as
well.
The
motivation
is
slightly
different.
They
want
to
have
a
person
which
is
flexible
and
supports
every
single
version
of
solidity
because
they
want
they
don't
want
to
like
certify
the
compiler.
You
know
mid
compilation
and
that's
the
problem
with
the
color
and
compiler.
It
only
supports
a
single
version,
so
why
would
we
want
to
do
this
because
I
want
to
attract
more
people
to
solely
compiler
development,
and
it
seems
like
C
plus
plus,
is
not
like
a
language.
A
People
like
or
people
are
interested
in.
It
has
been
kind
of
hard
to
attract
people
to
to
write
C
plus
plus
code,
and,
it
seems,
like
trust,
is
extremely
thriving.
Every
other
project
is
in
Rust
I've
been
using
rust
for
a
long
time.
So
I
would
be
happy
for
this
to
happen,
and
if
you
do
some
kind
of
a
re-architecting
like
this,
that
would
mean
that
we
have
an
opportunity
to
actually
improve
the
architecture
of
the
compiler
and
maybe
improve
the
language
itself.
So
that
is
the
next
one.
A
I'm
going
to
talk
about
is
what
kind
of
language
could
we
have
here?
You're,
really
surprised
or
not.
But
the
fact
is,
we
have
been
talking
it
like
this.
You
know
rust,
inspired
changes
to
the
language
since
2019
way
before
some
of
these
are
arrest.
Inspired,
evm
languages
came
about.
Oh,
it's,
actually,
another
sign
I
think
the
main
motivations,
the
main
reasons.
Those
discussions
were
started
because
there
are
a
few
issues
in
solidity
itself,
or
at
least
a
few
issues.
I
think
should
be
at
rest.
A
One
of
them
is
really
the
storage
and
implementation
itself
is
not
really
separated.
So
the
other
thing
we
have
right
now
is
this
contract
construct.
It
can
have
storage
defined
anywhere,
it
can
functions
defined
anywhere.
It
can
inherit
other
contracts
which
also
Define
storage
and
functions
anywhere,
and
you
never
know
where
storage
is,
it
could
be
handled
by
any
of
these
imported
libraries.
It
would
be
nice
to
actually
make
this
more
clear.
The
other
thing
would
be
nice
to
kind
of
make
clear
when
State
changes
or
state
access
can
happen.
A
We
do
have
some
of
this
in
the
language
today.
You
know
via
payable.
We
have
View
and
pure
functions,
but
that's
about
it.
It
would
be
nice
to
you
to
have
like
more
clarity.
Even
within
the
functions,
when
is
a
state
change
taking
place,
functions
can
be
quite
long.
I
think
good
code
bases
started
to
create
small
helpers
and
limit
the
scope
of
like
State
changes
to
those
smaller
helpers.
But
it's
still
people
can
write
no
matter
what
you
do.
A
A
A
Do
you
have
like
a
separation
of
this
could
be,
contract
could
be
struck,
people
leaning
towards
struct,
so
this
would
be
really
just
the
data,
and
then
that
would
be
the
implementation.
I
mean
it's
not
too
different
to
what
the
fee
is
trying
to
do
now,
and
this
is
the
distal
contract
I
had
as
an
example
before
yeah
I
mean
that's,
it
really
I
only
have
10
seconds
left.