Macro Mayhem

All right. Welcome everyone to another episode of Macro Mayhem. We are coming to

you in person, live, live. Well, not live, but live

to us, live to us from Goatmire in Varberg,

uh, not Stockholm, Varberg, Sweden. Uh, we are

in the last day of the conference now and we have been enjoying it quite

a bit. It's 1:48 PM. Exactly.

On a Friday, the 2nd of October. Yes. Cool.

So yeah, we've been in Warburg with the Goatmire conference.

It's been amazing so far, and we're kind of like readying

up. We're getting ready for the last big finale, but after lunch,

we just decided to sit down a little and give you the news and latest

vlogs that might interest you. So getting to the news,

the first one is that OTP 29.1.1

and also 28 and 27 patch releases were released recently.

And they fix a lot of bugs, but in particularly 3

CVEs that are quite serious. And if you haven't already, you should consider

updating because the CVEs, they affect SSL, for example,

where if a client that you connect to through SSL,

the client could just say that they don't have a pre-shared

key, and then SSL would accept it, and they would not verify the

certificate of the client. So then you would, yeah, just anyone

could be the man in the middle and you would connect to it and SSL

would not throw an error. Bypass verification. Bypass verification,

that's the word. Then also another one, another CVE is in

SSH, where somebody could create an SSH channel

to you and then open up max channels, as many

as they wanted, and then just take all your resources away and

could cripple your application. So that one is fixed now as well. You can open

up to, up to 256 channels,

and you can configure if you need more channels. And the last CVE that

was fixed is in the ASN package, uh, from OTP, where a,

uh, there was a denial of service attack possible in which an abnormally

large object ID could be sent, and that would then cause resource exhaustion.

So that one also has been fixed. And these were pretty severe.

The SSL one was a 9.3 on the CVE

scale. 9.2, I think. 9.2. So definitely get those updates.

Exactly. Next up, Explorer 0.13 is

released. Explorer is a library that has

been taken over maintenance by Alex Kutmos since early this summer.

He's been giving it a lot of love, adding some new features,

some new APIs to work on DataFrames and Series, as well

as bringing it up to speed on the latest Polars.

Polars is the Rust library underneath, and from what I hear, they have a bit

of a moving target. They have a lot of breaking changes,

so it's a bit of work to get Explorer

on the latest. So thank you, Alex, for doing that. Take a look and

yeah. Check it out. The next 3 packages are

all from the same author, Mathias Polikait from

Denmark. I hope I said that kind of correctly. Mathias, he created

the 3 packages you might've seen, or I actually

found them quite useful, so I wanted to share their announcements

here. The first one is LetMe, the library that makes it easy for you to

write policies for access. So you can write a policy for

each actor schema and then which role should have access

to it, you know, and then what kind of access it should have. And it's

a very nice DSL you can use to create access

policies and then use them in your code. So LetMe has received

a small refactoring update and the latest

version is 0.0.4.

3.0.4. It's been a long week.

And then Matthias also updated his popular Flop and

Flop Phoenix library. Those 2 libraries make it easy for you to do pagination,

cursor-based pagination, page-size pagination, and then

also filtering, that kind of stuff, sorting. So everything you would

need to expose in your UI for users to go through your data in the

database, Flop would take over the passing of these parameters,

you know, kind of some validations in there and so on. So I used Flop

before, I quite liked it. And yeah, Flop has a new version now,

0.29.0, and Flop Phoenix has

0.27.0. So check them out if you haven't

already. Nice. Next up, AtomicBucket 0.5 was

released. This is a project that is a fast single-node rate limiter,

which implements the token bucket algorithm. Now, I personally don't

know what all that means, but I do know that it's a rate limiter,

it is backed by ETS and the Atomics package in Is that

Erlang or Elixir? OTP. In OTP. So it's,

uh, very good for making sure that everything is going in the order

that you specify for the atomics. And, uh,

yeah, it's a good, it's, it's one of those less known OTP packages, I feel

like. So it's a good example of it. That's why I wanted to mention it

here because AtomicBucket makes very smart use of the atomics module

and atomics modules. They make it very easy for you to add counters,

global counters to your Erlang or Elixir application,

and they are perfect for rate limiters, right? So if you want to count how

often a certain user has accessed the API

in the last minute, you could use an atomic for that to

just, you know, increase an integer by 1 every time a request comes in.

And these atomics are not immutable.

Well, they are just integers, but they're not

getting copied into a new value every time you update them. So that's,

you can update them extremely fast, which is great

for rate limiting. Right. And this release, it looked like

it was focused on performance, adding a little bit of macro

helpers to help with some stuff and generally

just developer experience. So take a look. It should be an interesting

release. Exactly. And then the next library that came

out, which I found pretty cool, is called Smolnet,

S-M-O-L-net. And this library uses

a Rust NIF underneath for giving you a more

higher-level or transport-agnostic TCP/IP

stack. So for sending TCP packages, and it does

not use gencp. And the specialty

about SmallNet is that it does not use the kernel network stack

that usually you use. So if you have an application on your server and the

server, the application makes an HTTP request, It uses the server's kernel's

networking logic and code, and then eventually also the internet

card that connects through Ethernet or Wi-Fi to the

internet, actually. And SmallNet abstracts that a little bit and gives you

a bit more a generic approach to it in which you can remove or replace

your actual networking stack with something else.

And this is very interesting if you want to build something on top of TCP,

for example, like encrypted tunnels, or you want to have,

um, Anything like Iroh, for example,

is an interesting package that makes it really easy

to cluster together your applications that might run anywhere

from your local computer to your production server to Raspberry Pi.

And Iroh just creates a network between these really

quickly. And I believe that SmallNet kind of is an idea

around this. And that's bindings to the Rust smalltcp

library. Exactly. S-M-O-L. S-M, small.

Yeah. Great. So, so check it out if you're interested in, in having

really custom TCP/IP communication with your own protocols

or encrypted tunnels, network simulations, packet level tests,

uh, and, and others. So that is SmallNet for you.

