I guess as as you are helping and mentoring companies, are there popular tools and libraries that you prefer to use in your daily development environment? Yes. Of course, I mean, Phoenix and Ecto are definitely

pretty much the bread and butter for out there on the web. If I would give one shout out, then it could be O1 library. O1 is incredibly versatile and underused library. I mean, people do use O1 a lot, but there are so many scenarios where it can be a good fit, you know, so having this persistent job queue, which is in the same place as the rest of your data, right? So in the same database. So you can make a lot of this stuff very consistent and transactional. Like a typical example is you want to send an email, say as a part of the registration process, right? So if you write something into the database and then send an email, you have like a distributed transaction. You have two different systems interacting. So maybe you save to the database, but you fail to send an email and so this kind of fail. store the record to the database, right? But with Oban, you know, you make it transactional because you basically you store the record and you store the job record is a part of the same transaction. So it's either all or nothing. And then the job is going to be executing with like retries and whatnot. You could still fail, of course, but the chances are much slimmery because you're going to survive. Like even if the whole system is restarted and whatnot, you'll still be able to run that job. And so it makes it so much easier and so much more consistent. I had recently a case with clients where they needed... they had the limited set of resources, like GPUs, you know, and so you have customers or end users in queueing for that GPU, so they needed a queue that had some amount of concurrency. And they were thinking about doing a bit of Redis, a combination of Redis and PostgresQL. And then like when we started discussing this and thinking about it, we figured like, okay, we can do everything in Postgres and actually Oban implements already the queue in Postgres. So we did Oban. So basically, it lifted a lot of the implementation from us. And so like at first, look, you wouldn't think that this is even something which is required for it, which suits the job library, but it actually does. So Oban is really one library, I would like to single out and I have... Yeah, I agree with that. It's a very good tool to keep in your tool belt. versatile. Yeah, a lot of stuff that you need to do, like interact with other services and whatnot. Almost always, open is going to be the way because you should always ask yourself like if I'm interacting with a remote service, what happens if the server is rebooted at that point? Right? So am I going to pick this up later on or not? You know, frequently you need to enqueue an open job to, to get those retries to get persistent jobs. Yeah. Another the second one I want to name is rec req by boy tech. So this is a relatively new stuff built on top of finch, which is I think becoming the fact of HTTP client library. These days, it's the one that I would definitely recommend. And I think it's going to be like the end game, you know, of HTTP clients. So our EQ, definitely take a look at it. It's extremely well designed, has support for tests for mocks, right? And has support for like, different higher level features, such as, you know, decoding different kinds of payloads. And whatnot has this plug style of dealing with requests and responses. And so really nice library. Totally. Nice.

I'm, I'm glad I learned this. I just pulled it up on GitHub. Yeah, yeah. RQ. Yeah, awesome. Thank you for that one. It is now starred and I will be checking that one out later. Let me know how you find it. Yeah, I will for sure. Any any other ones? Oh, well, I'm

sure there are many others. So nothing comes to mind at this point. Okay. I'll probably remember like when the show is over. Of course, that's how it always works. Yeah, but the ecosystem is, you know, in general I think the ecosystem is nice. It's not too big, but it's okay. I usually find what I need. One thing that I would also like to mention is somewhat related to this topic is the article by Wojtek also it was a dash bit. I'm gonna have to look it up for the link. And it was about, you know, SDKs. So what he argues is basically that like for SDKs when you want to interact with this remote service, like I don't know, Stripe, I think he has a Stripe example. And I was just doing yesterday something with New Relic. Like instead of pulling the full library that does that, like you could actually use his Req and just make like a simple HTTP request, you know, and because you typically don't need like all of these features that the full API client or the full SDK supports, and then you're not going to have to bring in a lot of these modules that you typically do. Like, for example, Google APIs, they're notorious. Google libraries for Elixir, they bring such huge amount of modules that your startup time actually can suffer at production. You know, so that's a nice example of how you could, yeah. There's a blog, where should I post it? I'm gonna post it right on the chat link.

