EW S8E1
Transcript

SEASON 8 EPISODE 1

[EPISODE]

[00:00:07] SM: Welcome to Elixir Wizards, a podcast brought to you by SmartLogic, a custom web and mobile development shop based in Baltimore. My name is Sundi Myint, and I'll be your host. I'm joined by my co-host, Owen Bickford. Hey, Owen.

[00:00:17] OB: Hey, Sundi.

[00:00:18] SM: And my producer, Bonnie Lander. Our theme this season is the Elixir in a Polyglot Environment, where we talk about how Elixir works in other languages. Today, we are joined by super special guest, Miguel Cobá from Shore. Hey, Miguel. Thank you for being here today.

[00:00:33] MC: Hello. Thank you very much for having me.

[00:00:35] SM: We're so excited to kick off the season. We've been talking about this a lot, just in the Elixir community over the last few months about how, yes, we do a love Elixir, but how do we reach out to other communities and talk about how much we love Elixir? We realized, we've got to talk to people from other communities, too. Can you tell us about what, I guess, a polyglot environment actually means to you and how you might use Elixir with other languages?

[00:01:01] MC: Yeah. I think it is a very common thing. Right now, it is very hard to find a place where you only use one technology, because there are strengths in different technologies and companies, or startups, or any business that will try to leverage those strengths for the benefit of the company. In this case of technology and programing languages, there are a lot of languages that are very powerful for a specific application.

It's very common when you join a company to find a mixture of all these technologies. New maybe, and with some rough edges technologies. But everything, it makes it interesting. I think that is something that we would find more every day.

[00:01:45] OB: Before we started, you mentioned working a little bit in Ruby lately. You're really doing polyglot, if you're Ruby, Elixir, what other languages are you working in?

[00:01:56] MC: Yeah. I have worked in a lot of things that I like, and mainly that I don't like and I don't work anymore on those. The things I work in the previous job right now is more with a functional programing languages. Because I like this style of programing, this way of thinking about problems. Now that I have to use probably in programing languages, I feel even more before anything in paradigms, because it's very hard for me to now think about mutating objects, or a state and things like that.

It is different. In the previous job I was in front-end programing with Elm. It's a very known programming language, but it is a full functional programming language, the heritage of Pascal. The beginning is a little hard to understand. Once you get it, it is very cool. It makes you think about solving problems in a very different way that you are used to. Now I am working on the backend, doing a APIs and server stuff. It is very different. It is a slower pace, because there are no – the changes are not so fast, as in the front end. That was one of the reasons I wanted to switch, because it was super, super fast and I was, okay, let's hold on a little. Now, move to the backend.

Many years ago, I used Ruby. From Ruby, I jumped to Elixir. I love Elixir. The way that they combined several paradigms from meta programing and functional programing, I don’t know, pattern matching and things like that. That mixture is very special, very unique and allows you to express very, I would say, elegant solutions to problems. I like that a lot. Yeah, there is a lot of Ruby. Also, when I have to build things in Ruby, I like it because it is a funny language to work with. It is funny to work with Ruby. It is also sometimes like, “Why is this happening? Where did those come from? Which part of the code does these define?” Those times are not so easy, but the language is very, very funny.

[00:04:16] SM: I have heard a lot of descriptions, but not funny. Can you describe why it's funny?

[00:04:22] MC: I mean, you can read it, and it is like reading a letter sometimes. Because of all the domain specific language that created with Ruby, you can read it and say, “Okay, return if this. Or, do this, unless this other thing.” Maybe you can read it that. It’s not so hard in structure. I don't know, a square. That same flexibility is also a problem when you get to a new project, and you don't know which libraries they are using. Those libraries are injecting a lot of magic to the code. You see the context and say, “Okay. I read it. I know. Oh, I understand what this is doing, but I don't know why it is doing it.” Let me say, for people like me that like to know where this is defined, or where this is done is like, why this is happening. 