All right. And next up, xratatui 0.16 was released.

xratatui is a terminal UI library,

also a Rust NIF to, um, the Ratatouille

Rust library. And that is R-A-T-A-T-U-I,

Ratatouille. Kind of, I think it's a play on the name of, uh, the movie.

Yeah. Ratatouille, the, the mouse, right? Yeah. The mouse.

Um, And so, uh, this version is really

interesting to me because, uh,

Mauricio had brought,

um, he showed me some demos that he was doing with,

um, making it basically have a generic backend, uh,

to render characters or anything anywhere.

Um, and so he's using the, the Tui library then to render

buff, like pixels to a buffer. Even though it is just a, like a

TUI, you can render it to images. And he has a Phoenix

x Ratatouille package that was part of this group

of releases, I guess. And then he also has a Raster x Ratatouille,

which, um, was the one that he sent, DM'd me about, which he

used to, to put Ratatouille on the E-Ink name badges from

last year's Goatmire. Okay. So he showed me updates to it and it has,

you can do 3D renderings, you can do 2D renderings, images. It's very

cool. So if you use, uh, TUI libraries, like check out x-ratatouille.

Yeah, I used x-ratatouille for my LoRa devices,

which unfortunately I didn't have that much time to show on stage.

But, uh, I had a Nurse device and then in the Nurse device, I wanted

to run a TUI that I can use for sending messages.

Yeah, like a terminal user interface. And I just added Ratatouille to

it and poof, I had the perfect layout, perfect refresh rate.

It was, it was really, really nice. Yeah, it's a really cool library. Exactly.

And the last news item we have is another little library that

was released. It's called Gale, G-A-L-E.

And the interesting part here is that Gale is a Phoenix adapter,

like Bandit, that adds HTTP/3 support,

that is QUIC support. And HTTP/3

has been kind of like a moving target. It's very complex.

It's super complex, yeah. And there hasn't,

I think, yeah, Bandit doesn't have HTTP/3 support yet.

So it's interesting to see Gale that took a shot at this and actually added,

like, used Bandit as a base for HTTP/1 and

2. But then if you upgrade to HTTP/3, it uses a

ZigNIF for handling the communication.

And the performance improvements here were very impressive where

if you would use HTTP/3 with like 7 streams or

12 streams, it would have a 430 times speedup

of bandwidth of communication over HTTP/1

and 2. So again, HTTP/3 seems to be quite experimental

a lot and not every, like there is very little support for it yet.

So it was interesting to see Gale that took a stab at this and maybe

it will replace Bandit. I mean, not replace it, but extend

it and then become a new default or maybe Bandit will eventually integrate.

Or take approach, the approach that Gale took maybe to integrate HTTP/3

as well. Um, I don't see that like anytime soon,

but again, this was an interesting project to, to look at,

to see how it would be possible. Yeah. And actually looking at these

lists of blog posts and releases that we have here, it's also very interesting

to see that we have a lot of NIF-based libraries going out.

I think it's great that we have such great interop with other

native languages. And even though we don't have an HTTP/3 QUIC

implementation for Elixir yet, we can lean on other,

other ecosystems to add support for until we get one,

if we get one. If we get one, you know, this way we can also

reuse what other, um, projects do. Like you

can use a ZigNIF or a RustNIF, right? And then, you know, everyone just uses

one RustNIF to have HTTP/3 support,

but then you can add it to your ecosystem very quickly. So huge shout

out to the Rustler team, the Ziglar team, and the,

the, the folks behind, uh, is it CMake for C-based

NIFs? So it is, we're standing on the shoulders of giants here.

That's for sure. So yeah, whenever somebody says, oh, Elixir is not fast

enough, I'm like, what do you need? You know, what needs to be fast?

And then, okay, well, let's write a Rust library for it and then it's going

to be amazing. Exactly. So fast. You just have to think about how you send

and receive the data, but otherwise, yeah,

you can use Rust and then nobody should complain about speed anymore.

Speaking of giants, our first blog post here is by José

Valim himself, Evolving Programming Languages in the AI Era.

This is, um, kind of the extension

of his ElixirConf US talk, and we cannot recommend

reading this one enough because it is challenging some questions in our community,

how we move forward. That's also showing like some of the use case for

the type system. So what did you think of this? I enjoyed it

a lot. It's a more,

I would say vague, spectacular, not spectacular,

where you speculate. That's the word I'm looking for.

Thank you. He speculates about how the future could look like

for software engineering in general, but also in particular to open

source communities and language communities like the Elixir community. In this AI

era. Yeah. What will be in 2 years from now? Where will

we be? And what do we need to look out for?

Because he raises very good points. For example, he focuses

on 2 parts. One of them is a little bit how we humans

as developers will be impacted by the AI

era, but then also how will programming languages need to

evolve and what will they focus on? instead of what they have

focused on in the past, like what will change there? And the

first part is about the community building part. Do you want to talk about that?

Well, I think there's a couple of questions here is that one

of the questions he posed, rhetorical questions, I think, is that if

the language is no longer that important because AI

can just generate whatever code, Does it really matter?

Does it all of— does work on languages themselves matter? Are AIs

just going to be generating like assembly bytecode for your machines in the future?

But now you're jumping ahead. Now you're talking about the programming languages. Oh,

that was right. Yeah. But let me talk about the community aspect first.

Because the community aspect here is obviously important to us as a community

because a community is also built around the frameworks

and libraries and the language. That we all use,

right? So you have the Elixir language, but then you have Phoenix and other,

and NURS, like other, and Ash, like all these frameworks,

they kind of build the overall community by creating

a community of their own. And now with AI being able

to write most of the things you need, the question here will

be, will these frameworks still be a driving

factor to our community? And then if they aren't,

what will be, right? So how will we continue to get,

to build a community and to keep it together and share and collaborate

on software, which brings us together usually?

Again, José, he doesn't give any answers. He's just asking questions,

but I think it's an important aspect. Right.

And then he moves onwards, which you also mentioned, like how

will programming languages evolve a little bit.

