All right, cool.
So again, apologies for being this late.
I really don't take it out on the people that are organizing this room.
It's really my fault.
So I hope still you have a nice day.
And I'll try to keep it short, so we stay on schedule.
So this is kind of an introductory talk for people that are new to Elixir and Alang.
So Elixir is a language which now already exists for 10 years.
And it's built on top of the Beam virtual machine, also called the Erlang VM.
So it had some of the properties that the Beam runtime has as well.
And the Beam runtime is actually created for telecom systems.
So it's meant to be 24-7 on.
And by doing that, it has to be full torrent, so if something goes wrong, it can still heal
and keep on running.
And because it has to be on all the time, it also means that any code changes should
be done on the fly.
All the system is running without interruptions, without bringing systems down, bringing systems
up.
But just keep things running on and changing the code under the hood.
It also needed to be concurrent, because it needed to handle a lot of incoming telephone
calls at the same time.
And it also needs to be distributed, because you have to connect telephone switches together
and make sure that everything runs smoothly.
So those are kind of the properties that Erlang also inherited from Erlang as well.
So when you look at other systems, multi-threaded, OK, programming can be hard.
So in theory, it should all work like we have, you know, if you want to do something concurrently,
we spawn a few threads and they do their work.
But in practices, because threads can actually interfere with each other's work, it actually
becomes a mess.
So hence the second picture.
The other property that Erlang has is full torrents.
So in Erlang, you set up a supervision tree in which a supervisor is actually watching,
monitoring, or worker.
And if one of those processes dies, then the supervisor actually makes sure that a new
process is spawned in its place.
And the system as a whole keeps running, even though one of the parts actually fail.
And so the mantra that's very often told in Erlang is, let it crash.
Nice timing, OK.
Because people feel safe by, you know, if there's an exception, if your code always
goes for the happy path and something goes wrong, Erlang developers tend to not care
that much about it because the system, like the supervisor, will restart that process
again.
So very exceptional edge cases are sometimes not covered because they feel comfortable
having the system pick it up from there as well.
Before Alexa came around, Erlang also existed for quite some while.
So Alexa also inherited some of the experience of 20 years building telecom systems, which
also makes it, for example, WhatsApp had only 57 engineers working for them when they
were sold to Facebook.
But only about 20 of them were Erlang developers.
The rest were actually mobile developers supporting Android, Windows, iOS, et cetera.
And they actually could handle a lot of users while having a small team.
So then the question also becomes a little bit why does Alexa exist?
And when people, like, innovate when they're building new things, there are approximately
three things, three ways they can go around it.
So they completely build something very new, which didn't exist before.
Or they try to combine the ideas from previous, from other fields, for example.
Or in some cases, people just put a new label on it and say, well, this is new.
This is innovation.
So hence the title of my talk is, is Alexa really something new?
Or is it just a new label on the existing Erlang foundation?
And some other languages, they, you know, they've tried to incrementally do some innovations.
But after a while, the original sources picked up those changes.
In this, like, CoffeeScript is a very famous example, in which the original language picked
up those changes and nowadays a lot less people actually use CoffeeScript.
So how we're doing on time, okay.
So the question is then also, why did Jose, kind of the creator of Alexa, why did he write
a new language?
And he was at a time when he wrote, Alexa was working at the Rails team.
And one of the things that he faced was trying to make Rails thread safe, so making sure
that several threads that were running in the Rails program weren't interfering with
each other.
And by doing that, he was actually looking around, how did other, like folks, how there
are other problems in languages, other frameworks, how did they solve that issue?
And that's when he actually stumbled upon Erlang.
And he liked it.
It was, you know, just the thing he needed to use.
But there were also some things that he was actually missing.
So for starters, the syntax stems from Prolog.
So it's unfamiliar for a lot of people.
So that means that new people who come to Erlang have to, you know, have a high barrier
to, okay, high barrier to actually get around because they feel unfamiliar with the syntax.
So he did that first.
And he also introduced other new syntax, for example, the pipe operator in which, like
the result of the previous expression, is piped into the next function as a first parameter.
So by doing that, you can avoid having a very nested function calls by having something
that's more readable, more clear to other people.
He also introduced more extensibility to the language by introducing macros and protocols.
And one of my favorites is actually the bottom one.
I'm not sure if everybody can read it, but it's an upcase function which takes a string
and upcases every letter.
And it does that under the hood via a macro.
So the Unicode definition, like the library definitions of characters is downloaded and
actually being translated to functions under the hood.
So when you call this, you're actually using, you know, some data that is transformed into
functions for the language.
I'll skip over this part because we don't have judgment time.
And you also actually see that those macros are used everywhere.
So even like, you know, defining a module is a macro, defining a function, et cetera.
Everything is actually implemented through macros.
The other thing that he also introduced is the build tool to make it easier for people
who are, for example, new to the language.
If you want to have a package manager, like before, didn't really have package management,
like in the sense that you could add packages to your project, but you had to download them
by yourself, put them somewhere, define it in your config, like, okay, this is the path
to my library that I'm using.
And with Hex and with Mixed, Alex just made it easier, but, you know, by having a list
of dependencies and go download it from a central place.
Documentation was also made more prominent.
For example, the doc tests, which are inspired by Python.
So in this case, we have a function defined, and above it is a document, a comment in which
there's an example.
And this example doesn't serve only for documentation, but at the same time, it's also tests.
So, you know, actually, you can, if you would change the implementation, you can directly
see the effect of it because the test is just above it as documentation fails.
So, and, yeah, the documentation is also accessible from Rappel, from other places.
And this was built before the LSP.
So nowadays, you can, you know, just hover over function in your editor, and you will
see the documentation.
But when Elixir was created, those functionalities weren't that common, like among other languages,
and that's something that's really nice to work with.
And the last thing that he kind of also introduced is a different culture, a culture which is
a little bit more open to newcomers.
So it's not like Erlang, you know, shed away from newcomers, but it also didn't, like,
make it easier for new people who are new to the language to get started with it, et cetera.
So that whole, you know, like, to come back to my question, like, is Elixir in kind of
new flavor on top of Erlang?
I think there are kind of projects stemming from Elixir which make it more interesting
and which are really new.
So, for example, NX numerical Elixir is an extension which makes machine learning easy,
and that's something that, you know, before Elixir, nobody actually thought would be useful
to do with the beam, with the Erlang VM, because it wasn't meant for that.
It wasn't meant for numerical, for number crunching.
But this library, this tooling actually makes it a lot easier to do, and that's very promising.
Phoenix is actually a web framework which was inspired by Rails, and now study arounds.
Phoenix is now an inspiration for Rails and other frameworks to work with.
And NERVs is also kind of an interesting project which makes it possible to run on smaller
devices like Raspberry Pis or something like this.
So to answer the question, is Elixir really different from Erlang?
Is it really, you know, an innovation or is it rehashing?
I would say no.
I think Elixir really adds something to the whole ecosystem, which wasn't that easy before that.
So with that being said, thanks for listening.
Thank you.
Unfortunately, we don't have any time for Q&A, but you can find, don't you?
Yes.
Here.
Again, I usually have the handle toxified, so on Twitter, if it still works or mastered
on you, you can also find me.
And I'll be around, I think, for today if you have any further questions.
So thanks again for listening, and apologies for being this late.
Thank you again.
Thank you.