Macro Mayhem

Welcome to another episode of Macro Mayhem. My name is Peter

Ullrich. Today is September 1st. We record at 11:23

AM Berlin time. This time I'm talking to you,

I'm coming to you from Berlin. I went over

here and I'm spending the next 4 weeks here. So if you're in Berlin,

let me know. And I'm here with my good friend, as always,

Gus Workman. How you doing, Gus? I'm doing very well.

It's been a good 2 weeks. How have you been?

Yeah, man, I've been busy as hell.

You had a big drive. Yeah, a big drive. Actually, that was

pretty okay. It was like, we went to my parents first in Essen,

and then it's a 6-hour drive here, so it's not too bad. Nice. And that's

all on Autobahn, right? Autobahn, yeah. But we only do

100 kilometers an hour, it's not 300. There you go.

Yeah. All right. So, yeah, today we first

have to start with a correction. Gus, what is this

about? A couple of follow-ups from last episode.

If you tuned in, we talked about various security

patches with Phoenix. And we had a

message from Stefan Deutsch, one of the Phoenix maintainers,

Who had some comments that Phoenix does get security patches going back 4

versions. So that's back to Phoenix 1.5,

which is— Amazing. 5 or 6 years of

patches. Kudos to the Phoenix team for maintaining all the way back

to 1.5. Now, Stefan does

say that apps using old Phoenix versions should

still update for sure. But not necessarily for security reasons.

We had talked about this in context of the Phoenix adoption charts

that we had seen from the Pariah Labs blog post.

So there are still good reasons to update, but security old

versions are still getting patches. Just make sure you're still on the latest of 1.5,

1.6, 1.7, or 1.8.

So Stefan also says, and I quote here,

as a general note, a common misconception is that people think they have to copy

whatever changes we did in the gen That's not

the case. You can, of course, do that, but it's in no way a requirement

to update to later Phoenix versions. It's 1.x, so updates

are generally non-breaking. So thanks, Stefan, for sending in

the correction on that, the clarification for us.

And again, huge thank you for maintaining Phoenix

and doing patches back to 1.5.

Yeah. Stefan is definitely an unsung hero of the ecosystem.

Keeping it rolling there. Yeah. Sorry, I didn't fully understand that, though, but did he

mean that you don't have to copy changes to the generators?

And, like, what does he mean with that? Does he mean you don't need to

change the code that you generated with an older version to now be compliant

with the new version? Right. Like, how I understand that

is, the changes in

Phoenix itself are non-breaking, and LiveView are generally non-breaking.

They might change the generators. I think, if you remember, was it 1.

1.6 or 1.7 that introduced Daisy UI as the

default generator. That's an opt-in choice that the generators

make that scaffolds your new project. But you don't have to do that. And you

don't have to backport to Daisy UI to

maintain, like, Phoenix 1.8 compatibility,

for example. Right. So, Phoenix is— You

know, it's quite powerful. It gives you a lot of tools to do things yourself.

And, yeah, you don't need to— so, the changes now, the vulnerability

fixes, they're backwards compatible in a way you don't need to upgrade to the latest

version, but also the old versions, you don't— okay,

maybe we need some more clarification on this, but my understanding is that you can

just, you know, still upgrade your older versions. If you're on 1.5, there will

be a new 1.5 version that includes now the vulnerability fixes.

Okay, great. Moving on.

What about some NURBS news, Gus? Right,

moving into the news. So,

a couple of things. There's some fun news that we have. Peter,

you have some fun news. I have some great news.

I'm going to tease it because we're going to talk about it in the

end of the news section and then more in the discussion.

But I've been working on a giant project.

that I hope to make a company very soon. So we're gonna

talk about that later. So you have to stick around to hear

what it's about. Well, before we

get there, we'll talk about the other ecosystem news. One of the

interesting ones I've been involved with, I'm a Nerves core team member.

We have been working quite a while on figuring out

what our AI policy is. And now that AI

policy has been published. There will be a link in the description.

The NeurIPS project has taken a relatively, I would

say, sane, kind— I

don't know the best adjective to use here, but a relatively relaxed approach to

LLMs. We are saying that it's okay

to use them in code. It's okay to generally

use them. We use them ourselves. Yeah. But you

should try to express all communication

in your own words. That means like pull request descriptions,

communication messages in the NERD Discord, things like

that should be your own words. You shouldn't have LLMs

write for you. And this is really community building things.

We kind of talked about this one as well last episode where keeping the

human as the ultimate communicator is one

of those strategies to have better LLM usage.

So, it's an interesting one. I don't think other projects

in the Elixir ecosystem— Ash has an

AI policy, I think. I don't know that Phoenix does,

but it might be interesting for some folks to take a look at the Nerves

one. Exactly. Yeah. I, I mean, I submitted

a few pull requests to Elixir after I got started with using Claude for,

you know, looking at these libraries and languages. And I

gotta admit that in the beginning, the first pull request I made, I just had

Claude write the whole thing, but it generated a lot of text.

And then also, José, he pointed out that,

first of all, I have to add a disclaimer at the top that says,

you know, I used Claude to find the performance improvement

that I suggested, like, a fix for. I, you know, created the fix with

it, and also I wrote the benchmarks with it. So basically to disclose

everything that Claude has written. And I also then from the second

pull request onwards, I just wrote the whole thing myself, at least the

description of the pull request, to just also understand what really happened.

And then to just condense it into the words that I thought were necessary,

right? And not a single word too much, because, yeah, like, Jose also

doesn't have time to read 2 pages of description. Yeah,

it's a burden on maintainers, for sure, to just receive

a wall of Claude text. It's very easy

to pick out these days, but, yeah.

Well, I'm gonna be interested. Maybe we can talk about

this in a future session where you share your experiences

with the AI policy around Nurse and how well it worked for you. Yeah.

We'll have to see. This was just released last

week, so. Yeah, moving forward, we are at the frontier here,

at the bleeding edge of news. Well, talking about more news,

we have a new version for Oban and Oban Pro.

The version for Oban is 2.24, and it comes

with quite a few nice improvement of life or

quality of life improvements. They are— so

the Oban folks, they looked at the configuration across

Oban and Oban Pro, and they realized that they want to make it easier

and condense it a bit. So they moved together, for example, the plugins,

the queues, the repos, the services. All of that now basically

is on a top level of the configuration. It's not nested anymore.

So that makes it nice and easy to get an easy overview of what

actually is configured. They removed the plugin

namespace, or at least they moved a lot of those plugins onto a So

the cron plugin, for example, now is simply oban.cron instead

of oban.plugins.cron. The same with the pruner, which is now

oban.pruner instead, and so on. So that just makes

it easier to understand what is a first-level feature

and what is kind of, yeah, really a plugin that

is still, of course, well-maintained, but of less importance than

this. And generally, it's just easier to read the Oban settings when you don't have

to pass, like, 3 levels of configurations.

So, they changed the configurations a lot. They backported

a few things from Oban Pro into Oban. For example, that your cron jobs can

override the timezone. If you have 2 different cron

jobs in different timezones, you can inline in the cron definition now

say which timezone they should run in. Also,

Snooze now has a fix that it

will no longer— use an attempt

count. So, previously, when you snoozed a job,

it would consume a job attempt. And, you know, that basically

would run immediately, it would snooze the job, you know, which is

a feature that you want to use if you just want to check whether another

condition is already true. So, you check something outside, is it now

ready for me to continue my work? And then, if not, you would snooze the

job again. Previously, this would use a job attempt, which means after, like,

20 attempts, maybe that job that is waiting on another job,

is then cancelled, which you don't want. So, this way,

snooze now doesn't use up an attempt