And I think he makes a great point that he also has made before,

which is, if you make a language easy to use to a

human, it will also be easy to use to an LLM. And we've heard this

at a couple of conference talks here and at ElixirConf US.

I think Zach Daniel mentioned that quite a bit for his talk at

ElixirConf, which the recordings are out. So they're all very

good questions though. They're all very good points that I I think it is

something that we see with AI usage is that it's easy for a human,

if you can understand it well, I think that's the draw of Elixir for a

lot of us. It makes a lot of sense. And yet we also see Elixir

scores very well for some of those Trust Me Bro benchmarks.

That's research. Research. Yeah. Yeah.

But so José, yeah, he makes some valid points about

this. And then, then he continues talking about the actual language design and how a

language will evolve now that you have different requirements coming from

LLMs. And first, one of the discussion points in

maybe the broader ecosystem was, do we still need compilers

or will LLMs just start writing assembly? Is it just

a text-to-assembly machine? Exactly. Like, do we still need languages like

Elixir and everything? And he says, yeah, of course not. Like, we will still use

languages still. Did I say this right? Like, he does not buy the argument

that we will not use languages anymore and everything will be assembly.

Because, yeah, a language, the abstraction that it brings and

the ecosystem and the foundation that it brings, you don't

want to rebuild this for every single project. Right. And he's also not

saying that Elixir is the perfect tool for every single job. There are specializations

within languages that we see. Some are really good at processing

lots of data really quickly. Some are really good at parallelization. Some are good

at doing scientific verification, like Lean, for example, is a

very specialized language for mathematical proofs. Like you would

not want to write this yet again in assembly. And then also, how do you

share it with others? How, you know, other mathematicians, they would need to start reading

your, your assembly code. Not to mention if I wrote my

library, my Phoenix app or whatever, not Phoenix,

assembly-based app to work on my dev machine,

then you have to support your server or something, your NURBS device,

whatever. All the work that we have been doing and that frameworks

and libraries and kernels and operating systems give us, I mean, that is It's

not for nothing, right? Exactly. Yeah.

But one aspect that he says will be interesting is

agentic tooling. So how do we make our language more accessible

and more effective and usable to the LLM?

What I found interesting here is that he says that like

some of the aspects that already helped writing to

write better and more verified code, like specs and types,

for example, That is something that languages or like Elixir,

for example, already has, but it might not be used enough because humans,

you know, they're rather lazy and they don't want to write code. And then also

the types or the specs on top of it. But now— Now with LLMs.

LLMs, you can say, always write the spec, always write the type.

Exactly. So, and then that gives better tooling

for other LLMs or other agents at a later point to go back and

know how to use that. Not to mention the fact that we can then do

our static code analysis with the tooling that's being built around the type system

and things like that. Exactly. And my LLMs always have been writing specs,

even though I never asked them to. It's helpful because they show up in the

code hints when you do an LSP hover. Yeah. Yeah. When you

still look at the code, like,

if you look at the code. I'm outing myself. I still look at the code.

Oh, he does. I still do too, but my LSP never worked, so I

don't have that anyway. But yeah,

so this is an interesting part where if a language now

already offers these kind of formal verification

systems like specs and types and so on, the usage of

those will maybe increase because LLMs don't mind

also writing specs and types and these kinds of things themselves,

right? So if a language offers this, now LLMs can really like

boost it and use it a lot. And then it's also the the obligation

of the language to then use it more and help more and find more bugs

with it. So on. Right. Yeah. So I like the direction

our community is going with the type system. I think this is a great improvement.

Definitely. I found a lot of, uh, well, not too many though, but sometimes

you make a change and then all of a sudden you get a big ass

warning and I'm like, oh, okay, well, maybe I fix it. Or when, what was

it? 1.18, 1.19 was released with the first

comings of the type system. And then it spat out all those warnings of like,

this is an unused function head because it cannot match or things like With maps

and structs and that kind of stuff. That was a big difference. That was a

big deal. So, um, I think we will see more

of that as the type system gets fully developed for, I think,

structs and— I think it's fully developed now.

Well, when, oh, when we start typing it ourselves,

typing our functions. Which might or might not come in the future. Which might or

might not come. José, he pushes it. He delays it as much as possible because

his argument, and I agree with him, is If we can do it for the

developer, why would we need to ask them to, right? So they try to really

go as far as possible. And yeah,

2 other points that José made is about the future of

LSPs, language server protocols,

processes? Protocols. Language server protocols, yeah.

So will they still be relevant? Because as like

how humans use an LSP is when they actually write code and then

you might have autocompletion. Or you might go to definition, that kind of stuff.

And he argues LSP will continue to be very valuable

and important, not that much for the autocompletion or

the go to, but like not for the autocompletion, but for the

go to definition, for example. Right. And when your agent

knows how to say, hey, I'd like the entire body of this function,

can you tell me where that is? It doesn't have to go reading useless junk

into the context to then You know, try and find it. It knows how

to do all of that with the LSP. Yeah. So actually LSP

might change a little bit like this so that they offer more

support to LLMs to find code, find the call sites

of a function and that kind of stuff. Because right now my LLM always

uses basically regex through the entire file

system instead of using the more intelligent LSP

tools. So Yeah, hopefully Elixir can—

It'll be interesting to see how it all develops. Definitely.

Yeah. And then lastly, um, there's one

argument that he makes, which I also agree with, is that,

um, previously for also for many other languages, the debuggers

that you add to your code and then you execute it have been the primary

way of understanding the code and debugging it basically.

But he argues that that will go away a little bit because LLMs,

they don't want to set a breakpoint, run your code,

find, you know, the issue, set another breakpoint,

rerun the code and so on. But they will rather want

to have runtime observability, which we have with IEX,

for example. If you run the server locally in local

development, you can IEX into it and then you can run functions, you can

read the logs. You can read the state in memory,

all through these very nice REPLs that we have. So he argues that

that will become the primary way for the LLMs to debug

basically what is happening in your application. Yeah. Right?

