Coding Elixir with AI or building AI into your Elixir
apps? The Elixir AI Collective Discord
is your community for both. Link in the description below.
Secure your Elixir apps with paraxial IO.
From code analysis and bot defense to dependency checks,
they've got you covered. Elixir first design with GitHub
integration. Elevate your security at
paraxial dot IO testing. What's up?
I'm Jacob Litzow, your Elixir mentor and welcome to another
exciting episode of the Elixir Mentor podcast.
This is where we discuss everything related to Elixir,
from interviews with enthusiasts, pioneers in the
community to innovative projects and libraries shaping Elixir's
future. Today I'm joined with Leandro,
creator of MDX and Loomis, and he's also a returning guest on
the podcast. So it's exciting to have you
back. Thanks for joining me today.
And yeah, I always have more fun when I have returning guests.
I don't know why I feel like it's we already like broke the
ice. Thank you for having me back on
and excited to be talking about MBX and Lumis this time.
Yeah. And I feel like last time what
we talked about Beacon and I feel like what were you were
working on, like the UI, was it not?
No, what were you working on? I'm blanking now.
It was about a year ago, so probably I was working on the
admin interface for for Beacon. That's right.
OK. Yeah, So we were working on the
like the live editor of templates.
That's right. And it and it became a Elixir
conf talk in 2000, 24 as well. So yeah, for a little like quick
refresh for those watching that might not know you, do you want
to give like a just a brief background?
Oh, yeah, sure. Yeah, yeah, yeah, sure.
So, yeah, I've been working with Elixir for 10 years now.
You know, I used to work with Rios, you know, back in the day.
And I'm from Brazil, same as Joseph Vallin.
So it was kind of natural for me to get into Elixir, you know,
those 10 years trying to make my my contributions to the
community. And some of you might know me
from Beacon when I was working at Dockyard.
Now I'm working at Nutella Spark, it's an ad tech solution
for US based schools and also working on the MDX and Lumis
projects, Markdown and Syntex highlighter.
It's a you know it's it's a mix of Elixir, Rust and someone now
is working the looms project to Java and I'm also working to
port the looms project to Jean Crete as well.
So there is a lot we can we can discuss.
Yeah, that's really cool. I'm curious what what kind of
what sparked like MDX? Like what made you want to make
a Markdown library? And I'm guessing it's written in
Elixir, right? Yeah, that was like, you know,
it start about two and I don't maybe three years ago ish.
So I was working on Beacons Ms. right?
And we had to migrate all the blog posts from the old Docker
website to Beacon. And that means migrate about 800
blog posts just, you know, markdown.
And as you can imagine, like 10 years of history, you know,
different people writing blog posts, markdown files.
So we had a bunch of different markdowns to migrate from the
old one to Beacon. And that's when we realized that
Earmark at that time was not generating the output we were
expecting. And so just just to be clear,
Earmark is a really amazing library.
You know it, it has been serving the community for so many years
now. So it's a really, really hard
work to do. So if Earmarks works for you,
you know, keep you using, it's amazing.
But for us back then, we had an issue with some blog posts
because the the problem we've marked down is marked down is a
permissive format. Like you can write whatever you
want, but there's no guarantee the the output is what you
expect, right? So let's say for example, you
can write like a table or a lease, but the generate HML
might not be what you expect. And that's the problem I found
with some specific details with earmark.
And at that time I opened an issue for the project.
I was willing to contribute back upstream fix earmark, but the so
the maintainer at that time he, you know, he just, he just
realized the the earmark he could not change the earmark
design to make that implementation.
So I was stuck with this problem.
I need earmark solution markdown solution to migrate all the blog
posts the dockyard, but I was not finding a mixer solution
right. So coming back from Elixir Conf
in Florida, I was, I was stuck at the airport because of a
thunderstorm. So there was no, no timeline for
my, my flight. And you know, I had nothing to
do essentially. So that's when I, you know, I
opened the, the rust book. I started reading about Rust and
decide to create a new proof of proof of concept.
You know just a wrapper of the Conrac library.
Conrac is Rust is the Rust parser that does all the
markdown parsing and rendering for MDX.
So that's when I start MDX. It was pretty much a proof of
concept just to see like if you can use Conrac, a well
established markdown parser for Rust, if you can use that in
Elixir. So I was there at the airport
just reading the books and, you know, writing some code.
And that's how MDX started essentially.
And yeah, so I use, I use most of my free time at that time to
work on a proof of concept. And then eventually when I, you
know, proved that was working, I started using MDX on Beacon.
And that's how Beacon came to be, came to life.
And I'm also grateful for Dockyard because I was also
working on MDX on my work time sometimes.
So that's that was let's say a sponsorship of Dockyard on the
project as well. Yeah, that's really awesome.
So I'm curious, are you just, are you basically just using a
NIF then with with Comrack or how's that working?
Yeah, it starts just like a niche, just a rocker essentially
just passing the options from Elixir to Korak and, you know,
return the HML. So it starts like this, very,
very simple at that time. Now the project has grown to
have way more features like plug insurance and streaming and heat
support and more, more features that Correct does not have.
It's just a Linuxer MBX solution.
OK, cool. But but it's still using.
Correct. OK, What's like, what's the most
difficult thing you've ran into right now building MBX?
Probably in terms of implementation, I'd say
streaming, but that's that's the that's not the only difficult
when you're working on an open source project right there is
like maybe people don't realize how hard it is to work on open
source project. And even though index is not
super huge library, but you know, maintaining a project is
really hard. But in terms of implementation
now you'd say streaming. Streaming is streaming is the
feature that allows you to heal or complete the fragments of
markdown. And that's very useful for AI
like applications where you have the tokens.
So the the AI is feeding some tokens to you.
Those tokens are incomplete fragments of markdown and then
you have to render that, you know, those fragments.
So that's really, really hard to do because you have many edge
cases that you have to solve. So for example, let's say you
have like a cold block or a table or you know, blocks of
markdown. You have to complete those
blocks and then you've parse and you have to parse and render
those fragments. And there are many ways to do
this. Probably the most popular
popular library now is streamed down by Versailles.
They they have like this kind of library library for Markdown as
well. And there are some others
implementing a different way creating new parsers for this
specific use case. But for MDX it does not make
sense to create a new parser because we are using call Rack
and it's it's not an easy task to create a new markdown parser.
So the way it works essentially is as we get new fragments, we
keep placing those fragments into the stack and using new
ball parsec to parse those fragments and then try to figure
out which element we are working with.
Like a table table or a paragraph or a lease.
You know, what kind of element we have that fragment.
And then we have to complete that fragment like a link or a
table. For example, we've let's say we
have just the heater of the table and just the first column
of the table. Let's say we have those tokens
in the stack. Then we have to complete the
rest of the table in order to render that table.
So so yeah, streaming is. I'm curious with, with
streaming, you might not always have like you might not know
that the table's finished yet, right?
Because you can't control what's coming through.
Or is that interesting and so you just kind of assume it's
finished and you have to end the table and then as more data
streams in you, you build on it? Or how does that work?
Yeah, that that's pretty much how you, you know how that's
that's the problem we have because most of the parsers, the
markdown parsers, they need the full document, the full
markdown. So they only they only work with
the full document, not with fragments of or pieces of
markdown. So as we receive fragments we
need we need to complete them. So for example string DAO is
using regex, so they just try to find the element by regex.
So let's say there is a asterisk.
So you you know, that's, you know, you know, if that's like a
bold statement or something like that.
And then you have to place the the paint off the fragment so
you can render that. So let's say you receive like a
dash for a lease, right? And then you have to render that
as a lease. So you have to complete that
element as a lease. And as you receive more of that,
more of those elements, you keep, you know, you, you keep
just feeding the, the streaming parser and, and just like like a
buffer. And then eventually you just
flush and render. OK, Yeah, how do you, how do you
keep track of syntax? Like you're obviously what's the
word I'm looking for. You're you're basically like
optimistically completing things, right?
So how do you know when it's like you can't just like insert
that optimistic completion, right?
Because you have to know it it was you that added it as more
data streams in Or am I over complicating things?
No, that that's, you know, some, some, some implementations they
that's that's how index works. So let's think about an example
here. Let's say you have a code.
Code block is probably the most, you know the most the better
example here, let's say you you start code block, you know, you
have the back dates and you have like the Elixir info streaming.
And then you start streaming some code like the first line,
the second line and so on. So when when MDMDX receives a
new fragment, it just plays the the block and the end of the
block to close the decode block. And so as it it's get as it gets
more and more code lines, it just completes the end of the
block and render that piece. So I think eventually it's going
to receive the the end of the block.
So it just discard that's temporary block and then
continue. But the only thing that MDX does
not do now is reverting a decision.
So let's say you receive a piece of markdown and for some reason
they streaming parts of things that leak that's a lease or a
code block or whatever. And then eventually it realized
that was not. OK, so it can't go back and
correct its mistake. No, not right now, because
that's really, really complex to do, because you have to keep not
only the future like fragments, but have to keep the stack of
the whole document. And it can go back to the
beginning of the document, right?
Because Markdown you have blocks and inline elements and then you
have nested elements. So you have to go back to the
root of the decision. So that's really hard to do and
that's something that is not worth doing right now because
I'm curious can do that. Yeah, I'm curious, do you have
like a solution mapped out in your head or not?
Is it just too complicated or you haven't spent much time on
it? No I I had some ideas but it
gets so complex it's not worth it.
Well, and like you, performance becomes a problem, right?
Like everyone expects like a markdown to be rendered
relatively fast, right? Especially when you're streaming
the data and that should be almost instant.
Yeah, it also depends on the room time where you are calling
MDX. If you have a live view where
you can def the, you know, you can define the content, then
that helps a lot, right? Because as you get more
fragments and then you can just def the the reindeer to a live
view page, you can just leverage the define algorithm of live
view. So it it it really depends where
we you are streaming that markdown.
I'm curious like once you have like all the data like you know
well at least like a portion and you realize like you know some
syntax was assumed incorrectly, couldn't you just re render
everything you have in memory at that point or it does it not
really work that? You can, you can, but there's
going to be like a flag on the page, right?
Let's say you had like a list and then you just re render the
whole document. If it changed the elements,
you're going to see some changes on the page, like you're going
to see like the page changing. It's not a big deal, but it's
possible to just, you know, the documents finish, try to render
the whole document you know and make and fix any mistakes.
But the idea is to reduce the mistakes as much as possible
that you don't need to do that. There was there was a
contribution recently, someone sent a fix for the streaming
parser adding more patterns because we are using Invoke
Parsec. So that's how we identify the
patterns and someone sent a fix to improve it.
So I think it's pretty stable right now.
You know, some tools are using, we have Ashy Jido and others
libraries using MDXI. Don't know who is using the
streaming feature to be honest, but I know some, some, some
companies, some tools, some people are using this streaming
feature now. So it it should be stable
enough. That's awesome.
I won't be probably using the streaming feature, but I am
going to check it out and implement MDX into kill switch.
I think it'll be cool. Yeah, just like if you do just,
you know, just pay attention to the to the render HML, something
that is does not look right, just open an issue and then we
can like we can work on that because there are many, many,
many edge cases with streaming because you you don't control
the the fragments, right. And you know, it can be like a
whole lease or just a piece of that lease.
And that lease can be like a task or no task.
And then you don't know if you have to render a text or a task
like like those tasks you have in GitHub.
So it's really hard to, you know, to get all the elements
correct. But you know, it's, it's kind
of, it should be stable now, yeah.
I like that. How long have you been working
on MDX? On MDX let me check the first
version was September 2023. OK.
It was right after Elixir conf. It was just the first version
like the the proof of concept was working and then I released
the first the first. It all stemmed from you getting
bored at an airport. Yes, it's like that, Yeah.
I had no idea how wrestler worked.
Like I knew about the wrestler but never had used it in a
project before, so I started just learning there and, you
know, and that's how it started. Yeah I have never used rustler
or nifs and like in my own project so I'm aware of them.
I just have I have 0 experience with them.
What what was the learning curve like do you think?
Is rustler pretty easy or was it complicated?
I to be honest, I think Rustler deserves more attention from the
community because a really, really good piece of software,
it solves a lot of problems because sometimes you don't have
a library in the Elixir community, so you can just
leverage all their ecosystems, right?
And Rus has Rus has a lot of libraries for a lot.
Of different. Things.
If you're doing heavy computing or anything, you're better off
using Rust instead of Elixir too, right?
Just for speed of processing. It depends.
It depends what you if you need to exchange data, there's going
to be overhead between Elixir and Rust.
If you can, if you can share the same space of memory like some
projects do, then it's it's OK. But if you need to exchange data
and see realize the data, then it's going to have some
overhead. But it really depends on the
project. But The thing is, you can share
the same space of memory and that's a really, really cool
feature. Then it makes it way more.
Performing. Yeah, I can see that.
That's cool. Maybe someday I'll like come up
with an excuse to try Rustler and put in a project.
Yeah, it's really nice, really nice project.
So now like I feel like MDX and then it's Loomis, right?
I'm saying that correctly. Yes, I I I think so.
I to be honest, I renamed the project.
It used to be called another name which I don't know how to
pronounce. So that's the reason I I renamed
to Loomis and I just say Loomis, but you know.
Nice. Now I feel like I don't know.
I would always kind of assume the like Loomis would just be
integrated into a markdown, but there's probably a lot more
complicated aspects to syntax highlighting for code blocks.
Yeah. Yeah, Loomis also start like to
solve a problem on the Dockyard blog post because we had to, you
know, code. We have to have synthetic
highlighting for different types of languages and code because
the Dockyard blog, the blog has, you know, Ruby, JavaScript,
Swift and a lot of other stuff. And in the mixer we have the
makeup library, you know, create by just evaline and, and then it
didn't have all the parsers that I needed for this, this problem.
So then I, I started researching the options I had and I had two
options essentially, either I, I had to create new parsers for
makeup and I had to maintain those parsers.
And it's not easy to create those parsers either.
Or I could just leverage 3 seater. 3 seater is being used
by a lot of editors now. It's just a parser for.
It's essentially A parser for languages.
It's defines the grammar for languages.
And then one of the modules is the syntax highlight because it
identifies the tokens on the search code and then you can
apply like colors on those tokens.
So that those are the two options I had.
And since I was already working with Rust in the MDX, I decided
to just give a try for, you know, for these, for three
seater, I was using a library called Inkyjet.
Back back then he was also Rustler, pretty much the same
idea. And inkjet.
The Internet used to work with the Helix editor, right?
So we had the three pseudo grammars on one side and the
theme, the color schemes from the Helix editor.
The problem though, is, was that the colors were not matching
because many themes from the Helix editor was, they were like
outdated or incomplete. So it was not working very well
for my specific use case. And I was contributing to that
project, the inkjet project. But it came to a point where I
decided to create my own project so I could have the three serial
grammars and the Neofine themes. Because in Neofine you have like
all the themes, all the color schemes are very well maintained
and we have a lot of options. So that's when the synthetic
highlighter is started. But it start as like internal
code inside MDX and then it start growing to the point where
I create the, the Alton. It used to be called Alton in
Elixir. It was another, I separate the
two projects, so MDX and Alton back in the day.
And then eventually I realized the Alton project was more worse
than Elixer because it was because there is, there is no
bindings for three seater for three Elixer, no official
bindings. It's just Rust.
I mean it's Rust in some other like languages, but no, no
Elixer. So the project was pretty much
just Rust, right? And then I realized that I had
to it was better to just release a Russ library.
The the problem was the problem though, is like there wasn't the
autumn name was not available to publish as a crate, as a Russ
library. And the best name I could I
could, I could find was Autonomous, which is Latin,
Latin for autumn. It's not working very well
because you know, it's hard to pronounce.
People don't understand it, including me.
So eventually I just renamed Loomis.
And now we have Loomis for lexer, Loomis for Rust.
We have Acli, the the maintainer of.
I don't know how to pronounce this correctly, but Shikari or
something like that is the the was me runtime for Java.
He also ported movies for for Java, so we also have a Java
library now. I was.
Going to So are you supporting all these multiple run times or
do you just let other people support?
Well, I'm working on the JS runtime or JS version, so yes.
OK, so yeah. So the core engine is just Rust
and CLI is also Rust. Elixir is a Rustler rustler
wrapper, so it's not that much code right now.
JS in TypeScript on the other hand is the most complex one I'd
say because the biggest problem is with three seater is all the
languages that you have. They are defined the gram, the
grammar is defined like a like a Jason JavaScript file and then
it compiles to AC and transpires to C and then you compile that.
The problem is a parser for a Rus or Elixir.
They have like 1 megabyte or two maybe.
So if you include all the languages like let's say 100
different languages, each one consuming like 1 megabyte or
two, it does not work. Like you're not going to
download 200 megabytes for just a Syntex highlight library.
What you don't want just bloat in your project.
Yeah, so that's the biggest problem right now in.
Keeping projects small? Yeah, that makes sense.
So the way we I'm trying to solve these now is using OASM.
SO3 seater has a target. You can compile the parsers into
OASM modules and then the JavaScript libraries can just
load those modules, those languages dynamically at
runtime. So the core is to TypeScript,
but the languages, the parsers are loaded dynamically.
So that's a way to solve this problem.
Although it's not perfect because there is an overhead to
load those languages, but that's the best we can do right now, at
least until you we have the the water components.
Water components might solve this problem, but it's not
something we can use right now. I.
See I I don't know if I fully understand how wasm works.
Can you explain that a little bit?
Yeah, yeah, sure. So essentially you can think
about WASM like having like for example, we have the Bing VM,
right? And then you run some code into
into the VM. WASM is a WASM requires a
runtime as well. So, so in Ross you have wasn't
time. In Elixir we have some as well.
For Java there is this chikori chikori something like that.
It's a runtime as well. For JS we also have some
runtimes. So you you need to load at
runtime and then you can load the wasn't modules into that
runtime. And it works for the user and
and also for the developers. It works like transparent, like
it's transparent. You can just call the functions
from the from the new OSM module.
So if you create like a hello word function and then compile
into a OSME module, you can call that very same function in any
runtime in real S or JS or That's pretty cool.
So it, yeah, yeah, Wasmi is really, really nice.
I had never used it before for anything, like for real.
It's the first time I'm using Rawsmi for something that, you
know, I have to make it work correctly.
It seems to be really a really good solution.
I know. And some projects are using it
now, For example, the popcorn. I, I know it's on the news now.
Popcorn is just using OASM as well load Elixir on the browser.
So yeah, it's, it's a really nice solution, but there are
some limitations. It's not a, not a perfect
solution, but my, my idea with this is having the same API, the
same syntax highlight API for different platforms.
So we have the same API for JS, same API for reals and elixirs.
So you can have the same syndex highlighter, the same colors,
the same languages parsers, all the ecosystem in different
languages and including including the CLI.
Yeah, that's really cool. And then it kind of work.
It'll work the same way as you kind of change technologies and
tech stacks too, right? You'd be pretty familiar with
the library. Yeah, because right now you have
really good libraries, but if you go to JavaScript you have to
choose one, if you go to also have to choose another one and
so on. So sometimes you have a back
end, a front end and you have to choose different Syndex
highlighter libraries, including the CLI.
You know all those coding agents now have a Syntex highlighter
and and actually tree seater works really well for it.
You know AI streaming like feature shutdown interfaces
because Tracer. It works really well with
incomplete code. Yeah, that's cool.
The same problem we had with Mark now.
Interesting. All right.
I'm going to put this on hold for a second and we'll be right
back in like, I don't know. 30 seconds.
Hey, I'm Kimberly with Elixir mentor Jacob recently added
recruitment services to help companies hire pre vetted Elixir
devs. I help with company outreach, so
if you're hiring, I may be reaching out, or you can connect
with us anytime at elixirmentor.com.
And we're back, all right. So I'm curious between like
having two, like you're kind of the solo person in charge of MDX
and Loomis, right? How, how do you balance the
tube? Just having two open source
projects? I feel like that's a big
undertaking. I mean, you have to choose the
most important features. And one thing I learned I was
talking to you Zach from Ash a while ago and one thing he said
to me that it's really important for open source project is to be
like should be as responsive as as possible people open issue.
Zach is the most responsive person I've ever met.
That's. Impressive.
He and Valene, they are like AI don't know.
I think they are some kind of botch because.
I know. I don't think they're real
people. Yeah, they can just spawn up new
versions of themselves and they're just everywhere.
Yeah, it's, you know, it's unbelievable, but the idea is to
be as responsible as possible. If you have a someone open an
issue. If you don't have a solution, at
least just reply and say, hey, I'm going to work on this, it's
on the backlog. I have some ideas.
And then you just kind of, you know, gives.
So give something to the person. Sometimes that person has some
idea, he's just not sure what to do.
And that's how you also get contributions back, right?
So the idea should be as responsible as possible.
That's the first rule. And you know, using AI nowadays
is, is a way to help with the backlog, even though like vibe
coding is not a solution. You know, you have to be very
careful. Yeah.
Have you seen any like nasty messy contribution attempts?
Like does it increase your PRS from contributors or not really?
No, not really. MDX and looms are not products
that are receiving a lot of PRS, I would say.
But it's interesting because we are getting, we are getting more
contributions. The last version, the last MDX
version was was pretty much just external contributors.
So that's really cool when you have people contributing, right.
People are not only using the project, but also helping to
improve it. And I, I saw yesterday on the
leak surf forum the hope to be pronounced his name correctly.
Austin Ziegler. He's building some plug
insurance for for MDX. So it's it's yeah, it's really
nice because, you know, the plug in system.
I was talking to you why tech Mac like 2 years, two years ago,
because the plug in system is based on the rack system, plug
in system. It's pretty much the same idea.
And he was really, you know, cool to, you know, just, you
know, use it. And he gave some ideas, some
feedback as well for MDX. And now you can build plug
insurance. I built, I built the JFM, the
good Hub, McDonald, I built the Mermaid as well and a few
others. And now people are also building
plug insurance, right? So it's not just the MDX like we
have MDX, the plug insurance Loomis and also Conrac, Conrac
which you know the upstream markdown parser.
I am also contributor to Conrac because I need to make changes
on CONRAC first to support, you know features downstream in MDX.
The the most impactful contribution on CONRAC from my
end was the Higgs parser. So the markdown can work with
hex components and Elixir expressions.
So, but yeah, back to your to your question.
Essentially you have to be very pragmatic like you have an
issue, you have APR, you have to take a decision.
Don't, don't, don't let it file. Otherwise it'd be, you know,
there's going to be a lot of PRS and issues.
You have to be responsive. It's hard, but at least for now,
MDX and gums are not like huge projects like you know, like Ash
or Phoenix or whatever. So it's fine for now.
But getting, if it does get more contributions and issues, I
don't know. I just, you know, you have to
find some time. Yeah, for sure.
Yeah, recently I opened the spot the sponsors sponsorship on you
hub and yeah, I got some some sponsors like it's not something
I'm looking for like my you know, it's not not my main
source of commerce. Hey.
Guys, head over there and sponsor this project.
Yeah, like. If you're using MDX, you know,
feel free and you know, it's a, it's a really nice way to, to
help as well. And I'm grateful to have some,
like I had one, I had some one time contributors.
Mike from Dido is now contributing monthly as well.
So that's really, really nice to have.
Like, I mean, open source is about community.
That's really what open source is.
Jeto is something like they're making new projects every day.
I feel like they they're, I can't keep up.
I'm in their Discord and I can't keep up.
Yeah, you open Twitter X or whatever and there's a new
project. Like OK, I didn't have time to
see the other one, now there's a new one.
I'm making, I'm going to make Mike come on and do like a
coding live stream with me because I was like, dude, I
can't keep up. So you have to teach me
everything that you're doing in Jeto.
Yeah, it's really it. I mean, now AI, it's really hard
to keep up because you know. You feel like everyone's pedal
to the metal now and it's like new stuff multiple times a day.
Like we thought it was hard to keep up in in tech before AI and
now now look at it. Yeah, we should.
I guess we still need to learn how to navigate this.
This time is because, you know, new projects, you know,
contributions and you know, a lot of stuff happening at the
same time. In Markdown, for example, we
have so many new projects because, you know, Markdown has
a specification. So I'd say using AI to create a
decent parser from just, you know, from scratch, just using
AI is I'd say it's possible. So I had, you know, I'm trying
to follow some projects, but every day there's something new,
even for just for markdown or ceilidh highlights.
Yeah, that's crazy. One thing I'm noticing is there
seems to be a growing gap of like especially so like Ioffer
like pre vetted recruitment stuff.
And so I'm reviewing a lot of code and I think we have the
issue that I'm starting to see and it's kind of annoying is I
think you have a lot of people that are like very like junior,
mid level developers trying to claim senior level now because
they think they can code so much better and faster with LLMS.
But it you're just like wading through so much LLM slop, it's
like they don't know how to actually create, create well
structured code with LLMS. And there's like a there's a big
gap because like I see, you know, like senior level guys
that I work with on the daily on a daily basis.
I know they're using LLMS to write their code, but it still
looks like good code. And you know, you're not over
engineering solutions, but then you have like you're less
talented developers that are just like spitting out these
crazy over engineered solutions. And it's like almost too much.
And you're like, come on, guys. You got like, there's got to be,
I don't know, we need like a, a better push to teach people how
to use LLMS in their workflow. Yeah, yeah.
And that reminds me of another Jido project.
The there's like a Jido spec or something like the spec driven
development. That's a new, I mean it's not a
new thing, but seems like to be born again because of AI.
So you because there's a big difference between the AI
driving the code driving you and you driving the AI code.
Yeah, it's 100%. Right.
And seems like spec driven development is kind of, you
know, the, it's not, I'm not going to see the solution
because we are still learning, you know, but the spectrum
driven development might be a way that people can, you know,
just stop for a second, think about the problem 1st.
And to realize a bad, a good design, you have to be a senior
developer, you have to have experience, right?
And so AI alone is not enough. You need to understand what's
happening. So I was able to.
Catch architectural mistakes too, right?
If you just are just generically asking an LLM to create a
feature and there's no guiding or planning to that feature,
you're going to get over engineered slop and like unused
do. The amount of unused code in
coding projects is baffling to me too.
Have have you ever tried to ask Claude to review the codecs or
GPT code or vice versa? They, you know, put the two
together 1 reveal the code of the other and they always find
bugs and like a lot of stuff. I'm like, I'll be, it'll be like
hit or miss. I feel like sometimes it'll just
be a total garbage review and then sometimes it'll actually
find stuff that's like super helpful, but it's not consistent
enough that I trust it. Like using like Copilot to do
code reviews or clawed to do code reviews.
Like I feel like it hallucinates more than it helps but I still
use them. Yeah, I I'm finding that having
skills, really well written skills.
Yeah, skills are important. Yeah, it does help a lot.
It reduce hallucinations. It, you know, it's a way to like
a constraint for the, the AI for the Asians, but it's, I've been
doing this experiment like running cloud and codecs at the
same time and asking 1 to reveal the code of the other.
And it's funny because when I need to go back to the, to cloud
and say, Hey, that's what GPT found about your code.
And then it's like, Oh yeah, that's read a book like, so why
didn't you get the book before? So you you cannot trust for
sure. Like you have to review the
code, you have to know what's happening.
So it does require some, you know, experience to use AII.
Think the the big mistake a lot of like mid level and under
developers are making too is they're trying to one shot these
things instead of like stepping through a problem.
Because I like the smaller you break things down, the higher
quality of the code can because you're actually paying attention
to it more carefully too. So if it spits out something
that's not quite right, you're going to correct it and then
move on, right. So I feel like the one shot in
giant features is not the smartest move without plan.
So like I have like 1 shotted features before but like I have
a whole planning phase and I create like an epic and issues
and like a checklist essentially right?
So but that works. Because you have experience in
that, right? Yeah, that works because you
know what's happening. Yeah, yeah.
So by the coding's a mistake, it does not work.
Yeah, I think of it more as like a junior's writing the stuff you
don't want to write, but you still are reviewing it and
putting your name on it when you hit that merge button, you know?
Yeah, I mean, it's really cool to have contributions on on
projects, but you have to be careful, you know, especially on
bigger projects and even like bigger projects now they just
reject AI contributions. So they just.
Sometimes it's hard to tell though.
It's getting harder and harder. Yes, that that's true.
That's true. But.
But I think like the the giveaways are, I mean, if you're
not careful, you get random really weird comments in your
code. And I don't think any well
written code needs comments. So you shouldn't have commented
code And then I would say over engineering problems.
That's like a big giveaway. Yeah, you, you, you, you can,
you can tell. Sometimes it's hard, but you can
tell when it's AI generic code like comments and it's not it
does not go straight to the problem or it does not it's not
using the right boundaries on on your code that that a lot of you
know, or for example, adding new libraries that are outdated and
stuff like that. So.
It loves using old like old libraries like on everything.
Which actually an open source project makes sense because it
cannot depends on the ecosystem. But usually you have to declare
older versions, so otherwise people cannot use your.
Project. Yeah, that makes sense.
But you know, regular project, usually you want to, you know,
you want to have the latest right and AI they fail, usually
they fail to do that. There are always a couple of
versions off, you know. Yeah, yes.
So there are, there are ways to you know, that you can tell if
it's AAI generic code or not. But I guess sometimes it's
really hard and just, you know, just goes.
But but for open source maintainers, I can see the the
problem. Although although I'm pro pro
AII like to use AIII think it helps.
But you need to understand what's happening right?
Because the the code is is still yours.
It's your PR, it's your brain, it's your code even though it
was generated by AI. Yeah, I agree.
I'm I'm a big, you know, I'm a fan.
It took me, I was like a late, late to the partier but late to
the party. But now I like it because it, it
just improves my efficiency. And once you kind of know how to
work it into your own like workflow and planning, I think
it's pretty powerful tool. Like I'm not a good front end
developer and it helps me be a lot better front end developer.
So it's beneficial for me in those ways.
Yeah, same here. If you go to the Lumis website,
that was the itinerary like the front end is.
I have no idea to how to write that code because I'm not a
front end developer either. So for that stuff it's really
nice. And also, for example, the Lumis
requires a lot of, a lot of like bureaucracy code, like defining
the languages, repos and all that stuff.
That's the kind of, that's the kind of code AI just shines, you
know, just repeated code, you know, just get this block and
repeat and change just just the name or just the URL or
something. You know, it takes forever to
maintain this kind of code. But AI is just 5 minutes and
then you reveal and it's done. So there are many, many users
for, for AI for sure. You just have to be careful.
You definitely do. And yeah, yeah.
And guys, if you're not truly like a mid level or senior,
don't pretend you are because you think you are with AI just,
you know, take take. You got to go through the the
same ladders and steps everyone else has and you'll get there
eventually. Yeah, but you can use AI for
learning as well. Yes, absolutely.
I use it all the time for learning honestly.
Like if I ever see like a block of code or like some kind of
like flow in the code base that I'm not quite sure how it works.
Dude I I have AI break it down for me.
Yeah, I I do the same like for research and you know, you can
just use it. I just like, hey, give a talk
and how to brainstorm something or research it's or even
learning about a new product, about a new code base.
It's really helpful. Yeah, for sure.
I'm curious, with like MDX and Loomis now, do you have any
projects that you're building where you're using them
consistently or not? Not really anymore.
I was using for the Wazmi research because I had never
used Wazmi before even though I, you know, I knew about about it
but never used. So Wazmi research and these new
JavaScript library requires a lot of, you know, copy and paste
code essentially. So I'm using for that as well
and using for code review as well.
Even though it's not perfect, but sometimes it catch some bugs
or something that you, you like, you really, sometimes you miss
something, right? And then you can use for code
review and give some hints about something you for you're
forgetting or you have to take another look.
So for code review as well and for for Lumis, for Lumis and
MEDX, that's the, you know, that's where I'm using AI now
essentially. OK, nice.
Wait, I, I feel like it's, there's some sort of benefit
like if you don't to have another engineer look at code
that like not everyone can pick up everything, like you'll miss
things from time to time. And I feel like on solo
projects, AI has a huge benefit there because it's kind of like
an extra pair of eyes. At least it makes you look
closer at parts of code, whether you agree with what it finds or
not. Yeah, that's that's true because
most open source projects are just just one person like
working on a lot of stuff at the same at same time, you know, on
on his free time or or you know, short limited time.
So it's, it's a way to unblock new features to help with code
review. Yeah, it's for, I mean, there
are downsides of, you know, using or abusing AI in the open
source community, but it can also help.
Yeah, 100% that like now that you're not, you're not like
working on the Beacon project and that's where you're kind of
consuming these libraries. Are you consuming your libraries
anywhere else currently or no? No, not really.
Although I really enjoy working on MDX and Loomis, I'm not.
I'm not going to stop, but I had some ideas to use MDX or Loomis.
But you know, I was trying to find some ideas where I could
monetize the projects, right? Like a private project, like a
private closed source project, something I could sell.
But for now, I'm just trying to get the, you know, the bigger
features that I want to have on those libraries.
And then eventually maybe you know, create something like a
like a side project, not something big or whatever,
something small that I could try to monetize and help, you know,
to help fund the project. Yeah, Yeah.
I'm a big believer in doing like like micro products and just
have, you know, a couple micro products and you know, try to
grow them to a couple 1000 users and then that's good, that's
good like side income and eventually like it could
replace, you know, your day job, whatever.
And then you just have all these cool side projects that actually
monetize. Yeah, I mean, I'm not looking to
keeping keeping my my day, day job, but it'll be nice to have
like a side project that I could main mainly helped fund the
project. And yeah, for sure, that would
be nice. What?
What do you have any ideas that you can share?
No, not really. I was, you know that that's the
problem. Every day you open Twitter and
there are like a bunch of new projects, a bunch of new ideas
and stuff in. There's no original idea at this
point anymore, is there? Yeah, yeah.
But you can always innovate even in well established, you know,
areas. But the problem is there's so
many, so much happening at the same time, like and you know,
markdown has been used in projects for like MCP projects
or that kind of stuff. But it's moving so fast that,
you know, your idea became like, your idea becomes stale like in
a week. So it's like it's, it's hard to
decide. It's hard to find something that
you can like commit to because if you start some side project,
you have to be certain about that project, right?
Because you're going to spend some time.
So it's yeah for now just working on the working search
projects. Fair enough.
What? What kind of things do you work
on with your day job? Yeah.
So right now I'm working at Tallis Park.
They are a tech solution for, you know, for US based schools.
And so we, I can say for sure, but we were one of the first to
use live view, you know. In production.
I was just going to ask, are you writing Elixir every day?
Yeah, it's Elixir essentially. Yeah.
So we have been using Phoenix live view for like for years now
and seems like the first published, like one of the first
published versions. And yeah, so it's pretty much
Phoenix and Live view. And we do have some markdown in
the product, but not, not so much we, we, we use MDX here,
but it's not the core of the product.
But most of the projects just Phoenix and live view and that
yeah, that's how I got into live view.
And that's, yeah. So that's the, the, the project
we are. It's pretty much just live view,
yeah. OK, cool.
Any like interesting fun project or problems that you've recently
ran into that you had to solve? Like here the OR like any of
like you mean here in the like in the?
Company or yeah, in the company just on the platform, like do
you have like a pretty large user base?
Do you have performance issues you're dealing with?
Yeah, I guess, I guess now it's more about scaling the company.
You know, when you have like like you have a product and you
have a bunch of clients and you have to scale like the you know,
the infrastructure that you have, you need to scale and then
the the cold base. So you are that at this point
now. But over the years, that's how I
got into Phoenix Live your contributions, because we
started using live view on this product and also Ecto and all
the other libraries and we had to like, we needed some, you
know, some features that, you know, we didn't have back in the
day. So for example, when we start
scaling and having more customers, we had to analyze the
performance of the database and the queries on the database.
So that's, for example, when I contribute the EXPLAIN function
in Ecto, so we can run the EXPLAIN query on Ecto.
And so, yeah, I was able to do some, you know, contribution
here and there, the ecosystem because of, you know, the
company's growth. So that's another way that you
can also, in my opinion, you can contribute to open service,
right? You have a problem in your
project, like don't, don't wait for a solution.
Just, you know, you can solve it.
Yeah, I know it's hard, but it's another way that you can, you
know, contribute to open source. Well I always find it funny when
you see like open source projects and someone's
complaining about a feature not working or wanting a new
feature. Like guys you could just ask if
it's on the road map and then submit the PR.
Do it. Like if you need it, you should
submit the PR. Just just open Cloud Code and.
Vibe it out, put on your sunglasses and go.
And just submit the PR, Yeah, but you can, you can do like you
can, you can for sure contribute.
It's not super hard I'd say. Just make sure that it will be
accepted before you put it in the work though.
Yeah, it it depends when it's a feature request, depending on
the project, you have to use the issue tracker or there's a core
or you can chat about our discord server.
When it's a bug fix, I'd say don't wait, just send the patch,
just send the PR. And yeah, that's, you know, the
good thing about Elixir community is that we are pretty
much pretty much everyone is very friend friendly and open.
So it's AI would say Elixir is a we we could say it's a small
community compared to others. So we some we kind of know each
other, if you know what I mean. And then it's it's easier to get
contributions in this environment.
It's more friendly than others. Yeah, I'd say for the most part,
everyone's really nice in the electric community.
I think that's one of the bonuses, right?
Yes, yeah, yeah, and yeah. For so for index and, and and
Loomis, we got some contributions recently and it's,
you know, it's nice to see the the library growing and
contribution. So what I sometimes people ask
me like, hey, can I contribute or can do something like just
just open the issue, like open an issue we can discuss.
We can, you know, sometimes it does not work out, but
eventually most of them does work.
And that's how you can get, you know, contributions done.
Yeah. Any, any lessons that you can
share having open source projects because like did you,
did you do anything before Beacon or was Beacon kind of
your first open source project? I used to do some contributions
back in the day for angry JS and radios.
That's when I started and then, you know, eventually after
migrating to Elixir, getting some contributions to Elixir
projects. But I don't know, maybe maybe
Beacon was, you know, the first big one, I'd say, if I can say.
That you were like a main contributor on.
Yeah, yeah. But I'd say if you're starting a
new project, if you want to succeed, I'd say marketing is
very important, even though no one likes to do that.
No, it's the hardest thing ever. I always tell people the easiest
part of, like, building like a SAS product or like a library is
coding. And that's just because my
brain's not, Yeah, my brain's not wired for the marketing and
the sales. It's like you wish the like the
statement, build it and they will come.
You wish that was true, but it's the farthest thing from the
truth. And, and I'm guilt of that.
I'm guilt of that as well because that's, you know, MDX,
for example, I never talk about MDX in public.
I. Have Here we are, though you're
in public. Yeah, that's the first time I'm
talking about MDX in English. Like you know before that I had
a meet up, remote meet up in Brazil, but it was Portuguese.
Right now is the first time I'm talking about MDX in English.
Like the library, he's like 2 years old more and that that's
the first time I'm talking about MDX in English.
So marketing is important. So right now we have 500,000
downloads and I had. I have never talked about index
in public, only like Twitter. Sometimes I just post some
releases. I was going to ask, how do you
do you think people are finding it through the hex library or
through the hex website? Probably following you on on
Twitter. I'm I'm not sure to be honest.
I know some people react on the Elixir forum.
People use the Elixir forum as a sirs new libraries and news on
the community, the thinking Lexer podcast.
They have been covering the MDX releases for some time now.
I'm very grateful because that's a really good source.
Yeah, I know the I know Mark is using MDX, so he's always, you
know, following the development of MDX.
So that's probably a good source, but I'm, I'm not sure,
you know, people just starting to use it.
And sometimes people just say, Hey, I'm using index on this and
I, I had no idea. I I don't know, to be honest,
where people are finding index. But but again, marketing is
important. So, you know, I'm trying to be
more open about the development. There are a lot of challenges of
the, you know, development of people's people sometimes don't
realize how hard it is to, you know, mark down and Syntex
highlight are they look like a simple problem to solve, but
it's not. I mean, just talking to you
about like the streaming aspects and like things that I never
even thought about. There's a lot of complex
problems under the hood for something that you just want to
work perfectly right as a end user.
You just think, oh, it's simple. It's just.
Just. Markdown, dude, it's just
markdown. Yeah, it's it's not like
streaming is just one of the features.
We have a bunch of more stuff. Is there any benefit do you
think, like building a markdown library in Elixir versus other
technologies or languages? There's another Elixir library,
I think it's called Med if not mistaken.
And it's a really nice idea because it's pretty much even
based, not even like process, but you know, more like a
functional design. So you can leverage this kind of
functional design in mixer. I, I wish I I wish I could read.
I wish I could write a parser, a pure Elixer parser for for MDXI.
Don't know, maybe someday, but what is the?
What's the most difficult part there?
Just finding the time to do it or are there limitations that
you know of? Markdown has many many edge
cases you have to like. The parsing is not easy.
You have to deal with a lot of complication.
Even though you have the specification like you have the
common mark specification, which is like 10-11 years old now
this, this specification, so it is, it is well established, but
there are many sometimes some, some parts of this
specification. You, you have to understand what
they mean. Like it's not strict
specification sometimes. And there are many edge cases
that you have to deal with. So if if you look at like if you
look at the correct source code, it's like really complex source
code. And the the Conrad author, I
think they, they used to work on the GitHub specification at
GitHub and now working at GitLab and GitLab is kind of sponsoring
the Conrad development. And Conrad is used to generate
all the Rus docs like like we have the hack stocks where else
has documentations and they use they use conrac so it's a well
well established parser. So there are some reasons to
create a pure Elixir parser, but it's not an easy task.
Yeah, I'm sure. Sounds like a lot of work.
Yeah, it it like Conrac. Conrac has a lot of contributors
now, so it's the only downside of using correct?
My opinion is really having like.
It's not a blocker, but it's a REST library so if you want to
use it you have to either download the pre compiled binary
or compile compile the REST code.
Right. Right, which is not a big deal,
but there might be some scenarios or environments where
that's not allowed. But otherwise it's fine.
The the roster pre compiled project is like amazing.
It's so a lot of you solve this problem of confining the roast
code. Man you can just have the pre
compiled binary. You also have to kind of like
pick and choose how you want to spend your time, right?
For an open source project that's not really making you any
money except for, you know, a few sponsorships, Do you really
want to build a whole parser from scratch or just leverage a
tool that already works really well, you know?
Yeah, like I have so many, I have so many ideas to do with
MDX and Lumis. The next one I'm going to work
is the Higgs parser, right? Right now we do have Higgs
support. You can write Higgs components
and mixer expressions inside the markdown, and it does generate
a. It compiles.
I forgot the name of that struct.
Nowadays struct that is used by live view, so you can just bring
their mark down side live view page like like if you had a hex
template. So you can have components and
expressions inside markdown. But there's a problem the when
you the way it works now, it just identifies the boundaries
like what is markdown, what is hex inside the markdown
document, and it keeps the Higgs part out of the markdown parser.
And then we do a second pass compilation of using the Higgs
compiler. So first it parse the markdown,
keep the Higgs like, does that change that part?
And then the second pass with the Higgs compiler.
The problem though is the inner content of those Higgs parts,
Higgs blocks. We need to parse that as
markdown as well. Because if you have markdown
inside the component, which is inside the markdown inside
another component, you know you can be nested.
We need to go down all the children and parse those small
pieces of markdown as well. So that's how other libraries
work like MDX, the JavaScript library and that that was the
main inspiration for MDEX. There's MDXJS.
They work this way if you have JavaScript inside components and
markdown as well. It can it, it does render the
markdown, it does parse the markdown inside components and
that's really hard to do. I'm working on the Rose code.
Make that happen on the current parser.
As I get that done, I can just use it on on the MDX.
And then finally I can say the Heeks support is like 100% done
and working. So we can have Mcdowie Felixer
for, you know, for Elixer projects.
Yeah, that's awesome and right. So right now Heeks isn't fully
supported or it is. It works, but if you have
markdown side the components it's going to be like just raw
text. So OK, I see.
Because what it does is all the text, you know all the
information inside the, you know the block is just hex.
And then when you send that to the hex compiler, if you have
like a title or a bold text or something like a markdown text,
the H compiler has no idea that's a markdown, right?
Then it's just reindeers as a a raw text.
I see. So that's that's the problem we
have right now. I'm trying to solve on the
correct side first the the worst Spicer and then I can use them
in the X. OK.
That's cool, yeah. So yeah, you never would think
the complicated under the hood problems you have.
And. Now everyone knows that listens
to this podcast. They know how hard creating a
markdown library is. Yeah, it's no easy task like and
that's why maybe I, I mean, again, I should be talking more
about those those problems because you know, it's really
fun to solve those problems, but it does take time and you know,
I could be sharing more about this those problems.
Yeah, yeah, I know it's good and I'm glad that you're on on the
podcast talking about it. And I just have to have you back
on more often to keep keep us updated on all your projects.
Yeah, that would be nice because like if I get the three seater,
you know loom is alone has a bunch of complex like 3 seater
Novi cleaning that we need to extract and now wasn't
compilation, you know bunch of bunch of stuff happening there.
So you can so you can just to have like nice colors.
The source code you know the the the output seems simple but the
out engineering for is the hard part.
Yeah, for sure. And for for MDX, you know, MDX
has other features as well, but the main, one of the main
concerns is also the performance.
We, we had this problem back in the day with Beacon because if
because we had to compile a bunch of pages at the same time,
right? So if you take like a second,
like a second to compile a page, compile, I mean from markdown to
HTML to live view. If you take a second or two or
whatever and you have like 100 or 1000 pages, performance
matters. And that was one of the reasons
I chose Korac as well because you know, on a benchmark it's
way, way faster than any other Elixir library.
And and Korac is not even the fastest implementation.
There are others way even more faster than than Korac, but
conrac is is fast is fastest, you know.
So what's the fastest? Like breaking down to like AC
language or something like that or getting.
Yeah, there is. I mean again there's there's the
I mean there is a pull down C mark, which I believe is faster
than Conrac, OK. There is also Med for C which is
marked down for C It's also really really fast.
But the problem is correct. It was the only one that had
extensions that I could support GitHub and like discord, flavor
markdown, GitLab as well. And the IT had extensions so I
could plug in a syntex highlighter and a bunch of other
stuff. So and since the outer used to
work. On the specification, the GitHub
specification and now working on the GitLab specification.
I mean, they, they, they really know how it works.
So they have hands on experience.
So it was the safest choice. And I was glad to yeah.
And I was glad to know they, the rest team chose correct to
generate the the documentation as well.
So there was like a, you know, prove the the chart that you
know, that was a good choice. Yeah, cool.
Well, but I, I really appreciate you coming on and talking about
MDXI think we can like slowly start to wrap this up, but we
have a pretty good question and I think both of us can answer.
It has nothing to do with what we were talking about, but I
feel like we've both been on this developer journey.
And so Desmond asks, how has the journey been transitioning from
a junior to mid, then senior dev?
Did you have mentors along the way?
And then how about like coding in multiple languages?
Oh yeah, that's a really. I mean, we could record a
podcast just. I know we really could.
We could I'll, I'll give it a stab.
I, I think one, it's really important to have mentors,
right? You need to work with people
that are smarter than you and, but also support you like
learning and kind of like trust in your ability to learn and
produce, right. And I would say if I were to
think back when I first started, I was a very junior developer.
I was mostly like an iOS developer dipping my toes into
like node JS and some back end API stuff.
And the second I kind of felt like I could build a full app,
right? I can do the front end app work
and the back end rest APII was really cocky and thought like I
knew everything. And I think like I talk about it
a lot on this podcast, but the Dunning Kruger curve.
I think juniors have a really good habit of once they feel
like they can build a whole app, you're at the top of mount
stupid, but you like you feel like you could like conquer the
world, right? And then you Start learning
about like security vulnerabilities.
Your app might have gotten hacked and yet you fall down
real quick and you're like humbled.
And then from that point on, I would say you start becoming mid
and you slowly are building your way up to a senior.
But you always know how much more you don't know the more you
learn, right? So I feel like you're always on
this chase to know it all and it's impossible.
You never will. Yeah, it's it's interesting
because when you are junior, you don't know much you so you can
you can not do much yet. And then you Start learning and
then you start producing a lot of code, a lot of stuff.
And then when you are the middle is like you are on the top of
the curve like over engineering everything, like writing a lot
of stuff. And then senior for me is when
you realize that you don't like cold is not the end goal like
coding is just, you know, part of the process.
And then removing code is actually better than adding
code, which is kind of the opposite when you're learning.
But there is this difference when you get into like more
senior position and it. Becomes the simplest solution as
the best solution, not the over engineered like.
I feel like there's a weird thing and among engineers, not
just software engineers, but you, you want to like flex, how
smart you are with a real complex solution.
And that's the last thing you want in your code base is a
complex solution. You want the simplest version of
that solution. Yeah.
And two more things. One about mentorship is it's
really, really good to have mentorship, but don't wait for
mentorship. You have to build something like
yeah, you don't need, you don't need permission to build
something. You can just build something,
publish like just you know, that's true for our concerns,
for mentorship. Don't wait.
Just go and build something. Yeah, like I was really
fortunate. Like I, I worked like, you know,
I like my first developer job. I just was like, you know, the
CEO liked me, he liked my drive and motivation.
So I kind of like luckily fell into that and had like a really
good mentor there. But at the same time, like if
you don't have that, say you don't have a dev job, but you
have a, an idea, build that. And then, you know, watch
podcasts like this, watch my tutorials, follow other people
building stuff in the Elixir community.
And those people become your mentors and you can learn from
them 'cause they, they'll post about either what they're
building, maybe a mistake that they made.
And like so you have it, you're just acquiring it a little
differently. Yeah, and don't be afraid to do
this stuff like 2019. I had a talk at Elixir Conf and
the talk start with a mistake I made like really, really hooky
mistake. I was trying to contribute just
a fix on the documentation on on their Airlink and I completely
messed up the geek, you know, the geek branches or whatever.
It was like a really rookie mistake and like it happens.
And that was part of my talk because I was trying to say,
hey, just go and do stuff and. You know, just.
Don't don't need to wait. And you know, some, sometimes
something bad happens, but it's, it's fine.
Yeah, I mean, it doesn't matter where you are on your career.
Like you can be a staff level engineer and you're still going
to run into things you've never seen before.
Yeah. I feel like what makes what what
levels up an engineer is the ability to solve a problem that
they've never seen before, you know?
Yeah, yeah, it's I feel like that now working with me was me
stuff like I I have been reading about was me for a long time,
but never use it. So now I I feel like a junior
working was me because that's new to me, right.
And that's, that's, that's fine. Yeah, I mean, I'm so like to go
on his like, what about coding in multiple languages?
I feel like the the basic principles of programming,
they're all the same. You're just changing syntax
essentially, right? I mean object oriented
programming versus functional and immutable obviously have
their differences but for the most part like writing a
programming language comes down to syntax and I context switch a
lot less. Now I write a lot of Elixir and
a little bit of JavaScript. I don't do a lot of other things
anymore, but when I was jumping between like Swift, JavaScript,
C#, an that was the at the beginning and like, I learned a
lot. I'm real thankful.
But it, it, it wears on you, but at the same time you just end up
like I like, I would like forget how to do like for loops in
languages, right? Because I was so I had like
Google syntax all the time. But like for the most part, like
the concept of programming is relatively the same between all
languages. You just will.
You just have to remember the syntax or like the language you
know. Understand the fundamentals and
you'll be fine. You can jump into another
language and you'll be fine. I guess for me the the hardest
like move was from Ruby and Rails to Elixir.
My first year or so working for Elixir I was still trying to
write like objects, like an instance and state and using
gene servers as a class. You know, that kind of, it was
a, it was a mess. Coming from an object oriented
programming language, like that's all I knew.
And then I came to Elixir. It was hard.
It's hard to change your mindset.
Yeah. But also it once it clicks, it
makes it's it's way easier I think.
I believe like I have a feeling that Elixir is way easier than
other languages, but you have first the functional program has
clicked on your mind first and then I.
Just if you started with it, that's how your brain works
solving problems naturally, right?
Like you kind of transform a thing and pass it along.
But once you have objects oriented cloud in your brain,
it's hard to go back to that and relearn that that way of.
Thinking yeah, but if you start with functional programming you
have to learn Ruby shack oriented program as well because
you become a better better engineer when you understand
both they are. Completely.
They're not. It's not an alternative to 1 to
the. No, you can.
You can learn from both and use both.
I agree depend on the language but the concept.
The idea is you have you need to move.
Yeah, well, like just the idea. Well, when you're in the object
oriented world, you have a lot more architectural patterns,
right? And you know, you learn about
like singletons and you can pass state around and objects and you
know it has its superpowers, but it also leads to a lot of really
hard traceable bugs. Yeah, that that's one thing with
functional programming, at least for me, it leads to a simple
code way more than object program, Yeah.
It sets you up to write clean code.
Yeah. And think of not in the sense of
like the clean organization style, like I mean clean coding,
like writing less. Code like the simplest.
Yeah, the less code. Simplest.
Yeah. Simplest approach to a solution,
right? Yeah, and I'm not.
Yeah, that reminds me of another stuff like when I was every time
I tried to contribute something, I tried to learn from the
maintainer. And you can learn from people
like Joseph Alim, Charisma Card and others.
They have like a really good approach about, you know,
thinking design and, you know, realizing what is needed and
what is not needed, which is probably more important.
And then you can learn. And I see that, you know those
guys, they try to make the most simple solution and the most
effective one, which is really, really hard, but you can learn.
Yeah, I think it's harder to know what solutions shouldn't
even be brought into a conversation to like, you know,
how many features get thrown at any kind of like open source
project or language or anything, honestly, even like even if
you're building a SAS product, right, you know how many feature
requests you're going to get and the ability to know what
strengthens your product versus what, doesn't it?
I think that's the probably the hardest piece.
Yeah, the the balance of, you know, the amount of code you
need to write to support new features because the code has to
be flexible enough to grow and support new features, but not
over complex. So this balance is really,
really hard to get. You know, you have to write just
the minimum amount of code that is flexible, scarce enough to
continue. But that's really hard to do
that. I don't know if there's formal
education on that, but at least for me that was like like years
of experience, making mistakes, really time.
In the saddle, making mistakes and learning from them.
Like I I think my most like leveling up events in my life
were really bad mistakes. Yeah, you, you can learn from
manufacturing. Or hearing about other people's
mistakes, like I just had Thomas from level all on and you know,
staff level engineer, like super smart guy and they just had like
a rate limiting issue with Oauth and like so all their users
couldn't use their platform all of a sudden.
And it's like one of those things where you don't think
about and like they, they have like a school system platform,
right? A learning platform.
And all the students from a school district were on the same
IP address. And so they, they hit a problem
that they never knew they had because they were hitting a rate
limit on authentication. And that's just like things like
that. Yeah, that's another way to
learn is exposure to real world situations like, and you know,
if you're a junior, you're not going to have so much exposure,
but you can like other people do and you can learn from them.
And then you grow, you keep going.
And as you get more exposure and that's where you you learn.
So more conversations and like meetups are really important.
Go meet people, talk about your projects, talk about your
problems. And you know 9 times out of 10
someone else in that room that's listening already have the same
problem you're experiencing and they can tell you how they
solved it. Yeah, we have a really good
elixir Metap nearby in Toronto and they, you know, we have
metaps, I don't know, twice a year, maybe not.
It's not so frequent, but every time it's, you know, packing
with a lot of people and really good talks.
It's another way that you can, you know, you can, you can also
share like you can give a talk in the meet up if you, you know,
if you feel like it's another way to, I feel it's like another
way to learn as well is sharing about what you know, sharing
about your experience. So yeah, there are many ways to
grow in the career, but yeah, it's a very long.
Talk. Yeah, you just got to keep doing
it, keep showing up every day, right?
And then eventually, before you know it, you're like, wow, I've
learned a lot and I still don't know a lot.
And you just kind of have to accept that.
And then you just. That's it.
Yeah, it yeah. It's impossible to know
everything. If someone says he knows
everything, he's lying because it's impossible.
I'm going to tell you where he is right now.
He's on the top of the Dunning Crew Kruger curve if someone
claims to know it all. Yeah, yeah.
We are always learning. For sure.
Absolutely. All right, Leandro, thank you so
much for joining me. This was a fun conversation as
always. And yeah, anytime you want to
come back on, just please reach out.
Yeah, thank you for having me. Thanks to everyone for tuning in
and listening, I appreciate it and hope you guys have a good
weekend testing.