Today we talk with Wojtek Mach from Dashbit, about the Livebook Desktop app, a tool for writing interactive and collaborative code notebooks.  Dashbit primarily works with clients, helping companies adopt and run Elixir.  We talk about the history of how Livebook came to be, and the challenges of developing for desktop apps.  We also get a sneak peak into what is coming soon.

Hey everybody and welcome to another episode of Elixir Mix. This week on the panel we have Alan Weimar.

 

Hello?

 

And me, I'm Sresher Wolf, just the two of us, but we have a special guest. And this week we have with us Wojtek Mach. Wojtek, why don't you tell the audience why we invited you and what we are going to talk about today.

 

Hey everyone, yeah, I'm Wojtek and I guess we are going to talk about Livebook Desktop, which I'm pretty excited to talk about. Yeah, happy to elaborate on any or all parts.

 

Yeah, nice. I'm actually really looking forward to that because I feel that's one of the areas where in the Elixir ecosystem, there's been a lot of movement over the past few months. But maybe first things first, you're with Dashbit, right? So like, maybe you can tell the audience a little bit like about yourself and also how you ended up at Dashbit and how you ended up working on this thing. And then I think we can go from there, like, why you are building this, right?

 

Sounds good. Yeah, so, yeah, I'm working at Dashbit. I'm based in Krakow, Poland, but we are all working remotely, basically. I think I have joined Dashbit maybe four years ago or something. I think it should be about four years. So I've been working with some great colleagues a while. But yeah, like, before that, I was working for a Netherlands-based startup. But I basically started working professionally with Elixir in 2016. And kind of looking... And that was the year where I basically kind of focused on Elixir. focus more, like I've been looking at it since I think 2014 maybe, but in 2016, I really started to focus on it. So some of my kind of first contributions to the ecosystem was I was basically learning Elixir by writing PRs to the Hex PM project.

 

Mm-hmm. Mm-hmm.

 

And Eric was very kind and very patient. with this and down the road he invited me to be on the Hex team and I've been there since and that was a lot of fun. We were able to create some really nice projects and kind of keep the lights on. And yeah, as I mentioned, I have been working with Dashbit since about four years ago. We basically do two things at Dashbit. So we work with clients. And we like to say that we are helping companies adopt and run Elixir in production. So that's our main job. But what we also do is we invest in the Elixir ecosystem. So we work at Aton on open source libraries. So recently Livebook, obviously, which we're gonna talk

 

Hehehe

 

about, but other than that, we have, you know, Ecto, XDoc, Phoenix, some other Dashby projects, like Broadway and others, and then the whole Elixir machine learning ecosystem.

 

Yeah, it's pretty pretty.

 

Which, sorry to, yeah. which I think is fair to say that live book is a pretty important piece.

 

Yeah, definitely. I mean, I feel a lot of buzz, also like newsletters and everything, right? Like it tends to be about Lifebook and what people do with Lifebook. It's definitely like a topic I see again and again and again and again coming up in the community. So when I saw that you're now working on the desktop app, my first thought was like, okay, yeah, that seems like a natural next step because I did double a bit of Lifebook. I haven't really... done anything big with it yet, right? But I was like, hey, like me, you have to set it up on your local machine to get it to run. So the Livebook desktop app was certainly something where, let's just say I wasn't surprised, like it made sense. You know? So why don't you give us a brief little history, like a series of events that led to you working on this thing, like on the desktop app for Livebook.

 

Yeah, so to me, so kind of like personally, like I always, I think that the kind of out of the box experience is really important. And

 

Hmm?

 

like, you know, even before, even before Ruby, like I really started learning programming with PHP. I think I'm allowed to say it was back in the day, but I think so and Importantly for me was that like the out-of-the-box experience was pretty pretty good like, you know, I was a teenager I was able to download this one program at the um, I think lamp stack or you know, the equivalent on windows and I was basically able to do some, you know programming see the results Uh very quickly, so it kind of stuck with me the whole time and then there was Like, you know the nice and maybe not so not so nice part of it, which was the deployment. So again, back in the day, which maybe the younger listeners wouldn't know this, right? But what you do is you would FTP to your production box and then just upload files right away. There was no Git,

 

Yep.

 

no...

 

I still remember that, yep.

 

Yeah, so that was pretty wild. But like, again, kind of, there were so many wrong parts about it, but like on the other hand, kind of stuff just worked, right? Like there was no friction. So this kind of idea, the out of the box experience, like no friction, I think kind of stuck with me the whole time. And that was one of the appeals for me of Elixir, that like you download Elixir and you have a bunch of stuff ready to go. So it's Elixir itself, but like Mix. And I think Mix is just great as a build tool. And then we have, you know, X-Doc and Hex and... of the stuff, so like really nice set of tools. And so, and like importantly, outside that, with Elixir, like a lot of these things, so Elixir mix, EX and stuff, like COM included with the distribution, so you don't have to install them separately. So, yeah, so like. Stuff like that is important to me, let's say. So when Livebook came about, we started Livebook with just, Livebook was just Livebook, right? So how do we distribute it? Oh, so it's an Elixir project, so we made an eScript out of it. So if you already have the Elixir toolchain, I think the command is something like mix, eScript install. and then either GitHub or Hex. So that would be one way to install Livebook. But it requires you to have already the tool chain installed on your machine. And I think that is totally fine if you are already an Elixir developer. But I would say that one of the important parts, or maybe a lot of potential of Livebook, is to be a tool that brings people to Elixir. And so if you require you to install Elixir first, oh, and then by the way, you actually need OTP first. And then, oh, like actually you need OpenSSL, maybe like a very particular version and

 