anymore. They also cleaned up the readable durations. So, now you

can define them as a tuple with value and unit,

for example, 7, and then the atom days, or 1 atom minute,

which makes it nicer to read instead of microseconds that

you kind of need to then have a comment on what it actually means.

Like, what are 7,200. What's that? Oh, it's 2 hours. Okay,

that makes sense. So Oban 2.24

has quite a nice few features. And then the other

one is Oban Pro. And I mean,

still until today, I believe Oban Pro is the best money for

value product I've ever seen ever. So, and they just

keep on delivering there. One of the cool new features that

is coming in the Oban Pro 1.8.0, where they now

have a release candidate, The first feature that's really cool

is the workflow compensations. And I wrote about this in a blog

post, I think, a year or 2 ago, which is the saga pattern.

So, if you have a saga pattern, it means you have a couple of

steps, like booking an accommodation. You know, you're a booking system,

and you want to, like, do all the steps that are necessary to actually complete

a booking, which means charge the card,

reserve the hotel room, Maybe, you know, send out an email,

these kind of things. And then if any of these steps fail, you need to

undo the steps that came prior. So refund the money,

cancel the hotel room, that kind of stuff. And that's

a saga pattern where you always, for every action, you have a compensation action

that undoes the previous action. And now in Oban Pro,

they added that to the library, and it's called workflow

compensations. So you can create a new workflow, and then add

a cascade, which has a compensate function as well.

So, you can reserve inventory, and if that doesn't work out,

you can release the inventory again. That's a great new feature that

is, again, a super useful feature, but it needs to be done well. And I

have full trust in the Oban folks that this is done well.

They also have now a new feature called cursor-based backfills,

which is interesting if you have to backfill data. If you change your data schema,

and you have to backfill old data, they have a backfill,

worker, or I would say that's a job, right? Like everything is

an Oban job. So where you can easily backfill data

based on a cursor. And they

again streamlined the configuration, same as in Oban. And they also added global worker

defaults so that you don't have to configure those inside

different modules. You can just have it in one major configuration. For example,

where you, if you have a storage key, If you wanna store the

job outputs in S3 instead of your job's Oban

Postgres database, you can define that globally, and that's it.

Lastly, they also have inline cron scheduling, so you don't have to move everything to

the cron configuration in your config.exs. You can also have it inline in your worker,

which moves it into the worker, which makes it easy to see

when it's actually working. And actually, now,

almost lastly, they have so many features. Sorry, I'm gonna speed through them. They now

also allow you to record the job outputs in external

storage instead of your OpenJobs Postgres database.

So, you can, if you have an output from a worker and

you want to persist it, you can easily move that to S3, for example,

or Tigris or Redis, where it's cheaper. And they also

have persistent pruning and archiving, which improves the

Pruner plugin a little bit, which now isn't a plugin

anymore. but a first-party module. And that is all.

Can you believe this is a single feature version they released? Are you sure that's

all? I think there's a little bit more. There might be a little bit more.

I had to skip a few, but Jesus, the Oban folks were busy.

Yeah, they were busy. They— and they make good

quality code. So yeah, go check it

out. Get those updates. Go check it out. All right, moving on to the next

item. Right. This is a quick one.

Samlee, the Elixir SAML client.

Jonathan Menschen, the EEF

security, you work with him quite a bit, Peter. Yes. He has mentioned

on the Elixir forum and a couple other places that Samlee,

however you pronounce the library, Has security issues,

a few known CVEs, and needs maintainers. It's currently

in a bit of an unmaintained state. So if your company uses

Samely, and I don't think that there's another large Elixir

SAML client, that's kind of the primary one. If you use this at

your job and you are going to

need to fix some of these features because they're CVEs, you should probably take a

look and see if you can contribute and help maintain.

So, take a look at the link in the description and get in contact

with Jonathan. All right. Yeah, that's Jonathan Mentjen.

He's Swiss. All right. Next item is also

vulnerability security related, which is that the Ash ecosystem

has released quite a bunch of CVEs. And I have to admit that I'm

the The problem there.

The perpetrator. The perpetrator. The finder. I did

this on you. Yeah, so I've changed my approach

to finding vulnerabilities slightly in the last couple of weeks, which is I rather

focus on big projects, on, like, mini ecosystems inside the Beam

ecosystem, instead of going different libraries, you know, by different libraries,

because now it's easier to just, like, look at one ecosystem, like Nurse,

for example, or Ash, look at all the libraries at

once and then report everything at once. That's a bit more efficient for me.

So I've been doing that over the last year, a week or two with

the Ash folks. I scanned all the libraries that started

with ash_. Maybe there are more, but that's how I kind of defined the mini

ecosystem. I found a bunch of reports here and I reported them

to the Ash core team and they are extremely responsive and

they already pushed out a lot of CVEs and bug fixes and generally hardening

fixes. So if you're using Ash, keep an eye eye on the

latest versions, because we're still working on it. But over the next

week or two, there will be quite a few new releases coming out.

And just a small note here, the fact that Ash

has so many CVEs and vulnerabilities now does not mean that they're

unsafe or anything. The thing here

is, or that their approach to writing code is in an unsafe

manner. The thing here is that Ash, and that is Like,

what Ash does is basically it takes over the complexity that you would need to

write in your own application, you know, and then that would include—

introduce bugs and vulnerabilities. So, they do that

for you, you know, as a matter of convenience for the user,

but that means that they now own the complexity. And this

is actually better here, because if we fix it in one place,

everyone who uses Ash gets the safety that

they introduce by fixing the vulnerability. So,

Usually, you wouldn't need to now go in and fix your CRUD functions that you

have in your Ecto schemas or in your context, right?

Here, the Ash team does it for you. So, that's why they now have a

bit more work to do. But in the end, I think it might be even

safer to use Ash than to write Phoenix code yourself,

unless you're really safety-focused.

Right. It's a good thing for the ecosystem. But hopefully,

you know, with your scanning, we see that wave of CVEs

start to drop. Eventually, yes. But I think this quarter, we are triple

by now, triple the amount of CVEs than we had in the last quarter.

And yeah, so it's still, it's still, there's a lot of, there's still a lot

of work to do. And I'm still doing the work and all the maintainers are

doing the work too. And Jonathan as well. On a note here,

Lockfile is tired, Peter. Yeah,

I know. I'm getting tired as well. On a more serious note,

last note about this, though, is we always need funding

for this work, and we're currently doing it on a small grant from

Alpha and Omega, which is nice for us, but it definitely

doesn't pay the bills fully. And, you know, I'm just

asking if you're a company and you have some budget for this,

please consider donating a

substantial amount to the EF because we are doing all the safety work for

free, basically, for you right now. All the big companies,

you are getting all the safety that we find

and introduce for free. And it would be really, really nice and appreciated

if there could be a financial return, at least to

cover our bills. So that is something,

if you're listening to this and you have a good connection to people

up in the company, maybe point them at all these CVEs that we are pumping

out that make your software safer, and maybe convince them to

donate some money. That would be nice.

All right. Yeah. Next item,

it is going to be a big item, but I wanted to just

quickly highlight how cool I find it that

now everyone builds their own little tools for their own problems

with LLMs. Now that it's basically free to point an LLM

at a problem and tell it, fix it,

everyone does it, and I find it amazing. And I just want to highlight a

couple of tools that I've seen on Elixir Forum in

the last week or two, and they're all cool in their own way.

So, I just want to highlight what I've seen and how cool it is that

everyone kind of pumps out their own projects. So, the first one is

called Abuba, and it's a drop-in replacement for Mastodon.

If you run a Mastodon node, you don't need to use the Ruby

node anymore. There is now an Elixir version of it that you can run.