It is interesting. This switching between languages, as they are very different vision they have of programing languages is very different. This switching between them, it is sometimes a little hard, because you cannot switch in, for example, for me in the same day, I cannot switch from one language to other. Maybe for the next day, okay. In the same days, you're switching, okay, I'm going to do one hour of Elixir and then 2 hours of Ruby. It is hard, because it is, okay, let's switch something here. It’s a little hard. It’s nice.

[00:05:55] OB: Yeah. You can get into a similar situation with – I ran into this recently with a library that might have lean a little bit too heavily on macros, where even an Elixir. You can add a bunch of magic with those macros and then it makes it hard to find out why things are happening and how they're happening the way they are. Yeah, I have seen a little bit more of that in other languages than with Elixir.

[00:06:21] SM: Maybe we jumped real hard, real fast into all the different languages that you're learning. Can you quickly give us a background on where you started programing, how you got into programing, but also, maybe specifically, what was your first language? What was the first language that you learned how to program with?

[00:06:37] MC: Yeah. My first language was HTML, reading it from a Nintendo magazine, Club Nintendo Magazine that they had every month, one section about the HTML. I just read the pages, the text trying to understand, “Okay, I like it.” Then in high school, I come from a small town in the south of Mexico City that the high school didn't have a computer, or a room, or lab.

We had very old computers. When I arrived there, for me was, “Wow, I have to know how to work with those.” I started looking for information about it. Suddenly, there were not so much information. I found one book about Basic, and I started reading it, because I have a computer at home. Only the one in the high school. I can only use it once, or two days a week when I have the classes. All the week, I used to write code in a sheet. Then when I arrive at the school, I copied it and tried to make it work. That was my first language, my real language that I typed in a computer, Basic. Basic is very –

[00:07:46] OB: Are you saying you handwrote Basic code on a piece of paper and went to school and typed it in.

[00:07:52] MC: Yeah, exactly. Exactly. 

[00:07:54] OB: Nice. Did it run? Was it perfect when you typed it in?

[00:07:58] MC: Yeah. Yeah. There were not so many computers in that town. Computers were very expensive at that time. Now, it is very easy to get computers in a library, or in your phone. Even a cheap phone is very powered with computers. At the time, it was not easy. This town where I grew up, it was even crowded. You have to use any opportunity that you have in front of you. For me, was that. Yeah, I learned reading books.

[00:08:28] SM: That's so fun. I always talk about how ridiculous I think it is that I had to take my tests and computer science classes on physical paper, with pencils and stuff. I guess, some people do – have to do it on necessity. I hope, you win awards for that. I commend you for that effort there. I guess, so if that was your first experience with it, then when did you think of it as more of a career path? I guess, I feel like when you're learning how to program, you start learning more languages. That's the idea here is that in a polyglot environment, you start learning more languages and then that helps you become a better programmer.

The circumstances in which that happens can really shape how that direction goes. When you were learning multiple languages, were you just learning? Were you in school? Were you at a job? Where were you when that happened?

[00:09:20] MC: Yeah, I decided to follow this career when I had to pick one of the offers that the university. At that time, I like computers. I said, "Okay, I'm going to study a computer engineering, and that's it." In the university, I don't really learned to program, because it was not the focus of the career, computer engineering. I learned when I started working. Middle of the university courses, I started working. There is where I started learning a lot of things by doing. I started learning C, by programing a smart card reader, or something like that. Just with people that trust in you and give you the opportunity to break things.

That was an opportunity for me, because I could break things and learn migrating. I learned when I started working. From that, I started learning about all the different things that existed, and I didn't even know that that existed, because there were not much information about it at that time. Now, I think it is very good. The offers of people that is starting up this field right now, it's huge. It's amazing. You have courses. You have bootcamps, and you have free courses, and you have YouTube. You have books, printed books, or even friends. I don't know. Maybe in the library, you can go on and learn it.

At that time, it was very hard. Now, it's also very hard in another aspect, because anyone can learn. You have more competition to learn, to get a job, to find your place. I think, they have different challenges, people that is learning now, that the challenge that I have, for example. At least, they offer a big help to learn. It is amazing. I try to contribute a little to that by writing. Because for me, it was hard to find this, or to find someone that explained things to me, because there were not many people that knew about this thing like now. I like to learn, to learn and to explain it. That's why I write a blog, a post, or books, or whatever, because I like to explain at the same time that I am learning something new.