Mm-hmm. Mm-hmm.

 

other stuff like that. It's a lot of friction, right? So the second installation mechanism that we had for Livebook was we are creating, we maintain Docker images. So if you already have Docker, it's very easy to run Livebook. And like, well, I guess the, maybe, maybe the logical next step was to have kind of like, the kind of the parts that the Docker is good at, which is bringing everything together, but like without Docker. So that would be the like native, native installation method. So that's the Livebook desktop. Basically, it's a distribution of Livebook that contains everything that you need to run Livebook on your operating system. We support Mac and Windows at the moment. And basically, you download this one file from our website. And yeah, after installing it, using that one file, you are ready to go. So our goal is that... So like without it, let's say what you would have to do. Well, you would have to install, as I mentioned, install Elixir, install OTP, install OpenSSL. You don't need to do any of that. And as a matter of fact, it should totally work if you have a blank slate, totally new installation of your operating system, no DevTools, it should just work. If it doesn't, that's a bug that we will fix.

 

I found a bug then.

 

Yeah, let's hear it.

 

Yeah,

 

Hahahaha!

 

I feel bad for not reporting it. But like I was in the middle of showing somebody who

 

Yeah.

 

so he was like, Yeah, I really want to do more machine learning. And I want to do more Python because we do

 

I know

 

a

 

what it

 

lecture

 

is.

 

over here. Yeah. And I was like, Okay, check this out. And I showed it to him. And then I double clicked it to open up on a Mac. And it gave me an error message. And I was like, Well, it should work. And then I had to quickly change subject, right? Because He's a Python fanatic, so when I try to show him this kind of Jupiter-like notebook for Elixir, try to talk him more into Elixir and edX, it didn't help my case out at the time. So...

 

What?

 

Oh yeah, sorry about that. We did have...

 

It's okay. Yeah, I it's my fault for not recording it because I'm like, yeah, I should report that and I totally forgot. I'll see if I can report it what's going on because it's good to hear that it actually should work out the box. So I wonder what the problem was because the person's computer who I was using now is like somebody who just writes emails like so like even Chrome I think they haven't have installed so it should really be a really good use case where it should be working.

 

Yeah, so like I tested, I tried testing it on fresh VMs and it worked on my box, right? But

 

It works

 

there

 

on

 

are

 

my machine, yeah, yeah.

 

so many different scenarios and use cases. But yeah, if you can reproduce, we're happy to look into that.

 

Well, that's how it always goes, right? Like, I mean, at the end of the day, this is still a very fresh thing, and you're gonna run into situations like that. Actually, arguably, I would have been more surprised if nobody at all didn't find any kind of edge cases where this doesn't work. So yeah.

 

In some sense, it's maybe like, it's gonna sound silly, right? But like, because people report bugs, it means that like people are actually trying to use it, which

 

Yeah,

 

is nice

 

yeah,

 

to

 

definitely,

 

hear.

 

definitely. I'm actually curious, like, I mean, looking at it, like, kind of with insight, right? Like, okay, your first live book, and then you say, okay, you have to install with a local tool chain, but maybe you also have a Dockerfile, and now this desktop app, it seems like a natural evolution. But I'm actually curious to maybe look a little bit, peek a little bit behind the curtain. Like, how did this go at Dashbit? Like, how did you talk about that, right? Like, was it just clear from the get go, hey, we want to do this live book thing and like desktop app? sure that's the thing we aim for or was it more of like an iterative evolutionary kind of approach where like at some point somebody maybe you said hey what if we build a desktop app right

 

To bardzo dobre pytanie. Słucham się, że nie pamiętam o tym powstanie, ale myślę, że cały czas, cała drużyna była wstydna na to, że mamy bardzo fajną, wyjątkową doświadczenie. Myślę, że desk top był naturalnym następnym krokiem. it was kind of natural, but also kind of, we wanted to avoid going through the hoops for new users. And I think as the live book is still, we still develop it, there is still a ton of work to do, but for me personally, it would be really cool if people could use live book in classrooms and stuff like that. And so

 

Mhm, mhm,

 

it

 

yeah.

 

would be very nice if there is this one. one installation, like one artifact that they can run. And it's kind of like very reproducible. It's not like, oh, you know, maybe you install this, dependency this version, and then it breaks. Like, no, we kind of package everything up. And that makes it much more, this way, like we expect it to work. because it's kind of like more deterministic, so to speak.

 

Yeah, that makes a lot of sense to me. And I definitely can see the appeal of having it like this first kind of introduction thing to Elixir. I definitely see a value in that. In general, like how does it go when you work on a project like Live Focus? How big is team there working on this? Do you regularly come together and also figure out, okay, where do we want to go next? I mean, you said at Dashbit you also work with customers. Are there some people who only work with customers? Or is it like a rotation kind of thing? I'm just

 

Yeah.

 

curious to see what the development model there is.

 

Yeah, so in terms of working with customers, that would be three of us. So Joseph, Phillip, Sampayo, and myself. And the rest of the team is 100% open source, which is really nice. And then in terms of Livebook desktop, I would say that, like, I mean, so technically, I have commit access, so I can push whatever I want. But I really don't. contribute to parts of Livebook outside of the desktop. So that's the, I think mainly Jonathan. And then we also have Chris and Alec working on some really exciting upcoming new features for Livebook. But like, so I would say that what the Livebook team works is like the Livebook core. So... the infrastructure, the editor. And then recently there was a lot of work around smart cells. And then, yeah, and then there's gonna be some exciting new stuff that I'm not quite ready to talk about yet.

 