Yeah. Many smart things. I'm not surprised. It's a really good blog

post. It is. So definitely go take a read. I can't

recommend it enough. And it's like, I think it's just a collection of

thoughts that he said he put together from discussions at ElixirConf

and all this work on the type system, being in the community,

a lot of uncertainty with our industry right now. So,

um, yeah, it's interesting to see where José's head

is at, at least. Yeah, because he has always been a bit more critical or

realistic, pragmatic about it than others in the industry. So I,

I, I value his opinion quite a bit because I know it comes from

a point where— He's thought about it a lot. He's thought about it. Yeah.

And there's also some discussion on the Elixir forum about this article. So we'll leave

a link in the show notes for if you want to check that out and

see what others are talking about. And share your own thoughts about it. Yeah.

Then we have 2 more blog posts. One of them is by my ex-colleague

and friend, Ryan Zidago. He wrote a nice little blog post about keep

your product knowledge close to the code. And what he argues for

in this blog post is that When you think about function docs

and module docs, usually as a developer, you think about writing

the technical aspects of what, you know, what you

will see, like the function or the module you're describing. But Ryan,

he argues that in these documentation blobs, you should also

add the product knowledge and the reason why this function does that,

for example. And I fully agree with him. And I think I also have

done that quite a bit in my past. Where when you wrote a module that

behaves a certain way, you also document

why it behaves a certain way based on the product requirements.

So based on the business requirements about these decisions you made,

right? Because they belong together. The product decision influenced your

code decision. So if you only document how the code works

and not document why it works a certain way, In the future,

it's also harder for you or another developer to go in and understand,

well, why is it doing this thing? Right. It's like co-locating your Phoenix

templates, but kind of at a higher level of thought.

Yeah. Like to just add product information next

to technical information. Exactly. Yeah. So very nice blog post by Ryan.

Yep. And last up, we have a blog post by Herman Verschuuten,

uh, about Bluebeam. Blue-green deployments, um, on his own

server, his own bare metal server. Uh, it was mentioned in

the XAML thread on the forum, but it's kind of

a neat article because he walked

through all of the steps that he took to get this custom deployments

working with Caddy, um, shipping his

releases to the server with, I think it's SSH over the XAML tool.

And some problems he ran into specifically with EPMD.

Yeah. XAML is X-A-M-A-L. So it's like a Kamal rewrite

in Elixir. Elixir XAML. Elixir Kamal.

Elixir Kamal. Yeah. X-A-A-M-A-L. Yeah.

So yeah, Herman, he documented the

problems very interestingly or really well that you

will run into when you deploy an Elixir app. For example, EPMD,

which is a service that Erlang uses to cluster your

machines together, and that connects to one port

on your system. So if that port is blocked by

the old application, you can't start the new application in

a blue-green deployment way. So you can really only stop the old application

so that it frees up that port and then start the new application.

And that's really required because if you didn't know which port to talk

on, then it wouldn't be able to discover you. Like it would just be guessing

at ports. So, uh, EPMD is a really useful

app, but it's also, um, has these constraints.

So what did he do? I think he used Caddy.

Well, I'm not, I know he used Caddy, uh,

in front of the whole thing. So he, he started Caddy and Caddy connects to

ports 80443 and you know, 9000-something that

you use for EPMD. So Caddy is the only application that is continuously connected

to those ports. And then Caddy exposes these

ports to your application, but it

doesn't expose that exact port, but it might

give you port 9001 for application 1 and

then 9002 for application 2. And it redirects

these ports to then the port 9000, which your EPMD

service might listen to. So, uh, yeah,

basically Caddy does the, the proxying here. And that

allows you to then do blue-green deployments properly because you can spin up

one application and connect it to port 9001 and

wait until it's good, healthy, and then switch over just the,

um, which application then sends data to the port 9000.

Exactly. And Herman also mentioned in his article how much difficulty

he had with getting Caddy to work with this system of blue-green

deployments. And whatnot. There's an API for it, but it seems like it

prefers if you reload the Caddyfile, the config file for it. And then eventually

he mentioned that he found that there's a Unix socket to configure it separately.

So it's a good read. I know Herman is using this in production. He runs

a business where he has a lot of apps. So he's

doing this in production. It's a good read. Um, check it out. I will need

to look into it because I need to— You need to do something similar.

We talked about this. Yes, exactly.

Anyways, that finishes the news and blog section. We have one little

section about meetups and conferences. So take it away. Do you have your timer ready?

Not today. I can set up a timer. Alrighty. I'll be done

before you get us started. Meetups and conferences.

NERD meetup EU is on October 14th. We meet at 7 PM

CET, European Central, Central European Time.

It is this month we are Joining Isaiah

DeRose-Wilson, the previous ex, he just

recently departed, the CTO of SmartRent is going

to join us where Frank and John and a lot of the core team were

working for a while. He's built a lot of cool little robots and

he's going to talk about them. So yeah, come join us for the Nearest

Meetup EU. We are remote. That's October 14th at 7

PM. Central European. Remote via Zoom. Yep.

Okay. Uh, also upcoming is CodeBeam Europe,

the conference in Haarlem, Netherlands. That's October 21st, 22nd.

And there's an unconference organized by the EEF beforehand.

Um, there will be links in the description to go register for those.

Um, they will be a great time. You're speaking there, right? I am speaking about

the vulnerability work I've been doing with the EEF to secure the,

uh, Beam ecosystem. Right. So this is a great conference. I went last

year, um, and it's more than just Elixir, but it's a great convergence

of the Erlang, Elixir, Glean folks, everyone from

all corners of the OTP land. Exactly. So look for those.

And yeah, if there's other meetups, conferences,

things you'd like us to highlight, send them in. Um, we are happy to announce

them here on the show. Good. Peter, even though We

have fewer items to talk about. You were slower than usual. So next time,

next time we have to speed up again. Yeah. Next time. Well,

Peter, do you have a joke for us? I do have a joke. Let me

check my very long list of puns. Um,

well, I do have a DNS joke, but it might not resolve.