[00:11:39] SM: Yeah. To give context to all of our listeners, Miguel, I think we first saw you on in the Twittersphere when you were talking about your book, 100 Elixir Tips. Just to jump around here, you said you like writing, you like to give back by writing. How did you get the idea for A 100 Elixir Tips?

[00:11:58] MC: Yeah. It is a project that has occurred to me. One day, I was on Twitter and I started to be more active on Twitter. I also wanted to do more things in Elixir. I started writing more blog posts about different things in Elixir. Then I started to make the habit of writing every day something in Twitter, to be more active. I say, what can I do that is not very hard to do, that I can do constantly and doesn't take a lot of time? I started writing these tips in it, and I started writing one every day. When I write to the number 50, or 40, something, okay, maybe I can compile this in a book, put it in a PDF and just make it available for someone.

Many people started liking it, because previously to this, I wrote another book about deploying Elixir. I write for me mainly, because it is a reference for future me, because I am very bad at memorizing things and remembering things. I need to write it as a reference for me, when I need it again. That's why I write articles.

Then, I started with the topic of deploying, and I wrote a book about it, and compiling the articles that I put on the Internet. It was very well received. I say, okay, maybe I can create another one, because I have already done most of the job publishing every day in Twitter. I collected all the things that I publish on Twitter and put it on a PDF, and that's it. That's why I created it.

[00:13:32] OB: Are there a couple of stand-out tips, either tips that you always go back to, or tips that you think people just need to hear about?

[00:13:40] MC: Not a specific pick. What I like about those tips is that they show how – I don’t know how to say, but how easy it is to write and read Elixir. You can write with the functional paradigm very beautiful things. You can express solution to things using these paradigms. Elixir is very comprehensive and you can write in a few lines very interesting things, like when you are mapping one list of things into another, and you can transform one thing in another. It is very easy to do it. You can see the cascades in Elixir. It looks like a drop of water that is falling, pom, pom, pom, pom. At the end, you have a completely another thing.

Those tips are small snapshots of the things you can do. It’s not a full program, because obviously, a full program is completely different. You have to take care about more things, like maybe sign, but practices that you're seeing many other things. This is just to focus on the language and see, okay, look, this is like a small snapshot, a small light that shines for a second and then you forget it. That’s it. It’s just funny.

[00:14:56] OB: Right. I was curious, because I saw that you also had a book about — it was kind of meta. It was teaching developers how to write. Was that about writing books, or about how to write tips, or –

[00:15:08] MC: It is about writing books, but aimed to developers. We as developers are very – we are backed, because I don't know. I think a normal person goes up in a Google document, or a word document and start writing, and that's it. For us, is or cabled. Maybe something happen to my computer, I need to have a backup, or maybe I want to go back to three versions before. We never do that, but we have to do it. I have to put it in a version control system. I'm going to put it to GitHub. You try that. We are that way. We have to put it in a directory, with a certain structure and one folder for the image, one folder the text, and then and maybe make file to process and transform the images and optimize them and then keep everything on their source control.

I wrote this guide, because that's the way I wrote the books. It is the way I write programs and it is the way that I write books. I keep it in a version control system. I have so many scripts to transform the data and to generate the final product in this case, that the air for the people file. I wrote this guide, and this was a project that I get inspiration for with a course that Gumroad published then. It was called 14 Days Challenge, where they challenge you to publish, put something through sale using their infrastructure in Gumroad. I followed that course and this was my project to sell something.  That was what I did, a guide about how to write books if you are a developer. It was my first book.

[00:17:00] SM: That's so fun. I think I saw something about that. I know some people who are trying to publish for themselves will go through Gumroad. I think, I've seen that course before. It's really cool that you took that and you're talking about that now. I'm also really curious, is all of this separate from stuff you're doing at work? This is all just stuff you're doing on your own time, yeah?