Hahaha

 

So just a little tease for you. So, yeah, I'm not quite ready to talk about it yet.

 

I'm gonna keep my eyes open.

 

Yeah.

 

For this new stuff though, I mean, is this how do you guys work on new stuff without talking about it because it is in the open source, right? So for viewing the repository, can we see everything or am I wrong?

 

Yeah, you can see everything.

 

So if we take the time to actually research, we can find out what's going on. But if

 

Oh yeah.

 

you just won't tell us.

 

Yep. There's

 

I

 

a

 

always

 

ho-ho-

 

find that process very weird.

 

It is kinda weird, but yeah.

 

But you know what? It works because I'm too lazy to go check it out right now. So it's

 

Right?

 

working.

 

Exactly. I mean, we would occasionally work in like private repos that we would only make public once we announce

 

Mm-hmm.

 

stuff. But yeah, a lot of, I would say most of the work is in the open. Like if you, like even about the desktop, maybe it was teased at some like event or something, but like all of my PRs to the desktop stuff. were public from day one. So someone could totally be up to date by just following the repo, which I think is pretty cool that we are able to, like, if someone is interested, they can always just look at the code or contribute. Yeah.

 

I'm always curious about like if you're working in like a private repo and then like somebody sends up something very similar to your work and you're like you want to tell the guy no need or whatever but you know you work on something secret like how do you handle this kind of situation but I'm pretty sure that never happens.

 

Yeah, I don't think that happened often. Like, so,

 

Wait, you said often does that mean it does happen then?

 

yeah,

 

Ha ha ha!

 

I cannot think, yeah, okay, yeah, I take it back. I cannot think of any particular example right now. What I would say is that, like, even though, you know, I would say that, like, we are not, like, super secretive either, right? Because... I think it's mostly maybe like keeping stuff private, just so that like when we do launch it, we can control the story better as opposed to, you know, kind of, as opposed to not to. So like,

 

Yeah.

 

even if we are working on like, you know, exciting new secret project, it's not like 100% secret. Like you can, like if someone in the open is gonna ask about it, we are gonna respond.

 

It also gets a different level of commitment as soon as you announce

 

Yeah.

 

it, right? Like if you

 

Yeah.

 

work on it a

 

Right.

 

bit and you try something out and like at that point, you might still very, very well say, ah, okay, let's scrap it. It doesn't work out, right? But if as soon as you say, okay, you go out there and say, Hey, this is the thing we're working on, it gets a different commitment kind of to it.

 

Right.

 

I

 

So

 

think,

 

yeah.

 

but I think there's only one thing that Elixir does for one feature, which is like the type, the types, right? It gets announced and pulled back and gets announced again and probably will get pulled back again. It's like, I don't know why,

 

Tak, typy, myślę, że typy są może specjalne w tym, w sensie, że na wielu, wielu, wielu

 

but for some reason, like in the community, that topic will get talked about openly, but everything else is kind of like underneath

 

can

 

the

 

just

 

hood.

 

use Gleam as we had Louis here two weeks ago. Ha ha ha ha ha.

 

different arguments, unfair arguments and stuff like that. So yeah, maybe just because it's like that, types are maybe kind of special, but

 

But I'm-

 

yeah. I'm pretty sure we are gonna get it right this time.

 

Hehehehe

 

Ha ha ha.

 

Oh really? You have some information or we have to keep watching the repost now?

 

Yeah, no, that work is not in any repo, but we have a fantastic colleague, Gileam, that is working on a lot of theory behind it. But, you know, on the other hand, you know, it's research and development. There is no, like really no kind of, there is no promises. It's research.

 

Yeah,

 

But...

 

yeah, that's how it goes.

 

We're all very excited about the possibilities this may bring.

 

I would like to circle back to Lifebook, right? And I would actually be interested to hear from you, Voitek, like how, I mean, you said you were not that involved in like the whole Lifebook development, but you were very much involved in like getting this shipped on desktop, right? So how did this like happen? Like did you at some point say, hey, I want to build this or somebody came to you and then you started working on it, or did you like start to dabble on it in your free time? Like how do I

 

Yeah.

 

have to imagine this happening, right?

 

Yeah, again, I don't quite remember all of the details, but I think I was pushing for it, for having the desktop, just because I thought it's, again, you know, allowing to have this out of the experience. And I think that I'm pretty sure that Jose said that like... like, do you really want to do this?

 

Hahaha!

 

Like, do you really want to do this? And I said yes. And, you know, many, many, many months afterwards, we have something. But yeah, it was a lot of work, a lot of kind of trial and error. So another thing that Joseph said that kind of stuck with me was something like, I mean, half jokingly, right? But like, If you thought that cross browser web development is hard, talk about cross platform development.

 

Oh boy, I can imagine.

 

Yeah.

 

So, I can mean, he said that you don't remember details, but like roughly every 10,000 feet of of you, like how was your journey from, from there? Hey, I want to do this to now. Okay. We have this thing now and you can download it, right? Like I guess the whole cross-platform UI topic is probably like WX, airline, right? It's probably something which, which was difficult to deal with. I couldn't would assume. But in

 

Yeah.

 

general, what were some of the major roadblocks you encountered?

 

Right, so again, kind of like about, about like even starting with Elixir Desktop, with Livebook Desktop, I see I just made a common error. So I think it wouldn't be even possible if not for Elixir Desktop project, which is a project started

 

Mm-hmm.

 

