Andrew
00:00:01 – 00:00:06
Alright.
I think we've talked about everything there is to say about Marvell and Rails.
Why don't we talk about Phoenix?
Aaron
00:00:18 – 00:00:29
Okay.
Today, we have a guest.
It's not just Andrew and I today.
Today, we have Chris McCord joining us.
Chris, do you want to introduce yourself and tell us a little bit about what you're up to?
Chris
00:00:30 – 00:00:41
Sure.
My name is Chris McCord.
I'm the creator of a framework called Phoenix.
It's an Elixir web framework good for real time applications and high concurrency.
But that's kind of what I do.
Chris
00:00:41 – 00:00:51
I spent my days working on the framework itself.
Fortunately, my employer allows me to do that, so we can talk a little bit about maybe my open source work life balance.
But in general, I'm here excited to talk about Phoenix.
Aaron
00:00:52 – 00:01:36
So I first heard about you, I think, through your employer.
Your employer is fly.
Io, whom we love.
And I think the first place I heard about you was on the Fly blog, which is just, 1, it's beautifully illustrated, but, 2, it's hysterically technical, and I love it, and y'all do an amazing job over there.
So I'm familiar with Phoenix, and I've done some research, but for the sake of the audience, can you tell us a little bit about what Phoenix is, where it kind of fits into, I guess, the full stack landscape out there and then a little bit maybe about how it relates to Elixir and Erlang and kind of some of that stuff.
Chris
00:01:37 – 00:01:49
Sure.
The Fly blog is, yeah, amazing.
I feel like every post is wildly successful, so there's pressure to keep bangers out there.
But, yeah, we have a lot of fun writing those.
For Phoenix, the origin story, I'll try to make it short and sweet.
Chris
00:01:49 – 00:02:13
And I may get in trouble for saying this, but it's like the rails of Elixir.
I think that will resonate with the broader community.
People within the community may be, like, up in arms about that, but it's essentially the go to web framework, batteries included, for Elixir.
And if you haven't heard of Elixir, it's a language that runs on the Erlang virtual machine.
And if you haven't heard of Erlang, it's this more or less obscure language, at least for me, it was coming up through computer science education.
Chris
00:02:13 – 00:02:38
I had never heard of Erlang till I got out of school.
But Erling has been around for 30, 40 years almost.
It was started in the eighties to run telephone switches.
So this very, very niche language and to solve telephone switches maps, like, extremely well to modern web applications and services.
So they, like, they accidentally built this, like, concurrent distributed environment before, like, distributed computing was a thing and before even computers had multicore.
Chris
00:02:38 – 00:03:06
So they had this, like, very niche set of requirements that mapped really, really well to the multicore age when CPU started getting packed onto chips.
So it's kind of this obscure language that was perfect for kind of modern web services.
And that's what the creator of Elixir, Joseph Bilim, saw in the language, started writing it.
I got involved early on in, like, 2013 and started Phoenix.
And we've been one o'clock since 2015, so it's actually, I think, almost 9 years old at this point.
Chris
00:03:06 – 00:03:23
So, we've been around for quite a while, but Phoenix is really about utilizing all of that early heritage for distributed programming, hiking currency, but doing it in a way that gives you this rails or Laravel experience.
So you kind of use all this power and heritage, but without having to be, like, a an extreme expert in these things.
Andrew
00:03:24 – 00:03:44
That's really interesting when you were doing your introduction, and you were kinda introducing it as if people wouldn't know what it is.
And I feel like coming from the rail side, everybody knows about Elixir and Phoenix because in a way, it's kinda like, hey, that's where a bunch of the cool kids went.
Right?
So there's, like, a lot of Rails heritage there.
But it's interesting.
Andrew
00:03:44 – 00:04:04
I wanted to ask you with Phoenix.
So Ruby and Elixir, very different.
Right?
So it's very different technical underpinnings, I think, of the frameworks.
To what degree does that express itself or come out in Phoenix?
Andrew
00:04:05 – 00:04:28
So you kinda made the comparison, like, Phoenix is like Rails in the Elixir ecosystem.
In what ways and I mean, even without talking about LiveView, but in what ways does the framework sort of have a different expression than what Rails was and is sort of historically because of those technical underpinnings from Erlang and and Elixir?
Chris
00:04:28 – 00:04:51
One of the biggest things is the whole idea that, like, Phoenix is not your app.
The way we build Phoenix applications is kind of, like, even a misnomer.
Like, you write a Elixir application that happens to use Phoenix.
So there's a lot of crossover from the Ruby and Elixir community because Jose, the creator of Elixir came from Ruby and I also came from Ruby.
Jose was very prolific, so I think we had people's interest early on.
Chris
00:04:51 – 00:05:22
But the biggest thing is, like, when you write a Rails application, it runs the show.
Rails is running, like, you boot a Rails process.
An Elixir Elixir is like this an Elixir application is a collection of supervised processes, one of which is running a web server that is running Phoenix.
So it's like I could start up an Elixir application, only part of which is running Phoenix, or it could actually be running multiple Phoenix applications.
So it's a much less kind of global takeover of what it means to write an Elixir app, whereas if you're running a Rails app, it's running Rails.
Chris
00:05:22 – 00:05:43
That has some caveats and limitations.
Through the commuters, if they're familiar with, like, rails engines, if you wanna run multiple rails app side by side, that becomes this, like, big abstraction that they had to add to the framework because everything's global.
Like rails.
Root returns the root of the rails app that's running.
And for us, it's like, no, you're booting an Elixir app that could be running all kinds of services, one of which could be could be Phoenix.
Aaron
00:05:43 – 00:06:04
You said that, like, calling it a Phoenix application is almost a misnomer.
So you would boot an Elixir application that could be running multiple Phoenix applications or processes alongside some other processes.
So you'll have to forgive me.
Are we talking, like, are these microservices?
Is each Phoenix app its own little domain?
Aaron
00:06:04 – 00:06:11
And then what else in an Elixir app, what else is, like, running alongside these Phoenix apps?
Chris
00:06:11 – 00:06:22
Sure.
Yeah.
You could think about it that way.
It's kind of like the best of monoliths and the best of microservices.
A lot of people tend to write their app in a way that they don't have a ton of small, little microservices.
Chris
00:06:22 – 00:06:42
But the way Elixir apps work is the concurrency unit that we use is called a process.
It's like a really cheap thread, and those processes can message each other anywhere on a cluster of applications.
So it's almost like if you could take a thread and then just say, give that thread some work, but that thread could be anywhere on the cluster.
And in the case of, like, Fly.
Io, anywhere in the world.
Chris
00:06:42 – 00:07:24
And that allows us to do some really interesting things.
So, like, a web request can come in, and it's gonna hit the Phoenix web server, do some, like, standard cruddy stuff that you're familiar with, like, if you're doing a Laravel or Rails app, but then, like, you could actually just do work on some process running on some other machine on the cluster.
But the code that you would actually physically write to do that isn't like opening up a TCP connection, hitting a JSON API.
You're just like calling some elixir code that happens to be somewhere else.
So I think those are kind of the 2 biggest things where, like, yes, it's kind of microservacy, but it's more like the applications that you're writing are built on this unit of concurrency that happens to, like, birth these really interesting paradigms.
Chris
00:07:24 – 00:07:43
Microservices, typically, we think of open up a JSON API or gRPC endpoint, GraphQL endpoint, and then talk to everything.
And us, it's like, no.
You just write an Elixir application that can talk to other processes.
Like, that's part of the platform.
So we got a lot for free as far as the framework is concerned because we can build on these primitives.
Chris
00:07:43 – 00:08:02
We didn't have to come up with a RPC pattern or distributed pattern.
So I think there's some really core architecture differences.
But if you're trying to internalize it, yes, you can run, like, you could run 5 Phoenix applications that serve a web server on 5 different ports.
And that wouldn't be, like, this huge undertaking of, oh, no.
Now we have global stuff everywhere we have to tear down.
Chris
00:08:02 – 00:08:07
That's just, like, the way we build applications.
Okay.
That's very helpful.
Just
Aaron
00:08:07 – 00:08:20
one more clarification.
You said you could run 5 Phoenix applications.
Would that literally be 5 separate repos that you're deploying 5 different applications independently, or is there some other mental model that I'm missing
Chris
00:08:20 – 00:08:48
here?
Yeah, you could do both.
So we have this concept of an umbrella application, which is just like a bunch of applications that can start and run together inside one virtual machine, or you could deploy each of them separately if you wanted to.
So it's kind of like you could decide how you would want to deploy it, whether you're running a web server in 1 VM on 5 different servers or running 5 web servers on 1 VM in the same server.
So you could, I guess, choose your own adventure, and it's really depending on what you're gonna build.
Aaron
00:08:49 – 00:08:59
Okay.
So Andrew asked you a question of how it's different from Rails, and you blew my mind in, like, the first sentence.
And so I I kinda digress.
So if you wanna keep going about how it's different from Rails, that would be fine.
Chris
00:09:00 – 00:09:25
I think those are the big ones, and it's a functional programming language.
So there's a lot of weeds that we could go into.
But I think, like, the biggest one for me and, like, why I came from Ruby and Rails to Elixirs, I wanted to do things with WebSockets.
And Ruby was poor at the time for that.
I think they've gotten some WebSocket features since then, but I wanted to do things that required very high concurrency, lots of users on the app, and do that at scale.
Chris
00:09:25 – 00:09:47
So, Elixir is exceedingly good at doing these kind of highly concurrent things.
We can run millions of users connected to a Phoenix server, and we've benchmarked it up to that.
So, my goal really coming in was like high concurrent, real time applications.
And at the time, Ruby was not a great fit for that.
I still don't think it's a a great fit, but they have been able to add real time features over the years.
Andrew
00:09:47 – 00:10:49
So our friends at Remote Ruby just did an interview with Jose Valim, and he was talking kind of about the obscure history of Erlang in telephony and how that sort of influenced the structure of Elixir, and then that kinda plays into what you were talking about with the, like, 2,000,000 connections and as a benchmark.
That just blows my mind, but it makes sense just because it comes from such a different place.
I think it's amazing that Erlang was just sort of sitting there waiting for this new purpose to be repurposed in web application development coming from that history.
One thing and because you came from a Rails background, I'm curious on behalf of both myself and other folks that might be interested in taking a look at it.
What was the learning curve, whether it was going from Ruby to Elixir or functional programming generally, what was that learning curve like for you?
Andrew
00:10:49 – 00:11:00
Did it happen quickly or did it take a little bit of time?
Or was it the kind of thing where you started doing it and you're like, this is something that I've always been looking for.
It's so much better than what I was doing before.
Chris
00:11:01 – 00:11:23
I'd say a mix of what you just said, and also, it was my first functional language.
So it was a humbling experience at first.
I got, like, an elixir book, and then just trying to do, like, a recursive iteration.
I was like, what the heck?
I couldn't wrap my head around it initially as my like, it was so different from object oriented programming where, like, you have all this implicit state.
Chris
00:11:23 – 00:12:02
But then I would say, like, there's this frustration gap of 3 weeks until, like, things started clicking.
And it's interesting going back where an immutable functional language, like, your state is, like, always right there in, like, the code that you're using, whereas, like, going back to O'o, anytime I I go back, you have, like, you have no idea, like, your state of the world is, like, whatever's in memory on this object.
So I would say it's it's interesting looking back because now it feels so natural and so much more straightforward than my prior 15 years of OO writing.
But there was this frustration gap that I always tell people, like, you gotta get past that, your first functional language, and then things start clicking.
And then it feels like cheating.
Chris
00:12:02 – 00:12:24
Even now today, like, it feels like things work, and you're like, this feels like I should have be having to work harder.
And it's interesting is, like, for my journey, it's like I was hooked on, like, the promise of Erlang, where, like, I wanted to write a web framework that could scale to a ton of users because Erlang can do that kind of stuff.
And I wrote what I like to say is a best effort approach.
I had never written Erlang.
I've still never written an Erlang program.
Chris
00:12:24 – 00:13:06
So I came in kind of like as a very novice person into distributed programming, and all of this.
And then when we went to benchmark Phoenix Channels, which is like our WebSocket real time layer, I think we capped out at like 30,000 concurrent users originally.
And what eventually got us to 2,000,000 users was like less than 10 lines of code change.
So I like to tell people, like, the primitives that you use to build the language of course, you could write a really, really poorly performing Elixir program, but, like, your best effort approach is often, like, very close to an optimal solution, at least in my experience.
And this is coming through kind of like brute forcing my way into, like, hey, I can write a distributed pub subsystem.
Chris
00:13:06 – 00:13:24
I'm gonna do this for the first time in my life, and then that scaling out to 2,000,000 users.
So I feel like I've kind of lived the beginner through just bashing the keyboard to, like, how is this possibly working so well experience.
And I think that most people kind of have this progression.
So, also, I felt you were
Andrew
00:13:24 – 00:13:49
a little diplomatic with regard to WebSockets on Rails.
Oh, things are getting better or something like that.
Because of your background in Rails and how deeply you sort of deal with it in the Elixir world, Have you kept up at all kind of with the way that that has progressed on rails?
I'm not actually sure I could tell you what the number of connections are that you can get away with in rails.
Do you know in Laravel?
Chris
00:13:50 – 00:14:15
I'll let Aaron speak to Laravel.
I can't speak to how it scales now.
What I know intrinsically is, like, any threaded language, like, even if we're talking I'm gonna catch black.
But even if we're talking, like, Java, like, very performant languages, if concurrency isn't cheap, you're gonna struggle with a ton of concurrent users without having to kind of go outside your typical programming.
So it's like if you write code in a very careful way, you could potentially support a lot of users.
Chris
00:14:15 – 00:14:57
But if your language isn't highly concurrent, like out of the box with cheap threads, then you're gonna have to write code, like, in a special way.
And I think Ruby has some workarounds.
Like, one option, I think, is called, like, AnyCable, which is Action Cable can have different back ends that doesn't run through the Ruby web server, so you can theoretically start up a Erlang web server to service your WebSocket collections that calls back into your Ruby code.
So you end up with kind of like these Band Aid solutions that could support higher scale, but then you get into, like, all these other caveats.
So I think the story is better than it was certainly when I left Ruby in 2013, but I think you're still gonna kind of run into these caveats and either stand up additional infrastructure or pay some other service to do it for you.
Andrew
00:14:57 – 00:15:27
You call it a Band Aid solution.
I call it my real life and the work that I do each day.
Like, we definitely use any cable.
It's valuable, though, I think, to know what the strengths and weaknesses of each ecosystem are, and I do think that it's really special.
When I heard about that benchmark at 2,000,000 connections and Jose saying, yeah, and I sent a Wikipedia page down the wire to all of them, I thought, well, I'll just put this out there for any of the Rails people that are listening.
Andrew
00:15:27 – 00:15:34
If you know how to do that in Rails, please get in touch.
I probably have a consulting gig for you.
Right.
And one thing I want
Chris
00:15:34 – 00:16:05
to touch on, I was trying to do real time applications in Rails in 2013.
The way that it could be done is you could run I even wrote code to, like, there was an adapter service.
So it's like, if you wanted to use this library, I called it sync at scale, you could pay pusher.
So there was, like, a pusher adapter.
So it's like, I'm very 2013, but the only way to make the program viable that called into your Ruby code was to use event machine.
Chris
00:16:05 – 00:16:33
You're coming from Ruby.
It's this event loop on Ruby, which is like JavaScript's concurrency model.
So you end up kind of in this weird paradigm where it's like you can write concurrent Ruby code, but you're writing not regular Ruby code.
It's like, you want to do something with active record inside of EventMachine, like, oops, you better find some active record adapter that also is running inside an Event Loop inside of EventMachine.
You get into this weird valley of, like, only certain types of programs work well in this concurrent library.
Chris
00:16:33 – 00:17:01
And the moment you do something wrong, you've clogged the tubes everywhere.
And this kind of we see this similarly in Java Hasselt libraries that do this.
And even, like, JavaScript's concurrency model is interesting because interesting in that, like, Node is doesn't block on IO, so you can make concurrent programs.
But the moment you do anything CPU bound, your entire program is slow.
So I think the other interesting thing for us is we can do Erlang and Elixir are load balanced on IO and CPU.
Chris
00:17:01 – 00:17:26
So what that means is we can just do the work we want to do when a web request comes in, and the VM is going to, like, time slice that for us.
It's not going to suddenly slow down for all users.
So, like, a good example is imagine you ran 10,000 WebSocket connections on Node with Socket.
IO, and you accidentally wrote some CPU bound code and one of those users took a code path that triggers that.
Now, all 10,000 users have a slow experience because you block the event loop, you block all users.
Chris
00:17:27 – 00:17:47
For us, that one process of 2,000,000 would go CPU bound.
This the VM would give it time slices of work, but everyone else would have a good experience still.
So it's a little tangent into kind of like how our concurrency model, like, just lets you write code, and you're not really worrying about, like, am I blocking here?
Do I have to do something async?
It's like, no, you just write code that does the work it needs to do.
Aaron
00:17:48 – 00:18:15
I have never heard it explained that way, and that's extremely helpful.
Like, I think I now more fully understand why that's valuable.
And we've been talking a lot about concurrency.
So do you find, for Phoenix, that people are reaching for Phoenix to build certain types of applications or would so that's one question.
And then the other question is, do you advocate that they reach for it for, let's say, a regular cred app?
Aaron
00:18:16 – 00:18:24
Or would you say, oh, if you're gonna do a regular cred app, maybe use something else.
Or are you now covering all bases, including 2,000,000 connections?
Chris
00:18:25 – 00:18:41
Yeah.
I my goal is to cover all all bases.
I mean, I think early on, you've gotta buy mindshare and, like, open source is, like, just as much marketing as it is technological merit.
So I think people adopted Elixir and Phoenix initially because, like, it had to have a value add over what they could already have.
Right?
Chris
00:18:41 – 00:19:04
You have to make a bet on this thing.
You're not unlikely to do it unless you really need it.
So early on, you know, high scale companies that wanted a ton of concurrent users definitely flocked, I think, to us.
But my goal with Phoenix remains to, like, of course continue to service people searching for high scale where that you can just grow your product instead of having to rewrite it.
But I also want it to be like just like the best option.
Chris
00:19:04 – 00:19:22
Like, it should be just as easier, if not easier, than Laravel or Rails to write anything you wanna write.
It could just happen to also scale to millions of users.
So I think that my goal is to just blanket, go after everything.
And even if you're writing a CRUD app, I think it's still gonna be a great experience and still have merit over other choices in the ecosystem.
Andrew
00:19:22 – 00:20:19
I think the offering is very compelling, and it seems to me that when people find the opportunity to reach for Elixir, it may be so I can remember back when you were at 1.0 with Phoenix to circa 2015.
We had an engineer at the company I was CTO at Reach for Phoenix for a reporting dashboard, and it was an interesting challenge for us, I think, because we had a bunch of Rails developers and you've got this person on staff that's like, I really wanna try Elixir, I really wanna try Phoenix.
It's getting railsy.
I think it's time, like, it's really coming into its own in 2015.
So they go down that route of playing with it, and they never come back.
Andrew
00:20:20 – 00:20:57
And I've seen that happen time and time again where a developer just basically says this thing has something that I feel like I've always been looking for, and and different technologies provide that for different people.
I've heard people say the same thing about Vue components, for example, in Rails.
It just opened their mind and they felt like that was always something they were looking to reach for.
But then when somebody finds it and they adopt it and then they go into that world permanently, and so that developer never went back to doing rails ever again.
They used Elixir and they used Phoenix for every project after that.
Andrew
00:20:57 – 00:21:56
And I feel like that has been what I've seen as people reach for it, they play around with it, and then they commit to it.
And it feels like, as an ecosystem, it's a long slog to continue getting rails full time, not me personally, but I'm speaking more generally for Rails developers or Laravel developers, that it's difficult to sort of take the plunge.
You can maybe use it on some side projects but then maybe when they're looking for their next role, then they jump into it and they say, I wanna do this full time.
And I think that just the fact that that seems to happen, like, my sample size that I'm drawing on is pretty small, but it's also people that I look up to, developers that I really look up to and respect.
And then all of a sudden they're not doing rails anymore, they're like, no, I just wanna work in Phoenix and Elixir full time.
Andrew
00:21:56 – 00:22:31
So the timing on that, I think, is challenging because I think people really need to find those opportunities to make a switch, but it feels like you've got something.
Like you've got a gravity now in a good way where it's pulling people in and those people are staying and helping to grow the ecosystem and demonstrate, provide more and more examples of, like, really great applications, not just for their reactivity or live view.
They're not just there for the things that are, like, technically superior or whatever.
Like, no.
They're just building great apps.
Andrew
00:22:31 – 00:22:47
You look at SavvyCal that's built on Phoenix and Elixir, and it's like, this is a best of breed.
I wish he would do a starter kit in Phoenix that kinda shared some of those components or whatever, but somebody can do that.
And it does seem like it's a great choice even for the CRUD apps.
Chris
00:22:47 – 00:23:16
Yeah.
I think that developer buy in, you know, it's tough.
This is gonna sound, like, pretentious, but, like, you have to be next level in some ways.
Like you said, Andrew, like, it's a risk for anyone to jump into something that doesn't pay the bills, or it's a risk for a company to bet on a framework that they perceive as may not be around.
I mean, we fortunately, you know, we're old enough now that some of those concerns are are no longer relevant, but it's like you have to have, like, next level value add to give people a reason to even check you out in the first place.
Chris
00:23:17 – 00:23:30
And then, Andrew, like you said, you also have to stick around.
So it's like, you have to get through that what the trough of disillusionment.
Like, you have to try to live up to your promise.
So I feel like we've done a good job to be able to keep people around.
I mean, I think I constantly say, like, it feels like cheating.
Chris
00:23:30 – 00:23:52
I think that's why people stick around.
It's like they realize, like, what they're able to build.
And even me doing this 10 years now, there's still stuff that I'm blown away by, and it's just, like, stuff that I built myself that like, once you write an abstraction and then you use it, and then it's still magic to you.
Like, to me, I feel like that you're definitely onto something there.
When you're blowing your own mind, you're like, how can this work?
Chris
00:23:52 – 00:23:59
And you're like, I wrote this and still amazing.
I feel like I I'm still having those kind of, like, insights 10 years in, so I think there's definitely something special.
Aaron
00:24:00 – 00:24:10
Do you find that most of the developers are coming from the rails ecosystem?
I know Andrew mentioned offhand earlier that all the cool kids are leaving to go to go to Phoenix.
Andrew
00:24:11 – 00:24:14
Hey, come on.
Not all of them, just a bunch of them, and we still want them.
Aaron
00:24:14 – 00:24:39
You said it, not me.
So do you find that they're mostly coming from rails?
Because I think we've had a discussion before about it seems like all the excitement and young talent is going into the JavaScript ecosystem.
So what are you seeing from your point of view, which is different than Laravel and Rails?
What are you seeing from your point of view on where people are coming from and where the excitement is?
Chris
00:24:40 – 00:25:00
Yeah.
I mean, we absolutely have a ton of people from the Ruby community.
I mean, I think Jose and my proximity to Ruby and Rails naturally brought a lot of people over.
Syntactically, there are similarities as well.
So I think that was an initial driver for early adopters to come over from Ruby, but we definitely, I think, nowadays see a decent spread.
Chris
00:25:00 – 00:25:28
I know we've got quite a few folks from PHP, even the Phoenix core team made up from a couple people that have never touched rails before.
So it's not just everyone just flocking over from rails, but definitely a good chunk of people have come over.
And I've consulted in my prior career prior to joining Fly, I was a consultant.
So I worked with a ton of different companies, and we definitely had, you know, companies, PHP, c Sharp, that were making a bet on Elixir for reasons whether it was performance.
Typically, it was performance.
Chris
00:25:28 – 00:25:51
But historically, I mean, I'm trying to think we had a client that rewrote a PHP JSON API to Elixir not doing any of the, like, distributed high concurrent stuff.
They just chose Elixir for kind of, like, Carty type web services, and we're seeing wild success with that.
So I feel like we have a good mix, but definitely, probably the largest representation of folks come from Urvi, I would say, is still true.
Andrew
00:25:52 – 00:26:08
Alright.
So we've mentioned Fly a couple of times, your employer.
Let's talk about that a little bit.
And I'm interested in 2 things in particular.
I mean, one, it's great that they're supporting you in the work that you're doing on Phoenix.
Andrew
00:26:08 – 00:26:34
But also, Jose mentioned in his interview on remote Ruby about the deployment story.
And I had actually forgotten about this, but I remember this being a point of conversation in the past for people that were talking about Elixir.
Oh, it's so great to develop M.
Deploying is a bit of a pain.
I mean, that's the bread and butter of Fly is trying to provide a good deployment story for all kinds of platforms, and they've been hiring people.
Andrew
00:26:34 – 00:26:55
Like, I have friends that work there now whose goal it is to improve the deployment story for different platforms.
Let's talk about the intersection of those two things.
So what's the Elixir slash Phoenix deployment story on Fly?
Is it the best of breed?
Are there alternatives?
Andrew
00:26:55 – 00:26:56
How does that all play out?
Aaron
00:26:57 – 00:27:41
Before you do, I wanna take a guess, and this is going to tell you what an outsider thinks of FLY plus Phoenix.
So this is probably really valuable for you, Chris.
So here's my guess.
As an outsider who knows very little about Phoenix and a little bit about FLY, My guess is that Fly is really interested in Phoenix and maybe even particularly LiveVue because LiveView is a server side front end framework, which is insane to say, but I think it's close enough to accurate.
And Fly is really focused on geographically distributed servers close to the users, and so to have a server side frontend framework, it really benefits to have the servers geographically close to the users.
Aaron
00:27:41 – 00:27:51
So that's my uninformed guess from the Fly marketing.
I would be curious to hear, is that what y'all are trying to put out there or is that the whole story?
Take it away.
Chris
00:27:52 – 00:28:04
Yeah.
That's a good lead up.
So I think you are right about we'll touch on LiveUo in a moment, how it relates to Fly.
Yeah.
So historically, the deployment experience with Elixir, like, you couldn't deploy it anywhere that you could deploy a Rails app or a Node app.
Chris
00:28:04 – 00:28:24
You could deploy Elixir.
It's just, like, we, as in the developer community, since early 2010s, like, Heroku existed.
So it was like git push, and it just works.
I feel like the people say Elixir's harder to deploy, and it's like, well, harder than git push Heroku or harder than, like, coming from PHP.
I was a PHP developer in a former life.
Chris
00:28:24 – 00:28:56
Like, you just drag and drop FTP files over to your server, boom, you're running.
So more difficult as far as that's concerned, but if you can run command on a server, it can run the app.
So the Heroku experience for Elixir is kind of, like, what has been needed, I feel like, to get people thinking that we have parity with Ruby or a Node app.
But that's largely just because the hosting providers like Heroku and what have you didn't directly target us.
But where Fly comes in, and Fly wasn't on my radar, is they do geographic deployments, which is big, and they also give you a private network.
Chris
00:28:56 – 00:29:33
And where that comes into Elixir is Elixir is a distributed programming language out of the box, but you have to be careful when that you need a private network for those servers to talk to each other.
They can be secured, but there's caveats to if you're running this in some cloud where, like, you can send network traffic across, you need to be very careful.
So Fly, really, their networking layer solved a lot of problems for us.
And they really built the perfect platform for Elixir and Phoenix.
So when I found Fly originally, I was like, this is exactly what I've been waiting for because you get this private IPv6 network that's just connected around the world.
Chris
00:29:33 – 00:30:03
So I could spin up a server in the US East Coast, West Coast, and one in Sydney, Australia, and they can just talk to each other.
And since they could talk to each other, I could write an elixir program on my laptop, deploy it to these two continents, and they'll just connect to each other transparently.
And when you write the your blog message for a Phoenix app, it's just gonna show up across the world.
You wouldn't have to suddenly add infrastructure to do that.
So I think the really interesting parts of Fly is geographic deployments, but with a private network between those servers.
Chris
00:30:04 – 00:30:35
And why that's important for Phoenix and LiveView beyond, hey, distributed programming's cool, is what I've been working on for the last few years with Phoenix is a library called Phoenix LiveView, which Aaron touched on.
It's like, imagine if you took React and you put it on the server, which React has actually done over the last year, and we can touch on that.
We've come full circle.
I took React, I put it on the the React programming model, put it on the server where you could have dynamic server rendered apps.
But the caveat when you do that is, one, it could be expensive for the server, but it happens to be that Elixir is very good at running concurrent programs.
Chris
00:30:36 – 00:30:59
But, you know, you're running the state on the server.
Anytime the state changes, you can update the UI over WebSockets.
But if your users are in Australia talking to a server on the US East Coast, you know, they're gonna have high latency there.
So Fly is perfect by putting servers closer to users.
So it's almost like if you could take the CDN model, where, like, we deploy our assets on CDNs because we want users to have fast access to images and our JavaScripts.
Chris
00:31:00 – 00:31:13
So it's like, well, what if we just put our whole app there instead?
We know that like intrinsically CDNs are good because assets are should load fast.
Well, maybe our whole apps should just load fast.
So like Fly went off and built this perfect hosting platform.
I found them.
Chris
00:31:13 – 00:31:31
Kurt and I had a conversation just to, like, how could we get Phoenix working better on Fly?
And that was, like, my first thing, like, what is Fly?
We had one conversation, and I was, like, okay, this is amazing.
And, anyway, the conversation kinda started and, like, maybe we should hire you.
So, anyway, that's the world one tour of what's cool about Fly and why it's perfect for live use.
Chris
00:31:31 – 00:31:56
Because, like, you can run imagine if you could run, like, just like we deploy game servers.
Game servers for Xbox Live should be close to users because those users are physically co located there because of the speed of light.
It's like, well, we can actually do that for our LiveView processes and now for users.
So where the user can they click something on a web page and that server happens to be 10 millisecond hop away, that's gonna be a way better experience than if there are 200 millisecond hop across the ocean.
Andrew
00:31:57 – 00:32:19
I'm gonna say this part, and we can decide whether we wanna edit it out later.
But as I've been listening and kind of, like, reviewing the landscape of Elixir and Phoenix and Live View and Fly, it makes me think of NFTs and crypto in the inverse.
Aaron's like, we're already cutting this out.
Yeah.
Aaron
00:32:19 – 00:32:22
I'm nervous already, but you said inverse, so keep going.
Andrew
00:32:23 – 00:32:40
Yeah.
So the the thing with a lot of crypto stuff and NFTs and all of that stuff is people ask about the use cases.
Okay.
What's the real world application of they're literally, like, the whole decentralized, and that's the pattern match.
Right?
Andrew
00:32:40 – 00:32:49
The whole decentralized philosophy, they're having to rebuild everything from first principles because of this obsession with decentralization.
Chris
00:32:50 – 00:32:50
And then you get
Andrew
00:32:50 – 00:33:26
to it and you're like, yeah, but what are the use cases that are like meaningfully better than what we're already kind of accomplishing in our centralized world?
So you leave that behind and you're, like, alright, have fun crypto folks and folks working on NFTs and all of that stuff, and DAOs and whatever.
Have a great time, hope you have a lot of fun.
And then you fast forward a few months, and we're looking at all of this stuff together, And the use cases just jump out at me.
Think of all the things I could build that are not like my tools of choice, the ones that I'm most familiar with and so you build with what you have.
Andrew
00:33:26 – 00:33:57
And there's some, like, baked in limitations to what you will practically build with Ruby on Rails.
Like, I don't build video games on the weekend or, like, online collaborative games and things like that.
But if I were in Phoenix and Elixir, people do that.
Even when you tell them not to, they still do it.
And so you think of the use cases that you're talking about, it's not just like technical superiority or sometimes developers go down rabbit holes where it's like, I'm not sure there's a ton of value there.
Andrew
00:33:57 – 00:34:11
With the stuff that you're talking about, the value is evident.
The products that you can build with this are evident, and it's it seems like a a unique value proposition of the platform and the framework that you've built.
I think it's incredible.
Chris
00:34:12 – 00:34:29
I can make a point here that's it's probably going to offend some folks.
And I want to be careful.
On the point of the crypto space and NFTs, which is a trigger for me, I won't go down that rabbit hole.
But other than yeah.
Other than, yeah, absolutely ridiculous space, full of pain, misery, despair scams.
Chris
00:34:29 – 00:35:00
Okay.
But if we say, like, those folks are trying to reinvent the world just to accomplish, like, what we can already do.
It's a very interesting point because I see this same thing happening in the JavaScript space.
And I want to be very careful here, loving accusations.
But you see these hosting providers with tons of investment, where it's like, hey, we can run a JavaScript application close to users, and it's gonna be fast, a good deployment experience, like, but you have to, like, buy into like, oh, all your data needs to be stored on us.
Chris
00:35:00 – 00:35:20
Oh, you're going to pay per transaction.
We've got this thing called durable objects.
Like, we're going to put those around the world, but you can pay us and never leave us because, like, we're the biggest black box that exists.
So like, we're seeing all these ecosystems pop up around trying to provide value add to, like, write apps close to users because that's a good thing because the speed of light exists.
But, like, first, they have to invent the universe.
Chris
00:35:20 – 00:35:50
And the universe is, like, no, we have to invent separate universes.
And you pay us a lot of money and never leave us and we never go out of business, you can have a viable product.
And for me, like, my goal is, like, with Phoenix, we can write full step app.
We can side step the entire JavaScript labyrinth of complexity just even if we're talking deploying a JavaScript app on on Roku, not let let alone in the AWS Lambda or Cloud Fire worker, which is like a Nerf JS runtime kinda it's JavaScript, but, like, it's our own JavaScript runtime.
There's, like, this ridiculous labyrinth of complexity.
Chris
00:35:51 – 00:36:23
Or I could just write, like, my Phoenix full stack app, and I could, like, run that thing in Sydney, or and I can run that thing on the West Coast of the US.
I can put it in Tokyo, and do anything I want there, including running a user interface, and have the same speeds that I would have running, like, a Vercel or CloudFair worker close to a user.
So I think this idea of not having to reinvent the world is, like, what we're able to do with Elixir and Phoenix and Erlang.
It's, like, no, we could try a full stack app and, like, just do the things you're used to doing.
You wanna write to a file system?
Chris
00:36:23 – 00:36:42
Hey, there's a file system there on this server.
Let's just do that.
And then, like, a lot of stuff melts away.
This idea of CDNs is also interesting because if you're running your entire app, close to a user, your app is the CDN.
You can start, like, chopping off infrastructure layers where all these other platforms are like, oh, just add this new infrastructure layer and you get new features.
Chris
00:36:42 – 00:37:01
For us, it's like, no, we're trying to kill as many infrastructure layers as we can.
So, like, PubSub is one example where, like, we obviated entire business models.
I was using Pusher in 2013, and then I wrote Phoenix Pub Sub.
It just works on a cluster.
It's like, that goes away and it's just built in and everything's free and you can run 2,000,000 users.
Chris
00:37:01 – 00:37:18
My goal is to, like, do that as much as possible.
CDN, unless you're, like, trying to serve content to unbounded number of users, that completely falls away.
And like the more and more we can do that is the better.
And I'm trying to do that with a framework.
So LiveView lets you, you know, sidestep the JavaScript complexity, but also if you use Phoenix Live View.
Chris
00:37:18 – 00:37:38
And I want to touch on this because it was a recent revelation.
I was writing a blog post actually for Fly, which isn't published yet.
And I had this revelation that the Phoenix LiveView program model started because I wanted my Ruby app to do something dynamic.
Like Like, you've got a static page, and you're like, I could just click a button here, and, like, in a few lines of code, it changed the page.
That would be magic to me.
Chris
00:37:38 – 00:38:10
I built Phoenix and this website at Lair.
But once I got there, I still had this idea of, like, it would be nice just to make a page dynamic.
And that's where Phoenix Live View started, where, like, if you could have a template on the server that was stateful, you do some state change and the template re renders just like a React app, and then, like, we would have this small implementation detail that we sent the UI update over a WebSocket connection.
I was just kind of starting with this, let's make a page dynamic.
And what accidentally fell out of that was, like, we ended up chopping off, like, multiple layers of of abstraction from a web app.
Chris
00:38:10 – 00:38:29
And I didn't appreciate this until recently.
Once we did this, like, we tried to make a web page dynamic, you want a button on a page to do something.
And in doing that, you're no longer writing any kind of HTTP details.
There are no routes to write in your application.
You don't have to add a controller to then, like, serialize some JSON data structure.
Chris
00:38:29 – 00:38:42
Like, you don't have to figure out, like, well, I'm rendering it some users.
So, like, write a user serializer to pick up the fields I want.
Or you say, like, well, what if the client doesn't always want all these user fields?
So you're like, well, GraphQL exists.
Solve this.
Chris
00:38:42 – 00:39:02
The client can say, I only want these fields.
So you write a typed GraphQL schema.
The client can get minimal data.
What fell out in the program model for us was you write this naive template on the server, and we'll send them minimal data that changed.
And we have, like, RPC messages going back and forth, so those replace the entire HTTP stack.
Chris
00:39:02 – 00:39:18
You don't write routes.
You don't write controller files.
You don't have to think about how to serialize data.
It just gets sent down the wire, and the client doesn't have to say, only give me these keys for a user because that just falls out of a naive HTML template.
So it's like GraphQL goes away, HTTP goes away.
Chris
00:39:18 – 00:39:36
You're not thinking about HTTP verbs.
Like, you're not thinking about HTTP at all.
So, like, for me, the goal is to, like, kill parts of the stack as much as possible and reduce dependency on any external vendors.
And that's kind of where we ended up versus what I'm seeing elsewhere in the world of let's first create this new universe of abstractions and things to pay for.
Andrew
00:39:37 – 00:39:56
Yeah.
It's interesting.
One of my favorite I don't know if DHH coined this phrase, but I just looked it up real quick, and it looks like maybe he did.
Conceptual compression, that's one of my favorite concepts or phrases out there, and it is exactly what you described.
It's just so much simpler.
Andrew
00:39:56 – 00:40:33
And then on the proprietary platform stuff, I think it's critical to think about that in terms of adoption by new generations of developers.
If you think of getting people into software development, well, if you wanna get students into software development, you need to do that in a way that is accessible to them for free without commercial strings attached.
And so I think that there's sort of an altruistic reason to continue focusing on that, I think, in all of our software ecosystems as well, trying to keep things freely available and open source where possible.
Aaron
00:40:34 – 00:41:09
Yeah.
You talked about all of the things that melt away with LiveVue, and I have done just a little bit of LiveWire, which is our implementation of LiveVue, basically, over in Laravel, and you're absolutely right.
It's the same kind of feeling I had when I first used Tailwind, and I was like, oh, I don't have to come up with made up names for all of this garbage, like container left side article.
It's like, I didn't just put the freaking classes on it.
When I was using LiveWire, I didn't have to come up with, like you said, the serializers, the controllers, the routes, the handling of JSON on the other side.
Aaron
00:41:09 – 00:41:28
Did you find other ecosystems?
I know that there's obviously LiveWire.
Did you find other ecosystems look at LiveView and say, that seems simpler, that seems better, we should also do that.
And did you have any interaction with Caleb Porgyot when he was writing LiveWire on the Laravel side.
Chris
00:41:28 – 00:41:39
Yeah.
So I've I've had interaction with Caleb.
He's awesome.
No other authors, but I I think at the same time Phoenix LiveView was released.
Dotnet has Blazer, which is a framework.
Chris
00:41:39 – 00:42:05
There's, like, also a client side portion of that, but the dotnet community was doing something very similar in the space at the same time.
FlyView was happening.
But since LiveView was released, we've seen basically every community do something similar.
And I can't say that this is because of LiveUer, but it does seem to me that the JavaScript space like React is doing like React server components now.
So it's like, I wanted to put, like, the React model on the server, and then React folks were like, wait a second.
Chris
00:42:05 – 00:42:17
Why have you put React on the server?
We should put Rack on the server.
So it's interesting that we're coming full circle, and the JavaScript community is approaching it.
Like, we're coming at it from different sides of the spectrum.
We moved everything from the server, and we're, like, making it.
Chris
00:42:17 – 00:42:52
We're moving as close to the client as we can to, like, make the data payloads very small, and they're coming from the JavaScript side and, like, what can we put on the server?
The biggest difference is, like, we have a stateful bidirectional model, but we are seeing, I think, every language that I can think of from Haskell to Go has a LiveView type thing, like, where the read me of the project will be, like, Phoenix Live View for Go for language here, which is awesome to see, but it definitely has resonated with folks.
I feel like something intrinsic to not having to deal with all this complexity to effectively solve the same problem has resonated, for sure.
Andrew
00:42:53 – 00:44:15
I think it must be very satisfying to have worked on something that was really you mentioned other people were coming up with a similar idea at the same time.
That's fine, without discounting the fact that they also had a discovery, kinda like who discovered calculus or whatever.
But it must be deeply satisfying to have contributed something to not just your own ecosystem, but computer science generally.
And I feel like that's in the DNA of this little show that Aaron and I decided to start doing was just recognizing that there are these things that evolve in their individual ecosystems.
It could be approaches to, you know, marketing, a framework, or it could be something deeply technical like what you accomplished and conceptual, really, totally novel idea, and then realizing that, yes, that can be a unique selling proposition because of the technical underpinnings in Phoenix and in Elixir, but also that it doesn't have to stop there, that there may be people that are in businesses that exist and they will never be on Phoenix and Elixir because they are huge businesses that employ 100 of people, but even those developers' lives can be improved by the ideas that you made generally available.
Andrew
00:44:15 – 00:45:05
And the fact that you didn't patent it or try to extract some sort of, like, value exchange with people, but you put it out there, and the best of breed version of it for sure is in your own ecosystem.
I have no doubt about that, and that's from my own perspective even using the stuff that we have in Rails that's similar, like, you all are tailor made for that particular problem that you're solving for, but many of us have taken inspiration from it and applied that and our lives are better for it.
I have to imagine that's very satisfying for you to see something that has gone out.
Pan framework, pan ecosystem, all of computer science, all of software development, every language in the world, human spoken languages, developers are doing things and working with approaches that came out of your brain.
Chris
00:45:07 – 00:45:36
That's a bold statement, but it's fascinating to see.
And I think the most interesting thing is like folks came from if they remember if they're old enough when Rack first came on the scene, I think the Rack developers were like they self admitted that when they were making it, they were like, people are going to hate this.
Like, hate this idea.
It's been kind of fulfilling for it to be like, I knew it was gonna be a contentious way to build applications, and it remains a contentious way to build apps.
And I think people also don't really internalize what it's truly about.
Chris
00:45:36 – 00:46:00
They think it's just like, oh, since it's on the server, it's got to be worse is better.
But it has been really kind of, like, fulfilling to see it, like, kind of take on a life of its own.
And, like, people actually understand now that, like, oh, this could be a better way to build apps in cases.
Not like a severe caveat to like, oh, if you don't want to write JavaScript, maybe that is an okay, but heavy approach.
It's like, no, this may just be a better way to build apps depending on what you're trying to build.
Chris
00:46:00 – 00:46:14
So that's been really fun to, like, kind of see the haters turn into believers.
Even on the Phoenix team, when I was first writing this, we had a couple folks on the team that were like, this is a bad idea, Chris.
Don't do this.
And they've come around.
They were like, okay, I was wrong.
Chris
00:46:14 – 00:46:19
But, yeah, it's absolutely been fun to see this kind of take on wipe of its own.
So in the last couple
Aaron
00:46:19 – 00:46:55
of minutes here, I kinda wanna talk about your ecosystem in general, the parts that you think are totally fleshed out and the places that there are opportunities for maybe other people to come into the ecosystem, potentially bring some of their ecosystem knowledge over to Phoenix and maybe execute on something similar or slightly different.
So do you see, like, some places that are missing, maybe even some commercial things that are missing, some paid packages or paid SaaS offerings or anything like that.
As the leader of this ecosystem, how do you view the whole landscape?
Andrew
00:46:56 – 00:47:30
I'll add to that question as well.
I think that one of the refrains that has sort of repeated itself over the years about package parity, So, oh, we're in terms of rails, like, we have all these packages, we have all this wealth, it's all this stuff that has been built up over the years, and I'm curious to hear as well, maybe speak to that point a little and how that's evolved because it has to be that you're now covering more and more of that surface area.
But, yeah, to Erin's question as well, what's still missing?
What are the opportunities for people to provide something in the Phoenix ecosystem?
Chris
00:47:30 – 00:47:35
What's missing?
Yeah.
The package parity earlier on, that was the biggest thing.
I mean, for me.
Right?
Chris
00:47:35 – 00:47:47
I was like, oh, I wanna build everything in Elixir once I found Elixir.
And I was like, well, since I build web applications, I guess I need a web framework.
So I had to write one.
Right?
So over the years, those cases become less and less.
Chris
00:47:47 – 00:48:02
You need an s 3 library.
Well, we have an s 3 library.
Or you need an authentication device for Elixir.
Phoenix has a built in authentication generator now.
So, like, most things I think folks need the the kind of the things that they would expect to be there or there.
Chris
00:48:02 – 00:48:30
But, obviously, a community that lives for decades or 15 years before we started is gonna have more packages.
But I think that's a much less of a problem now compared to, let's say, 5 years ago for folks coming in.
On as far as what's not there, I think my goals for the framework itself are to continue to eat away at this is gonna sound pretentious again.
But, like, my goal with LiveView isn't to replace single page application frameworks.
I think they have excellent options.
Chris
00:48:30 – 00:48:48
And multiple options in the ecosystem are excellent.
They have their use cases, but, like, I want to obviate them for a large number of apps.
So I use the term obviate, like, to make unnecessary.
And I think that's my goal for the framework.
If you have bold ideas, like, I wanna build a scalable global application.
Chris
00:48:49 – 00:49:22
I want you to be able to just go do that without having to pay a service to send messages across the planet.
Durable Objects from Cloudflare is a good example.
One of the things that I want to build long term with Phoenix is, like, we have this Phoenix PubSub, which is distributed PubSub.
There's Phoenix presence, which we haven't talked about, which you can see who's online on the cluster that's built in, but it's not backed by durable storage.
So there's a layer here that exists commercially and various hosting platforms where like, you can pay someone money, and they'll put your state all over the world and allow you to have these like durable actors.
Chris
00:49:22 – 00:49:50
And it's like, no, we have a distributed programming model with distributed actors already.
We just need to write a an abstraction that allows them to back up their data and send it across a cluster.
So I think long term, my goal is to explore kind of like the distributed actor space distributed durable actor space within a Phoenix Pub Sub project.
And that way, we're chipping away at more and more why you would use kind of these other services.
So, like, I think we're already pretty close, like, just like we kind of obviated Pusher.
Chris
00:49:50 – 00:50:14
If you want scalable WebSockets for free, we did that 10 years ago at this point.
So I wanna eat into more and more of those use cases.
The CDN is also another good example.
If I'm already running my app across the world, I should just have something that can replicate files across the world.
So anyone's interested in kind of like a file replication or kind of distributed kind of a distributed programming toolkit is what I wanna build out of Phoenix PubSub.
Chris
00:50:14 – 00:50:17
Those remain to be solved, but it's definitely what's on my mind long term.
Andrew
00:50:18 – 00:51:04
So looking out from where you are, you have created an incredible world that you, your friends, some of my friends get to live in and really enjoy the work that you get to do every day creating this new world with a ton of use cases and reasons why you're building it.
I love it.
What do you see when you look out from the vantage point that you've given yourself?
Obviously, incredible strengths, you know what they are.
Are there any things that you look out at in other ecosystems that you still kinda think, oh, there's an inspiration or there's something that I can look up to as we're building out this relatively new or newer ecosystem in some cases?
Andrew
00:51:04 – 00:51:16
Or maybe there are newer ecosystems that have also cropped up where you're like, oh, that's a strength.
That looks great.
Are there any things like that when you look out, you think, we can do that, we can benefit from that, we could do
Chris
00:51:16 – 00:51:32
more of that?
The dot net community and I have the least touchpoint with dot net.
Like, I I did, like, a c for some college.
But beyond that, I'm not really in that community.
But what they have is Microsoft created a framework called Orleans, and it was written for, like, Xbox Live.
Chris
00:51:33 – 00:51:52
And I touched on kind of this distributed, durable actor thing.
That's definitely what I take inspiration from when I think about that.
Before I would go start working on something like that, I would go read a an Orleans book.
If you think about, like, Xbox Live, like, you've got these virtual actors.
So, like, you have something, let's say, representing a game lobby who's there.
Chris
00:51:53 – 00:52:07
And what represents the game state, you ideally wanna put that close to wherever most of those actual players are.
So you have this idea of, like, I've got a program running that has the state, so this actor, and I wanna be able to move that around across servers.
Andrew
00:52:07 – 00:52:07
So this is where you get
Chris
00:52:07 – 00:52:30
into distributed, durable, virtual actors is what I wanna build for for Elixir.
And that I already have these actors that I can talk to across the network that's just built in.
But can I be able to say, move this one now from this server to this other server?
And where I'm taking inspiration from that is what the Orleans folks have done.
Akka in the Akka framework for Java is also doing something similar in this space.
Chris
00:52:30 – 00:52:48
So there's definitely some prior art here that I look at it and I'm like, they had to, like, first invent the universe to even build their primitives.
So, like, I'm taking inspiration there, but much of the hard problem for me is already been solved by the virtual machine.
So I kind of am spoiled in that regard where I can take inspiration and then, like, much of the hard problem of, like, talking to servers is already solved.
Andrew
00:52:48 – 00:52:49
I love it.
Man, Andrew,
Aaron
00:52:49 – 00:53:29
I'm glad you asked that.
And, Chris, your two answers, I've heard of neither of them.
And so I'm really excited about this because Phoenix, obviously, is Webb, but Elixir, Erlang, the whole deal is so far beyond me and the stuff that I've done historically that I feel like there's a lot of really interesting stuff to learn about that I have never even heard of.
Like you said, Orleans, and I was like, That's never crossed my Twitter feed once.
And so, this world that you live in, I feel like straddles both traditional full stack MVC web or whatever and then this other historically telecom, you know, distributed computing stuff.
Aaron
00:53:29 – 00:53:34
It's really interesting.
So I'm just super glad that you came by today.
This is amazing.
Andrew
00:53:35 – 00:53:39
Yeah.
And I love it on that answer because the two things that you mentioned,
Chris
00:53:39 – 00:53:40
and I think that this
Andrew
00:53:40 – 00:54:09
is something that we need to get past in our own little pockets of the industry.
You mentioned dotnet and Java.
Like, I think in other contexts, people would, in the Rails community or in PHP or whatever, in Laravel, you might have developers that kinda like, that's like the punch line of a joke.
They look down on Java that they maybe worked with in the past, or they see the Microsoft stuff.
There's some history there for those of us who have been at it for a while.
Andrew
00:54:10 – 00:54:55
And I think that there really isn't a place for that If you wanna get the best possible results in your own ecosystem, you're not above anybody, and you're not above the engineers that are doing work in those ecosystems, they're not excluded from having distinct, unique, novel insights into how we solve problems on this infrastructure that we're all building on top of.
And so I love that those were the two answers.
It was, like, the ones that sometimes people would roll their eyes about or whatever.
I think that was really cool.
Chris, thank you so much for joining us today, and everybody's gonna wanna know where they can get your crypto investing advice.
Andrew
00:54:56 – 00:54:59
So where do people find you on the Internet?
Chris
00:54:59 – 00:55:16
Oh, wow.
Yeah.
Chris_record on Twitter is where I exist.
But, yeah, I don't really really have any hot takes, but, this is if you're looking for hot crypto takes, yeah, you might have to find me in private.
But yeah, I think anything elixir related, happy to chat with folks.
Chris
00:55:16 – 00:55:23
Also the elixir Slack room, I'm generally available.
So if folks are hopping in, just getting started, I'm always happy to answer questions.
Andrew
00:55:23 – 00:55:34
And I meant what I said earlier, Chris.
Many of us are working with tools and approaches and living in a world that originated in the things that you shared with all of us, so thanks for those gifts.
Chris
00:55:34 – 00:55:48
Awesome.
Yeah.
Thanks for having me.
I I love people basically using things that I've built.
But I love building things that build other things, so I feel like it's, like, the ultimate meta thing to be able to build a framework that somehow people can use to, like, build novel things I would have never thought of.
Andrew
00:55:49 – 00:55:52
Framework Friends is edited by Paul Barr at Peachtree Sound.
Aaron
00:55:52 – 00:55:55
Our intro music was created by Corey Griffin.
Andrew
00:55:55 – 00:56:04
You can find us at frameworkfriends.com.
Andrew's on Twitter at Andrew Culver.
And Aaron is on Twitter at aaron defrances.