And according to the own benchmarks of Abuba,

it is much faster than the Ruby client.

The next one I found really cool, it's called Beam Console.

It is an embeddable process map and flight recorder for Beam applications.

So, basically, think Observer, but then

on steroids with a nice UI. Kind of like

the Live Dashboard of Phoenix, it combines some parts of that as well. So,

it's a combination of Observer and Live Dashboard, but in a nice

UI. And, yeah, you can just add it to your application. It's open source,

so you can vet it before. And it's just a better dashboard, basically.

The next one is also a modern alternative to Observer, and it's called

Voyager. Similar idea. Also, just make Observer more

approachable, nicer UI, have a nice overview

of all your system, of the usage, how many atoms,

tables. Yeah? I believe that one is a desktop

app, too. It's by Software Mansion. So,

it's— they're targeting kind of the

debugging use case, not embedded in your application like a live dashboard.

Right. Yeah. So now you have different ways of— Cool.

I find this really cool because, yeah,

sometimes you just want to look at your supervision tree or your atom table,

or you also have reduction counts. So you can see which functions reduce

a lot and, you know, could be improved, that kind of stuff. I hope that

eventually I, you know, I can point my LLM at this and then tell it,

find the issues and fix them. That would be

really nice. The next little tool that I found really cool is called

MaplibreX, and it's for the Maplibre GL

JavaScript. What is that dependency?

Well, it's using Maplibre, and it comes with like 30

or more LiveView components that you can use to quickly

add Maplibre components to your application. So that includes

everything with maps and navigation and that kind of stuff. So that I found

this really cool because it, it gets you going, like, to add a map in

a nice way to your application really quickly. The next,

uh, little tool is called Temper, and it

is a flaky test detection for xUnit. And that one I found really cool because

we all have that issue that sometimes there's a flaky test that breaks

CI, and then you have to kind of take the seed, go back into your

local terminal, rerun the text the test unit with that seed,

sometimes it might fail, sometimes not. So Temper,

you can run locally, but also in your CI. And it writes to a local

file when, like, the test outputs.

And when it sees that the test output changes,

although the code didn't change, then it, you know,

reports it to you because that might be a flaky test, basically,

where you run it 5 times and then the 5th time it just fails,

but the input is the same. And the code didn't change, right? That is

a flaky test. And yeah, Temper just makes it easier to track these

and to report on. Now,

the next one is, and I found this really cool for a very particular reason,

it's called DSH, and it's a

DeepSeek coding harness written in Elixir. And the background story,

this is really cool, because José, he went on X,

and he said that, Somebody should write a coding harness in Elixir,

because Elixir is really well suited for that kind of job,

where you have, for example, one main supervision,

a supervisor agent that coordinates

the work. And then you have a bunch of worker agents that execute on the

work and report back on this kind of thing. And if you think about it,

these are all GenServer processes that are supervised and that can terminate

and you need to restart and that kind of stuff. So it's a one-to-one mapping.

Of the problem to the Elixir architecture.

So, Jose said, somebody should build this. And then somebody went out there

and built this. They're now focused on the DeepSeek model,

but I think you can also probably replace them with different models if you wanted

to. But they, you know, took a stab at how

would a Coding Harness CLI written in Elixir look like.

You know, so, it's a great project. I really like it. like that

idea. And I think it's kind of like a prototype for now. Let's see where

it goes. Maybe others, you know, want to improve on it, or it will improve

itself. But it's definitely a really cool project to get started.

Now, the 2, 3 last— 3 last ones.

Man, again, this was just the last 2 or 3 weeks.

People were busy during the summer. They were having little problems, and they

just pointed alarms at the problems, and out came a little project or

library that others now can use. So, the last 3 ones,

the first one here is ProBax, and it gives exact answers to structural

questions about Elixir source. It is built by agents for agents.

And it's a little tool that you can install on your

system itself. It's written in Elixir, but it's

not an Elixir library that you put into your application. It is a little local

CLI that you can run, and it just makes it easier for the agent

to look at files in your project. And that happens a lot where

the agent just goes off and does a regex search through your project

to find a certain module name and the file and that kind of stuff.

And that uses a lot of tokens, which fills up the context

window. So ProBax, it went out and said, hey, this is a CLI

that does exactly that work, but more efficiently. And it only gives you back the

answer you need. So you can drop it in and

give it to the agent to use instead. Elixir-aware,

so it finds the module that it's looking for, the agent.

So, that's really cool. Now, quickly, the last 2 ones before

we go to the big announcement. I'm sorry that I've been talking for 10 minutes

here, but, you know, it was me getting excited about all these tools and just,

like, keeping— I just posted them all in this document, and I thought, oh,

this is gonna be a quick 3-minute section, and here we are.

But the last 2 ones is about generating PDFs,

both of them. One of them is called Paperforge. It's a pure Elixir platform

for building, securing, and transforming PDFs. So it's a bit higher level than just generating

a PDF. I think you can also spawn many different PDF

workers. So if you have a high PDF throughput

where you need to generate a lot of PDFs and you don't want to do

it in your application, you want to outsource it to another system, you can do

that with Paperforge. One thing I didn't fully understand here

is how they generate the PDF. I don't think they use Typed or

Chrome. So it's interesting. Pure Elixir, I think.

Pure Elixir, yeah. Well, I hope this

is gonna be a compatibility issue in the future, but,

you know, let's see. So that was the only downside where I

would have wished that they had types support, because then you can use types to,

you know, create the PDF layout and then just insert the data dynamically,

and Paperforge would take over the rendering and the orchestration

of the rendering and that kind of stuff. And last one is called Press.

It is an HTML-to-PDF library, 100% written in Elixir. So,

yet another PDF generation library. I can't say— I

can't stress this point enough, but I think every single

new PDF library is a win.

Oh, somebody's hammering next to me.

Because I can't use Chrome Drive anymore. I want to use types for everything,

but now the issue is, Yeah, if you have to generate a lot of PDF,

you can't do that in your application. So, you need kind of, like, a microservice

for it or something. So, you know, it's still a problem not solved yet.

And the more people take a stab at it, the better.

That's why Paperforge and Press were really cool.

All right. That's the— It's been fun opening up

the Elixir forum and seeing, you know,

the whole page is full of A lot of those salmon-colored

tags with announcements of things people built.

Exactly. So, it's been fun. Keep posting stuff there, guys,

everyone. So, we— it's

fun to see. It is great to see, you know, and we

won't do this roundup every week, but this week, I just wanted to highlight how

many tools are being built and put out there. And then, you know,

people can I mean, you don't have to use them. You can just use the

idea and then generate your own code and own it, you know, if it's important

to you. But it's just, it also gives you great ideas and shows you how

a potential solution could look like. Right.

And you've been doing some of that yourself,

haven't you? I have. So,

yeah. The big announcement of this

year for me is that I've been working myself on you

know, a tool like the tools we mentioned above,

slightly bigger, though. Not, you know, a weekend project.

Just a little bit. Just a tiny bit larger than this.

And I'm very happy to announce today that I've

been working on a European GitHub competitor,

and I'm calling it Pushin, pushin.eu.

So, This is it.

If you need— if you don't like GitHub anymore because

it is unavailable all the freaking time,

if it's too slow, if it has yet another 500 status and

you can't get your work done, maybe consider pushin.eu.

It is still— it's there. It's going to work for you.

I've been testing it myself for the last few months. I worked almost 100%

on there yet. Not yet for my work stuff, which is still on GitHub,

you know, but for everything else, I use Pushin. It is

also work in development, right? So if you have any feature requests

that you didn't see on GitHub, I think just having a project that actually implements