by Dominik Letts. And he basically showed that like, this is possible to have, you know, like, this app, this kind of distribution of Elixir. I think this has happened since we started the work, but he was even able to submit an app to the app store, the iOS app store. So pretty

 

Yeah,

 

impressive

 

yeah.

 

stuff that compiling OTP just for an iPhone or an iPad and kind of like package and covering up. So even before we officially started. Livebook desktop, our Livebook desktop journey, we were already in contact with Dominik and he has been super helpful since. So Elixir desktop is really about, let's say the whole kind of, yeah, that like you can build a Phoenix app with basically a web view. So it's a native window with web view that's pointed to your app. And... And so we, when we started with Livebook, we wanted to tackle like in the same space, but we wanted to tackle like a subset of that problem, which was just the packaging part. So like creating the appropriate bundle for operating system, patching your packaging up the OTP and other dependencies, and then kind of be like maybe a little bit. agnostic to how the application actually works, but like just doing the bundling part. So at that moment, which was about, I think, a year ago or so, the Dominic obviously already had like a lot of a way to package everything up, but it was not

 

Mm-hmm.

 

part of the Elixir desktop project. It was kind of, you know, maybe something on the side. So we wanted to... as part of the Livebook desktop project, we wanted to build this tool that would solve that problem, well, the bonding part. So since day one, we had like an internal, in the sense it was part of the Livebook repository, but it was a separate project. We had a little project called AppBundler that we still have there with an idea that like once we are comfortable, we are going to extract to be for it to be its own thing. But what a bundler does it... it, so a browser basically has two parts. The first part is like configuration. You configure your application, so you set stuff like, like what's the name of the application, what's the icon, but also maybe more importantly, like some unique features, I mean, features that we really need for Livebook, but kind of maybe more involved features, so like, what the... Custom file extensions does my application support or what custom

 

Mm-hmm.

 

URL schemes does my application support? So with the up-bundler, we have this configuration which you put into your next release configuration. I'll get you set stuff like icons or the URL extensions and stuff. And off of this configuration, which is basically a cross-platform, we then go ahead and make it work for different operating systems. So on Windows, we create the application bundle, which by the way, I think it is pretty elegant how they did it. So an app is just a folder, basically with some kind of subfolders and some files and specific locations. So you can totally build an app. yourself with just a bash script, for example. You just need to

 

Mm-hmm.

 

put the bash script into a specific place, which I think is super cool. But yeah, so on a Mac, we create the app and also we create the DMG. So that's this image, which is like a very common way to install things. It's like the kind of drag this file into this applications directory or something. On Windows, we have the... we create like a setup, like installation wizard. Yeah.

 

I mean,

 

Oh,

 

how

 

and

 

much...

 

then, oh, sorry.

 

I wanted to ask how much swearing did happen while you were figuring out all of this.

 

Yeah, it was definitely a journey. So I mean, I almost have forgotten like most of it, but I don't know

 

So

 

like.

 

bad, so bad you forgot most of it. I know

 

I'm not

 

the feeling.

 

gonna do it.

 

Yeah, it was pretty bad. I would say that it was a huge surprise that we were able to make it work in a very short amount of time. So I would say that in a very short amount of time we got like the 80% done, but

 

Uhhhh

 

the final 20% was just the worst. So I don't know, just kind of like some random stuff. we deployed, we started testing stuff on Windows and we noticed that on high resolution displays, it's the little GUI that we have. We don't really have any GUI at all. It's just like the system indicator. But like we noticed that like, oh, that is very low resolution, like what's going on. So, you know, you go into this rabbit hole and turns out you need to write something called a manifest that you then have to attach to the executable.

 

Mm-hmm.

 

So that was fun. And then, I don't know, so like on Mac, so you mentioned that we use WXWidgets, which I think is really, really cool project, but it does feel like it's that like 80% solution, that like you can get really a lot of work done with WXWidgets, but to get the last remaining 20% it's a lot of work and you can run into edge cases. And then, so specifically about WX widgets or maybe the WX Erlang, so the Erlang bindings to it, since we are using it, so it's like, you know, it's our app, then there is the WX Erlang and then there is the WX widgets. So it's kind of like, you know, these layers, these different projects and... you can hit bugs in any place in these layers. And so again, kind of specifically about WX widgets. So I think it is really nice that it is part of Erlang. Again, there is that out of the box experience, right? Like it's already there, you can just use it. But if there is a bug in WX Erlang, then... and you fix it, you need to fork OTP, you need to build it yourself. So that adds a lot of work. And then if there is a bug, and we did hit those in WX widgets itself, that's C++. So again, in this particular case, because the project has these kind of like different layers and you can, in this particular case, In particular case, if you run into bugs or just limitations to be frank, it is pretty hard to peel off those layers too. It is hard to make changes.

 

It's turtles all the way down.

 

That's too, yeah.

 

So did you also, I mean, you just said like, when you fix a bug, for example, in WXO link, then you need to fork OTP yourself.

 

Yeah.

 

So did you actually have to do that? Is this something?

 

Oh, yeah.

 

Okay. Okay. And did, are you planning on like merging those upstream or did that already happen?

 

We have, so we had some PRs already merged.

 

Mm-hmm. Mm-hmm.

 

We have some kind of pending PRs, like we are waiting for feedback. But yeah, we are trying to upstream as much as possible.

 

Yeah, yeah, makes sense.

 

It's

 

And

 

actually

 

I guess the-

 

funny that you mentioned it because we, so one of the, I mean, it might be of some interest. One of the recent works in the Livebook desktop space was that we are, so. up to this point, all of the releases of Live with Kudoscope, which I think was just, I think it was frankly just one release or maybe two, they were all done out of my machines. So I was like

 