[00:17:20] MC: Yeah, exactly. I had my day job and at night, I write. I learn things, the things that I find interesting, I write about them, in maybe a short article. Then when I start learning, I see that there are even more than what I learn initially. Okay, maybe I should write a second article, or a third article, then that initial blog post, now it is a series of blog post. For example, for their deployment in Elixir, I just wanted to do a guide to deploy using Elixir. Then, I end up with eight articles, one for [inaudible], one for render, one for Elixir, one for Heroku and a lot of things. That's how it started and how it ended. Sometimes you cannot stop and you just keep going and see what happens.

[00:18:11] SM: I think that's what we call, 'that escalated quickly.' What projects, if you can speak to it, are you working on at Shore that might use Elixir alongside other languages?

[00:18:24] MC: I am writing my third book about Elixir right now. It is the second part of Deploying Elixir. This is for advanced topics. Because almost 1600 people download the book. A lot of people wrote me with their feedback about it. Many people say, “Oh, have you think about writing about Kubernetes, or deploying to Bare Metal? Maybe BPAs, or I don't know. A lot of topics.” I said, “No, yeah. I thought about it, but I haven't time to write it.” 

Maybe I can put that in a second part. As more people come and give me feedback, I say, okay, maybe there is enough material to do a second part. I write in this second part of Deploying Elixir, it would be advanced topics. I don't know, consider in the previous one in this. I will write about Ash or AWS, or Bare Metal installs, or Kubernetes, or things like that. That's why, yeah. I'm doing here right now.

[00:19:31] SM: Cool. I mean, there's so many projects. You're just a content creation machine right now, and that's just making me tired a little bit just thinking about it.

[00:19:42] MC: It is a lot. Yeah. But it is fulfilling. I don’t complain. I like it. I write for people that is learning, as me. I'm learning all the time. I don't consider myself an expert in anything. It is very hard for me to say something like that. Usually, that word is very scary for me to say, I am an expert. I am learning all the time and I write what I learn. I like to write it in a way that if was me, the one doing it for the first time, I could learn it in the way I like it.

What I find fulfilling is that a lot of people find it useful, the way that you write it. They don't expect that I am an expert. They just want to learn something new. There is always people learning things. If I can help them to learn Elixir, for me, that is perfect. I don't need more than that. There are, of course, a lot of books for advance topics, either no meta programing, or internals, or compiler creation. I will never do something like that. I am not that kind of person.

[00:20:52] SM: Never say never.

[00:20:54] MC: No, no. It's not my goal. I write for people that sound the same mistakes of learning as me. I think, there is enough people in that space to be always providing information and material for them. That's my goal.

[00:21:11] OB: Tying together this learning process with the polyglot environment that we're thinking about the season, you talked about deploying Elixir and Kubernetes and some of these more advanced infrastructures. For someone coming from a primarily Elixir, Phenix type of non-polyglot environment, what are some of the surprises you might discover when you're deploying to Kubernetes, where you're probably connecting to other services and other languages?

[00:21:42] MC: I think, it is very different how you deploy when you are creating a small application, or monoliths. When you do this jump to the microservices, or the cloud, or things like that. Because it is not easy anymore. Yeah, you have to consider a lot of things. You also have to program how to infrastructure EBs. That is something that nobody tells you before. You’re just, okay, I'm going to compile real and that's it, or I'm going to start the server import 8080 and that's it. When you go to a company that those, all these orchestration and Kubernetes and AWS, and continuous deployment is completely another layer.

I look at the scripts everywhere and a lot of checks before going to production. A lot of languages that work differently, their deployment process is different. For example, for Ruby, it is very heavy to create a deployment, a bundle, compared for example, for Elixir, you have very big bundles for Ruby and very slim bumpers for Elixir that influences the startup banks, for example. You'll never think about it. Yeah, it's going to start. Yeah. When you are in production with some system that cannot be down more than a few seconds, those seconds matter.

The faster something that starts, or boots up in production is a barrier, but you never think about it. You just start comparing this additional features of the language, or products of the language decisions when you use them in these production and scenarios that you don't see normally when you are programing on your laptop, or your PC. It is interesting to compare how the language features reflect in a production environment, when you mix things up that are for example, compiler, or interpret it.