new features and takes user input into account, that's already,

you know, a competitive advantage. Yeah, so that's

what I've been working on. Pushin.eu. Gus,

I showed it to you. What did you think about it? I had a blast.

So, we might talk about this later,

but I got a text from Peter one day that said, hey,

Gus, you want to try this cool thing that I'm working on?

And then he said, I'll buy you a beer for every bug

you report. So, if you see me drunk at Goatmeier,

it's Peter's fault. You still remember this,

don't you? Oh, yeah. I was kind of hoping you would forget.

I owe you a couple of beers. Don't make promises

you don't want to keep. That's right. Yeah.

It's been fun. So, I may

have broke it a couple of times and sent Peter a couple of messages,

but, like CFEs, Pushin's better for it now,

right? Yeah. We'll talk more. We still

got to cover the blog post, Peter, so. Exactly. We will speak about it

in the end of the podcast in our discussion section.

And I'm going to also go into details about how I implemented

the whole Git hosting thing, what's on the market right now, what are different,

you know, options for you if you want to migrate off GitHub.

I'm also going to talk about how I used LLMs exclusively

or extensively at least to build this giant

thing, which is a Git hosting platform, right? It's not just a

weekend project. I've been working on this almost every day for 6

months now. And it's good. It's fast.

It's not going to lose your data,

which is the most important part here. It's not going to lose your data.

But yeah, we will talk about all of this in the end of the podcast.

Cool. Well, kick us off with some blog posts here, Peter.

Right. So let's go through the blog post section. And again, we have

a lot of blog posts to mention because the summer has been busy. The first

one I wanted to highlight is by the Gleam team. I love, I just love

how that flows off the tongue. The Gleam team. The Gleamlings,

I think they're called, right? Lovely people.

And yeah, Gleam has been accepted into the GitHub Secure Open Source

Fund a while back. I think like 3, 4 months ago they announced it,

or maybe now they announced it, but they couldn't before. Anyway, but they have

been accepted into this program, and it gives them some

money, but most importantly, it gives them industry experts on

security that go through the language and point out

potential security issues. And the Gleam team wrote

up a blog post about the experience of this project,

kind of what they found. I mean, not like identified every single change,

but generally what they found, because it was not that much.

They have always been safety-focused, so they were positively surprised

to see that there weren't that many security issues they needed to fix.

Yeah, so it's a nice blog post just explaining what

they have done in this project, in this fund.

Next one, it's about LiveView.

Yes. Next up, Software Mansion,

the Elixir consultancy in Poland, I want to

say. They released LiveView Local. They're the ones behind

Popcorn, which is bringing Elixir to WASM and running Elixir

in the browser. LiveView Local now builds

on that base of Popcorn and allows you to write

live components for your LiveView applications

that run on the client side. I think the end

result is kind of similar to Hologram. There's still some cross-server,

cross-to-the-client, running code on the client. But it's

interesting because their approach is a little bit different. And they have—

I mean, the way that they implemented it is instead of use Phoenix.LiveView,

you can use local LiveView or

LiveView local. I forget what it was named. But take a look.

Their blog is very nice and explains the

release. Exactly. The next blog post

is by the river.com company. I think they do crypto

trading or crypto, something with crypto. And they wrote a very nice

blog post about how they replaced their internal API,

which had 30+ different functions for adding

balances, subtracting balances, basically handling all types

of money changes, like transactions and that kind

of stuff. And they replaced that with only 2 functions.

Again, written in Elixir. I think before it was also written in Elixir, but they

kind of changed the internal API to just 2 functions. One of them is a

get, just get record or fetch record, you know, show me the information

for this thing. And then the other one is the function

to change the state. So, one getter and one setter function, and that

is it. Now, you gotta, if you think about it,

if you hear about it, it sounds amazing, but then you read the blog post,

and what you actually realize is that they replaced a direct function call with

an event type. Basically. So, instead of calling

update_user_balance, whatever,

they call just update_record, and then they send an event that

has the type update_user_balance, for example.

And it sounds a lot like the

CQRS, right? Like event sourcing, CQRS pattern,

where you kind of send commands, and that updates

the state, and then you have a read_state that reads from it. And it also

sounds a little bit that they added the double-side booking.

No, what's that? Yeah, double entry accounting. Double entry

accounting. Yeah. I think they had that before, but now with the events, it just

became clearer that they were doing basically that. So generally

for them, it was a big improvement to move away from functions to events

because events, you can also persist and you can keep a history of and you

can replay them. So, you know, that was one of

the major improvements and advantages they made. They got

out of this refactoring. So, it's a very nice read. It was

a good read. And it's more of the medium,

large-ish company engineering team blog post.

Like, it was pretty good technical content, and it had some interactive

widgets inside of the blog post. It was a good read.

Very good read. Now, next one, by our repeat

perpetrator. Yeah, she shows up quite a bit here.

Joanna Larsen has been,

again, busy this summer with a lot of writing, but another good one

on speeding up the Phoenix LiveView web app with a CDN.

She posted about her experience in,

like, a tutorial type of blog post on On how to add Bunny.net,

which is kind of like a Cloudflare alternative, in front

of your Phoenix app so that you can serve your assets from

CDN instead of from your server directly. Exactly. So,

that was a really good overview of how to set all that up, especially on

a not the most— not as

well known of a CDN provider. So, it probably also extrapolates

well to other non-Cloudflare CDNs.

Yeah. And I remember her telling me that, so she

had a blog post a while back that went viral on Hacker News. And that

means getting tens of thousands of users or visitors to your website. And I

think I texted her in Bluesky and saying like, rip your server, like your server's

probably going to explode. And she said, she doesn't even worry about it because she

uses Bunny CDN. And yeah, all these requests just hit Bunny instead

of her own server. Which, I think her server had barely any uptick

because of that. So, now she wrote a blog post about it, which I like

quite a lot. All right. We got 3 more

left. The first one is from Alexey Matyushkin,

or his tag is @mudasopwa.

And he wrote 2 very nice blog posts, one about anti-anti-patterns

in Elixir libraries, And that was quite eye-opening

because I also have quite a bit of, uh, quite a few Elixir libraries.

And there are kind of a few anti-patterns that also the Elixir language,

the documentation tells you not to do. For example, using application configurations

instead of having, um,

like options as your, as an API of your public API.

So, if you have a library call, in that call, you always wanna also receive

the configuration so that people dynamically or themselves

can configure your library through that call.

So, you should use that instead of using an application config where

they have to write your config into runtime.exs or something like that. Yeah.

And this blog post goes against that and says, well, it always depends,

right? And that's true. Because sometimes you do want that, right?

Sometimes you want to have compilation-time configuration instead of runtime

time configuration. So yeah, this blog post

goes through, I think, 9 or so anti-patterns that are

not actually anti. So, you know, they make an argument against them.

And what I liked about this is that he shows

the use cases and the situations in which it does make sense

to go against this wisdom, this guidance from

the Elixir library, the Elixir language.

And then the second blog post by Alexei is Why LLMs Rock.

Or Boolean logic for the initiated.

So it's Boolean logic, but, you know, with an LLM in there.

And it's actually a really interesting blog post. It's a different kind of blog

post. Never seen such a thing before. But it takes a slightly

mathematical approach with Boolean logic. So like, you know,

A or B and then A and B, that kind of stuff.

2 different use cases of using

LLMs and then with an operator, with a developer that is,

for example, dull or wise.

So, you know, if you have a dull operator with a wise LLM,

what you get is slop code and vibe coding, for example, you know,

but if you have a wise operator with a wise LLM,

then you get a really like a 10x improvement, that kind of stuff.

So, so Alexei, he goes through a few of these setups.