Mm-hmm.

 

the bottleneck, the point of failure, single point of failure. So what we were recently doing is we were trying to automate the building part. So we do that with GitHub actions. And so right now, I kind of remembered about this just because like we automated everything, including building OTP itself, exactly because we need to run our own patched OTP. There is just like a very small change that we needed, but we are hoping to upstream, we are hoping it's gonna land. But... But yeah, so speaking about our automation, we are building, yeah, so we are building for Windows, we are building for Mac, on Macs specifically, since I think two years ago, there is the, well, there are two different architectures basically.

 

Hmm.

 

So we have the old, so to speak, Intel Macs, and we have the new Apple Silicon Macs. And... Up to this point, we had two installers, one per architecture. Something kind of cool that we are working on, that we are going to, I mean, it's all done, but we are yet to announce it, is we were able to create what they call universal binary. So it's universal in the sense it contains the code for either architecture. And as a matter of fact, again, because we are building our own OTP, we built like a universal OTP for Max. So it's a distribution of OTP that all

 

That's

 

of the

 

cool.

 

native parts work on both architectures.

 

Did you just leak something? Is that what I just heard? You said you didn't even announce it yet?

 

Hahaha!

 

Yeah, you heard it here first.

 

Woohoo! Ha ha ha ha!

 

Finally, something comes our way. We got some breaking news. I'm going to tweet this to my mom tonight.

 

Yeah.

 

Yeah,

 

Excellent.

 

that sounds really exciting. Is this, I mean, the way you know phrase that it kind of sounds like something which could also be available in general down the road for like, when you install OTP

 

Yeah,

 

in your system.

 

yeah. So right now it's kind of only, right now it's all specific to Livebook just because

 

Mm-hmm.

 

we are the main user and again we use this patched OTP but what I'm hoping is to eventually make these binary builds for Mac available to everyone. So I think, I think what's going to happen is we are going to integrated with the, with hex. So in the hex team, we have like a little project called Bob, like Bob the

 

Mm-hmm.

 

Builder and Bob.

 

I wanted to ask if Bob was involved actually, but I was like, no, don't be stupid. I think it's only for something else.

 

Yeah, so it is and it isn't. Like it's going to be kind of like this in the area of expertise of Bob, so to speak. So

 

Just like,

 

for example.

 

do you want to give people like a 10 second introduction of what Bob does? Because I'm not

 

Yeah,

 

sure

 

right,

 

everybody

 

sure,

 

knows.

 

absolutely. So Bob helps with automating some of the, it does automation for some of the parts of the Elixir Hex ecosystem in the sense that, for example, when there is a new Elixir release, Bob compiles the Elixir on specific OTP versions and makes them available on repo.hex.pm. So a lot of tools are using that repo hex PM as the upstream source, tools like ASDF, but even I think a lot of Docker images, like the official Docker images are, I think pulling from that. Bob also though, so speaking of Docker images, Bob also, okay, this is more than 10 seconds, but if someone was ordering hex, the team manages like the unofficial Docker images. And we have a ton of these because we are very strict about, like we basically try to pin all of the dependencies. So you might have, you can pull from hex Docker registry an image like elixir1 14.0 slash OTP slash 25.0.4 slash. So it's like very. it's very verbose, but like that's by design because it's very important to pin these dependencies. And again,

 

Yeah, I can definitely

 

yeah.

 

say just as like a user experience, like since these images are available, those are my go-to default because it just removes the whole layer of friction about where you like, we need to guess, okay, what kind of OTP version does this now use? What kind of Alpine

 

Right.

 

does this now use or whatever?

 

Yeah.

 

Just this exact thing and it just works. So, already, yay.

 

Yeah, so, right, and then kind of, you know, bringing it back to live book desktop and stuff. Like turns out having very particular versions of dependencies is pretty important. So that's what we are trying to solve with desktop. But yeah, in any case, we are planning to make these Mac builds available to everyone. Oh, and it is very important to mention. So we have, so we build the, on Intel Macs, we just use GitHub. But for the Apple Silicon, we use MacStadium. And MacStadium has a kind of open source program. And they were kind enough to let us in. So thanks to MacStadium for providing us with the Mac in the cloud to build the images.

 

I'm just looking at the website. So basically it's like a cloud hosting service specifically for Macs. Right.

 

Yeah.

 

Like

 

Yeah.

 

the interesting.

 

Yeah.

 

Okay.

 

I'm kind of curious about which platform has been the most painful to work with. I'm guessing it's probably Windows or Mac, probably Mac for some weird reason.

 

It's tough. I think, so for me, I think Windows was tougher just because I have zero experience, like zero recent experience with Windows. So, and then like it was in a way like also tougher because I didn't have a PC. So it was like always in a VM. So it was kind of.

 

Mmm.

 

kind of annoying, but like from the, from the technical side, um, I think it is hard to judge which one was tougher. It's just like, you basically run into different problems in different, in different places.

 

Yeah, they both with their wrinkles and warts,

 

Yeah,

 

I guess,

 

definitely

 

right?

 

both have the wrinkles.

 

Okay, cool. And so we now talked about like, okay, how you can hide to for go to be how you're better off getting the last 20% and now now those things out there and available to everyone, right? So

 

Yeah.

 

what do you feel is like next, next step from here on? Like, what is the thing you would like to do tackle next? And where do you see this going?

 

Sure, so as far as next steps, like we are not quite there yet, but we would like to extract out the app bundle part so that everyone could use it. And in terms of like what the Livebook desktop, so yeah, as I mentioned, we want to make the back. builds available to everyone. This is something that may or may not happen, but frankly, it would be very nice if we could have live book on something like an iPad.

 