Yeah. Wasn't too good. Oh, come on. Nah, it wasn't too good. Okay. It's always

DNS. It's always DNS. Okay. One more. Um, how about this one?

Did you know that a mosquito can fly, but a fly can't

mosquito? Also pretty bad.

It's pretty bad. It's pretty bad. In a live situation like this, you actually see

that somebody's not laughing. No. Um, okay.

Spare the audience. Spare the audience. One last one. This one is good.

This one is good. Okay. Okay. So what is important?

When an ant goes to another country, it is called

an import ant. That one's

better. That is better. That is better. You should have led with that one.

Good. Okay. That's it. And that's it. That's our first

section of the episode. So if you're not interested in our discussion

about Goatmire, where we are currently, and we will also go back to after this

recording, you know, you may tune out now, turn off the radio.

Um, which I also spoke about in my talk quite a bit.

So maybe I could, you know, interest you in staying with us because

we will talk about our experience here at Goatmire, interesting talks we've seen,

interesting discussions we had, uh, learnings.

It's been a lot of fun. It's been so much fun. So this

is, this is a discussion section now, right? Right.

Right. Goatmire. Where do you want to start? Oh man, so much. I mean,

you were here first. You arrived last Friday already, right? I arrived on Saturday

morning. Saturday morning. And so I helped out with some of the setup

for all of this secret show that was going on.

Um, so if you're listening to this,

um, I guess you could have been here.

There's some, some listeners that have come up and said hello, but if

you were not here, you're wondering right now, what is this secret show

that we're talking about? Um, and Lars and largely

Flora, who did the puppet show at Goatmire last year,

describing the lifecycle of a process. Yeah. have taken

it to a whole nother level. And let's see,

what do you want to talk about first? There's a tree. There's a giant LED

tree. Okay, I can talk about my play

because before we started recording this, I literally went on stage and played

a goat. And I was killed by Lars,

who played Odin. I don't know why he killed me.

I still don't know. The finale has not happened yet. And so we need to,

we do need to wrap this up because I want to see that finale.

Exactly. But so what Gus is talking about,

basically in between talks, I think 3 or 4 times a day,

there are short little sketches that they play on stage,

which for example, I just played where I was a goat sleeping. And then Odin

came in and said, have you finished your work? And I'm like, yes, I did

finish my work. And he said, okay, then deploy it because I have a meeting

with the investors coming up. And I deploy it with like a huge 3-meter-tall

tree that has nerves because like it uses nerves

to make LEDs on leaves flicker.

So I was deploying it while the tree was flickering and then

Odin killed me. I don't know with his— I don't know why he did that.

Because he's an asshole. Apparently. But yeah,

he's extracting all value like a good capitalist.

Not paying me for it. Apparently not paying you for it.

He's been pushing hard deadlines. And then you had to get help

from Mimir, which is a, in Nordic mythology,

the god of wisdom. The smartest man alive or smartest god.

He's a floating head in the mythology and in the

show. There's a giant floating head which has someone inside,

and Mimir represents the god of wisdom. So it's AI.

And Mimir has been spewing toilet

paper All over to help the goats write,

write the code and get it pushed to production. So for a while there,

the tree was all red and yellow and looked unhealthy because

there was just so much toilet paper on the stage. So, so that

is just one part of Goatmire that was already, that already would have been the

greatest, coolest thing we could talk about for the entire next year. Right.

But then there were also the, the, the starting show on, on Wednesday.

Right. I didn't see it because I was the first speaker right after, so I

couldn't see it too well from behind the stage, but you saw it,

right? Yeah, I mean, it's still part of the goat story,

and it introduced Odin and Lars and a whole bunch of the characters

in this. But I kind of actually

want to talk about the orchestra. Oh, yes. And the live music that

we have, because there's not only people that are up there on

stage acting out some of these scenes, there's also music to accompany them,

which is what I was helping set up when I came here early. Because a

lot of fun. Because listener, imagine, I mean, you imagine an

orchestra or maybe you just imagine, you know, like a xylophone

and a drum set and a crash cymbal.

And then also you had like a bell. So these

are all instruments. And when we talk about live music, you would think that people

play these instruments. However— That's not the case.

It's not the case. These are Nerves-powered devices? These are Nerves-powered devices,

and they're spread out throughout the entire auditorium.

So the glockenspiel, which is the

xylophone-like thing, is right up at the front. There's a drum set kind of up

at the front, but up in the balcony, there's 3 singing bowls.

There's cymbals somewhere over in the crowd.

There's a whole bunch of stuff. A whole orchestra. A whole orchestra.

And it's all connected to a Wi-Fi network in the theater.

And it's all, all the devices, they're all like Raspberry Pis that are just

powered there. And they are hooked up to a cluster on

that network. And they're all driven by a laptop offstage. And that laptop

has an app in it that one shows a whole dashboard of

all the devices that are connected and, and controlling. It's like the, the big

controller of everything. And they're taking MIDI files, the music,

the digital music files, and dropping them into the

app. And then they click play and then the whole orchestra just starts going and

it's just sending RPC calls to all of the devices that say,

hey, play this note now. Hey, play this note now. Hey, play this note now.

So for every note you have an RPC call or is it kind of like

buffered or periodic? It's buffered a little bit because network latency. So they

say in When your clock reaches this time, then play

that note. Okay. Right. And all the notes are driven by solenoids.

So a solenoid is just a little device.

It has an iron or steel core

inside of it, a rod that can slide up and down, and then

it has a wrap of copper wire. And so when you apply a current through

that wire, it creates a magnetic field, which then triggers the iron to move.

To move, like up or down. Up or down. So it's used

for valves a lot. So it's like a switch on-off, things like

that. And here we're using it, we're triggering it really fast to like be

the hammer to hit the xylophone. Or for the drums,

it's pulling down and it pulls the drumstick and hits the drum.

The drums are really cool, by the way. They are really cool. So cool.

Yeah. And the thing is, when I first heard the music, I was like,

okay, this is a background track. You're just playing, you know, you're pressing play on