And then he explains, yeah, you know, sometimes when people say,

oh, LLMs are not useful, maybe they're on the dull side of

things. Like he doesn't say, you know, directly, but this is in the category they

would fall into. So yeah, it is a

nice blog post about understanding a good

setup, like the developer and the LLM, they both need to be on

a good level of expertise to work well together.

Good. Gus, what do you have for us next? Yes,

my favorite type of blog post, a Nerves one by Lars Wieckmann,

or @laak on a lot of the social media.

He posted a blog post titled Nerves,

Apparently Popular with Agents, kind of outlining his

experience in the last year or so from where

LLMs are being used in Nerves.

It's a good read. It has a

lot of exposure to some of the ecosystem that's been developed with hardware and

Nerves. So he's got a lot of good links in there.

It's a good resource. Yeah. And then the last

blog post is one by, yet again, Terence Tao, who is the most famous mathematicians

of this time. And he wrote an article about a talk

that he gave at a conference, which is called Mathematics in the Age

of AI. Again, it's not software development related, but if

we look at the math community, we can kind of foresee

what will happen or what is happening to us in the software development

community. And I think the mathematicians, they have

maybe a clearer picture of what LLMs can

be used for or should not be used for. So, you know, it's a bit

clearer than writing code. I'm not sure, but I can just,

if I look at their problems, they become clearer to me,

maybe because mathematicians are really good at just identifying the core problem

of their problems. But yeah, when I read this Terence Tao

article, it made me think, okay,

what are actually the problems we're facing?

And, you know, what are the potential situations in which we end up, you know,

in? And 2 quotes that I wanted to pull out of this blog,

of this article, is because I think this is really important as well for us.

One quote is, the goal of training a mathematician is not

achieved by producing correct homework. So, what Terence

says here is that if you have junior developers

slash junior mathematicians, or, you know, students of math,

Like, it's for them, it's not about getting the right answer. It's about learning

and understanding how to get to the right answer.

So for them, he even says that maybe you should forbid

LLM usage because they need to sit down and do their homework

themselves to understand the concepts and the approaches and everything that it

teaches. And yeah, maybe that's also something for software developers that we need

to take into consideration where junior developers, they should maybe still write code

by hand and not use an LLM because that's the only way they learn about

the frameworks they're using, Architectural decisions,

code style, you know, mistakes in the code, that kind of stuff.

So that was a good quote. And then the second one,

I think that is something we really need to take to heart, is above all,

our community needs to come together to have open and honest

discussions about LLM usage in their industry.

And if I go to Bluesky or, you know,

Hacker News, I don't see an honest and open discussion at

all. It is very much black and white. And if you think LLMs are useful,

you're immediately, you know, like a Putin lover or a Nazi,

whatever. You know, it's not an open and honest discussion.

I think we need to take these words to heart a little.

All right, 45 minutes in, we finally finished news,

blogs. Last thing, meetups and conferences. And gosh,

we need to make this So, are you ready to get

timed on how quickly

you can say this? Last week's. Let's see. Okay.

All right. So, start. Nerves meetup.

We are taking a break in September. We will be back in October,

kind of related to the summer being really busy.

More news on that next time. ElixirConf US is next

week, September 10th and 11th. I will be there. If you're gonna

be there and you want to meet up, ping me on socials. I will be

around. We'd love to chat Nerves or whatever.

Codebeam Europe is October 21st and 22nd in Haarlem,

the Netherlands. Another good conference covering not just

Elixir but also Erlang, Gleam, and other Erlang ecosystem

info. And of course, Goatmire, which is coming

up at the end of this month. It's now September, so September

28th through October 2nd. There's 2 days of workshops, 3 days of conference.

It's going to be a really good time. The day after,

also in Varberg, Sweden, is AshConf and the Goatmeier Hackathon.

They kind of take place in the same building. That's on October 3rd.

So if you're around for Goatmeier, which you really should

be, then Stick around for the AshConf and/or

GOTO Mayer Hackathon. Peter, we're both gonna

be there. Time. Time. 1 minute, 10 seconds. Yeah,

call it a day. Hey, that's fast. We're both gonna be there at

GOTO Mayer, and you're prepping a fun talk.

I'm prepping some fun secret stuff.

Yes. I wanted to say, if you are still on the edge

or uncertain about whether or not you should come to GOTO Mayer, First of all,

come to Gouda Meijer. Second of all, I have maybe a reason because

for you to come to Gouda Meijer, I mean, I'm not going to be the

only reason, but there's one extra, which is that

I'm probably going to give the most interesting talk

I have ever given, ever. Like in my entire career of speaking,

this is going to be the most interesting talk and hopefully

also my best talk, because I'm going to prepare for it a lot.

It's going to be a little bit of a theatrical show. It's not just going

to be a straight standing there and giving a talk.

I'm really looking forward to this. I'm going

beyond and above anything I thought I would present.

You know, I'm just having Codex build yet another project

I'm going to present, that kind of stuff. So I'm really

looking forward to GOTO Maya. I'm going to be super ready for it. And yeah,

maybe this will be the best talk of my lifetime. So maybe you want to

be there to experience that. The best talk. So far.

So far, yeah. But, I mean, it's also stressful.

It is. So, maybe afterwards, I'm gonna be a little bit more chill again.

Yeah. Well, and so, Peter's gonna do a good

talk. Last year, I did the Goltmeyer name

badges, which was a little Nerves E Ink device.

I have been busy these past months and have finally got

everything all ordered. I can confirm that there will be

a Goatmeier 2026 badge.

There's just a few pictures leaked online

so far, but if you want the full picture, I'm going to be announcing

it and showing it off soon on my socials. So just

to kind of tease, if you want to go to Goatmeier, you'll get some hardware

to come home with. So Exactly. Sign up.

Please sign up. All right, last 2 sections.

All right, Peter, this is— well,

after the joke, everyone can, you know, take off if they don't

want to stick around for the discussion. But stick around for the joke, because you

got a good one this week, don't you? Well,

today's— this week's joke is, did you know that

koi fish always travel in groups of 4.

If attacked, koi A, B, and C will

run away, leaving behind the decoy.

The decoy.

Poor koi number D. Yes. Poor koi number

D, the decoy. The decoy. All right. I'm sorry.

I'm very sorry for these jokes, but I have to make them. I have to

get them out of the system. I probably should stop encouraging you, but it's

kind of fun. It's like, it's like, yeah, seeing a car

crash. Like, you can't look away, but you also don't want to see it.

Exactly. And, you know, if I'm going to be subjugated to some

of these jokes, I might as well make the audience have to listen to them

with me. Exactly. Yeah. Shared suffering. Perfect.

Shared suffering. All right. For everyone— Let's talk Pushin'.

Yes. So, for everyone who is not interested in hearing about my latest startup,

feel free to leave after only 15 minutes of us giving

you the news. And I apologize for that. I'm going to try to cut

it down next time again. But leading

into the discussion, so, yes, I've been working for the last 6 months on a

product called Pushin, pushin.eu. So, push in without a G,

It is a Git hosting platform. It is very

much modeled, aligned of the GitHub

experience. So if you look at Pushin and you look at GitHub, it will feel

familiar. I didn't want to give you a completely new experience. I kind of wanted

to make it as easy as possible for you to migrate from GitHub to Pushin.

I think the most important features are also

reasons why I built Pushin is, first of all, it's hosted in the EU.

It's not hosted in the US. It's going to be a European company.

Infrastructure is going to be 100% European.

I'm very particular about the services

I'm using. So I'm not using US companies. There's one single exception

right now, which is I use Sentry with a European server,

because I'm just so used to Sentry. And I've been trying out other options,