Oh yeah, I can imagine.

 

So, I don't know, maybe you heard it here first, but yeah, it would be

 

Now you're just

 

like...

 

playing with me right? I

 

Right?

 

know what you're doing now.

 

Yeah, no. Yeah, we are definitely not announcing it or anything like that. But speaking for myself, I think it would be extremely, extremely cool. And it could just be maybe like the next... I mean, this is like, you know, maybe like super over the top, but like if Livebook desktop is maybe potentially bringing more people to, you know, Livebook or probably to Alixir, maybe something like... Livebook on an iPad, you know, this pretty cheap device that a ton of people have could maybe help with adoption as well.

 

That sounds promising. And like you said, you wouldn't want to extract this app bundle part out of this. Like, I mean, this is for like building the native kind of different post-platform kind of versions, right? But

 

No,

 

the

 

so

 

does

 

it

 

this also

 

yeah

 

contain the desktop app kind of thing, right?

 

Yeah, so specifically a bundler is about just creating the, like the distribution, it's more about the distribution part. So

 

Mm-hmm.

 

again, like creating this package and putting OTP in the right place, putting your application in the right place,

 

Mm-hmm.

 

creating about two of these different configuration files and all, but it's strictly not about the UI. Like with the UI, you would still use something like WX widgets

 

Fair enough.

 

or something else. Like... Yeah, so that's something that we would, that we are also exploring how to make a bundler maybe. Like it is not very connected. Like technically speaking, it's kind of agnostic, but it is like the WX widgets is like the only real use case at the moment to use it. So kind of exploring how maybe it will look like with using not WX widgets. about having a bundler. Me personally, I haven't looked into it at all, but there is the scenic library about building OpenGL basically and stuff. Like

 

Hmm.

 

I would be like personally, I would be, I'm keen on seeing if maybe, we could bundle up a scenic app with bundler. That would kind of cool maybe.

 

Pretty cool, pretty cool. Definitely something I think a lot of people are gonna keep their eyes open for. And it kind of leads me to my next question, because I mean, you have Livebook Desktop, we have Elixir Desktop, which I mean, a lot of what you just thought about is like kind of standing on the shoulder of giants, right?

 

Mm-hmm.

 

But is now the era of Elixir Desktop apps? Is that the next thing,

 

Oh, yeah.

 

right?

 

Yeah, I would say that, yeah, so that's a very tough question because people may, like with the desktop. So, yeah. I would say this, that it is definitely something that is not easy yet to build the desktop apps in Elixir. And I think to build like really like native desktop apps, it is probably going to be very not easy for a very long time and maybe forever. And I specifically mentioned building the apps in terms of like using all of the... GUI elements, like, you know, building like all

 

Hmm?

 

of the buttons, windows, and stuff like that. That stuff is hard because, so for example, with the double X widgets, it's like, it is hard because all of these GUI, because all of these GUI frameworks tend to be, well, they tend to be written in something like C++, and they tend to, you know, use like object-oriented programming and sometimes like some of the kind of, a lot of like the details about the paradigm kind of leaks. So like maybe you can only implement certain functions, certain things by subclassing. And like we cannot really emulate that very well. So there is that, there is that

 

Mm-hmm.

 

friction. On the other hand, I am very, like on the other hand, I am very helpful about the approach that they have with the live view native that the Docker just announced with. on the ElixirConf, which is kind of, which is building the native parts, like in the native language, but then kind of having some kind of communication. I think this is a pretty good idea. But yeah, kind of Elixir on the desktop. I would say writing, you know, like all of the controls, Windows and stuff like that using native APIs is probably a bad idea at the moment because it's going to be really hard to hit that. that final 20%, unless you're using something like LiveView Native, then I wouldn't do it. With LiveView Native, I have much, much better hopes. But then on the other hand, the thing that ElixirDescope does, which is kind of, it's just like, it's just a little wrapper, it's just like a WebView window, and then you do the UI inside, you do the UI with Phoenix, you know, with Phoenix LiveView or something like that, that's... that is very much more appealing.

 

Yeah, I guess we just have to wait and see what happens. Right. I mean, it's, I've just was under the impression that a lot of work has not been going into like also bringing some of the ecosystem onto like a desktop kind of app, so wanted to hear your thoughts.

 

Yeah, I wouldn't say that we are done, not

 

No, no, no, no.

 

by a long shot, but I think we are in a much better place than we were a couple of years ago. And I think, for me personally, that's definitely an area of interest to basically have this much better story of Elixir in the Descope. space.

 

Hmm. Hmm. I think that life in the 80s, as far as I know, they're basically reviving Lumen for this, right? Like where they take this thing,

 

I don't

 

which

 

think

 

is

 

so.

 

kind of compiling to WSM. And then, but yeah, details.

 

Yeah, I might be wrong, but I don't think that's it. I think this is more like they implement the native controls in, so they just started with Viva. So they implemented all of the controls in Swift, but then they have a way to communicate. So like all of the GUI is done with Swift, but then like the server is actually in control. And so there

 

Oh, okay.

 

is a communication between the client

 

Interesting.

 

and the server.

 

Okay. Okay. I haven't really dug too deep into that. So maybe some people who are listening to this right now are like, no, it's all wrong, but...

 