Yeah, it might not let you do the link. Are you talking about the SDKs with Rec, the Stripe one? June 25th, I'll post that. I think it lets me do links. Okay. And I'll also, I'll add that to the description. I think that's one of my favorite things to stain in the elixir ecosystem is you, we don't have thousands and thousands of dependencies when we start a project.

manageable and reasonable and you start with those stock things and you don't really need a lot in my experience other than like these more general purpose one like open for example, our yeah,

I agree. I like that a lot. When you start looking ahead, like maybe let's see, it's about to hit your 10 year reunion from your book, right? Yeah. 10 years from now, where do you a lixer? What what do you think will be happening? How popular do you think it will be? Where do you think it'll be? Oh, this is a wow.

This is the tough question to answer, right? Well, I definitely hope that it's going to be at least as popular as it is, relatively speaking to the growth of the communities or developers in general. It's kind of hard to say where development is going to be 10 years. That's a good question, really. Honestly,

right now, it's hard to see where it'll be in like five years or less, honestly, right?

So things have changed, like, I feel like they have changed radically or dramatically in the past few years. So that's, that's a, that's a good question. But what I hope to see is still like this spirit of, you know, friendship and human oriented focus. That's the first very first thing that I would like to see within the community itself and with the language. The language is, I don't know, I mean, Jose always pulls up something new. So we always get family features in the language. Now, I mean, the types, the types are obviously the most the biggest one. And so that's probably going to take them like, from what I understand, a few years until it's full of lands, if it ever lands. Otherwise, I'm going to be curious to see how the whole NX, you know, direction, the whole machine learning stuff develops. This is very interesting area that the Master Meet I haven't been following so much.

I am really bad at following it and I've had Thomas Malar on and then I just had Sean Moriarty on. And those are some smart guys in the machine learning space. That's for sure. And yeah, I

think it's my head. But I'm trying. I feel this is kind like the nerves. This is sort of a completely separate space in a sense. But this is good, right? Because I never thought like 10 years ago, we didn't have nerves for we didn't have an X, you know, and it never occurred to me that you could like even use Elixir for some of that stuff, you know, like for embedded programming or for like this. It's really cool seeing

it be used with embedded programming and the IoT world.

I definitely hope it's going to bring more of the people to our community. It

seems like Elixir is a pretty good place for machine learning and like being able to leverage all the processes and just the overall concurrency to run difficult algorithms and things. But yeah, over my head, I'm trying to read Sean's machine learning book right now, but it's hard to find enough time to really get consumed in it, but it's really cool stuff. I feel like you don't want to ignore because I feel like as a developer you'll be left behind a little bit.

But it's hard to say that like so many things to learn but yeah I definitely also have it on my to -do list to check it out. Yeah and then is there gonna be a book someday? Machine learning? Well I don't know about that. I think there's more qualified people to write about that than me, you know. I would like to write some book, you know, another book someday, but yeah, currently no plans about it. Okay. We'll

change that. What have been your favorite projects or contributions to the

Elixir community? Well that kind of is similar to libraries, right? So I would definitely, another thing that I could maybe single out could be Livebook, right? So Livebook is very interesting? interesting project in that it helps you know people explore Elixir or even present, you know, elixir in a more interactive fashion. So this is something that while I haven't been using it myself It's also on my to -do list But it like I've seen some presentations were like Jose had a presentation I think, recently, where he basically just made it all with Livebook, you know, so he was like, showing off some demos and then writing some code inside there, interacting with this and so that's a very nice and interesting project.

Livebook looks awesome. I'm on the same page as you though. I keep telling everyone I'm gonna learn it and I haven't yet. Especially with education, it looks like a really good way to learn how to write code and you can, you know, compile and run it right there in UI

friendly Livebook. Another thing I could mention is maybe the unsung hero, the xdoc. So xdoc is really terrific. And it has been like since day one, you know. They of course constantly make some addition changes to the experience. But it's always great, very snappyappy from what I've seen recently now Erlang Documentation is using it as well Seems to be powered by xdoc too And I mean the whole focus on documentation on writing having good documentation And searchable documentation usable rights. This has been my in my impression This is been like a big focus since day one. Yeah.