but they were just not the same. So that is something I'm still keeping there.

But everything else, the servers, runs on Scaleway,

for example, which is a French company, and the servers are in

France, in Paris, and there's also going to be a second region

eventually in Amsterdam. Yeah, so it's hosted in the European

Union, which means no politics from across the pond that

affect you, no CLOUD Act. I'm not sure how many people know about

the CLOUD Act, but that is law in the US, which means that the

government can request data from all the hosting providers,

AWS, DigitalOcean, Azure, you name it,

even for customers in other countries.

And the only, um, the only, uh,

how you say, options or requirement here is that the hosting company is

US or has a US subsidiary even

sometimes. So, you know, sure, Amazon is a US-based company, so even

if you run your server on AWS in Frankfurt or Amsterdam,

still the US government can go and say, hey, please give me all that data.

Well, I'm not going to say please, they're just going to say give me all

the data of the customer that you have here in Frankfurt,

which might be a German customer, right, with a German company.

So I think the Cloud Act is one of the major reasons that European

companies are looking for European hosting solutions

for everything. And there isn't really a good European

hosting solution for Git hosting.

Now, talking about the, the other options there, I mean, GitHub is one.

The second one is GitLab that you might think about. And yes, you can

run GitLab yourself, but do you want to do that?

Probably not. They are actually listed on NASDAQ.

They're on the New York Stock Exchange. They're very much American by now,

I think, you know, American owners, that kind of stuff. So these are really the

only 2 major commercial offerings.

And then you now have Tangled, which is a

very nice startup from Sweden, and they also focus on where they host their

stuff, and they also make it a first

citizen or first-party feature for you to self-host your server.

So, I'm super excited about Tangle, and I wish them all

the best, and I hope that they succeed. Because they also mostly

build on the Atmosphere, like, on the AT protocol. So, it means that if you

make changes to your code, if you have, like, comments, or pull requests, or issues

on your code, it's super simple to migrate them away to a different provider,

which is not easy right now for GitHub. So, I really hope they

succeed. So, that's Tangled. But they also mostly,

right now, they only focus on open-source code.

They will have some private offerings, but again, I'm also not super concerned

about that, because I don't think they will be super focused on businesses

and enterprises, which is rather what I'm focusing on.

And then, other options you have is Codeburg, which is a German NGO.

You know, but they also only focus on open source code.

They— you can have a private repo, but it's discouraged. And I

think, you know, if you, if you're a proper company, you might not want to

use that. Um, you can run what

Codeberg runs, you can run yourself, because they use Forgeo, which is an

open source Git hosting platform. Basically, you can just,

you know, download a Docker container and have it running in 5

minutes. I, I did that myself in the beginning of Pushin as well. So you

can run it and host it yourself. But again, the problem here is a

managed experience, also for companies and enterprises,

but also for people who don't want to self-host and people who want to have

some kind of private code. You know, like, not all of my repos, like,

are public. Some of them are just my personal stuff that I want

to have somewhere hosted but not publicly, you know.

So that is kind of the, the group that

I'm looking into. At what point did you just

wake up one morning, GitHub was down, and then you're like, this is enough,

I'm building my own? I think that's pretty much

it, yeah. I saw the, you know, unicorn,

the 500, which is— unicorns should

be rare, you know? Happy and

rare. Yeah. Unicorns are meant to be rare. That's why they chose it

in the first place for the 500 errors. So yeah, they're everything

but rare in the last year. And I'm not really seeing

that improving by a lot. So yeah, that's,

I woke up, I realized we need, I want to have a

European solution. I also moved everything that I host to my own European servers

in the last 6 months. And I just wanted to have the same for

my guest hosting. But I also wanted to have a managed experience, you know,

not like a self-hosted experience. And then you can't log into my personal Forgeo

instance and we can't collaborate on it. So I knew

there needed to be something like GitHub, but then, like,

in Europe, but a managed experience. Right. So you didn't

want to self-host, so you decided to self-host for

everyone. Exactly.

Exactly. Yeah, that's one of these, like,

scope creep issues. Scope creep indeed.

Well, it's been very nice. I will say, so my

experience, Peter sent me an invite, what, 2 months ago

to start testing it out. And yeah, it does feel

very similar to GitHub. And since then,

you've released a couple tools to import repos and

things like that from GitHub. So, if you wanted to port and keep in sync,

you could even keep GitHub as

your primary and Mirror to Pushin, is that right?

Yeah, exactly. So you can— I have a whole CLI written in Rust

that makes it super simple to import through your own computer

GitHub repos into Pushin. So, you know, it's just a CLI you can start,

and then it asks you which ones do you want to import, and then it

pulls down the Git repo, but also issues, pull requests,

like closed pull request history, all the discussions

of your issues, the labels that you have on your tickets,

So it was really— Can you import stars? Not the

stars, no. Not the stars, darn. No, no, no. But, you know, like about,

the description, links, that kind of stuff. It makes things easy.

It makes it easy to move over. Exactly. And then

I do— you can mirror a repo from GitHub to Pushin if

you want to have a read-only copy on Pushin.

I'm thinking maybe as a next step, I'm also gonna do the other way around

so that you can push to Pushin, but then you sync that change to GitHub.

Just as a backup option, which you know I don't mind at all.

That's going to happen next, and yeah,

generally my approach right now was to kind

of get feature parity for the most important features, right? I mean,

just having a repo is just one thing, but you also want to have issues,

pull requests. You want to have actions, so runners.

I do support self-hosted runners now. You can just start

a git git runner. I have it running on a Hetzner machine with

20 cores, so it's super fast. And yeah, then you can pull

the jobs from Pushin and run them on your own infrastructure and push it back.

The next step there will also be to have managed runners, just like GitHub experience.

You just pay for by the minute.

And I'm gonna use what Tangle is doing right now. They're also focusing

on Firecracker VMs for running these one-off jobs.

runners. And hopefully, that's going to be much faster than

what you can currently have on GitHub, because they have a different setup.

So that's going to come pretty soon, the next month or two. Yeah.

But that's about it. That's, you know, most of the features. And then

all the collaboration. I can sign in,

make issues on your repos from my account. Exactly. I can make

PRs on your repos. You can make PRs on mine, the public ones. Of course,

I can share private ones with you. There's orgs, right?

You can fork. It's very much the same. You can fork. You can make

a pull request back. You can create issues. I have organization support as

well. So if you have an organization with multiple members,

but then also collaborators, you want to give access to only 1 or 2 repos,

you can create teams inside the organizations, and then public

and private repos. And right now it is invitation only.

And I think I'm going to keep it invitation only for a while, just to

make sure that everything is running well and then also no bad

actors are joining the network. But yeah, going forward,

it will also be paid eventually, right? So probably organizations,

businesses, that's going to be paid. And then I'm probably also going to introduce an

individual payment plan for individuals that want to pay anything between €10

or €20 a month. I haven't figured out which amount yet for it,

but that's going to give you everything you could ever imagine, you know, like runner

minutes, private repos, as many as you want, like all the good stuff.

Yeah. And this is like right now I'm still working on just getting feature parities

with the most important features. But then going forward, there's so much

more exciting stuff that I want to introduce. And I think one

of the biggest things is what we see on GitHub is just

the slop that gets thrown around. You know,

maintainers are drowning by PRs that have like 2

pages of description and then 10,000 line changes.

And, you know, when they talk back to— when they ask questions, they basically talk

to an LLM, you know. So it's not a good experience for the maintainers.

And that is one of my main focuses

that I want to cut down on that slop. The invitation-only system is one

of that, one part of it. The second one is vouching, like Tangled has

it. I think that I'm going to introduce that. And then I'm also going to

