Very short presentation about me,
what is BIM for everyone that doesn't know it, of course.
Thank you, David.
Thank you.
So thank you all for coming.
As David said, this is just a brief introduction on what most of us,
I think, already know the BIM and what's around there.
I'll try to speak louder because I don't think that those things are working,
but the camera is okay.
So obviously, this one doesn't work no more.
Come on.
Oh, spoiler.
Okay. So what is BIM?
BIM, as we know, is the virtual machine that powers the old Erlang,
Elixir, Glim, etc., etc. ecosystem.
It was originally built in the late 70s to early 80s,
and it runs in production ever since.
Very nice. It's almost 40 years of running in production.
Okay. The focus of the virtual machine,
since it's very conception,
was on concurrency and distribution in a moment where nobody was considering it.
Actually, people are still inventing the wheel of concurrency to these days.
Let's think of ACCA, for example, or things like that.
An interesting statistics about the BIM is that according to Cisco,
about 90 percent of internet traffic goes at least one time through BIM and Erlang node.
BIM is being used in production successfully by WhatsApp, Discord, and such,
to handle a very large amount of messages per second,
like more than one million.
Obviously, since we're all here and we are cool kids,
we do love doing things cool, like making programming languages.
So the first of all is obviously Erlang,
the one that started it all,
the old-wise guy, and that's an example of Erlang.
It's very inspired in its syntax by Prologue.
It is a functional language, dynamically typed.
There are some very nice things like pattern matching, binary pattern matching.
Actually, this is an example of the Ranch library,
which is a framework for handling TCP connections.
As you can see, there are things like tuples, lists, etc., etc., supervisors.
I'll talk about this later on.
And it's an example of a behavior, of an application.
I'll talk about this later on, too.
There are macros in Erlang.
There are preposers based.
And this leads to Elixir,
another language in which macros are first class, first of all.
And Elixir is much more recent.
Some say it triggered a renaissance of the beam,
of interest in the beam,
because of its ruby-like syntax,
which is, in my opinion, nicer than Prologue,
based on one.
But I don't say so for everyone.
This is an example of another library,
and it's under for connections to a kind of database.
Also, Elixir is functional,
just like Erlang,
and it's dynamically typed for now.
Because there's some work on bringing types to the Elixir compiler.
Being a beam language,
it also has pattern matching,
also binary pattern matching,
and macros, as I said, are first class.
And then there's the cool new kid, Glim.
I see many people rejoicing.
The syntax, it's a strange mix between an ML language and a beam language.
Its syntax is a bit inspired by Rust,
but the most important thing is that it's statically typed,
rather than dynamically.
And it also has a philosophy,
being a statically type of handling some errors before they happen,
rather than just doing it later on.
And it can also compile to JavaScript.
As I say, it is the cool new kid,
so it has to compile to JavaScript.
But then, as I said,
there are a number of other friends of the beam.
Least flavored Erlang, if you really like parenthesis.
Pure Erl, if you're an Askel guy who wants to run on Erlang for some reason.
Then if you're more Askel-y than Askel's guy,
and you want to try dependent types,
you can also compile Idris2 to Erlang, if you want.
And then just a bunch of languages that the great wise man Peter Weirding did.
So, Braggful, which is a PHP compiling to Erlang,
Lua compiling to Erlang, and all things like that.
He just loves making beam languages.
And he's a very nice guy.
So, why is people still continuing to build languages on the beam?
Because the beam has some kind of superpowers built in there.
Actually, let me interject for a moment.
What I'm referring to as beam is actually beam OTP,
or as I have written, he started calling beam plus OTP.
What's the difference?
So, beam is just the bytecode VM that runs the core bytecode code.
And it's register-based.
Then there's a runtime system called ERTS,
the Erlang runtime system.
That handles how to make this binary code run on the beam.
Yeah, that's true.
So, we have concepts, processes, synchronization,
because everything in the beam is a synchronous.
And ports, ETS tables, which are used for storage of persistent data and such.
It also takes care of scheduling the processes on the beam in a preemptive fashion.
And it's usually mixed, confused with the beam.
So, I keep referring to beam plus ERTS as beam, as everyone is doing.
Then there's another part, very important, in the Erlang ecosystem, that's OTP.
It's a framework that provides you with some battle-tested abstractions.
I think many of us use supervisors, gen servers,
state machines, and things like that.
Supervisors handle what happens if a process fails.
Gen servers are an abstraction on the concept of a server.
State machines are abstractions on the concept of state machines, obviously.
The great part of using the Erlang ecosystem is that all of these three
components provide one alpha of greatness.
So, we have three albs of greatness in total.
So, what are the superpowers, or beam plus OTP?
As I've recently started talking, calling it.
First of all, concurrency.
As I said before, the main unit of concurrency is the process.
The process is just a piece of sequential code that's running,
having his own memory, his own it, and sharing nothing with all other processes.
What's the point of it?
Handling failure in just one simple and easy way,
located just in the process.
Meaning that when you have a crash in your process,
only that process will crash and not the whole application.
Then, a consequence of that is that garbage collection runs on a per process basis.
So, you don't need like in Java to stop everything just to run the garbage
collector, you can run it synchronously.
And finally, since we do share nothing, the only way process is ever to
communicate with each other is by sending messages or signals actually.
This allows the beam to scale seamlessly from a single node setup to a multi-node setup.
You just rather than sending it to a local process,
you send a message to a process in a different beam node.
Then, this leads to the let it crash philosophy of beam and OTP.
Since every part in the end is just a tree of supervisors, a supervision tree.
You can also obviously propagate failure between processes so
that you can handle doing the right thing depending on what process is crashed.
But why in this world would you need supervisors?
Since we have Kubernetes that almost seem to do the right and the same thing.
Restarting our pod if something is not working.
Well, the main idea is that when if a network connection goes down,
you don't want to restart your application.
So, those are two different layers.
OTP focuses on the application layer, handling failures in your domain.
And then Kubernetes focuses on the larger aspect of orchestration.
So, you don't want to crash, as I said before, if a network question is going down.
You just need to handle that in your application and you restart the pod or your deployment
just in very specific cases or very tragic cases.
That's where Kubernetes comes into the rescue.
Being application-based, the supervision trees are obviously also more granular.
So, that you can define a different strategy rather than just turning it on when the process crashed.
So, it provides for your application a more flexible way to handle crashes.
Kubernetes does not.
It just handles networking, bring up and down pods, and that's it.
Those are different level orchestrating containers is a different level than handling failures in your application.
Next superpower of being a plus OTP is immutability.
It didn't seem so when it was built, but now we see its value together with a share nothing concurrency.
Because having no shared memory means that the processes cannot change the state of under process unexpectedly.
And that's the reason why we also have immutability of data structures.
This also leads to a referential transparency.
Even if the beam allows you to have some kind of side effects, for example, logging or networking,
it's just a pragmatic way of handling it rather than setting up a whole monad stack, for example.
Then, final superpower distribution.
As I said before, from the point of view of an application, it's the same to pass messages to a local node,
a node in the same virtual machine or in another node that is running maybe in another part of the world.
This allows you to distribute the work efficiently, seamlessly as a programmer.
And this is made by a built-in protocol to discover nodes.
And you can scale horizontally however you want.
The code that you wrote will just work most of the time.
Finally, since those things run in production ever since, there's a huge interest in observability and debuggability.
The most easy thing to do is connect to your live application and start an interactive shell just to see what's going wrong.
You can trace.
There's an interesting tool called tracing later on, and access all the information of a process and so on and so forth.
Tracing and profiling, as I said, are built-in into the machine.
They are battle tested by running in production for years.
If anybody uses ReContrace, it's very nice, but can anyone give me a match spec that works?
I never found a way to make it work.
And let's not forget hot-code reloading.
It's really interesting.
You can change your code while it is running so that, for example, if you have detected a bug in your live application,
you can just fix it on the fly and your application will just work with the new fix.
Then there are other interesting aspects.
The first one, pattern matching, is more interesting from one who is writing programming languages.
The BIM makes it really easy to write functional languages with pattern matching, also at binary level.
Then BIM is already container aware since a number of years, I think,
allowing you to use C-groups and Kubernetes, obviously, seamlessly, not what Java does, for example.
It makes it easy to have foreign function codes.
You just write a C-node that seems to be an orang node and just communicate with it.
Or you can use the FFI built-in.
What's the future for the BIM?
Obviously, the first part is being more and more largely adopted.
And then there are some interesting research level developments on bringing gradual typing to some languages like Elixir and Erlang.
Also, Elixir, but a number of languages, are doing a pretty huge job of developing numerical computing and AI on BIM nodes
in order to distribute those calculations in an easier way.
Obviously, there's also work on embedded systems, like bringing, for example, a small instance of the BIM vehicle machine on microcontrollers.
There's a work on that, especially at UMBM.
Then, the main challenge is obviously becoming a wider and wider adopted choice for the backend.
And in that sense, having all these people here is a very good sign.
Thank you for being there.
And if you have any questions, feel free to answer.
I mean, feel free to ask.
Thank you.