the speaker. AV tech guy to go play a cue. Exactly. Okay, play. But no,

these are real devices spread out through the audience, through the theater.

And yeah, and then you see that, oh, because you hear the xylophone and there's

a nice melody and everything, it kind of sounds like a MIDI thing. And it

resonates through the whole theater. It does. And then you're like, hang on, that's a

real device, actually, a real instrument. And it's played by a Neurse

device, which is— Just so cool. And I'm really happy because

I got to Rickroll the audience. I don't know if you saw my 10-minute

spiel up on stage. I think you might've been prepping or chilling after your talk.

But, um, I had 10 minutes on stage where I was talking about,

we'll get to them, the badges. But, um, and last

year I had pseudo mode, if you remember. Pseudo mode for the badge. For the

badge. Right. And it's in the settings. And so when you activate pseudo mode,

uh, you get a Rickroll on the screen. Um, so this year I was

telling them how to, how, how to use these badges. And of course I have

sudo mode, which again plays a Rickroll on the screen.

Um, but when I was up on the stage, I was showing the simulator and

had all the big simulator, the image on there. And then I got the,

I got the team behind the stage to say, hey, when I go to sudo

mode, can you play the Rickroll on the orchestra? The Rickroll.

Nice. So that was a lot of fun. Yeah. You were Rickrolling

the audience with NURBS-powered instruments. With NURBS-powered instruments.

And then it has been a part of several talks now too. Um,

the Fledex talk, which is the library that is

used to power all of the LEDs. Um,

Matthias, uh, had done his talk where he was talking about

how all of it works, showing some code examples. And when he did the code

examples, the tree, which it's a 4-meter-tall tree,

like, what is that? 12 feet, 13 feet. Who knows?

Um, for American Listeners,

13-tall-foot tree. Um,

and it has 900 NeoPixel LEDs

on it, 3 strands of 300. And so each

of those strands can drive the LEDs and to any color,

uh, individually addressable. So along the length of the strip,

you can say, I want LED 13 to be red or something like that.

Yeah. So it's wrapped up around the tree, which means then they've

counted all the LEDs very meticulously and they can light the

leaves individually. They can light the stem individually. And yeah,

it's been cool. But during Matthias's talk, since he wrote the

Fletch library, he actually connected to the tree and showed the different animations

that you can do with Fletch, the ways you can find things, how it's,

yeah, it was very cool. I mean, so we, we had the talks,

uh, the, the little place in between, we had the instruments,

we had the tree. And you also already mentioned the badge. And I

think the badge that, well, if you're just listening to the audio,

you can't see it right now, but we're going to hold it into the camera.

We described it, you know, also in the last episode, but it's

a little tablet with a full-size keyboard and a couple of special

buttons. And it has, in the standard form, it has a kind

of transparent tainted background so you can see inside

it. Yeah. And it has a little LCD screen. OLED even.

No, it's just LCD. Just LCD screen. And it's running on AtomVM.

And I mean, last year already you had some badges, which compared to these felt,

you know, like the beta version of badges. And this feels to

be like the 1.0 version of the badge. I certainly learned a lot when we

did the badges last year. But the cool thing is you also

had a workshop about them on Tuesday, right? Where you first handed them out.

Right. Out of a sudden, like, okay, there are some

apps on here that are cool, but then people just started going nuts

with adding their own. Absolutely crazy. I've been blown away.

The people who got the badges early also like learned how to put code on

them. And then of course, with the advent of AI and

whatnot, LLMs, people have just been going to town.

It's crazy. I've been, every time someone comes

up to me and says, hey, look at the badge. This is the app I

made. Like, I'm just blown away. So, so which, which some of

the apps that I saw were Connect Four between

2 badges. Between 2 badges. So at the top of the badges,

there are 2 little LED— no, what's that?

Yeah. IR receiver and transmitter. Yeah.

Infrared transmitter and receiver. And if you

hold them top to top, 2 badges, they can communicate

through infrared. And you can use that to then, for example, play Connect

Four. Right. The intended use case for this was to be I

call it poor man's NFC. You tap 2 badges together and then you

can share your contact details. And that's worked surprisingly well.

I was not certain that it would work so well, but people seem to be

having a good time sharing their contact info. Um, and so,

but since it's there, it's exposed to some of the things that the, the,

the apps can take advantage of. So Benjamin Mildy,

uh, lost Cobra Kai on the forum and most places online.

He made Connect Four where you put

the badges up next to each other, you press, you can start

your moves and then it sends it to the next badge and then they can

see their moves. And then from there, it's, yeah, it's really cool.

And so Connect Four, and then we also saw, which other apps did you see?

For IR, I saw a couple people using multiplayer

games where they would share the joining info.

And then connect to Wi-Fi and then just connect

directly to them. And so one guy made a racing game and

it renders like much faster than I ever thought it would.

Is it like 30 frames per second even? Not quite 30 frames per second.

It's like 4 frames per second. Oh, still good enough. Yeah. Plenty fun. And then

you could move the race. You could play with your arrows. You could play

with the arrow keys or there's an accelerometer on the badge. And so you can

tilt it. And so, isn't that just, it's so much fun.

So you tilt it to the right and then the car drives to the right.

Exactly. Tilt it to the left, it drives to the left. Can you accelerate and

decelerate maybe? You had to press the spacebar for the acceleration.

So that's the next step then. Yeah. I'll tell him he shouldn't, he should

make it like that. I've also seen,

um, Doodle Jump. Do you know that game? Doo Doo Jump?

Doodle. Doodle Jump. It's the one where it's like platforms and you're

trying to go up infinitely, essentially. And so originally

the first version he showed me is like, oh, you have this little blob and

it's bouncing from platform to platform and you can control it with the arrows.

Then he did the same thing with the accelerometer. Then you can rotate

the badge and make it, make the game work. And then

he changed the blob to a goat for Goatmire. Of course. Of course.

And then he made the different platforms. Some of them

are trampoline, they bounce you way up. Some of them are They break the first

time you hit them. Some of them have spikes on them. So I'm just