use my own LLMs to check your contribution,

quote unquote. Does it look like a slop contribution to another

LLM? And if so, maybe hide it, or not hide

it, but collapse it for the maintainer, mark it as a potential slop

contribution, something along these lines.

So Again, right now, it's still getting feature parity, but then moving forward,

I have a lot of super exciting features I wanna add there that I'm missing

in GitHub. Well, not just that you have feature parity, but you've

definitely exceeded GitHub in a few areas as well. So, one of the things that

I, one of the issues I helped you find was some speed improvements,

right? Right. So,

what was I doing? I took a, A fork

of Buildroot, which is a Linux— it's

a project that helps you build custom Linux systems. And there's,

like, 60,000-something commits in there. And I was

customizing it to add support for my hardware. And then I pushed it up to

Pushin. And then I sent you a message and said,

Peter, it's not pushing. Yeah. What happened? And how

are you speeding things up? Yeah, that one was really interesting. And there's

one thing I should notice, I should mention, and I should have mentioned that earlier,

but I've built my own Git implementation,

you know, and there's a huge asterisk to this because it's gonna

sound all the alarm bells and whistles, and I fully agree with that. And I

was very, very, very particular about making this decision,

and I fully understand the risk and the maintenance. Yeah.

However, hear me out.

When I made the decision to build this, I could have gone the same route

that every other hosting provider, including the new ones like Tangles,

are doing. And also, there's one from Cursor right now. It's called Origin. They built

their own Git hosting solution that supposedly can handle,

like, hundreds of pushes a second, because they had their own

issues with thousands of agents pushing all the time. So they had to build something

themselves. But yeah, every single one of

them uses the canonical Git CLI, which makes sense. But it

has major, like a few major drawbacks that are particularly bad

for a hosting service like Pushin or GitHub or whatever.

And the 2 ones are that, first of all, it doesn't have an API.

Everything is a CLI call. So the input and output you're getting is

standard in, standard out. And yeah, if you want to find history

of Git and you want to go back, you have to kind of call the

CLI, And then get back the input. That is

the major issue there. There's no API that you can call, so it's all CLI.

And that also adds overhead of calling a

process, a system process. It adds security issues of having system

calls potentially interfering with each other.

So it's generally not great. It's great for individuals client-side, but not

great for hosting providers. Yeah. And the second, and that's actually the biggest

problem with the CLI, is that it requires you to keep the entire repo

on your disk, and it works only against that copy on

your disk. So, that is the storage problem here.

The storage is meant to be on your disk and not

somewhere else, not distributed in Postgres or in S3,

which I'm coming to in a second. So, GitHub, if you look at that,

and GitLab as well, they solved,

quote unquote, or tried to solve this issue that your state is on the disk

by replicating it across different disks on different

servers. So GitHub and also GitLab and others,

they all run multiple servers that copy your

repo to their own disk. And then only if, you know,

like if you have 3 read replicas, if all 3 of them say,

yes, I've added the change now, Then GitHub

returns a 200 success to the client,

right? So the client pushes, GitHub changes this in the primary

repo, and then replicates the change to 3 different read-only,

or 2 other, mostly 3 other read-only repos.

And then when all 3 of them updated their state, they notify back

the primary repo, primary repo gives back the success to

the client. Yeah, that is a workaround, because everything

is on disk, and you need to replicate disk state. So, that is

also an issue why GitHub is slow, and doesn't scale well.

You know, it's that kind of stuff. So, when you look at a

newer implementation, and I took that idea from the cursor origin approach,

yeah, what you're basically having here is a state

that you need to store, and replicate, and make sure that you

never lose. Right. You can't ever lose a

byte. S3 is why this

exists. Like, S3 was created exactly for this problem. And it

is battle-hardened. If Amazon can run on it, I can run on it.

It is a well-understood problem. So that's

also why Cursor, they use S3 for storing

the state of your repo. And these are the Git packs, actually.

So these are kind of the packed— Like,

it's, you know, I can talk about this more in the future.

And I also wanted to write a blog post about this. But, like, the core

of your Git repo is a Git pack. And that actually keeps the bytes of

your repo. And if you take these packs and you put them on S3,

yeah, all of a sudden, they're replicated. You know, they're fault tolerant.

And you can quickly download them to your server as well.

And you also don't need to have 3 different versions of it. Like, S3 takes

care of that. You don't need to have 3 versions of your Git repo.

So, you can only have— you can have a single primary repo

that reads from S3, and then does the operations, and writes back to S3.

So, that gives you a lot of scalability,

safety, integrity, lots of benefits.

And that's why I decided to then take a

different route, and not use the canonical CLI,

the Git CLI, but instead, I'm relying on a

Rust library that's called Git Oxide. And what they do

is they want to basically rewrite Git in Rust and have

a CLI as well. But they moved a lot of the functionality into individual libraries

that you can pull in. So, gix_merge is

one of them. That's what I use to actually merge your

changes into your primary version. So, I rely

on them a lot for the hard parts, and then I build around those.

mostly the orchestration parts and just the data

delivery parts. So, I make sure everything is in place, and then I call Git

Oxide, you know, to make the changes and so on.

So, you're wrapping that in Rust or NIFs?

Everything's Rust. Yeah, the whole Git backend is in Rust,

which also makes it super fast and also allows me to, you know,

have issues like what you had with, you know, more than 500,000 objects,

in your repo, and take that and just optimize

the hell out of it. And that's what I've done.

When you mentioned that in the beginning, you couldn't push your 500,000

objects to Pushin because it timed out. I improved it so much that

now it's twice faster as GitHub. Right.

So it takes a minute and 20, 30 seconds to push it to GitHub.

It takes 40 seconds to push it to Pushin. By now, you know.

On the first push. Yeah, the initial push.

The subsequent ones are just 1 second or whatever. Yeah, like, the subsequent ones is

just small changes, right? But the initial 500,000-object push,

that's the big problem, you know, and that takes 40 seconds now on

Pushin. So, this way, by owning the Git backend,

I can also make these improvements, and I make them all the time. I still,

like, I make improvements, and all of a sudden, it's 96% faster to see your

You get blamed, for example, you know, that kind of stuff. So yeah,

and the way I kind of make it safe-ish, you know,

like, it's never going to be 100% safe, just like Git will never

be 100% safe. But what I'm doing here is I'm

also reusing the official Git test suite

and copy the important parts to my own test suite, you know.

So I actually have a a test that

fails once a week if I don't update from the official Git

changelog. Like, if I don't look at the Git changelog, and then

I see, oh, they made some changes, like they had vulnerability fixes, or they,

you know, had some compatibility issues with older versions, and they fixed

it here. And they're really good about writing tests for that. So, then I take

those tests, and I feed them to Codex, and I say, rewrite them in Elixir

and Rust. And then, you know, I can kind of— Yeah,

I'm staying upstream. I'm staying in sync with upstream this way.

And I also reuse that to build my own test suite. And I have,

like, I think, 1,000 or more tests, plus 200

Rust tests, just for the Git backend. Right. And the cool thing

here is that I can use Git, the Git CLI, to basically test

the correctness of everything. And that's what I've done substantially as well,

where, you know, I just, yeah, have Git do something, and then I take

the output, and I compare it to our output. And it needs to be 100%

byte for byte. identical, which is what Claude loves to say.

But this way, I always know that, yeah, what I'm

producing is the same as what the Git CLI produces.

So that kind of makes it safe-ish.

Yeah. Right. And so,

I mean, you've definitely engineered this for a lot of speed and things, but now

that you are announcing it here, thanks to everyone who's listening

first to know, But now that you're announcing it

here, where do you think the scalability issues— how