An example, we have right now at Python, we have a Ruby, we have Elm, Elixir. All those have very different processes to deploy the production and maybe, you have to jump between one on the other to have the full system work and in production.

[00:23:56] SM: Yeah. Everything you just said just reminded me that a lot of people get into Elixir really do just jump in and they use Elixir and Phoenix and that's out of the box. What are some interesting combinations? Do you like Elixir backend with Elm frontend, or are there combinations out there that you really enjoy working with that you think work well together that maybe we wouldn't have thought of?

[00:24:22] MC: I like Elm in the frontend and Elixir in the backend. For me personally, for my side projects, I use that, because I think it is a very good combination. You have in the frontend, the warranties that the compiler, the Elm compiler gives to you, and you can be sure that the code is going to behave very well, without any exception or handling error. In the backend, I think Elixir gives you a very fast way to create APIs. Also, there are a lot of libraries to do almost anything through the GraphQL APIs to connect to services for monitoring, for error logging, for I don’t know, connect to AWS, to storage, to process, maybe in the background, some video, some images, some anything.

The landscape libraries are very mature right now in Elixir. You can do almost anything without the need to include additional technology. If you are programing something by yourself, or in a small team, you can just rely on Elixir, and you can get maybe 80%, 90% of what you need to go to production and start earning money with your idea, with your startup. You can later maybe some specialized tools, or other languages for things that Elixir is not, I don’t know, aimed to that, or to solve that. You can go very far using Elixir in the backend and in the frontend using Elm.

Now, React is king right now in the frontend. Personally, I don't like it. It's too much technology. You cannot use it just, okay, I'm going to start with React. Yeah, you need 20 things just to start something with React.

[00:26:09] SM: Is it too early in the season to start ragging on JavaScript?

[00:26:12] MC: No, no. I prefer to operate in Elm. I know that is not perfect. It lacks many things. For me, as for my side projects, I can do everything I need just using Elm in the frontend and just using Elixir in the backend. I like it. In the day job, in my day job I use more things. As I said, switching between the power lines in object-oriented languages and functional programing languages is hard for me to do it in the same day. I try to do one or two days just to focus on Elixir, and then the other days in Rails, or whatever, and not switch too much.

[00:26:52] SM: Yeah, that was a follow-up question I had. If you're working in multiple languages out in your day job, would you maybe split up the work, like you're saying, you do some language one or two days and then you switch languages. Or does somebody on your team – Do you only do Elixir, or someone else in your team only does Elm, like for example? Or doers everyone do everything?

[00:27:14] MC: We are mainly specialize in things that we like the most. We try to have people work in the things that they like, because they are more productive, or they feel by better, and that’s good for the person itself and for the team. Yeah. Sometimes there is no other option than just jump and do okay, there is something that we need to do. I know how to do it. Okay, I'm going to do it even if it's not what I do every day. Sometimes I have to go off to Rails. I have to go to Elm, some React. Yeah, but I try to keep myself in the things I like the most. For me, this lasts a couple of years is Elixir. If I can be in Elixir 100% of the time, for me is the best. I can switch to the other maybe as needed.

[00:28:01] OB: Context switching is hard, even within an app. When you know and understand the thing you're working on and then you need to think about a different part of the app, it's a big app, even within Elixir, within a single language, it can be a lot to switch out of. 

I'm curious how, if you're in a polyglot environment, say either because Elixir isn't the strongest in a particular use case, or because of other reasons. At the end of the day, If you have to use Elixir with multiple other backend languages, what are some examples of how those applications talk to each other? How do they sync up with data and that thing?

[00:28:42] MC: No, not for specific applications. If what you are solving has a lot of concurrency, Elixir is very good at it. It is very easy to create a process to do something in the background, or asynchronously. That is not so easy to do in other language. For example, in Java. Java is very hard to create processes and monitor them just to check if they have finished what they have to do. You have to write lines and lines and lines, just to spawn a separate process. Elixir, it's very easy to just like, wishing and it appears, in this DOM. You can check the result, or you can just monitor if something happened through a process.