shocked that it can handle all this. And that is all running on AtomVM,

right? All of it's running on AtomVM. Okay. In Elixir. In Elixir.

Someone else made a Tamagotchi. Uh, someone made a,

like a 3D, uh, like the Raycaster

Wolfenstein. Right. Like, like Doom kind of thing

where you walk towards, like through A maze

of rooms with walls to the side and you can move forward and sideways.

Right. The one I'm really excited for and

that I need to spend some more time because it's a bit more of an

involved change, but it is going to be, it's going to land as a PR

and we're going to have it in eventually. But, um, there is

an implementation of an app store for,

for, for the badges. And I think that's super cool.

Um, because yes, the games are really neat, but as myself,

I don't want to include them all by default on the base firmware.

And they take up a lot of space if they have big images and things

like that. So you can't download all the apps, you can't include them all.

But if there's an app store, you can download them, you can offload them,

you can do whatever. Like, I'm really excited for that.

And I've talked with a different Matthias. Yeah. Um,

he's, uh, been implementing this and so That's,

it's really cool. I'm excited for that. Um, but look for those changes after

Goatmire. I think this thing, it seems like it's a fun, it's a fun

toy. It's a fun way to like have your first hands-on

experience with AtomVM. And I'm really excited to see where people take this.

But it's great hardware too. You know, it's, it's a good LCD screen.

It's a good keyboard and it has the infrared and the accelerometer.

Yeah. Yeah. So. There's so many, there's a lot of capacity that

you can just play around with. Yeah. And that's what I learned last year with

the E-Ink badges. They're really cool devices, but our use

case for them was, I mean, it was just really

minimal. It had 2 buttons on it, an E-Ink screen,

and that's about it. Yeah, the refresh rate was not great to, and not

fast enough to write, uh, to play games. I mean, you made Snake on it,

but that's about the limit of what you could do. It was updating once

a second, so that was still okay. Oh, speaking of Snake, I saw someone made

Snake. Someone made Tron, someone made, uh,

yeah, a bunch of stuff. And, and the, so yesterday evening

we went out for dinner and somebody else showed you, showed you the batch and

you were blown away. I was blown away. So,

so we ship these with AtomVM and the idea is that you would

run this with AtomVM because it's an Elixir conference. And of

course we are encouraging that, but someone else had said,

Hey, this is a really cool hardware platform. And I know that what's inside the

chip is an ESP32-S3. And,

um, it's supported

for a lot of like retro gaming emulators.

And so there's a project, I don't know which one he actually did, but he

basically forked it, added support for the keyboard, um, and then got

a retro gaming emulator running on this badge in C or Rust or whatever

it was. written in. Um, and so when he handed it to me, it was

loaded up with old school Mario. It was Mario playing on

the little screen. On the badge. And the keyboard worked and

like, oh, I was just blown away. And it was, it was a very fast

refresh rate, faster than we have with AtomVM, to be expected because they're,

it's not rendering, it's rendering in buffers and can do

a lot of optimizations, whereas we render each frame completely.

So it was very cool. There's a lot of potential for these devices.

I'm really excited to see what people do with them. And yeah,

hopefully at some point in the future, I think that we might be able to

make these available for people who didn't go to Goatmire. Yeah. But for now,

if you are not here, I, yeah,

you really missed out so much. You did. Not to add to the FOMO,

but— Well, yeah, but I mean, now it's over and you could just only feel

bad for not being here. We told

you, you gotta come. We told you many times, like, this is the conference of

the year and it will not happen next year. And after that, it's undecided

yet. So I think this, that also has led

Lars and the team to make it the biggest event

and everything they wanted to do now. Yeah.

It's okay. Lars needs a life. He's just been— He needs a

life. He needs a rest. Yeah, he does. Really. I think it was his wife

mostly who said, well, yeah. Yeah. I think

it's, it's something that's incredibly fulfilling, but he also I

don't think he gets to experience the conference. He's behind the scenes, in the,

behind the stage, like prepping the next person. Okay. Are you ready to go speak?

Are you ready to do this? Not to mention the whole show that's going on.

So it's been exciting. I also have really liked to

see that Pushin has been mentioned a lot and used

in some of the skits used by a lot of presenters that

are putting their slides or projects on Pushin. Yeah. How has

that been? It's been absolutely amazing and

a little, not overwhelming, but like intimidating at

how much people like the platform. Yeah. So people just

started signing up for it and then I walk around and they're like, oh,

you're Peter. Are you that Peter? The Push-in Peter? I'm like, yeah, I'm the

Push-in Peter. So I got plenty of signups and it's just

the best feeling. It's an amazing feeling. I went to the lightning

talks 2 days ago and that's when I saw it for the first time.

Where the speaker of the lightning talk, he said, well, this is my project.

And I put it on this thing that people like, which is called Pushin.

So here's the link to pushin.eu. And I was like,

man, that felt so good. Yeah. And that

has been, yeah, kind of snowballing. It's come up quite a few times. Yeah.

And it's just now I see it on the slides a lot. People talk

to me about their use cases. I have plenty of feature requests

as well, but also people like who say, oh, I really want to use this

full-time. Um, lots of development on that front. Right. And I

think the greatest thing, one of the greatest things about the Elixir community

in general is the culture. We have a

very, people are nice, just genuinely

nice people in our community. And I feel like this is a great way for

you to, like a great place to launch Pushin because I mean,

it's Git hosting. It's not, it's completely agnostic to whatever language,

but because you're in this community, I feel like People are

really supportive. People are gonna send you bug reports and not, you know,

be mad. Your code is terrible. I hate your platform.

Why don't you just use GitHub? Exactly. Yeah, no, I, that is

also why I decided to kind of launch it here first.

I mean, I would always have done that, but I felt really good about first

inviting everyone in the Elixir community to it because yeah,

I do need to beta test it and stress test it and I don't have

all the features yet. you know, all the scalability in the world.

Like, this is a very, very nice community to launch that product in. It is.

Yeah. And it has like already gotten beyond that community.