are you going to scale this as you get more people, you know,

signed up, trying it out, pushing stuff? What happens on that when it

hits Hacker News front page and you have 10,000 visitors?

Yeah, I hope that— I'm going to keep it off Hacker News for a while,

both for the user count, but also for the attitude,

right? Because almost all of this was

written with Codex, and before that, Opus, right?

I made sure that I understand the test suites, at least I understand the high-level

picture. I made a lot of architectural decisions, and I set up the test suite.

Like, I made all the design and architectural decisions, and I made sure that I

understand what is happening. But again, I can't really write Rust.

I understand Rust-ish a lot. Okay enough,

right? But I'm not like a Rust developer, so yeah, I can't

tell you whether the Rust code is the most optimal one, but I can tell

you that it works and it's fast, which yeah, I think it's good

enough. Yeah, um, but yeah, so scalability here

is not going to be the raw throughput, it's rather going to be an architectural

issue. And my advantage is that I simplified

my architecture so much that I can scale pretty easily.

So, I can run a single server that runs your repo,

right? I don't need to copy your repo to 2 other servers.

So, that already cuts it down by 2/3.

And then, because I have everything stored in S3 and Postgres,

that's where I kind of keep the metadata of your repo. And then, on S3,

I keep the actual bytes of your repo. Yeah,

I can spin up a new server that then hosts different

repos. So, I can have one repo per server, or one server hosting

particular repos. I don't need to copy repos across all

the servers. This way, I can just spin up a new server, and that

server can pull your repo from S3 onto local disk,

and start serving your requests within a second or 2,

sometimes 3 seconds. So, that's my delay for the cold start.

And then afterwards, I keep everything on disk, and these are NVMe

disks, so it's super fast. And I do everything in Rust.

So, I have a cache on disk, and I update

the cache, and then every update also needs to go to S3 and Postgres.

Only then I kind of commit it and say everything's fine.

Yeah, but this way, I have a cold start of, like, 2 to 3 seconds,

and then everything after that is just a hot cache from local disk that

is then synced to S3. Yeah, and if my server goes boom,

and I have to restart it or add another server, Not an issue

again, right? Just spin up a new server, it pulls from S3, it's done

in 2 to 3 seconds, and it can start serving requests.

So, horizontal scalability is a lot here. You think,

then, mostly this sounds like sharding between

different servers, routing certain

repo requests to the shard of

the server that it should go to. Do you think

that you will add, as well, all the features, nice features that

we love with Elixir and LiveView, and clustering them together

to do all that sort of stuff? Or how do you—

where does Elixir benefit for you? Well, I mean, everything is

written in Elixir, and then the rest is written in Rust. So, the Git stuff

is written in Rust, and everything else is in Elixir. And I use Ash as

well. So, that takes away a lot of the complexity of writing my own Elixir

code, and it pushes it onto Ash. And LLMs are great for

Ash, or Ash is great for LLMs because it's very minimal syntax.

So the LLM can't really do much wrong. It just, you know.

Yeah, Elixir. I don't think even that I will cluster my nodes for now

because I really want to keep it, you know, one user per repo,

basically, or like one server for multiple repos,

but the repos are only ever on that server. So I don't really need— Yeah.

clustering between those. And I'm just going for simplicity

here because I'm also a single guy, you know, and I need to write

it in such a way that I can scale it for, again, I'm not VC

funded, so I need to pay these bills myself. So I need to have it

simple in a way that I can scale cheaply or cheaply enough.

And that it's also kind of, you know, fault tolerant.

Yeah, so that's why I simplified the architecture a lot. And again,

clustering, if I don't need it, I'm not gonna do it. Got it. Right.

But, of course, the whole frontend is LiveView, and that's

been quite snappy, and also development productivity

is way up there. So, it's working out.

Yeah, it's working really well. I'm super happy with it.

Again, if you're from the US and you connect to it, it's going to be

hosted in Europe. So, there's going to be a lag. You know, I will

need to see that I'm— I will need to make sure that the connections

are fast still for everyone in the world. I don't want

to run another server in the US because that's exactly why I'm not doing it.

That's against the point. So we got to see how it is for people in

the US. But if you're in Europe, it's super fast and snappy.

Yeah. And if you're in Australia, sorry.

Sorry. Move to Europe. Well, I mean,

Australia is fine. Eventually, maybe I could move to Australia

as well. Like, the US is the issue here. Right. And, right, like, if I

have, if I have a local Australian, uh, hosting provider,

I could use them to run Pushin as well. So yeah,

for the, the Ash folks who are all in Australia, I apologize, but I also

thank you for your work.

Yeah. All right, let's,

uh, let's wrap this up. Anyone who's interested, if you want to sign up for

Pushin, you can just go to pushin.eu, and there's going to

be a sign-up button, and there's a waitlist now. So you can just sign

up for the waitlist. I'm gonna get notified. And if I know you,

and you maybe leave your GitHub username so that I can identify you better,

I'm gonna invite you pretty quickly. You will get an invitation code, and then you

can just start pushing. Haha. Wow, Peter.

Otherwise— You're pushing the barrier of new technology here.

Pushing the boundaries. Yeah, hopefully. Pushing the boundaries.

Maybe if you leave a good Pushin joke, he'll Well,

yeah, I should add a text input for that. But just

sign up for the waitlist. I will invite you pretty quickly. Let me know what

you think. You can reach me on Bluesky. And I'm also going to set up

a chat server with chato.run very

soon. It's a Discord competitor written in Go

and Svelte. But it's from a guy here in

Europe, in Germany, actually. And he, you know, You can self-host it,

so I'm gonna self-host, and then we have kind of like a Discord experience,

but on self-hosted European servers. Again, I try to do

everything on European infrastructure.

Yeah, otherwise, you can catch me at GOTO Mayer. I'm also gonna speak

at, on Thursday, actually, at the Ruby meetup here in Berlin.

And then next Thursday, I'm gonna speak at the Elixir meetup here in Berlin.

And then I'm gonna speak at GOTO Mayer. Nice. And then I'm gonna speak at

Codebeam. So you can catch me at any of these events or just shoot me

a message on Bluesky. Busy September and October there,

aren't you? I can tell you, yeah. I'm looking forward

to the end of the season, kind of. Yeah. Fair enough.

Well, yeah. Very nice. All right, everyone. Well, hopefully we

can get some reviews and, you know, maybe we'll follow up

on this in the next couple of weeks and see what people are saying.

Exactly. Yeah, I appreciate all the feedback. I know it's not perfect

yet, but I'm working on it. And especially if there are features that you're missing

or that you love, like either that you're missing in GitHub or that you

love from GitHub, and there are really interesting cases

here that people told me. So just, you know, send me a message and I'll

prioritize them and make them happen. He gets them

updated really quick. I can tell you from experience.

It's not like GitHub where nothing happens for a year and then maybe

something happens. Like, give me a day or two and it's gonna be fixed.

Yeah. All right, everyone. 1 hour 20,

that should be enough. Apologies for the long episode,

but thank you for sticking around. And we'll be back in 2 weeks,

right? Just before GOTO Mayer. Just before GOTO Mayer.

I'll have a little bit of an ElixirConf US review,

we'll decide whether or not deep dish pizza is

pizza. I booked the reservation already, so we— Perfect.

Our reporter on the ground will report back. Yeah.

Yeah. All right, everyone. Thank you for listening.

Yeah. Thank you for listening. Apologies for

the length of the episode. Apologies for my Wi-Fi, but this is Berlin and this

is Germany. So, So, yeah, it is what it is, and it's not great.

And we will listen, we will see each other in 2 weeks' time.

See you next time on Macro Mayhem.