Ruby is kind of solve with this, I don’t know, a psychic, or heart, or something like that. It's not part of the language. The language is single credit. Was not really made for this. Elixir was made for this. It is super easy to solve this problem that you need to delegate to a separate process of the job and the work load, and then you get a notification, or when maybe some. It is very easy. If you have a problem that have this kind of particularities, Elixir is a strong solution for – a strong option to fix it. That's it.

I guess, that if you are solving some mathematical problem, maybe Python is better, or C, if you are interacting a lot with hardware. I try to also avoid that company some problems, because it's not something that I like a lot. At least, what I try to find these companies that use Elixir to solve these things, or Elm to solve this kind of problem. I would say that it is best, Elixir is best for this kind of problem, that have a lot of concurrency, or that you can split in parallel tasks that you can monitor for the result you want.

[00:30:44] OB: I think for the communication piece, I think I'm thinking of rest APIs, GraphQL. Let’s say, if you need to send data from Python to Elixir, you can do that with APIs, RPC, or you can just use your database as a way to synchronize between different applications. You talk about native languages, like C. With Elixir, we have NIFs and tools like that. If there's something that you really do need to do with another language, then yeah, we've got a handful of tools and I'm probably forgetting a couple that will help you interface with other languages when you need to.

[00:31:22] MC: Correct. Yeah.

[00:31:24] SM: When you're hiring people, or you're looking into working with different people on side projects, is there anything you look for in particular in terms of languages that they've worked in before, or are you just looking for somebody who's good at learning? I know we talk about this a lot from different point of use in the – on Elixir Wizards. In particular multi-language environments is something I'm curious about in terms of hiring.

[00:31:52] MC: I have always thought that the best thing to look for in a colleague that you are trying to get into your team is the attitude. Not the technical knowledge, or the technical jobs or skills or whatever, because the technical things, you can learn it. If you just give this person time, they will learn whatever. We always are learning new things by yourself, or in a course. You get a course, whatever. We can learn it.

The attitude, you cannot change it. For me, the most important thing is a person, if he is eager to learn, if he is a person that gets along with the team, that it is, I don't know that can learn from the others and this to the others, I think that's the best thing. Because if you cannot give feedback about technical things to the other people, you are not going to go far with that person. If you cannot say, “Hey, maybe we should change this, because of this reason.” This person takes that maybe personally, because it is my goal that I am the best. You know nothing. You’re on the snow, or things like that, it's hard to have a good thing communication. For me, I don't care much about what they know, or where they have to work, or if they are the expert, or in this, or that.

What I like is that they are eager to learn new things. Because we are learning all the time. Even if you have work in a super big project and you switch to a different company, it is completely new. You are going to learn a lot of things there. I think, that's the best thing. The language, they will learn what is needed. Frameworks, libraries, processes, workflows. They will learn it in a couple of days, a couple of weeks, a couple of months. They will learn it. After that, the person remains there. If the person doesn't get along with the team, it's not going to be a good thing.

[00:33:54] SM: Yeah, totally agree. Then, that also reminds me about something that we talked about a little bit last season is if somebody comes in and they are – maybe they haven't worked in Elixir before, but they're learning Elixir, or maybe they already know Elixir and now they're learning Ruby, do you see any similarities across different languages where knowing Elixir has changed the particular way that you approach a problem, or a project?

[00:34:23] MC: That happens very often. We do see people programing in a new language, still with the old language techniques, or good practices. That can be good or bad, depending on where you come, or where are you going from. I don't know, I don't want to say languages, because it's not fight of languages. If the code you are writing, it is expressive for the other programmers, for the other developers, I think that is the best, even if it's not optimized is not the best. I don't know. It is not all in, or one, or locked in, or whatever, it doesn’t matter.

You can optimize that later when you see that it is having really performant issues. For me, the most important thing when you are programing is that the code is readable for the other developers. You'll see that it can be optimized, you will optimize it. It doesn't matter right now. You need to write code that is good to understand. If in your previous language you already write code this way that is expressive, you will write it in the new language also in a way that is expressive. In a couple of weeks or months, you will learn the practices in this specific project. Then, it will convert to the team, to a good practices. I don't think in the long-term it matters too much. The thing that matters is that the code is readable for other people.