I'm getting interest from JavaScript, which is scary.

Unleash the cannon. Hold back. Yeah. Like, I'm happy

to collaborate with you on your projects, but maybe

hold back on like promoting it too hard because I can't

support 10, 100,000 users, right? Right. Your one server.

Yeah, I still only have one server. That's going to change in the next,

in this month actually. And then I need to work on CI, which is going

to happen the month after. Well, since we last talked about it,

you've announced you're going full-time on Pushin, right? Yes. So from October,

so today's October 2nd, it's already my second day full-time on

Pushin. I'm still going to do the EEF security work. So don't worry about

that. I, that's my part-time that also pays my bills. We worry about that.

We worry about getting a message from you. Yeah. Sometimes I

feel bad when I message people on Slack, just say hi,

you know, and then they're like, oh my God, I already know what's going to

happen next. Yeah. But no, that's going to continue with

the EF for at least a couple of more months until next year.

However, we do struggle with financing and, uh,

yeah, so this, this whole security work has been financed by the

EF through donations from foundations and so on, but that money is

drying up. We do have a little bit more, but yeah,

it's not enough to really do this sustainably for longer

than, let's say, 7 more months. So until like mid next year.

Yeah. So if you, and I think all of you in the ecosystem

have profited from this work, you know, you're living in a secure,

more secure ecosystem now. Yeah,

go talk to your boss, to your CTO, whoever has the

credit card basically. Yeah. And tell them that they need to start

financing this security work in the EFF. And they can do that with a sponsorship.

If they, yeah, they can just sign up for it. There are different new tiers

also. They can now pay more than $10,000 a year, which also has

held the EFF a little bit back. Now they can go up to $64,000 a

year. And also project-based financing is also there. So if they want to give

more, that's certainly possible as well. And also you personally,

if you just become an EFF member for $100 a year,

You are supporting this work and not only financially, but also kind

of with your vote, with your number. Because if we say we

have a large, very large community and many of the Elixir developers

are EEF members, then that also gives us more negotiation

power when talking to foundations and people with money.

Right. This has been a topic that's come up a number of times during the

conference and it's really important work for community. And we can't

stress enough how bad it would be if the EFF did

not exist. So, um, let's make sure

that we don't get to that point. Let's make sure the funding keeps, uh,

keeps the EFF afloat and doing the great work that they do.

So please, please talk to the decision makers.

Just to make it clear, if by, in the next couple of

months, if we don't find substantial new financing,

this work will cease next year, beginning of next year.

Yeah. That's it. And then there will be no one

in the ecosystem who looks for reports for vulnerabilities and reports them

and does the whole triaging and publishing of the CVEs and

that. There will be nobody left because I can't work without getting paid

for it. You know, Jonathan, the CCO of EEF, he also can't work without

getting paid for it. And he already has been getting paid less than he should

have because money was drying up. Yeah, so very

clear, if we don't get money, this work will cease. That's it.

Cut and dry. Cut and dry. But anyway, we have

to go back to the beautiful Goatmire conference now. We haven't even spoken about

talks and learnings. Not to mention it's been amazing talks. The talks

were amazing. Okay, real quick. One, one. What's your favorite? But I don't want to

toot my own horn, but I think I really I

put so much creativity into my talk and it was the first talk of the

conference on Wednesday morning after the first

theatrical play of all of you, of the team around Lars. And then

I came out and I thought, I can't come out here, first talk of Goatmire

and be a boring, just clicking through the slides talk.

So what did I do? So first of all, you had

on a whole Viking outfit. Yes. Um, it was,

it was a sight to see, to say the least, at 9

AM on a Wednesday morning. Um, yeah. So you had

a whole outfit and then you also were very visual

in your descriptions of how radios work. Um,

so you're, you, you compared radio waves to that

of a pendulum and the swinging of a pendulum. And before the,

before, before your talk, you were like, hey Gus, do you have anything that's like,

like a pendulum? I was like, uh, we could put a badge on a string

or something. He's like, I kind of wanted something more rigid or something.

I'll figure it out. Come his talk,

he's up there on the stage swinging his arms back and forth like a crazy

guy. I became the pendulum. You became the pendulum. There's some really good photos

of you up there that are probably trickling out by now,

but it was fun. It was so much fun. I mean,

the talk, like, I wanted to talk about LoRa,

but then I fell down the rabbit hole into how radio

works. And I explained everything from AM to FM to digital radio.

And then to how LoRa works, it was kind of built up. I kept,

I wanted to keep it general so that everyone takes something away from it.

But it was also mostly about the creativity, just being the Viking.

And when I came out, I was like, Goatmire, because I was so pumped.

I was so pumped and everyone was so pumped. It was so much fun.

It was great energy to bring to the start of the conference. Yeah. And I

did floss. I did floss. You did floss because of course you're swinging your arms

up on stage and, you know, Some of them just,

one of them slips behind your back while you're— Exactly. I was doing a little

flossing on stage in a Viking costume. It's just a weird pendulum.

I was the weirdest pendulum ever, but I think I made my point and that's

what counts. Exactly. Yeah. And with that, we're going

to talk probably more about Goatmire. And we also have CodeBeam coming up where I'm

going to speak. And are you going to attend CodeBeam? I will not be there.

I'm taking a well-deserved break. You do. You do. You really worked hard.

Yeah. So whoever will, like whoever's at the CodeBeam

conference, please come and say hi to me.

I'm more than happy to talk with you about this podcast, about anything,

Pushin, Elixir coding, whatnot. Just, you know, approach me,

say hi. And with that, thank you very much for

listening. We have to go back to the conference now. I really don't want to

miss that finale. Exactly. We need to go back. It's actually, it's fika time.

Oh, it's fika time. It's fika time. That is a Swedish— Nah, they can

look it up. Oh, okay. It's a Swedish specialty. Look up what fika is.

F-I-K-A. F-I-K-A, exactly. So it's fika

time, everyone. Have a good one. Thank you for joining in and see you next

time on Macro Mayhem.