Visit our site to listen to past episodes, support the show, join our community, and sign up for our mailing list.
Summary
Efene is a language that runs on the Erlang Virtual Machine (BEAM) and is inspired by the Zen of Python. It is intended as a bridge language that serves to ease the transition into the Erlang ecosystem for people who are coming from languages like Python. In this episode I spoke with Mariano Guerra, the creator of Efene, about how Python influenced his design choices, why you might want to use it, and when Python is the better tool.
Brief Introduction
- Hello and welcome to Podcast.__init__, the podcast about Python and the people who make it great.
- Subscribe on iTunes, Stitcher, TuneIn or RSS
- Follow us on Twitter or Google+
- Give us feedback! Leave a review on iTunes, Tweet to us, send us an email or leave us a message on Google+
- Join our community! Visit discourse.pythonpodcast.com for your opportunity to find out about upcoming guests, suggest questions, and propose show ideas.
- I would like to thank everyone who has donated to the show. Your contributions help us make the show sustainable. For details on how to support the show you can visit our site at pythonpodcast.com
- Linode is sponsoring us this week. Check them out at linode.com/podcastinit and get a $20 credit to try out their fast and reliable Linux virtual servers for your next project
- I would also like to thank Hired, a job marketplace for developers, for sponsoring this episode of Podcast.__init__. Use the link hired.com/podcastinit to double your signing bonus.
- Your host today is Tobias Macey
- Today we are interviewing Mariano Guerra about his work on the Efene language.
Interview with Mariano Guerra
- Introductions
- How did you get introduced to Python? – Chris
- So Efene is a language that runs on the BEAM VM which you say was at least partially inspired by the Zen of Python. Can you explain in greater detail in what form that inspiration manifested and some of the process involved in the creation of Efene? – Tobias
- What inspired you to create Efene and what problems does it solve? – Tobias
- How does Efene compare to other BEAM based languages such as Elixir? – Tobias
- When would a Python developer want to consider using Efene? – Tobias
- What benefits does the BEAM provide that can’t be easily replicated in the Python ecosystem? – Tobias
- Does the Efene language ease the transition to a more functional mindset for developers who are already familiar with Python paradigms? – Tobias
- I understand that you are experimenting with another language implementation that runs on the BEAM. Can you describe that project and compare it to Efene? What were your inspirations? – Tobias
Keep In Touch
Picks
- Tobias
- Mariano
Links
The intro and outro music is from Requiem for a Fish The Freak Fandango Orchestra / CC BY-SA
[00:00:14]
Unknown:
Hello, and welcome to podcast.init, the podcast about Python and the people who make it great. You can subscribe to our show on Itunes, Stitcher, TuneIn Radio, or add our RSS feed to your podcatcher of choice. You can also follow us on Twitter or Google plus and please give us feedback. You can leave us a review on iTunes to help other people find the show, send us a tweet or an email, leave us a message on Google plus, or you can join our community. Visitdiscourse.pythonpodcastdot com for your opportunity to find out about upcoming guests, suggest questions, and propose show ideas. I would like to thank everyone who has donated to the show. Your contributions help us make the show sustainable.
For details on how to support the show, you can visit our site at python podcast.com. Linode is sponsoring us this week. Check them out at linode.com/podcastinit and get a $20 credit to try out their fast and reliable Linux virtual servers for your next project. I would also like to thank Hired, a job marketplace for developers and designers for sponsoring this episode of podcast.init. Use the link hired.com/ slash podcast in it to double your signing bonus. Your host today is Tobias Macy. Today, we are interviewing Mariano Guerra. Mariano, could you introduce yourself, please?
[00:01:21] Unknown:
Sure. So as you said, I'm Mariano. Originally, I'm from Cordo, Argentina. Now for the last couple of years, I've been living in Stuttgart in Germany. I'm a software engineer, and I like mainly playing with programming languages. I like to create them also. I and I also like, distributed systems and also yeah. All all of the parts of software like back end, front end, everything in between.
[00:01:55] Unknown:
With the wealth of interesting projects and tools, it's kinda hard to pick a particular niche to focus on because there are just so many interesting areas to explore. It's also interesting how many of our guests and how much I've heard about Argentina coming up in reference to various Python communities. And it seems like there's a pretty strong, strong community of Python users down in Argentina.
[00:02:15] Unknown:
Yeah. It's, quite big. And Spanish speaking countries is, I don't know if the biggest, but a really big 1. And also, the name is Python Argentina, but we have members from all over the Spanish speaking countries. So it's not only Argentina in that sense. Okay. And,
[00:02:33] Unknown:
Stuttgart is a bit of a difference from Argentina. I'm just curious if you'd like to share how you ended up over in that neck of the woods.
[00:02:39] Unknown:
Yeah. Sure. I came to Germany for the first time, like, 6 years ago for a scholarship for 6 months. I studied here in the 6 months in the Cultural Institute of Technology and then went back. And and in this travel, I met my girlfriend, current girlfriend. She's also from Argentina. And we went back. We got our degree. And, yeah, we we liked the traveling because while we were here, we travel around. Like, 1 nice thing about Europe is that it's small and you can cross countries really easy. So, yeah, I got my degree and I went to work a couple of months to England. And when she visited me, she got, she applied for some jobs here, and she got a job in Schulgaard. So we I moved. And I I work from home, so I can be here and enjoy, like, the nice airports and that everything is close by.
[00:03:36] Unknown:
Yeah. Being able to work from home as a developer is definitely very convenient in that respect.
[00:03:40] Unknown:
Yeah.
[00:03:41] Unknown:
So how did you get introduced to Python in the first place?
[00:03:44] Unknown:
I guess it's a combination of, things. When I started with Linux, like, I don't know, 15 years ago, 2000, I installed Red Hat 6.1, I think. And Red Hat, I think they still do. They all of the scripts and automation they do, they do it in Python. And when I was playing around with Red Hat, because at that point, you had to play around a lot with the software with Linux, I saw like every single utility was written in this Python programming language. At that point, I think it was 1.5 or 2.0 or something like that. And then so I, I came back and I I just read the the scripts to try to figure out those stuff work, but I didn't know the language. And at that point, I didn't have Internet. And, also, I didn't know anyone who were was a programmer.
I just had a c book and I started with c. And so then I learned assembly and then c plus plus and then I started studying at the university and then learned Java. But, yeah, with Java, I got this feeling of, like, complexity. And then, like, someone sysadmin told me, like, yeah, we do we we use Python for automation. And then other person said, hey, have you checked this software? It's made in Python and I will I kept hearing about Python here and there. And a friend of mine told me, yeah, come to a meeting. The the labs of the university are presenting the projects they are working on. So they presented what they're working on and 1 of them was, 1 person doing research on this Python programming language.
So I say, okay, here it is again. So we applied for to work on that group and we that was, like, 2, 004. So we entered and, our job was to pick 1 UI toolkit and 1 web framework. We picked GTK at that point and, turbo gears. Like, we did a presentation of all the alternatives and and which 1 was good and which would why we pick the ones we pick. So we did, some software for the labs. They manage, like, equipment and stuff, with, turbo gears at that point. And then I wanted to to try GTK more in-depth. So, my my brother was using Windows at the moment, and he told me, yeah, I would use Linux only if there was a decent, MSN Messenger client for Linux.
So I said, I took a weekend and I I made a joke, a really long joke. I made a really simple MSN Messenger client for him, and I say, here you have 1. You now you can switch. And he say he start laughing. He he switched, and he started using it and started giving me feedback. And I was, like, changing all the things he said really fast to to make it work for him. And at some point, I blogged about it and, like, people really started to use it. That became MSN, which was really popular, at that point. And, yeah, we we got, like, hundreds of thousands of users, like, lot of contributors. It was translated to many languages, then it grew and learned to work with, g talk and Facebook Messenger. But then when MSN closed, I just, we just left the project, die a peaceful death, let's say. Mhmm. The code is still there, and it runs. And it runs on Mac, on Windows, on Linux, and everything. But, yeah, the main purpose is not there anymore, so we are not supporting it. So yeah, that's how I got into Python and, yeah, and that at some point there, I think when I was at the labs, I joined Python Argentina, the user group. And, yeah, the the cool thing about Python Argentina first is that the people there are awesome.
But also that they organize a lot of events. They have this idea of, federal group. So they are well, they we. I'm a member also. Organized like by days where you can set up 1 day of talks, mainly normally in universities to to talk about Python and try to bring new people. It's to tell students mainly or people that are interested in language about Python. So our all introductory talks, and there there were a lot of them and then, like, PyCon started happening, I think, in 2009. And then, like, PyCon's And, yeah. So I stayed, I came for the language and stayed for the community. I still hang around in the chat helping people, maintaining some projects,
[00:08:36] Unknown:
just because the community is so cool. So, I brought you on today to talk about your language. And actually, I'm gonna pause for a second and just to make sure I'm pronouncing it the right way. So how how do you pronounce the name of your language?
[00:08:48] Unknown:
In it's a play of words. It's a f n e. Okay. It's, because 1 may my first project is MSN. Okay. And it's how you pronounce in Spanish, MSN. Mhmm. And FNA is how you pronounce in Spanish, FN. Mhmm. The 2 letters. Right. So that's the play of words.
[00:09:07] Unknown:
So, f n a is a language that runs on the Beam VM, which for people who aren't familiar is the proper name for the Erlang VM. And in the documentation, you mentioned that it's at least partially inspired by the Zen of Python. I'm wondering if you can explain how that inspiration manifested in some of the process that was involved in the creation of FNA.
[00:09:27] Unknown:
Yeah. Sure. So about Python, I like, as I said, the community, but also like the mindset. There's the thing I like, I don't know who said it, but you should learn languages that change the way you think about programming. And in some sense, Python changed the way I think about programming in terms of simplicity. Like, that's the main thing I like about Python. But also, like, when read when you read the same, there's so much there to learn. When I was, starting, like, I improved a lot of programming with Python. And if you just follow the same when you are thinking about solving a problem, like, it's a good guidance.
And at some point, I was working at some at the work doing Python. And someone newer than me at the for in Python was asking me questions, and I kept replying with the send of Python. And he said, oh, these Python parameters is, like, they talk like send monks. They always reply in this send ways. So I I like, like, it's like a small text that guides you when you are trying to solve a problem. And, like, you see some code and you say this is really complex or really complicated. And then they, like, the same concept you would say this shouldn't be like this or this is too nested and stuff like that. So I I really like like the like the idea of the zen of Python. It's a really small text, really nicely written that, like, con concentrates what Python is or what people think Python should be. So I I like to bring these ideas of the of the of the SEN because I'm not really good at writing SENs or or Haiku or stuff like that. So I just say, okay. Let's adopt everything I like about the Python community instead of trying to come up with some new idea. For example, like, Ruby has this idea of, optimized for programmer happiness and which I find really interesting, but I prefer the simplicity thing of Python. So, 1 thing that, keeps coming back on FNA is, not invent anything new. Just pick stuff from other languages that works and and that I like, of course.
So I tried I bring stuff I like about the the Python community a lot, something in JavaScript and something from the Erlang language and something also from closure. I I don't know if it you can see it in the code, but, like, I some ideas from the closure community are really interesting too. And I forgot the second question.
[00:12:00] Unknown:
Just wondering if you can explain some of the process that was involved in the creation of FNA. Some of the concerns that you have to think about when you're designing and building a new programming language. I started,
[00:12:11] Unknown:
it was an accident. Like, every single thing I do, like MSNA also, I started learning airline in 2006, I think. No. A little bit late later. And, I was finding it really hard to find an excuse to use the language. Like, I learned a lot with I learned a lot a lot from Python while doing this lab project and while doing MSN. And I couldn't find 1 excuse to actually use our link for something real to learn about it. So I was looking for some something to do. And as I said, I like languages, so I did a calculator. Like, you enter, like, formulas and it did the calculation for you.
And the it's actually on GitHub. Still the decoder, you can go commit by commit seeing how it evolves. And at some point, I say, yeah. I could add, like, variables, and I added variables. And then I I said, okay. I can add functions, and I added functions. At this point, it was interpreted. So I said, let's see if I could, compile this to bytecode, actually. And when I managed to compile to bytecode, I say, okay. There's a language here. So I was invited to Orland Factory London in 2, 002, 2010 to talk about it, and I felt this pressure to actually have something more, interesting to show. So I rewrote it as a language from, from scratch. And then, like, there was some interest, so I kept working on it, on and off, since.
I stopped, at some point when, like, Elixir picked up and also because I was really busy working on my personal startup. So when I saw Elixir, I said, okay. There there's, the reason I created FNA was to make it easier for people coming from mainstream programming languages or scripting languages to come to the Erlang ecosystem because, at first, airline looks really alien to people in some sense. But, so when I saw Elixir, I said, okay. They are doing the job. But at some point, when I started having a lot of some no.
Some more free time, I saw that there was still an issue on my ideas of what a nice programming language for the Erlang VM would be. So I started working on it again for the last year, year and a half. And, yeah, it's almost finished. And, yeah, I think it's, like, there there are, like, 4 main programming languages and then Erlang VM, LFE, LISP flavored Erlang, Elixir, and FNA. And, I forgot about another 1. I don't know. It's pronounced Hoksa or Yoxa or I don't know how it is. It's another list. And I think, each has its own characteristics and strengths.
So that's why I still work on FNA because I I think there there's a place for FNA in the in the ecosystem. I'm not trying to compete against the other languages.
[00:15:26] Unknown:
And so that mostly answered my next question about what your inspiration was. And so, you said it was essentially an accident and,
[00:15:34] Unknown:
I like, yeah, I like designing programming languages. I have a lot of hidden failures that are not public, but the first 1 was 1 I did, like, I don't know, 15 years ago or more, that compiled straight to assembly and then that was the fan. And then in the middle, I did 1 the a scheme that compiled to with the PyPy toolchain. There's a talk around and the code is available online. So, yeah, I I like programming languages and and also I like to think on different points of view. Like, if I have this, if I want to focus only on this characteristic, how the programming language would be if I constraints. If I have this constraint, what programming language can I build with this? If I want something that focus on 1 topic or something. And then f n is 1 that the constraints are that it's really easy, really simple, really regular, looks familiar for people coming from Python, Java script, or, like, Algol or mainstream programming languages.
And, yeah, that it's easy to read, easy to pick up, like, the readability of Python, like, that you read the code. And even if you don't know the syntax, you can see what's going on and stuff like that. That's like the the main focus on the language. And what I try to to focus on f n a is, many people complain about the the syntax of Erlang and some other things related to the syntax. And you hear the creators of the Erlang language saying but, like, Erlang is really simple. The the the syntax is really simple. You can learn it in an a. And when I was doing f n and trying to, like, do the same ideas of the syntax, but the idea of, Erlang, the language, like, the syntax is pattern matching and case clauses and and guards. So it's only these 3 things, and you write, like, in English. Like, you have commas and columns and semicolons and columns, and, that's all you have.
So I try to to extract these ideas they had when they well, they didn't decide the syntax. The syntax was mostly inspired by product. So I say, okay. What if I try to extract what they are trying to say and, like, create a different syntax that may be more approachable for people that are used to these algo languages? So that's the current state of f n. It's based on that. Note that I say f n because, many people say f n too. So I tend to say FN but the correct pronunciation is FN. Okay.
[00:18:12] Unknown:
And that also brings up an interesting point because in my listening to some of the communications from the elixir community, I've seen some people mention how in some ways, it can be a bit of a disservice having the more familiar syntax because it can kind of hide some of the cognitive differences and how you actually approach a problem in Erlang based languages because of the more functional and distributed nature. Whereas in languages like Python or Ruby, you're generally more procedural or procedural or iterative in the approach and so that can actually cause some, some initial pain when you're trying to write something the same way as you would write it in Python, but it turns out that the way it is actually executed and the way you should be thinking of it is, somewhat different. So I'm just curious if you've had that experience or had anybody mention that to you.
[00:19:05] Unknown:
Yeah. That's something I keep thinking about, but I have 2 views. It's true that, like, if I could make FNA have the syntax as closely or as similar as possible to Python, and then you have this problem. Then you say, hey. This I know the syntax. So people can think I know the syntax, so I know the semantics of the syntax. I know what happened here. So they will write something and it won't work or it will work differently, and they will say, hey. There's something weird here then. So I didn't copy this the Python syntax or the JavaScript syntax or any other syntax 100% because you will have that. You you read something and because you know what that does in Python, you think it what it does in in in our line or if and So you have this trap of a familiar a familiar syntax, making you think you know what it means.
But in this case, in FNF, like, variables are, uppercase, so you there go, like, okay. This is something different. And then, like, lowercase words are atoms, and it's a plain in documentation. So I fall in that part, I follow the the Erlang approach, the Erlang syntax. So there you see a difference. And f n a is functions first. The I don't try to make something like objects or classes or object oriented notation, so you won't fall in that trap. But on the other hand, like, I try to do it, like, its own syntax that you say, okay. This is a different language. This is not Python for the Erlang VM. But where you can say, okay. Like the rules and the syntax and my fingers are used to write like data, like JSON and functions and the operators like plus and the arithmetic operators and or and and the binary operators.
People are used to read them in a way, so I use that because they mean the same thing. But when it comes to, like, the case statement or pattern matching or function definition with different k function clauses and stuff like that, I don't reuse a similar syntax from another language because I want to make it clear that it's something else. But on the other hand, when I was learning Erlang, I had this problem that it's the, like, the other side of this argument, which is you are fighting 2 things 2 3 battles at the same time. 1st, you are learning a different semantics. Like, the semantics of the Erlang virtual machine, which are really different from, like, JavaScript, or any mutable object oriented or imperative language.
Then you are fighting the tooling because the tooling in Erlang is quite different. It's improving right now, but it's different. You have to get used to that. And then you're fighting also the syntax. So your your brain is trying to learn 3 things at the same time. The the syntax of a language that is really different from what you know, The semantics of the language that if you come from, imperative object oriented languages, it's different from what you know. And the tooling, which it used to be really bad, but it's getting really good lately. There there's a big push on on tooling lately that's improving. So, like, you are going to, stop learning, Erlang and move to something else because you're saying, okay. This this is too much at the same time. I I'm like, you didn't it's if you are a Python programmer and you start learning JavaScript, many things are the same. Like, objects are like objects, arrays are arrays, mutability is mutability, and stuff like that. Functions are functions, modules are modules. So you can and the syntax is not that different.
So you can take a lot when you move. And then you start to get this moments where you say, okay. This is different. And you can, like you take, like, a mental note of this is not like in Python. But you can start with there's this saying that you can write Fortran in any language. I used to write c in any language until I learned Python. And now I try to I used to try to write Python in any language. And then, like I learned closure and the the style makes you try to code in a in a particular way because your your mind gets used to thinking that way. My idea with DEFN is to let you bring a lot of the things you already know.
And, of course, to clarify when something is different. But so you don't have to start from scratch learning everything, like, the syntax, the tooling, and the concepts. I want to focus on making the tooling and the syntax as approachable as possible and also having a lot of focus on errors and documentation and support and community. So, you can focus on learning just the semantics of the airline ecosystem, which are the the part that is different and the part that makes the airline ecosystem interesting. Because, Erlang, the language, like, the syntax is you're not going to learn Erlang because of the syntax, or you're not going to learn airline because of the tooling. Your the virtual machine allows you to do stuff that it's not as easy in other virtual machines or ecosystems.
So I want to make a language that is so simple and so, like, the definite project is not only the compiler and the syntax and the language, but also the landing page, the documentation, the tutorials, the templates, the plugins. The FNA project is everything. All of that is a release of the FNA language. It's, when when I say 1.0, it means the language is ready. The compiler is ready. The error messages are clear. The templates, are all up to date. The the plug ins are up to date. The documentation covers all the topics, and it's, you have, like, tutorials and step by step guides. I want to make the 1st weeks with the language easy so you can focus on learning what's different. This this moment when you say, okay. This is different in Erlang. This is what I came from for.
So that's my idea with the with the project. And I think the Elixir community is doing the same for the people coming from Ruby in some sense because the creator creator of Elixir, Jose Valim, is a core Ruby on Rails committer. So I think he's trying to make as easy as possible for the people coming from the Ruby on Rails community to land on the airline ecosystem and get on their feet and running as quickly and as easy as possible. Of course, if you try to write Ruby on Elixir, you will get these moments where you say, okay. This doesn't work like like, what I expected. But, you are already running a website, a web server doing queries to a database. So you already have something to show and you're happy because you have something running like a web server that replies and displays a website.
And then you say, okay. It's worth to learn it and, like, interiorize it because it's worth it and I'm already so far ahead with the language and I'm already productive that it's worth learning it. But if you get stuck the 1st day or the 2nd day or you say or you see that in the 2nd week, you are still on the hello world and you don't understand anything, The chances that you will stay and you won't move to another programming language are really big. Not big, really low.
[00:26:44] Unknown:
So, yeah, from your description of how you're trying to play that balancing act of making sure that the syntax is familiar enough, but not so much that it's deceptively familiar. Seems like a pretty thin line to walk, but it sounds as though you're doing a pretty good job of that. But another thing you mentioned too is that the tooling in the Erlang ecosystem is getting progressively better. And I know that part of that is because Erlang, the language in and of itself, has seen a bit of a recent, rise in popularity largely because of the scales that a lot of people are trying to operate at. And also, you know, there have been a few success stories of companies who are using Erlang, so for instance, WhatsApp and then also the React database and RabbitMQ all being written in Erlang.
And also, I know that part of the tooling is partly due to the fact that Elixir has been gaining a lot of popularity. And I know that Ruby the Ruby community has a pretty good focus on the developer tooling partly to play into their whole philosophy of developer happiness. And it seems that 1 of the benefits of writing a language that runs on the beam is because, you know, similar to JVM based languages, all of those different ecosystems can interoperate because they all compile to the same byte code. So for instance, correct me if I'm wrong, but you can actually take libraries written in Elixir and in Erlang and utilize them directly in Afin a without having to do any modifications.
[00:28:15] Unknown:
Yep. That's right. Yep. So also the the the the Elixir here is a difference, between my approach and the Elixir approach, which I I'm not saying it's a good thing or a bad thing, but just difference, on the airline side, what the Elixir people showed to the airline people let's say is that you could actually make it really like improve programmer happiness on the airline virtual machine, with not so many programmers because when the Elixir community started, they were a small group of people, really active group, but not that many. And they, in like 1 or 2 years, they've created like a package manager and a and a release tool and a website where you could publish packages and web framework and all this stuff. And they, this is only my idea, but, they showed that if you really want to make it easier, simpler, and more user friendly, you can. It's not a matter of the size of the community.
But at the same time, it was already getting better. Basho, the company behind React created rebar that, you may like it or not, but it was it solved the problem. It had some problems also, but it was better than what was there before, which was only make files. So some people picked up the work there and and created river 3, which was a rewrite of river that solved the problems that people were having. And also the there's the Airline MK project, which is a more unique style, build tool. So it's it improved along with the Elixir people. But then there was this back and forth and, like, cross pollination where, like, since the Elixir people already had a package manager and a package format and some ideas, 3 bar 3 people said, okay. Let's use that package manager and that format for 4 d airline packages too. So there was this back and forth where all the tools kept improving with the work of both sides and the feedback, of both sides.
So it's been a good 2 or 3 years on the Irvine side in terms of tooling. Still a way to go but quite nice compared to 3 or 4 years ago. And what makes difference with FNA between Elixir? Elixir has mix and hex and some other tool that I may be forgetting. The idea of FNA is to not have, its own tools, but to use, all the tools available on the Erlang side. So if any works out of the box with rebar 3 and with Erlang MK, you just have to add the a 1 plug in under configuration that comes already configured on the templates for the projects I have. And you are already running. You can mix airline code with f n a code with LFE code and it will work.
So the idea is to also to not have a standard library. Usually, elixaries has some ideas of their own. It's the language that is the most different from the languages on the Erlang VM. So it's usual that some people, even when you can use, Erlang libraries directly from Elixir, it's usual for people to wrap Erlang libraries to make them more Elixir like. It's what also happens in Clojure. You can use Java libraries directly but you can't find wrappers for almost all the libraries. So, they have like a closure feel. Elixirs tend to wrap to thin wrappers around urban libraries to have a more Elixir field. The idea of f n is that we don't have a standard library.
Elixir has 1, not that big but has 1. And we don't have f n libraries. Libraries that are created with f n a can either be used directly from Erlang or even compiled to Erlang. If you want to write in FNA, but the build or the source code in GitHub and your packet manager be directly Erlang, it will be. We are not trying to, like, create an ecosystem of tools and libraries inside inside of the Erlang ecosystem. We reuse everything that's available and try to we we are more in that sense, we are more like, CoffeeScript to JavaScript, and Elixir will be, like, closer to Java.
They they are further ahead because, Elixir also has concepts of their own that they take from the closure side, which are protocols, where you can implement a protocol for data type and it will work across all the data types that implement that protocol, which is really cool but requires you to do some extra compiling magic in the middle like Scala and closure have to do. But if any, it's just straight compiling. You can each line of f n a is 1 line of Erlang and there's no overhead. There's no intermediate generation of code behind the scenes that does something extra. It's just straight Erlang.
You can even compile FNA code instead of FICO to Erlang. So it in that case, it's more like a coffee script.
[00:33:58] Unknown:
That's interesting. I didn't realize that you could, so easily transpile if any to the Erlang syntax. And, it's also an interesting standpoint to like you said not have a standard library and not try to build up a community specifically of FNA users just to basically provide a bridge to people who wanna come into the Erlang ecosystem to make that initial step a little friendlier and then maybe either continue using FNA and stay there or just move further and just use Erlang directly. So
[00:34:30] Unknown:
Exactly. As I said at some point, I don't care if, FNA is a gateway drug in some sense where you start with FNA and then realize that, yeah, now I understand Erlang because, it's 1 to 1. Now only I have to learn the syntax, and I can stop using this plug in, and I can use straight Erlang. I I really don't care. It's my way of helping the community get bigger and more more diverse by trying to bring these people from Python and JavaScript that are afraid, maybe, when they see airline. So that's that's the whole idea. And try not to duplicate work because I'm not trying to, in that in that sense, I'm not trying to create a 3rd community, like the the Erlang guys, the Elixir guys, and the FEN guys. I'm not trying to do that. I think the Elixir people are doing a great job at creating a language that has its own ideas and its own its own community. And so, I'm not trying to create a 3rd group. I'm just on the airline side of things.
[00:35:45] Unknown:
And, in a couple points, you've alluded to some of the benefits that the Beam provides that are hard to replicate in languages like Python. So, I'm curious if you can give a bit more detail about what some of those benefits are and why somebody why why a Python developer might want to consider using FNA or Elixir to take advantage of them.
[00:36:07] Unknown:
Yeah. The reason I came for is, as everyone may think, and that was actually the case concurrency. But when you get in for the concurrency, you stay for the fault tolerance. So there's some people that say I came for the concurrency and stayed for the fault tolerance because that's the most interesting part. Of course, the scalability and the concurrency is great, but default tolerance is the thing other than immutability, the thing that makes change that Erlang change your way of seeing the programming world. The concept of actors and supervisors and message passing and supervisor trees and crash early and often and a supervisor will pick up the crash and will restart and you have this supervisor, and the restart policies, and everything, like, starts crashing because there's some problem. And, then it, the supervisors restart everything from unknown state and you get everything back.
Because there there's even a paper that says, like, 99 of the server bugs are transient. Like, if you retry it enough times, they they go away. And if they don't go away, then you should keep crashing until you reach the top supervisor and if it keeps crashing then you crash the VM because there's nothing to do. But all this idea and not only the idea as a pattern, like, you maybe you could create this in other in other languages, but the VM is created for that. So, immutability helps because 1 actor cannot change something in another actor like this spooky action as a dis at a distance that you have on on mutable languages, which are, like, almost all of them.
And also message passing, actors, you cannot inspect what's inside an actor and you can only modify it by sending messages and you can only send messages if you have the process ID. And and also, each process, since it's receiving messages from a message box, inside the process, it's acting serially. So it takes a message, handles it, then takes the next message and handles it. So inside the process, you are not thinking about concurrency, But when you start to assemble all these process hierarchies and networks of processes sending messages to processes, you get the concurrency for free because the the VM does preemptive scheduling of processes for you, and you have, like, lightweight threads. So lightweight processes, actually. So you don't have to think about how many are these too many processes I'm spawning. You don't care because you can spawn millions of processes without problem, which there's, I think the creator of Erlang said. When he was created, Erlang said, imagine that your programming Python and I, and I say to you, you can only have a a 1, 000 objects.
Like, how your way of designing the program will change if you could only create a 1, 000 objects. It's the same with all the programming languages in terms terms of concurrency. You can only create, I don't know, some thousands of threads we have before you start having problems. In our line, you can create millions and you don't have these problems. And also the VM since it does the preemptive scheduling, 1 process cannot affect the other process because if it takes too long to execute some message handling, it will be, sent to the back of the queue.
So that's nice also. And the fact that the GC on on Erlang is per process. So each process has a really small heap and it grows as needed. And each process does garbage collection on its own heap. So you don't have a global unique huge heap, that will do stop the world to garbage collect gigabytes of data. So that's cool also. So these all these ideas are the ones that you don't when someone says Erlang, they say, yeah, like concurrency and scalability because of the concurrency. But all of these details, also 1 that is really interesting is the degree of introspection. Run time introspection, you can do on on an running system. You can connect via shell to a running system, even via SSH if you want. There there's a blog post over there.
And start, like, inspecting and see the live process tree, and you can even stop processes and inspect what they have inside and all this stuff, which is really useful when you're running a a really complex system. And finally, 2, since you're doing all these message passings passing and you only have a process ID, to send a message, It doesn't matter if the process is on this computer, on this core, on another core, or another another computer on the data center. So the the scalability from 1 core to 5th 16 cores and from 1 server to 15 servers, is, like, use use the same instructions.
And 1 I didn't mention that many people, think it will be more interesting, and I I thought so, but I I still didn't make so much use of it. It's a hot call reloading. Since you have all this immutable thing and no global heap, You compile a new version of a module. You you reload it, and the code with the will reload, of course, with the procedure. It's really useful if you want to have a high availability, but if you can, like, you have to do some steps to achieve this. You have to write code to handle the migration from 1 version to a next version and the migration back from and the next version to the version before in case the upgrade fails. So it's there, but people normally only use it when when it's really needed, when you are running stuff like WhatsApp or or React or stuff like that. It's not something you you say, okay. I will start a, like, a a blog with the back end in Erlang. I will do hot call reloading because you can restart. It's easier to restart at the beginning.
[00:42:42] Unknown:
Yeah. Speaking to your point about fault tolerance, I can't remember exactly the company. I think it might have been, I wanna say Sony's Ericsson, but there is some, yeah, there is some company who using Erlang was able to achieve 9 nines of uptime because of the Erlang VM and its reliability.
[00:43:01] Unknown:
Yeah. It's Ericsson in the they created a telephone switch, a hardware switch using Erlang. And there every second, you are not, handling calls, you get a fine because it's regulated. So, yeah, they achieved on on that switch, 9 nines of availability. And, also, Erlang, that that's maybe the point where it shines. It's used in these high availability, high scalability services. That's why you can see like databases and message queues and like MQTT brokers and all these backbones. Also, Amazon, s 3 is done with Erlang. All these, like, backbone services that you would expect are highly available to be written in Ireland because of of these, these concepts. And the way of approaching and solving a problem that, allow you to have these properties.
[00:44:06] Unknown:
Yeah. It's definitely a very interesting ecosystem and 1 that I continue to want to find a reason to program in, but I have not have not yet found the time and the motivation to do so. So I understand that you are also experimenting with another language implementation that runs on the beam. I'm wondering if you can, give a brief description of what that is and how it compares to FNA and what inspired you to start that project. Sure.
[00:44:34] Unknown:
So as I said, FNA is a conservative language. It tries to be simple. Not I don't want to invent anything new with the language, with the tools, with anything, with the syntax. It tries to be really conservative. But as I was developing FNA, I had all these crazy ideas, and I had, like, a backlog in my mind of all these crazy ideas I wanted to try in a language. And, at some point, I say, okay, what if I bring all these crazy ideas into a language? Of course, that won't be a fan because it will turn into a crazy language. So 1 day, I had a really long, wait times, on airports.
Like, I had, I don't know, half a day coming back to Germany. So I said, okay. Let's try these ideas and see if they all together fit into 1 language that makes some sense. And that began became Interfix. It's an experimental programming language. Experimental in the sense that I try some things that, may not be good ideas, but I wanted to try them in, in 1 language. It's experimental in that sense, but in the sense of, if it works, yeah, it compiles and it it may be a little bit behind FNA in terms of, stability. But, I've tried it, and I've written some code. And there's people that have written code in interface.
And, yeah, it works. I I keep Interfix as a place or a project for people that want to experiment with alternative ways of, writing programs, but always in the syntax part. It compiles it compiles also straight to Erlang, bytecode and can cross compile or transpile to Erlang source code. So you can see what what the meaning of the thing is. And, yeah, there's no, it's, there's no overhead. Like, each feature of the languages compiles directly to a feature of the Erlang language. It's, let's say, it's a crazy syntax that compiles to Erlang Bickel. But I, like, I really like, what I really like about the language is that, when you read some examples, it looks like it can't compile to something.
That can't be because my my idea was to use as the least amount of punctuation as possible without resorting to the list list trick of using parentheses. So it's like a Lisp without the parenthesis. And, the language is quite interesting. I suggest you to check the examples on the readme and the examples folder to see what it looks like. And, I can assure you that all the examples compile to something. Of course, some source codes, the the the thing that the program is actually doing are not useful, but, everything compiles to to to actual code that can run.
[00:47:55] Unknown:
And, just bringing it back around a bit. So there are definitely plenty of benefits to using the Erlang VM VM and the Erlang ecosystem. I'm wondering if there are any cases that you can think of where the where you would not wanna use Erlang or an Erlang language and would rather use Python because it's either easier or more effective.
[00:48:17] Unknown:
Yeah. There are. If you are doing, like, something where Python shines where which is scientific computing, numeric stuff, don't use Erlang because in the math part, it's slow, so it doesn't make sense. And, also, there are some algorithms that are much more efficient if you use, mutation. The you you create an array and sort it in place, replacing the the values that are in the array. If you are using a mutable algorithm, you will be creating 1 new object per change. Of course, if you use something like, structural sharing, you are not creating that much new memory, but it's slower, much slower. So in the part of, numerics and, like, scientific computing and calculations and machine learning and all that stuff, don't use it.
And, also, for scripting, even if you could, there's no reason, I think, because Python and I think if I have to write a script, I would write it in Python. I use Python for Glue, basically. Or if I have to do something quick, I use Python. Erlang is more if you want to take advantage of the of the Erlang as you said and play to the strengths of the of the platform. Platform. Maybe there there are people doing, like, Erlang back ends and then putting Ruby on Rails on front or Python on front with Django to do the the front end of the back end in some sense, on that language those languages.
Even if you can do it in our language, you could if you wanted. But as I said, for scripting, for numerical stuff, I think you shouldn't use. And if you want to create a desktop application, it I wouldn't use Erlang either. Of course, for websites and for web services, it's great. And for I say, backbone. I don't know about, like, databases and message queues and all that is great. But for desktop applications, for scripts, for, and for numerical stuff, I wouldn't recommend it.
[00:50:32] Unknown:
So, are there any questions that I didn't ask that you think I should have or anything else that you'd like to bring up before we move on?
[00:50:41] Unknown:
I cannot think of 1. Oh, that's it.
[00:50:45] Unknown:
So for anybody who wants to get in touch with you or follow what you're up to, what would be the best way for them to do that? Or anybody if they're asking for advice on, how to get involved with FNA and the Erlang ecosystem?
[00:51:01] Unknown:
You can I guess you will write this on the notes because I won't spell it? I'm warrenoguera on Twitter. I'm marionoguera in GitHub, marionoguera.org is my blog. Those will be the, like, the 3 entry points. And for if you're interested particularly on fna, go to fna.org and first contact me directly and, so I can help you because, I've been working on the language, for the last year and a half half to, have a 1 beta. Like, the first release will be 1 0 beta because the language is almost finished or finished, actually. But, of course, I I don't I don't want to come out with a 1.0 because there may be problems. The only reason I don't do the release is because I want to improve the documentation, and I want to do the release when I I have free time to support the people that come. But if you want to be an early adopter and help me, like, polish the product, before the release, just contact me on those channels and I will gladly help you to get started with the FNA and with any question you may have.
[00:52:15] Unknown:
Excellent. So with that, we will move on into the picks. And for my picks today, my first 1 is a project that I came across recently because I just started a new job and got a new computer for it and needed to set up my dot files all over again and decided to to take the opportunity to see if there's a better way that I could go about it than what I was currently using. And so I found a project called dotfiles, spelled d0tphiles. And it's just a collection of dot files for various things such as zsh and bash and your Python RC and, git config and all of that kind of stuff.
And it's a really good starting point. A lot of good utility in there. And so I've forked that and made it my own a bit and have been enjoying using that so far. And my next pick today is a conference talk video that I watched a little while ago called the unreasonable effectiveness of dynamic typing for practical programs. And it's a discussion of the static versus dynamic typing argument that's been going on for ages and has a lot of really cogent points about how static typing is good for solving certain sets of problems, but in the whole dynamic dynamic typing is at least equally as good at a number of those same problems, particularly in terms of the accuracy and reliability of code as long as you're practicing proper unit testing, techniques and not relying solely on manual testing. So the the gains that you get from static typing don't necessarily outweigh the gains you get from dynamic typing and in some cases can also be detrimental because of the upfront cognitive load necessary for having to decide all of your types ahead of time and how all of that is going to play out throughout your entire application.
So definitely recommend giving that a look, particularly for people who are firmly in the Python camp. And with that, I will pass it to you, Mariano. What have you got for PIX today?
[00:54:26] Unknown:
Some in terms of software, 1 thing I've been creating lately, small to medium sized application using, I don't know if it's a framework, but a library from from ClosureScript, the closure dialect that compiles to JavaScript called omnext. It's on alpha currently, so you may get burned, but it's quite stable. I've been using it and the product works, and I hadn't had any surprises with it. I recommend you to check, David Nolan's talks about Next and the reasons behind the the the project because also the it's a really novel approach to creating UIs on your browser.
It I I don't know if I will be able to go back to JavaScript after creating a UI with Next because it makes so many things that in JavaScript are a pain so simple that, yeah, I it's addictive in some sense. Of course, there there may be, applications where you need a, like, extreme performance where you cannot use it, but for simple applications, for experiments, for applications that don't require extreme performance on the front end side, I think on next, it's really, really interesting. And as a result, I recommend you to check closure script if you don't like JavaScript and are looking for something else to create your front ends because, sadly, Python doesn't have a good story on compile to JavaScript. There there are many projects trying to, but I don't think there's 1, like, production ready, like, ClosureScript is. And also something I'm checking, it's also quite new.
It's, a project called The Things Network. It's a project that started in the Netherlands. The some people found, a new protocol and some devices. The protocol is called LoRaWAN that allows really low energy devices to that can can live with the battery for, like, years to send really small amounts of data, but for long distances. So they they did an experiment in Amsterdam, and it's I think it worked, And they created a Kickstarter campaign to to create a really cheap, what they call a gateway. That is, a device like a Wi Fi router that you connect to in your home and can cover theoretically 10 kilometers, how do you say it, circle area of 10 kilometers.
Mhmm. That that means it can receive messages from 10 kilometers around, lines of sight. In a city, it reduces to, like, 3 kilometers, but it's a lot. And some development kits and devices that to make it easy for people to experiment with this technology. And the Kickstarter was successful. They are launching the the this, the things gateway in July, I think, and I find it really interesting. I'm looking into it. Yesterday, I gave a talk about the the protocol. In my blog post, I wrote a short description of the protocol and how it works and what it does and what it doesn't do and stuff like that, I recommend you to check it because I think, I am always thinking on doing something with, like, sensors sending information and then showing it somewhere else.
But you if you use Arduino or Raspberry Pi or Beaglebone, you have to have a power source and they all rely on Wi Fi or something like that. So you cannot create 1 of these and put it on a field or on on a tree or on a river because it won't work. And I find this really interesting alternative. Of course, it's the the the protocol is new and the devices are new and the project is new, so I'm not saying everything works. I'm exploring it, and I recommend you to check it also.
[00:58:50] Unknown:
Well, again, I definitely appreciate you taking the time out of your day to join me and tell us all more about FNA and why we should consider using it for some of our projects. And, I hope you enjoy the rest of your day.
[00:59:04] Unknown:
Thank you. Enjoy your rest of your day too.
Hello, and welcome to podcast.init, the podcast about Python and the people who make it great. You can subscribe to our show on Itunes, Stitcher, TuneIn Radio, or add our RSS feed to your podcatcher of choice. You can also follow us on Twitter or Google plus and please give us feedback. You can leave us a review on iTunes to help other people find the show, send us a tweet or an email, leave us a message on Google plus, or you can join our community. Visitdiscourse.pythonpodcastdot com for your opportunity to find out about upcoming guests, suggest questions, and propose show ideas. I would like to thank everyone who has donated to the show. Your contributions help us make the show sustainable.
For details on how to support the show, you can visit our site at python podcast.com. Linode is sponsoring us this week. Check them out at linode.com/podcastinit and get a $20 credit to try out their fast and reliable Linux virtual servers for your next project. I would also like to thank Hired, a job marketplace for developers and designers for sponsoring this episode of podcast.init. Use the link hired.com/ slash podcast in it to double your signing bonus. Your host today is Tobias Macy. Today, we are interviewing Mariano Guerra. Mariano, could you introduce yourself, please?
[00:01:21] Unknown:
Sure. So as you said, I'm Mariano. Originally, I'm from Cordo, Argentina. Now for the last couple of years, I've been living in Stuttgart in Germany. I'm a software engineer, and I like mainly playing with programming languages. I like to create them also. I and I also like, distributed systems and also yeah. All all of the parts of software like back end, front end, everything in between.
[00:01:55] Unknown:
With the wealth of interesting projects and tools, it's kinda hard to pick a particular niche to focus on because there are just so many interesting areas to explore. It's also interesting how many of our guests and how much I've heard about Argentina coming up in reference to various Python communities. And it seems like there's a pretty strong, strong community of Python users down in Argentina.
[00:02:15] Unknown:
Yeah. It's, quite big. And Spanish speaking countries is, I don't know if the biggest, but a really big 1. And also, the name is Python Argentina, but we have members from all over the Spanish speaking countries. So it's not only Argentina in that sense. Okay. And,
[00:02:33] Unknown:
Stuttgart is a bit of a difference from Argentina. I'm just curious if you'd like to share how you ended up over in that neck of the woods.
[00:02:39] Unknown:
Yeah. Sure. I came to Germany for the first time, like, 6 years ago for a scholarship for 6 months. I studied here in the 6 months in the Cultural Institute of Technology and then went back. And and in this travel, I met my girlfriend, current girlfriend. She's also from Argentina. And we went back. We got our degree. And, yeah, we we liked the traveling because while we were here, we travel around. Like, 1 nice thing about Europe is that it's small and you can cross countries really easy. So, yeah, I got my degree and I went to work a couple of months to England. And when she visited me, she got, she applied for some jobs here, and she got a job in Schulgaard. So we I moved. And I I work from home, so I can be here and enjoy, like, the nice airports and that everything is close by.
[00:03:36] Unknown:
Yeah. Being able to work from home as a developer is definitely very convenient in that respect.
[00:03:40] Unknown:
Yeah.
[00:03:41] Unknown:
So how did you get introduced to Python in the first place?
[00:03:44] Unknown:
I guess it's a combination of, things. When I started with Linux, like, I don't know, 15 years ago, 2000, I installed Red Hat 6.1, I think. And Red Hat, I think they still do. They all of the scripts and automation they do, they do it in Python. And when I was playing around with Red Hat, because at that point, you had to play around a lot with the software with Linux, I saw like every single utility was written in this Python programming language. At that point, I think it was 1.5 or 2.0 or something like that. And then so I, I came back and I I just read the the scripts to try to figure out those stuff work, but I didn't know the language. And at that point, I didn't have Internet. And, also, I didn't know anyone who were was a programmer.
I just had a c book and I started with c. And so then I learned assembly and then c plus plus and then I started studying at the university and then learned Java. But, yeah, with Java, I got this feeling of, like, complexity. And then, like, someone sysadmin told me, like, yeah, we do we we use Python for automation. And then other person said, hey, have you checked this software? It's made in Python and I will I kept hearing about Python here and there. And a friend of mine told me, yeah, come to a meeting. The the labs of the university are presenting the projects they are working on. So they presented what they're working on and 1 of them was, 1 person doing research on this Python programming language.
So I say, okay, here it is again. So we applied for to work on that group and we that was, like, 2, 004. So we entered and, our job was to pick 1 UI toolkit and 1 web framework. We picked GTK at that point and, turbo gears. Like, we did a presentation of all the alternatives and and which 1 was good and which would why we pick the ones we pick. So we did, some software for the labs. They manage, like, equipment and stuff, with, turbo gears at that point. And then I wanted to to try GTK more in-depth. So, my my brother was using Windows at the moment, and he told me, yeah, I would use Linux only if there was a decent, MSN Messenger client for Linux.
So I said, I took a weekend and I I made a joke, a really long joke. I made a really simple MSN Messenger client for him, and I say, here you have 1. You now you can switch. And he say he start laughing. He he switched, and he started using it and started giving me feedback. And I was, like, changing all the things he said really fast to to make it work for him. And at some point, I blogged about it and, like, people really started to use it. That became MSN, which was really popular, at that point. And, yeah, we we got, like, hundreds of thousands of users, like, lot of contributors. It was translated to many languages, then it grew and learned to work with, g talk and Facebook Messenger. But then when MSN closed, I just, we just left the project, die a peaceful death, let's say. Mhmm. The code is still there, and it runs. And it runs on Mac, on Windows, on Linux, and everything. But, yeah, the main purpose is not there anymore, so we are not supporting it. So yeah, that's how I got into Python and, yeah, and that at some point there, I think when I was at the labs, I joined Python Argentina, the user group. And, yeah, the the cool thing about Python Argentina first is that the people there are awesome.
But also that they organize a lot of events. They have this idea of, federal group. So they are well, they we. I'm a member also. Organized like by days where you can set up 1 day of talks, mainly normally in universities to to talk about Python and try to bring new people. It's to tell students mainly or people that are interested in language about Python. So our all introductory talks, and there there were a lot of them and then, like, PyCon started happening, I think, in 2009. And then, like, PyCon's And, yeah. So I stayed, I came for the language and stayed for the community. I still hang around in the chat helping people, maintaining some projects,
[00:08:36] Unknown:
just because the community is so cool. So, I brought you on today to talk about your language. And actually, I'm gonna pause for a second and just to make sure I'm pronouncing it the right way. So how how do you pronounce the name of your language?
[00:08:48] Unknown:
In it's a play of words. It's a f n e. Okay. It's, because 1 may my first project is MSN. Okay. And it's how you pronounce in Spanish, MSN. Mhmm. And FNA is how you pronounce in Spanish, FN. Mhmm. The 2 letters. Right. So that's the play of words.
[00:09:07] Unknown:
So, f n a is a language that runs on the Beam VM, which for people who aren't familiar is the proper name for the Erlang VM. And in the documentation, you mentioned that it's at least partially inspired by the Zen of Python. I'm wondering if you can explain how that inspiration manifested in some of the process that was involved in the creation of FNA.
[00:09:27] Unknown:
Yeah. Sure. So about Python, I like, as I said, the community, but also like the mindset. There's the thing I like, I don't know who said it, but you should learn languages that change the way you think about programming. And in some sense, Python changed the way I think about programming in terms of simplicity. Like, that's the main thing I like about Python. But also, like, when read when you read the same, there's so much there to learn. When I was, starting, like, I improved a lot of programming with Python. And if you just follow the same when you are thinking about solving a problem, like, it's a good guidance.
And at some point, I was working at some at the work doing Python. And someone newer than me at the for in Python was asking me questions, and I kept replying with the send of Python. And he said, oh, these Python parameters is, like, they talk like send monks. They always reply in this send ways. So I I like, like, it's like a small text that guides you when you are trying to solve a problem. And, like, you see some code and you say this is really complex or really complicated. And then they, like, the same concept you would say this shouldn't be like this or this is too nested and stuff like that. So I I really like like the like the idea of the zen of Python. It's a really small text, really nicely written that, like, con concentrates what Python is or what people think Python should be. So I I like to bring these ideas of the of the of the SEN because I'm not really good at writing SENs or or Haiku or stuff like that. So I just say, okay. Let's adopt everything I like about the Python community instead of trying to come up with some new idea. For example, like, Ruby has this idea of, optimized for programmer happiness and which I find really interesting, but I prefer the simplicity thing of Python. So, 1 thing that, keeps coming back on FNA is, not invent anything new. Just pick stuff from other languages that works and and that I like, of course.
So I tried I bring stuff I like about the the Python community a lot, something in JavaScript and something from the Erlang language and something also from closure. I I don't know if it you can see it in the code, but, like, I some ideas from the closure community are really interesting too. And I forgot the second question.
[00:12:00] Unknown:
Just wondering if you can explain some of the process that was involved in the creation of FNA. Some of the concerns that you have to think about when you're designing and building a new programming language. I started,
[00:12:11] Unknown:
it was an accident. Like, every single thing I do, like MSNA also, I started learning airline in 2006, I think. No. A little bit late later. And, I was finding it really hard to find an excuse to use the language. Like, I learned a lot with I learned a lot a lot from Python while doing this lab project and while doing MSN. And I couldn't find 1 excuse to actually use our link for something real to learn about it. So I was looking for some something to do. And as I said, I like languages, so I did a calculator. Like, you enter, like, formulas and it did the calculation for you.
And the it's actually on GitHub. Still the decoder, you can go commit by commit seeing how it evolves. And at some point, I say, yeah. I could add, like, variables, and I added variables. And then I I said, okay. I can add functions, and I added functions. At this point, it was interpreted. So I said, let's see if I could, compile this to bytecode, actually. And when I managed to compile to bytecode, I say, okay. There's a language here. So I was invited to Orland Factory London in 2, 002, 2010 to talk about it, and I felt this pressure to actually have something more, interesting to show. So I rewrote it as a language from, from scratch. And then, like, there was some interest, so I kept working on it, on and off, since.
I stopped, at some point when, like, Elixir picked up and also because I was really busy working on my personal startup. So when I saw Elixir, I said, okay. There there's, the reason I created FNA was to make it easier for people coming from mainstream programming languages or scripting languages to come to the Erlang ecosystem because, at first, airline looks really alien to people in some sense. But, so when I saw Elixir, I said, okay. They are doing the job. But at some point, when I started having a lot of some no.
Some more free time, I saw that there was still an issue on my ideas of what a nice programming language for the Erlang VM would be. So I started working on it again for the last year, year and a half. And, yeah, it's almost finished. And, yeah, I think it's, like, there there are, like, 4 main programming languages and then Erlang VM, LFE, LISP flavored Erlang, Elixir, and FNA. And, I forgot about another 1. I don't know. It's pronounced Hoksa or Yoxa or I don't know how it is. It's another list. And I think, each has its own characteristics and strengths.
So that's why I still work on FNA because I I think there there's a place for FNA in the in the ecosystem. I'm not trying to compete against the other languages.
[00:15:26] Unknown:
And so that mostly answered my next question about what your inspiration was. And so, you said it was essentially an accident and,
[00:15:34] Unknown:
I like, yeah, I like designing programming languages. I have a lot of hidden failures that are not public, but the first 1 was 1 I did, like, I don't know, 15 years ago or more, that compiled straight to assembly and then that was the fan. And then in the middle, I did 1 the a scheme that compiled to with the PyPy toolchain. There's a talk around and the code is available online. So, yeah, I I like programming languages and and also I like to think on different points of view. Like, if I have this, if I want to focus only on this characteristic, how the programming language would be if I constraints. If I have this constraint, what programming language can I build with this? If I want something that focus on 1 topic or something. And then f n is 1 that the constraints are that it's really easy, really simple, really regular, looks familiar for people coming from Python, Java script, or, like, Algol or mainstream programming languages.
And, yeah, that it's easy to read, easy to pick up, like, the readability of Python, like, that you read the code. And even if you don't know the syntax, you can see what's going on and stuff like that. That's like the the main focus on the language. And what I try to to focus on f n a is, many people complain about the the syntax of Erlang and some other things related to the syntax. And you hear the creators of the Erlang language saying but, like, Erlang is really simple. The the the syntax is really simple. You can learn it in an a. And when I was doing f n and trying to, like, do the same ideas of the syntax, but the idea of, Erlang, the language, like, the syntax is pattern matching and case clauses and and guards. So it's only these 3 things, and you write, like, in English. Like, you have commas and columns and semicolons and columns, and, that's all you have.
So I try to to extract these ideas they had when they well, they didn't decide the syntax. The syntax was mostly inspired by product. So I say, okay. What if I try to extract what they are trying to say and, like, create a different syntax that may be more approachable for people that are used to these algo languages? So that's the current state of f n. It's based on that. Note that I say f n because, many people say f n too. So I tend to say FN but the correct pronunciation is FN. Okay.
[00:18:12] Unknown:
And that also brings up an interesting point because in my listening to some of the communications from the elixir community, I've seen some people mention how in some ways, it can be a bit of a disservice having the more familiar syntax because it can kind of hide some of the cognitive differences and how you actually approach a problem in Erlang based languages because of the more functional and distributed nature. Whereas in languages like Python or Ruby, you're generally more procedural or procedural or iterative in the approach and so that can actually cause some, some initial pain when you're trying to write something the same way as you would write it in Python, but it turns out that the way it is actually executed and the way you should be thinking of it is, somewhat different. So I'm just curious if you've had that experience or had anybody mention that to you.
[00:19:05] Unknown:
Yeah. That's something I keep thinking about, but I have 2 views. It's true that, like, if I could make FNA have the syntax as closely or as similar as possible to Python, and then you have this problem. Then you say, hey. This I know the syntax. So people can think I know the syntax, so I know the semantics of the syntax. I know what happened here. So they will write something and it won't work or it will work differently, and they will say, hey. There's something weird here then. So I didn't copy this the Python syntax or the JavaScript syntax or any other syntax 100% because you will have that. You you read something and because you know what that does in Python, you think it what it does in in in our line or if and So you have this trap of a familiar a familiar syntax, making you think you know what it means.
But in this case, in FNF, like, variables are, uppercase, so you there go, like, okay. This is something different. And then, like, lowercase words are atoms, and it's a plain in documentation. So I fall in that part, I follow the the Erlang approach, the Erlang syntax. So there you see a difference. And f n a is functions first. The I don't try to make something like objects or classes or object oriented notation, so you won't fall in that trap. But on the other hand, like, I try to do it, like, its own syntax that you say, okay. This is a different language. This is not Python for the Erlang VM. But where you can say, okay. Like the rules and the syntax and my fingers are used to write like data, like JSON and functions and the operators like plus and the arithmetic operators and or and and the binary operators.
People are used to read them in a way, so I use that because they mean the same thing. But when it comes to, like, the case statement or pattern matching or function definition with different k function clauses and stuff like that, I don't reuse a similar syntax from another language because I want to make it clear that it's something else. But on the other hand, when I was learning Erlang, I had this problem that it's the, like, the other side of this argument, which is you are fighting 2 things 2 3 battles at the same time. 1st, you are learning a different semantics. Like, the semantics of the Erlang virtual machine, which are really different from, like, JavaScript, or any mutable object oriented or imperative language.
Then you are fighting the tooling because the tooling in Erlang is quite different. It's improving right now, but it's different. You have to get used to that. And then you're fighting also the syntax. So your your brain is trying to learn 3 things at the same time. The the syntax of a language that is really different from what you know, The semantics of the language that if you come from, imperative object oriented languages, it's different from what you know. And the tooling, which it used to be really bad, but it's getting really good lately. There there's a big push on on tooling lately that's improving. So, like, you are going to, stop learning, Erlang and move to something else because you're saying, okay. This this is too much at the same time. I I'm like, you didn't it's if you are a Python programmer and you start learning JavaScript, many things are the same. Like, objects are like objects, arrays are arrays, mutability is mutability, and stuff like that. Functions are functions, modules are modules. So you can and the syntax is not that different.
So you can take a lot when you move. And then you start to get this moments where you say, okay. This is different. And you can, like you take, like, a mental note of this is not like in Python. But you can start with there's this saying that you can write Fortran in any language. I used to write c in any language until I learned Python. And now I try to I used to try to write Python in any language. And then, like I learned closure and the the style makes you try to code in a in a particular way because your your mind gets used to thinking that way. My idea with DEFN is to let you bring a lot of the things you already know.
And, of course, to clarify when something is different. But so you don't have to start from scratch learning everything, like, the syntax, the tooling, and the concepts. I want to focus on making the tooling and the syntax as approachable as possible and also having a lot of focus on errors and documentation and support and community. So, you can focus on learning just the semantics of the airline ecosystem, which are the the part that is different and the part that makes the airline ecosystem interesting. Because, Erlang, the language, like, the syntax is you're not going to learn Erlang because of the syntax, or you're not going to learn airline because of the tooling. Your the virtual machine allows you to do stuff that it's not as easy in other virtual machines or ecosystems.
So I want to make a language that is so simple and so, like, the definite project is not only the compiler and the syntax and the language, but also the landing page, the documentation, the tutorials, the templates, the plugins. The FNA project is everything. All of that is a release of the FNA language. It's, when when I say 1.0, it means the language is ready. The compiler is ready. The error messages are clear. The templates, are all up to date. The the plug ins are up to date. The documentation covers all the topics, and it's, you have, like, tutorials and step by step guides. I want to make the 1st weeks with the language easy so you can focus on learning what's different. This this moment when you say, okay. This is different in Erlang. This is what I came from for.
So that's my idea with the with the project. And I think the Elixir community is doing the same for the people coming from Ruby in some sense because the creator creator of Elixir, Jose Valim, is a core Ruby on Rails committer. So I think he's trying to make as easy as possible for the people coming from the Ruby on Rails community to land on the airline ecosystem and get on their feet and running as quickly and as easy as possible. Of course, if you try to write Ruby on Elixir, you will get these moments where you say, okay. This doesn't work like like, what I expected. But, you are already running a website, a web server doing queries to a database. So you already have something to show and you're happy because you have something running like a web server that replies and displays a website.
And then you say, okay. It's worth to learn it and, like, interiorize it because it's worth it and I'm already so far ahead with the language and I'm already productive that it's worth learning it. But if you get stuck the 1st day or the 2nd day or you say or you see that in the 2nd week, you are still on the hello world and you don't understand anything, The chances that you will stay and you won't move to another programming language are really big. Not big, really low.
[00:26:44] Unknown:
So, yeah, from your description of how you're trying to play that balancing act of making sure that the syntax is familiar enough, but not so much that it's deceptively familiar. Seems like a pretty thin line to walk, but it sounds as though you're doing a pretty good job of that. But another thing you mentioned too is that the tooling in the Erlang ecosystem is getting progressively better. And I know that part of that is because Erlang, the language in and of itself, has seen a bit of a recent, rise in popularity largely because of the scales that a lot of people are trying to operate at. And also, you know, there have been a few success stories of companies who are using Erlang, so for instance, WhatsApp and then also the React database and RabbitMQ all being written in Erlang.
And also, I know that part of the tooling is partly due to the fact that Elixir has been gaining a lot of popularity. And I know that Ruby the Ruby community has a pretty good focus on the developer tooling partly to play into their whole philosophy of developer happiness. And it seems that 1 of the benefits of writing a language that runs on the beam is because, you know, similar to JVM based languages, all of those different ecosystems can interoperate because they all compile to the same byte code. So for instance, correct me if I'm wrong, but you can actually take libraries written in Elixir and in Erlang and utilize them directly in Afin a without having to do any modifications.
[00:28:15] Unknown:
Yep. That's right. Yep. So also the the the the Elixir here is a difference, between my approach and the Elixir approach, which I I'm not saying it's a good thing or a bad thing, but just difference, on the airline side, what the Elixir people showed to the airline people let's say is that you could actually make it really like improve programmer happiness on the airline virtual machine, with not so many programmers because when the Elixir community started, they were a small group of people, really active group, but not that many. And they, in like 1 or 2 years, they've created like a package manager and a and a release tool and a website where you could publish packages and web framework and all this stuff. And they, this is only my idea, but, they showed that if you really want to make it easier, simpler, and more user friendly, you can. It's not a matter of the size of the community.
But at the same time, it was already getting better. Basho, the company behind React created rebar that, you may like it or not, but it was it solved the problem. It had some problems also, but it was better than what was there before, which was only make files. So some people picked up the work there and and created river 3, which was a rewrite of river that solved the problems that people were having. And also the there's the Airline MK project, which is a more unique style, build tool. So it's it improved along with the Elixir people. But then there was this back and forth and, like, cross pollination where, like, since the Elixir people already had a package manager and a package format and some ideas, 3 bar 3 people said, okay. Let's use that package manager and that format for 4 d airline packages too. So there was this back and forth where all the tools kept improving with the work of both sides and the feedback, of both sides.
So it's been a good 2 or 3 years on the Irvine side in terms of tooling. Still a way to go but quite nice compared to 3 or 4 years ago. And what makes difference with FNA between Elixir? Elixir has mix and hex and some other tool that I may be forgetting. The idea of FNA is to not have, its own tools, but to use, all the tools available on the Erlang side. So if any works out of the box with rebar 3 and with Erlang MK, you just have to add the a 1 plug in under configuration that comes already configured on the templates for the projects I have. And you are already running. You can mix airline code with f n a code with LFE code and it will work.
So the idea is to also to not have a standard library. Usually, elixaries has some ideas of their own. It's the language that is the most different from the languages on the Erlang VM. So it's usual that some people, even when you can use, Erlang libraries directly from Elixir, it's usual for people to wrap Erlang libraries to make them more Elixir like. It's what also happens in Clojure. You can use Java libraries directly but you can't find wrappers for almost all the libraries. So, they have like a closure feel. Elixirs tend to wrap to thin wrappers around urban libraries to have a more Elixir field. The idea of f n is that we don't have a standard library.
Elixir has 1, not that big but has 1. And we don't have f n libraries. Libraries that are created with f n a can either be used directly from Erlang or even compiled to Erlang. If you want to write in FNA, but the build or the source code in GitHub and your packet manager be directly Erlang, it will be. We are not trying to, like, create an ecosystem of tools and libraries inside inside of the Erlang ecosystem. We reuse everything that's available and try to we we are more in that sense, we are more like, CoffeeScript to JavaScript, and Elixir will be, like, closer to Java.
They they are further ahead because, Elixir also has concepts of their own that they take from the closure side, which are protocols, where you can implement a protocol for data type and it will work across all the data types that implement that protocol, which is really cool but requires you to do some extra compiling magic in the middle like Scala and closure have to do. But if any, it's just straight compiling. You can each line of f n a is 1 line of Erlang and there's no overhead. There's no intermediate generation of code behind the scenes that does something extra. It's just straight Erlang.
You can even compile FNA code instead of FICO to Erlang. So it in that case, it's more like a coffee script.
[00:33:58] Unknown:
That's interesting. I didn't realize that you could, so easily transpile if any to the Erlang syntax. And, it's also an interesting standpoint to like you said not have a standard library and not try to build up a community specifically of FNA users just to basically provide a bridge to people who wanna come into the Erlang ecosystem to make that initial step a little friendlier and then maybe either continue using FNA and stay there or just move further and just use Erlang directly. So
[00:34:30] Unknown:
Exactly. As I said at some point, I don't care if, FNA is a gateway drug in some sense where you start with FNA and then realize that, yeah, now I understand Erlang because, it's 1 to 1. Now only I have to learn the syntax, and I can stop using this plug in, and I can use straight Erlang. I I really don't care. It's my way of helping the community get bigger and more more diverse by trying to bring these people from Python and JavaScript that are afraid, maybe, when they see airline. So that's that's the whole idea. And try not to duplicate work because I'm not trying to, in that in that sense, I'm not trying to create a 3rd community, like the the Erlang guys, the Elixir guys, and the FEN guys. I'm not trying to do that. I think the Elixir people are doing a great job at creating a language that has its own ideas and its own its own community. And so, I'm not trying to create a 3rd group. I'm just on the airline side of things.
[00:35:45] Unknown:
And, in a couple points, you've alluded to some of the benefits that the Beam provides that are hard to replicate in languages like Python. So, I'm curious if you can give a bit more detail about what some of those benefits are and why somebody why why a Python developer might want to consider using FNA or Elixir to take advantage of them.
[00:36:07] Unknown:
Yeah. The reason I came for is, as everyone may think, and that was actually the case concurrency. But when you get in for the concurrency, you stay for the fault tolerance. So there's some people that say I came for the concurrency and stayed for the fault tolerance because that's the most interesting part. Of course, the scalability and the concurrency is great, but default tolerance is the thing other than immutability, the thing that makes change that Erlang change your way of seeing the programming world. The concept of actors and supervisors and message passing and supervisor trees and crash early and often and a supervisor will pick up the crash and will restart and you have this supervisor, and the restart policies, and everything, like, starts crashing because there's some problem. And, then it, the supervisors restart everything from unknown state and you get everything back.
Because there there's even a paper that says, like, 99 of the server bugs are transient. Like, if you retry it enough times, they they go away. And if they don't go away, then you should keep crashing until you reach the top supervisor and if it keeps crashing then you crash the VM because there's nothing to do. But all this idea and not only the idea as a pattern, like, you maybe you could create this in other in other languages, but the VM is created for that. So, immutability helps because 1 actor cannot change something in another actor like this spooky action as a dis at a distance that you have on on mutable languages, which are, like, almost all of them.
And also message passing, actors, you cannot inspect what's inside an actor and you can only modify it by sending messages and you can only send messages if you have the process ID. And and also, each process, since it's receiving messages from a message box, inside the process, it's acting serially. So it takes a message, handles it, then takes the next message and handles it. So inside the process, you are not thinking about concurrency, But when you start to assemble all these process hierarchies and networks of processes sending messages to processes, you get the concurrency for free because the the VM does preemptive scheduling of processes for you, and you have, like, lightweight threads. So lightweight processes, actually. So you don't have to think about how many are these too many processes I'm spawning. You don't care because you can spawn millions of processes without problem, which there's, I think the creator of Erlang said. When he was created, Erlang said, imagine that your programming Python and I, and I say to you, you can only have a a 1, 000 objects.
Like, how your way of designing the program will change if you could only create a 1, 000 objects. It's the same with all the programming languages in terms terms of concurrency. You can only create, I don't know, some thousands of threads we have before you start having problems. In our line, you can create millions and you don't have these problems. And also the VM since it does the preemptive scheduling, 1 process cannot affect the other process because if it takes too long to execute some message handling, it will be, sent to the back of the queue.
So that's nice also. And the fact that the GC on on Erlang is per process. So each process has a really small heap and it grows as needed. And each process does garbage collection on its own heap. So you don't have a global unique huge heap, that will do stop the world to garbage collect gigabytes of data. So that's cool also. So these all these ideas are the ones that you don't when someone says Erlang, they say, yeah, like concurrency and scalability because of the concurrency. But all of these details, also 1 that is really interesting is the degree of introspection. Run time introspection, you can do on on an running system. You can connect via shell to a running system, even via SSH if you want. There there's a blog post over there.
And start, like, inspecting and see the live process tree, and you can even stop processes and inspect what they have inside and all this stuff, which is really useful when you're running a a really complex system. And finally, 2, since you're doing all these message passings passing and you only have a process ID, to send a message, It doesn't matter if the process is on this computer, on this core, on another core, or another another computer on the data center. So the the scalability from 1 core to 5th 16 cores and from 1 server to 15 servers, is, like, use use the same instructions.
And 1 I didn't mention that many people, think it will be more interesting, and I I thought so, but I I still didn't make so much use of it. It's a hot call reloading. Since you have all this immutable thing and no global heap, You compile a new version of a module. You you reload it, and the code with the will reload, of course, with the procedure. It's really useful if you want to have a high availability, but if you can, like, you have to do some steps to achieve this. You have to write code to handle the migration from 1 version to a next version and the migration back from and the next version to the version before in case the upgrade fails. So it's there, but people normally only use it when when it's really needed, when you are running stuff like WhatsApp or or React or stuff like that. It's not something you you say, okay. I will start a, like, a a blog with the back end in Erlang. I will do hot call reloading because you can restart. It's easier to restart at the beginning.
[00:42:42] Unknown:
Yeah. Speaking to your point about fault tolerance, I can't remember exactly the company. I think it might have been, I wanna say Sony's Ericsson, but there is some, yeah, there is some company who using Erlang was able to achieve 9 nines of uptime because of the Erlang VM and its reliability.
[00:43:01] Unknown:
Yeah. It's Ericsson in the they created a telephone switch, a hardware switch using Erlang. And there every second, you are not, handling calls, you get a fine because it's regulated. So, yeah, they achieved on on that switch, 9 nines of availability. And, also, Erlang, that that's maybe the point where it shines. It's used in these high availability, high scalability services. That's why you can see like databases and message queues and like MQTT brokers and all these backbones. Also, Amazon, s 3 is done with Erlang. All these, like, backbone services that you would expect are highly available to be written in Ireland because of of these, these concepts. And the way of approaching and solving a problem that, allow you to have these properties.
[00:44:06] Unknown:
Yeah. It's definitely a very interesting ecosystem and 1 that I continue to want to find a reason to program in, but I have not have not yet found the time and the motivation to do so. So I understand that you are also experimenting with another language implementation that runs on the beam. I'm wondering if you can, give a brief description of what that is and how it compares to FNA and what inspired you to start that project. Sure.
[00:44:34] Unknown:
So as I said, FNA is a conservative language. It tries to be simple. Not I don't want to invent anything new with the language, with the tools, with anything, with the syntax. It tries to be really conservative. But as I was developing FNA, I had all these crazy ideas, and I had, like, a backlog in my mind of all these crazy ideas I wanted to try in a language. And, at some point, I say, okay, what if I bring all these crazy ideas into a language? Of course, that won't be a fan because it will turn into a crazy language. So 1 day, I had a really long, wait times, on airports.
Like, I had, I don't know, half a day coming back to Germany. So I said, okay. Let's try these ideas and see if they all together fit into 1 language that makes some sense. And that began became Interfix. It's an experimental programming language. Experimental in the sense that I try some things that, may not be good ideas, but I wanted to try them in, in 1 language. It's experimental in that sense, but in the sense of, if it works, yeah, it compiles and it it may be a little bit behind FNA in terms of, stability. But, I've tried it, and I've written some code. And there's people that have written code in interface.
And, yeah, it works. I I keep Interfix as a place or a project for people that want to experiment with alternative ways of, writing programs, but always in the syntax part. It compiles it compiles also straight to Erlang, bytecode and can cross compile or transpile to Erlang source code. So you can see what what the meaning of the thing is. And, yeah, there's no, it's, there's no overhead. Like, each feature of the languages compiles directly to a feature of the Erlang language. It's, let's say, it's a crazy syntax that compiles to Erlang Bickel. But I, like, I really like, what I really like about the language is that, when you read some examples, it looks like it can't compile to something.
That can't be because my my idea was to use as the least amount of punctuation as possible without resorting to the list list trick of using parentheses. So it's like a Lisp without the parenthesis. And, the language is quite interesting. I suggest you to check the examples on the readme and the examples folder to see what it looks like. And, I can assure you that all the examples compile to something. Of course, some source codes, the the the thing that the program is actually doing are not useful, but, everything compiles to to to actual code that can run.
[00:47:55] Unknown:
And, just bringing it back around a bit. So there are definitely plenty of benefits to using the Erlang VM VM and the Erlang ecosystem. I'm wondering if there are any cases that you can think of where the where you would not wanna use Erlang or an Erlang language and would rather use Python because it's either easier or more effective.
[00:48:17] Unknown:
Yeah. There are. If you are doing, like, something where Python shines where which is scientific computing, numeric stuff, don't use Erlang because in the math part, it's slow, so it doesn't make sense. And, also, there are some algorithms that are much more efficient if you use, mutation. The you you create an array and sort it in place, replacing the the values that are in the array. If you are using a mutable algorithm, you will be creating 1 new object per change. Of course, if you use something like, structural sharing, you are not creating that much new memory, but it's slower, much slower. So in the part of, numerics and, like, scientific computing and calculations and machine learning and all that stuff, don't use it.
And, also, for scripting, even if you could, there's no reason, I think, because Python and I think if I have to write a script, I would write it in Python. I use Python for Glue, basically. Or if I have to do something quick, I use Python. Erlang is more if you want to take advantage of the of the Erlang as you said and play to the strengths of the of the platform. Platform. Maybe there there are people doing, like, Erlang back ends and then putting Ruby on Rails on front or Python on front with Django to do the the front end of the back end in some sense, on that language those languages.
Even if you can do it in our language, you could if you wanted. But as I said, for scripting, for numerical stuff, I think you shouldn't use. And if you want to create a desktop application, it I wouldn't use Erlang either. Of course, for websites and for web services, it's great. And for I say, backbone. I don't know about, like, databases and message queues and all that is great. But for desktop applications, for scripts, for, and for numerical stuff, I wouldn't recommend it.
[00:50:32] Unknown:
So, are there any questions that I didn't ask that you think I should have or anything else that you'd like to bring up before we move on?
[00:50:41] Unknown:
I cannot think of 1. Oh, that's it.
[00:50:45] Unknown:
So for anybody who wants to get in touch with you or follow what you're up to, what would be the best way for them to do that? Or anybody if they're asking for advice on, how to get involved with FNA and the Erlang ecosystem?
[00:51:01] Unknown:
You can I guess you will write this on the notes because I won't spell it? I'm warrenoguera on Twitter. I'm marionoguera in GitHub, marionoguera.org is my blog. Those will be the, like, the 3 entry points. And for if you're interested particularly on fna, go to fna.org and first contact me directly and, so I can help you because, I've been working on the language, for the last year and a half half to, have a 1 beta. Like, the first release will be 1 0 beta because the language is almost finished or finished, actually. But, of course, I I don't I don't want to come out with a 1.0 because there may be problems. The only reason I don't do the release is because I want to improve the documentation, and I want to do the release when I I have free time to support the people that come. But if you want to be an early adopter and help me, like, polish the product, before the release, just contact me on those channels and I will gladly help you to get started with the FNA and with any question you may have.
[00:52:15] Unknown:
Excellent. So with that, we will move on into the picks. And for my picks today, my first 1 is a project that I came across recently because I just started a new job and got a new computer for it and needed to set up my dot files all over again and decided to to take the opportunity to see if there's a better way that I could go about it than what I was currently using. And so I found a project called dotfiles, spelled d0tphiles. And it's just a collection of dot files for various things such as zsh and bash and your Python RC and, git config and all of that kind of stuff.
And it's a really good starting point. A lot of good utility in there. And so I've forked that and made it my own a bit and have been enjoying using that so far. And my next pick today is a conference talk video that I watched a little while ago called the unreasonable effectiveness of dynamic typing for practical programs. And it's a discussion of the static versus dynamic typing argument that's been going on for ages and has a lot of really cogent points about how static typing is good for solving certain sets of problems, but in the whole dynamic dynamic typing is at least equally as good at a number of those same problems, particularly in terms of the accuracy and reliability of code as long as you're practicing proper unit testing, techniques and not relying solely on manual testing. So the the gains that you get from static typing don't necessarily outweigh the gains you get from dynamic typing and in some cases can also be detrimental because of the upfront cognitive load necessary for having to decide all of your types ahead of time and how all of that is going to play out throughout your entire application.
So definitely recommend giving that a look, particularly for people who are firmly in the Python camp. And with that, I will pass it to you, Mariano. What have you got for PIX today?
[00:54:26] Unknown:
Some in terms of software, 1 thing I've been creating lately, small to medium sized application using, I don't know if it's a framework, but a library from from ClosureScript, the closure dialect that compiles to JavaScript called omnext. It's on alpha currently, so you may get burned, but it's quite stable. I've been using it and the product works, and I hadn't had any surprises with it. I recommend you to check, David Nolan's talks about Next and the reasons behind the the the project because also the it's a really novel approach to creating UIs on your browser.
It I I don't know if I will be able to go back to JavaScript after creating a UI with Next because it makes so many things that in JavaScript are a pain so simple that, yeah, I it's addictive in some sense. Of course, there there may be, applications where you need a, like, extreme performance where you cannot use it, but for simple applications, for experiments, for applications that don't require extreme performance on the front end side, I think on next, it's really, really interesting. And as a result, I recommend you to check closure script if you don't like JavaScript and are looking for something else to create your front ends because, sadly, Python doesn't have a good story on compile to JavaScript. There there are many projects trying to, but I don't think there's 1, like, production ready, like, ClosureScript is. And also something I'm checking, it's also quite new.
It's, a project called The Things Network. It's a project that started in the Netherlands. The some people found, a new protocol and some devices. The protocol is called LoRaWAN that allows really low energy devices to that can can live with the battery for, like, years to send really small amounts of data, but for long distances. So they they did an experiment in Amsterdam, and it's I think it worked, And they created a Kickstarter campaign to to create a really cheap, what they call a gateway. That is, a device like a Wi Fi router that you connect to in your home and can cover theoretically 10 kilometers, how do you say it, circle area of 10 kilometers.
Mhmm. That that means it can receive messages from 10 kilometers around, lines of sight. In a city, it reduces to, like, 3 kilometers, but it's a lot. And some development kits and devices that to make it easy for people to experiment with this technology. And the Kickstarter was successful. They are launching the the this, the things gateway in July, I think, and I find it really interesting. I'm looking into it. Yesterday, I gave a talk about the the protocol. In my blog post, I wrote a short description of the protocol and how it works and what it does and what it doesn't do and stuff like that, I recommend you to check it because I think, I am always thinking on doing something with, like, sensors sending information and then showing it somewhere else.
But you if you use Arduino or Raspberry Pi or Beaglebone, you have to have a power source and they all rely on Wi Fi or something like that. So you cannot create 1 of these and put it on a field or on on a tree or on a river because it won't work. And I find this really interesting alternative. Of course, it's the the the protocol is new and the devices are new and the project is new, so I'm not saying everything works. I'm exploring it, and I recommend you to check it also.
[00:58:50] Unknown:
Well, again, I definitely appreciate you taking the time out of your day to join me and tell us all more about FNA and why we should consider using it for some of our projects. And, I hope you enjoy the rest of your day.
[00:59:04] Unknown:
Thank you. Enjoy your rest of your day too.
Introduction to Mariano Guerra
Python Community in Argentina
Journey to Germany
First Encounter with Python
Joining Python Argentina
Introduction to FNA Language
Creating FNA: Process and Challenges
Balancing Familiarity and Novelty in FNA
Tooling and Community in the Erlang Ecosystem
Benefits of the Erlang VM
When Not to Use Erlang
Experimental Language: Interfix
Getting Involved with FNA
Picks and Recommendations