Yeah, I guess I was just that person. Sorry about that. But no, I cannot emphasize this enough. I think this is a very good approach because then like, because then they can focus on the Swift code and kind of like make that, or rather it's more maybe a little bit about more about control. And they, with LiveView Native, they do give you some control. So the difference maybe with WX widgets is that with LiveView, you kind of like start a next code project and you actually have like Swift code and then you kind of call into LiveView Native, but you can also write your own Swift code. And this is very appealing to me. I mean,

 

Okay.

 

like, you know, maybe it's a little bit of a Stockholm syndrome here, but. But being able to write native code as part of your project is very cool because if you hit bugs, you have a much better chance to fix them or if as opposed to again, forking OTP or something. Yeah. So I'm pretty hopeful about this. So I'm pretty hopeful

 

pretty exciting, yeah. Okay, do you have anything you would like to add to what we already talked about Wojtek or Alan, any questions you would like to ask? Otherwise I would slowly transition this to PIX since we're nearing

 

No,

 

the one hour mark.

 

I did record a separate podcast with Brian Cartarella. I think it's how you say his last name about Live View Native. I

 

Oh

 

don't

 

nice.

 

know if I should just self pick my thing, but he talks some more about how it all works. And there's our example project online you can take a look at. They're already working on Jetpack Compose for Android. I did ask him if he'd be interested in having a Flutter version and he very much did not like that idea. He thinks native is all the way to go. And that's fine. I understand his style, but it is kind of cool. You write this kind of very much XML, HTML inspired kind of language for each platform. So I think kind of like the bad part is like you have to really make it towards the UI for like the native platform. But at the same time, that's kind of usually a better experience, right? It should be. But it's weird because you're not writing Swift code, you're writing like HTML with different kind of tags, something like that if you've seen it before. So it's a little bit weird.

 

Yeah, if I may jump in, I think this is, yeah, it is a little bit weird, but it is like, so you write Higgs templates basically that are not really HTML, it's like this, yeah, like a description of what's on the screen, but it is pretty interesting where like the industry seems to go, right? Like with SwiftUI, you have this declarative thing, and then with Jetpack Compose, you have this declarative thing as well. So I mean, might as well.

 

Yeah, and no way am I saying it's a bad thing. It's just like, it's a little

 

Yeah,

 

bit weird, right? That's

 

it is

 

really the big

 

weird.

 

thing.

 

Yeah, but just one comment. So what Brian said, like, like, go native. I can, I approve of that message. I think.

 

So don't go WX widgets, go native, right?

 

Yeah, I think so because, or let go of WX widgets, but have a way to fix bugs or missing features yourself as part of your app, because otherwise it is very painful to maintain like the whole build process. Because again, right, like part of the OTP. So if you need to fix something in WX widgets, you need to build that WX widgets, build OTP with that WX widgets. and then build your app with that OTPs. Yeah, so.

 

I guess that it's exactly the opposite of what you said at the very beginning, right? The out-of-box experience is not

 

Right,

 

great. Hahaha!

 

yeah, it's not, yeah.

 

I'm kind of curious about the OTP team. Are they pretty okay with like upstreaming the changes? Because I've heard good and bad things about working with the OTP team, like they have their own style and stuff. And but I mean, obviously you got to continue to patch up for whatever reason. So I can't imagine that the experience must be too bad.

 

Oh, no, I think all of my interactions with OTP were fantastic, basically. In this particular case of the WX widgets, I think it's probably pretty low priority for them. Like they, you know, I'm pretty sure the WX widgets in Erlang exist because they want to use it in Observer and in the debugger. But other than that... like besides these use cases, I don't think it's, it's a lot of priority. So yeah, I would say that.

 

So between supervisor bug, PR, and upstreaming your changes, they just kind of,

 

To jest bardzo rozumieszczająco.

 

nobody really uses WX widget. Yeah, but still exciting though. I'm curious to see if ErlangSci does anything too. I mean, I don't know if they actually work on anything that Elixir kind of spearheads besides the documentation. That was pretty huge, I think.

 

I'm not sure either. But what I do know though is that there's a lot of conversations, a lot of collaboration between the teams. It's really cool, I think. People can just ask questions to the OTP team. It's a possibility. Especially with the... So the Erlang ecosystem foundation has a bunch of different working groups. There is one about built and packaging. And so for example, there was John from the team available on many meetings kind of helping out with the rebar team as well. Yeah, I think there is a nice collaboration between different teams for sure.

 

But the one thing I think is a little bit funny, though, is it reminds me of the old joke we used to npm install bower to manage your front end thing. We do do that a little bit with mix, right? We have to mix local rebar in order to compile our Erlang code, which is a little bit kind of weird, right?

 

It is, right? But again, like this out of the box experience, like if it was up to me, I think rebar should be part of OTP. And if it would be part of OTP, then we wouldn't have to local rebar install it. It would just

 

But then

 

be.

 

everybody would be wondering, why do I have rebar and rebar 3, but where the heck is rebar

 

O, tak, Rebar.

 

2? I'm a little out of the story,

 

Hahaha!

 

but

 

Tak, tak, tak.

 

people who don't know, it's like...

 

Jeśli to będzie zupełnie do mnie, to Rebar 3 powinien być znamieniem Rebar. A potem, już zapomniany Rebar. Ale myślę, że to tylko działa na OTP 17, może, czy coś takiego. W tym momencie nikt powinien to używać. doesn't get

 

I do

 

security

 

have

 

patches.

 

one last question. Why is it that they always do mixlocal.hex? I never really looked into it. I'm just kind of curious since you're here and talking about this stuff.

 

Why do we have to do mix local hacks?

 

Yeah, exactly. Before we talk to Hex, is it because there's like some API changes or something that may happen?

 