I X doc, I'm glad you brought that up because it's probably one of my favorite things in elixir and then just with like, um, writing unit tests and things where you can just include your doc examples. I think that is like one of the most powerful things we have at our, like you don't, you your example once, it works as documentation and a test. It's

quite amazing. Exactly. How you can cross -link between different modules or you link to a module from another library and it just works on a hex talk. This is really nice stuff, which we kind of take for granted, just like the hex package manager as well. But it's really important for the whole general experience with the language.

I know you kind of have a tight schedule, so if we were to close this off, do you have any advice for developers that are hesitant or thinking about

getting into Elixir but they haven't pulled the trigger yet? Well, you should give it a try, right? So like I'm not affiliated with Elixir. Yeah, I wrote a book, you know, but I didn't really make a lot of money out of it. So I'm not, I'm not trying to sell you Elixir for some personal I'm basically just a happy user of Elixir. I've never realized that I needed this stuff that I get from that language until I tried it. So give it a try and keep an open mind and see how it goes. What I typically recommend for new people as a book author is not to read a book first. Of course, different people have different preferences, but I think for it's going to be better if you just, you know, try it hands on, right? And so, Elixir has a really good getting started guide, which is kind of like in a tutorial form, you build a simple, small key value in memory, and you kind of follow that guide. You're not going to really know how to write a lecture after that, but you're going to get a bit of a teaser of how it works. And then the same thing with Phoenix. So the official Phoenix documentation has a tutorial. I forgot what it was about, but they basically go through all the major parts of the Phoenix architecture. And so you kind of get your feet wet, right? And so you kind of experience in practice. And then maybe you can consider reading a book or doing some video course or whatever works for you. I would say pretty much unless you're serious, full serious, maybe not so much need to read some extensive resource, you know, but more like experimentally with it. I

yeah I agree and the getting started guides are really good. I think it's a good place to start and it's funny I just started well, I didn't just start but I've been doing live streams where I've just been reading through the getting started guide and it's been Awesome. It's been very popular people. Come on watch me read documentation and go through examples. And super interactive. It's been a lot of fun.

Exactly. Yeah. So also, you can try exorcism. I think it still works. Right. So exorcism, as far as I know, I used to do use that all the time. That's nice. Because you get a little just

what do you kind of like not code, what's the word? Just a little problem. Yeah, you got like exercises and then people

are mentoring you, I used to do it myself, the advent of codes. So like it helped me improve my functional style a lot. And in general, I think if you want to give any language you try, you know, maybe try to do some exercises of, of advent of code with, with the language, you know, and try to see how that works for you. Because those are like more like smaller examples. Typically for Advent of Code, you're not going to need concurrency, you're just going to have to make it functional. And this is a nice part of the challenge, you know, how can I do this without introducing other processes or add stables and whatnot, and still make it work reasonably fast. So yeah, maybe also give that a try. But yeah, my advice is always, you know, at least that's how I am, you know, try things practically first, at least a little bit and then, you know, move on to a more in -depth resource.

advice on learning, elixir, start a project to learn it too, because then your hands on, and then you have specific things you have to learn to figure out, and then you go and find your solutions. And it's the best way to learn. And at least you're building something at the same time.

Yes, yes, precisely. It's much better than just, you know, reading, reading

a book and like, okay, what am I gonna do now? You know? Yeah, exactly. Well, this has been awesome. Thank you so much for joining me, Sasha. And I'm sure everyone that's tuned in is super appreciative. And you're a huge staple in the elixir world. So thank you for being part of it. Thank you for coming on my little podcast. I appreciate it. And thank you so much.

Okay, thank you so much. It was a lot of fun. And you know, wish a lot of luck with future edition. And I'm sure everyone that's tuned in is super appreciative. And you're a huge staple in the elixir world. So thank you for being part of it. Thank you for coming on my and yeah, maybe we'll see each other again someplace.

Yeah, absolutely. All right. Well, thank you everyone. Have a good weekend.