[00:35:53] OB: Yeah, I echo that. I think, a lot of lessons I learned from Elixir, they come from Ruby in some ways, just from the legacy of the creator and everything. Yeah, understanding that longer function names, variable names are actually useful more often than not, and trying to make it readable, so that I can understand it in six months, or that someone else on the team can understand it the next day, or in a year or two. That's all important, regardless of the particular language, or programing paradigm that you're working in.

[00:36:28] MC: Yeah, exactly. That's better, because most of the time, we are writing code, not writing code. It's better to understand it when you read that, when you try to write it in a very clever way, that you are not going to understand in two weeks, or two months.

[00:36:44] OB: Now, I'm curious, we've circled around this. You work at Shore. I'm curious, what's the role of Elixir there and as a polyglot environment?

[00:36:52] MC: Yeah. A very polyglot environment. Shore is a company that is software for small businesses. It has been here for several years on the market. Our time has been accumulating several technologies, and technologies that were famous at some point. Now, they are not so famous. We have a lot of technologies. We are trying now to converse to Elixir and React, because those are the technologies that we see the most potential in the near future.

Currently, we have Python. We have rails. We have Elm. We have React and Elixir, and also, we are using Mongo. We are using PostgresSQL. It is a lot of things that you have to grasp, just to fix, or to have a new features. Okay. In this case, we are going to push this, all projects that they see in Python. I'm going to interact with this other project that they see in Rails, and the new one is in Elixir. We switch a lot of technologies, just to create one new feature. The idea is to converse to Elixir and React. Because for us, that’s a few.

[00:38:03] SM: Another thing that I'm also curious about while we have you, is you mentioned that you're trying to be more active on Twitter to reach out, to be engaged in the community. Do you have a particular goal there? Is that to engage in the community specifically, or to learn more?

[00:38:21] MC: Yeah. The first thing is I want to learn more and to share the knowledge, or what I learned with the community. Yeah, in the long term, my plan, my ideal dream will be to not work anymore in programing. It is as the years passed, I think, okay, maybe I should do another thing. Maybe I should be a carpenter and do chairs and things like that. Because, I don’t know, you get bored of computers. I love them, but it is too much. It’s too much changing every day. I am not so young. My capacity to learn is in severely diminishing. I would like to at some point, just to leave doing content for people. Maybe learning, maybe even doing videos about programing and maybe writing more books about the technology that I like, and I will write a book. If I could leap from that, that will be great.

With that goal in mind, I start to say, okay, maybe I should start a community that can be my audience for this project. Obviously, here, there is always this thing. Okay, he’s going to sell something. He’s not so, yeah. Yeah, but we have to eat. If I work in my day job, I am doing it, because I need to eat.

[00:39:51] OB: A yacht is not going to pay for itself, right?

[00:39:52] MC: Exactly. My family needs to eat. We need clothes. We need to pay their rent and bills, and something like that. Yeah. Maybe we don't think about it every day, but at the end, we need money. It's not that I try to extract all the money that you have right now. Give me, give me, give me. Maybe, I will do nine times for free and nine things for free and one is pay something, because that is I need to eat. I follow many people on Twitter that is making a living, just creating content. I don't want to be an influencer, or YouTuber, or some. Many people can do it. For me, okay, I want that too. I want to do it with something that I lie. I like programing. I like to teach. I like to learn and teach what I am learning.

If I could at some point make a living doing that, that will be top. That's why I started being more active in Twitter. Because at some point, I would like to do that if it's possible. If it's not possible, well, at least I tried. Yeah, that is the end goal.

[00:40:59] SM: Awesome. Before we start to wrap up here, you mentioned earlier about missing types. I'm curious, what are things that you love from other languages that you're missing from Elixir, or vice versa?