No, so hex is not part of Elixir, so you need to install it, which you can do with MixedLocalHex. So Elixir does ship with a very tiny shim. I mean, it's not really a shim. It's just like a little bit of integration that like, we know that you're going to install hex dependencies, but if you don't have the hex installed, then it will tell you that you need to MixedLocalHex to install it. But what MixedLocalHex does, it just downloads the... hex archive. And so, yeah, so in this particular case, right, like, I don't know, one could ask, maybe hex should be part of elixir. Maybe it should, maybe it shouldn't. I think it's good that it's not part of the elixir because we can have a different release schedule and stuff. And it is kind of orthogonal as well. Like,

 

And after that makes

 

yeah.

 

sense. Yeah. But I think, I mean, like, yeah, we just talked about the expense, like local rebar, local hacks. At the end of the day, when you run this stuff locally, like, I mean, the mix even asks you, Hey, seems like this is an early dependency, right? You need to install rebar for that. What should go ahead? So yeah, it could be better. I guess maybe you should have begun with OTP or not, but at the end of the day, again, out of a box experience, I have to press. why once.

 

Yeah, right, it's

 

So

 

not,

 

whatever.

 

yeah.

 

I think it's already, it's already like light years better than some of the other platforms where they could get

 

Yeah,

 

cryptic

 

and

 

build messages.

 

yeah, actually, I think that I don't know if there were any like conversations about this, but I don't see a reason why like when you, I don't know, when you maybe mix get depth get for the first time and you don't have log, you don't have rebar or you don't have hex, I don't see a reason why we maybe by default we should just install it for you if you, maybe it should just be installed like it's kind of like through separate projects and stuff, but we just remove this friction. Because like, I mean, like if you already have a project, you don't have, you clone a project, you devscat, you are not going to say no to installing hacks. So,

 

Mm, mm.

 

if you always say yes, then maybe you shouldn't even have to choose, but

 

That's

 

I don't

 

the

 

know.

 

thing I never really understood. Like when I go to like a government thing and I have to pay for something, they like to say, okay, with you. And I always ask them, do I have a choice? And they say, no.

 

Yeah,

 

So

 

right.

 

why do you even ask me? Just take my money and it make me feel bad. Why do you have to ask me? Like I willingly want to do this.

 

Okay peeps, I think this is where we cut it off.

 

Josie's gonna be not happy with you and me, I think, after this.

 

Hehehehehehe

 

Oh, you know why we did this stuff.

 

Okay. So yeah, let us transition to pics. Oh wait, one last thing. If people want to reach out and get in touch with you, right? How can they do that?

 

Sure, you can find me at Twitter. This is at Wojtek Mach. It's the same on GitHub or Elixir. Yeah, I think Twitter is probably the best way to reach out.

 

Great. OK, now, picks. Alan, I guess I'm going to start off with you. And feel free to pick this one episode you just like this recording I talked about earlier, because I think it's relevant.

 

Yeah. Which episode was that? Oh, that one. Oh, but it's not out yet. Yeah, I could pick that one. So I'm gonna do two picks, right? One is that episode. So I have a podcast called flying high with flutter all about flutter. When I saw this thing released, I thought it would be really, really cool to to kind of show because I like to bring other technologies on to see what's the difference, right? Which one could be better, etc. But I did have another one with something called Tari. Have you guys heard this one before? T-A-U-R-I.

 

Nope.

 

Yeah, yeah, yeah. And when I saw this, I was thinking that it's very similar. And I'm sure you guys must be able to learn things from each other or whatever. So I think it's a pretty cool, like, it's very similar where you use a web technology to do your app, but they do all their stuff with Rust. So I think it's a pretty cool thing to also take a look at. So that's kind of my two picks then.

 

Nice. I have to be honest, I don't really have a pick this week. So I'm just gonna hand it over to you, Wojtek. Do you have any picks for our listeners?

 

I have two picks. The first is a talk from the Alexiurcon 2022. It's a talk called Time Algebra by Kip Cole. And I just wanted to say it was, I had a great time watching this talk. Kip is fantastic. So he's maintaining the Alexiur's CLDR. and a bunch of other libraries. I actually used to work in that domain, like around time and scheduling and stuff like that. So I think the, yeah, that was super interesting to me. And he did a fantastic job. Like it was very entertaining as well. So yeah. Go watch the, I don't think the videos are out yet, but when they are, should definitely check. Time Algebra by Kip Cole. And my second pick is, so this is kind of random, but I really like this. It's a kind of a little bit like science fiction novel, or it's a two part novel. So it's Demon and Freedom by Daniel Suarez. I mean, somewhat old, I think it's 2000. 2005 or 2006, the first novel came out. So I only picked this because I really like this book. It's kind of like my comfort read. I read it a bunch of times and I like to kind of go back and just read it again. It's kind of interesting, especially nowadays, like in the last couple of years, with like the whole AR, VR, multiverse and stuff like that, the book touches. touches on those subjects, AI obviously as well. So I don't know, cannot talk. When you asked me to have some picks, I immediately thought about this book.

 

Interesting. I always like fiction books are always something which which I like to put on my reading list because

 

Yeah,

 

Really

 

it's

 

good

 

as...

 

fiction books which catch your attention Are

 

Tak, tak, więc dla mnie, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był, co był

 

rare for me nice and I'm pretty sure I'm gonna check that one out so yeah thank you for being on the show Wojtek, it was a pleasure!

 

Thank you. Thank you so much for having me on.

 

And then I hope you all enjoyed it and tune in next time when we have another episode of Elixir Mix. Bye bye!