[00:41:14] MC: Elixir is dynamic. It has types that are a check on compile time, but not on writing time. They are a check on runtime, but not on compile time. You can compile the project and it will be okay. When you're running, it blows and breaks, and then something happen with it. Why? On Elm, for example, since you are compiling the compiler is very helpful for telling you, okay, here you're trying to pass this on. It's not going to work, because this is expecting maybe an integer, or a string, and it is very helpful, but not just in the sense of it is complaining, “Hey, this is not going to compile. Fix it.” It is very academic, or like a teacher telling you, okay, this is going to fail, because of these. You can fix it this way.

That is a way of learning the language. When you have a program in Elm that compiles, it works and it's amazing. I know that a lot of people have mentioned this a lot of times. It really is amazing just to see it run. It's amazing, because you didn't even open the browser. When you open it the first time, it works and it’s, wow, it’s like magic. Because the language is very strong in checking that kind of things.

Elixir is not that way. It is more relaxed. It is more flexible. You can pass a symbol, instead of a string, and it's not going to tell you nothing, until you try to run it. Then it is failing, because it's not finding that symbol, because there is a string there. Those are some of the things that I missed in Elixir when I am not working on Elm, because I like a lot from Elm. What I like from Elm is other things that it has, like this concurrency, or the virtual, machine or miss hash passing style there, because that is one thing that I like a lot from other language that Elixir, for example, misses, or lacks. That's one thing.

The other is maybe that it is very – the meta programing is not so clear to understand, or easy to understand. Not many people use meta programming. Even if it is one of the pillars of the language. Not many people use it, because it is hard to use meta programing to do everyday tasks. It is something that only the advanced people use. It’s like, okay, for me, I have never used it. I have used, but all the developers have created a Microsoft, but I have never created one. For me, something that is okay, someday, I am going to learn this. For me, another level is the next level.

[00:44:06] SM: Wow. When you were talking about the compiling of the string versus character thing, it just reminded me of every time in Elixir I try to do something and it wouldn't let me, because it was an emoji. That was like, “I just want to use my emojis. Just let me do it.” All right. this was super awesome. Thank you, Miguel for again, coming on and kicking us off into our polyglot season. Do you have any final plugs, or asks for the audience, anywhere on social media where people can find you?

[00:44:34] MC: Yeah. I am very active. Well, this last month I was not very active, I was very worried. Normally, very active in Twitter. I have my blog on Hashnote. If you are starting writing, I recommend 100% Hashnote. It is a very amazing platform to write. I use it for writing all my articles and you can save those to GitHub. From there, you can make whatever you want, like creating books. You can do that.

Yeah, if you like Elixir, there is a lot of new exciting things in Elixir, like a live view. That is one of the things I have in my to-do list. It looks super interesting what they are doing with live view. I have not yet had the opportunity to learn it, but I want. So far, I have been focusing on the deployment on telemetry things on Elixir. If you are interested in that, you can get free books in my home page. You can get and maybe learn something the same as I learn them. Yeah, that's it.

[00:45:43] SM: Awesome. Well, thank you so much. Everyone listening. Please check out Miguel's content, his blog, all the Twitter stuff. It’s just so good. So much out there to learn. Great. That is it for our first episode of Season Eight of Elixir Wizards. Thank you so much to our guest, Miguel Cobá, for joining us today.

Elixir Wizards is a SmartLogic production. Today's hosts include myself, Sundi Myint and my co-host, Owen Bickford. Our producer is Bonnie Lander and our executive producer is Rose Burt. Here at SmartLogic, we build custom web and mobile software. We're always looking to take on new projects. We work in Elixir, Rails, React, Flutter, and more. If you need a piece of custom software built, hit us up. We're also currently hiring two technical roles, staff engineer and mid-level Rails, or Elixir developer.

If you're interested, you can find more details at smartlogic.io/jobs, or just check out the show notes for the link. If you're enjoying Elixir Wizards, please don't forget to like, subscribe and leave a review on your podcast service. Your reviews help us reach new audiences and grow our audience. All @smartlogic on Twitter for news and episode announcements. You can also join us on the Elixir Wizard Discord. Just head on over to the podcast page to find the link. Don’t forget to join us next week for more on Elixir in a Polyglot Environment.

[END]