EW S5E2                Transcript
EPISODE S5E2


[EPISODE]


[00:00:07] EO: All right. We are recording. Here we go.


[00:00:10] RT: — And that’s actually the secret of the universe. The funny thing about relativistic physics is if you had actually done that equation, we would’ve already had transluminal travel. So, you guys were recording that right?


[00:00:20] JE: Welcome to Elixir Wizards, a podcast brought to you by SmartLogic, a custom web and mobile development shop based in Baltimore. My name is Justus Eapen and I’ll be your host. I am joined by my sensational co-host, Sundi Myint, and our enigmatic producer, Eric Oestrich.


This season's theme is adopting Elixir. Today, we're joined by none other than the Founder of Thunderbolt Labs, Randall Thomas. How are you, Randall?


[00:00:47] RT: Another day in paradise, sir. Happy to be here.


[00:00:49] JE: Do you like that segue from whatever you were just talking about, to the intro of the show?


[00:00:53] RT: Yeah, I really do. I actually like that you didn't miss a single beat. Smooth.


[00:00:58] JE: Well, I was actually leaving something out, because I wanted to ask where your — we have here where you're maybe from, but I’m curious where you're recording from, where you're calling in from.


[00:01:08] RT: Oh, Miami, Florida.


[00:01:09] JE: Miami. Nice.


[00:01:10] RT: Home of great healthcare central. Just want to know.


[00:01:13] JE: Great healthcare central.


[00:01:14] RT: We’re number one, or we were for a while, at least for COVID response.


[00:01:18] JE: Okay. Very cool. Well, I am personally someone who loves Florida and the weather down there. And the people down there. I go down all the time, actually, to Miami, Fort Lauderdale area. Next time I’m down there, I’ll come and say hello.


[00:01:29] RT: Yeah. Next time now, we can mask up and go out.


[00:01:31] JE: Yeah, that sounds great actually. And Sundi, Eric, how are you all doing?


[00:01:36] SM: We are great. Well, I’m great. Eric, how are you?


[00:01:40] EO: Doing great.


[00:01:42] JE: Rock and roll. Welcome to season five. This is our first normal interview of the season and we're very, very excited to have a new season underway. We want to open up with some basic personal background questions for you, get to know you a little bit, Randall. Tell us how you got into programming initially. Were you formally trained? Did you teach yourself?


[00:02:03] RT: It was an accident. I was very lucky to attend — basically, okay, everybody has those short buses that take the smart kids off to some program. They export the smart kids out of the school. I was lucky enough to be in one of those programs and we actually had robotics. Our robotics program ran eight hours a day during the summer, year-long.


Basically, by the time I was a junior, I basically spent literally all day in a robotics research laboratory. Then, our robotics program actually started an hour and a half, I was so nerdy, I showed up to school an hour and a half early to get a double period of robotics in. I literally had no intention of doing this. I just thought it was cool. We started playing around with stuff like C, robotic end effectors, embedded systems — all while I was in high school.


The accident for me was my mentor at the robotics program suggested that, when I was looking for a day job, like for a summer job when one time he's like, “Well, I know some people over at NASA. Why don't you go ask there?” I’m like, “Because it's NASA.” He's like, “It pays 15 bucks an hour.” I’m like, “I’m going. Okay.” 


Which, for a kid, making 15 bucks an hour, it was the most amazing thing ever. I sat around in an air-conditioned laboratory playing with stuff that I would have played with for free and they paid me money. I’m like, “Hey, this engineering thing. Wow. Kinda cool. Neat.” By the way, this was at a time when hardware was really expensive. A computer was super expensive. I think my first 386 at 16 megahertz, I think it was $1,800 in 1990s money. It had just under a megabyte of RAM.


So I was getting free hardware from the stuff that we burned out of the lab, like SIMs, DIMs. This was just everything. Then after that, I just fell into it. I never left. I don't know. Growing up as a kid, I think I wanted to be a lawyer. I don't think I ever said, “Ooh, I’m going to be an engineer.” That's where I started and then I went on to study electrical and computer engineering in college.


[00:03:58] JE: What was your first job in programming?


[00:04:01] RT: My first paid job in programming was actually that gig at NASA. I was lucky, because we already had computers around the house. My dad was an electrical engineer, so he was a computer hobbyist. We had an Atari 800, 64K back when you had to type in all the programs in Basic by yourself. You'd spend a week typing in basic commands and then you'd save it to a cassette tape. That's not bullshit, that you actually would save data to an audio cassette tape. You're looking at me like I’m making this up, but this is —


[00:04:32] JE: No, I believe you. It's just hard to imagine.


[00:04:35] RT: To fathom? Yes.


[00:04:37] JE: Yeah. I grew up in the 90s, so —


[00:04:42] SM: I actually have a similar — like, my dad's also an electrical engineer. He built my first computer. I only recently thought about that era early 90s and being like, “Wait, how was it that we had a computer? That wasn't normal. My friends didn't have computers.” He was like, “Oh, I just built one. I built you one.” I was like, “Oh, okay. I guess that was a normal thing for you, but none of my friends had that.”


[00:05:06] RT: It's really funny. I actually think that I was really fortunate to get into computing when I did, because in the 90s, you had no choice. I’m telling you, the drivers were to get Wing Commander running on your 386. You actually had to go in and set memory maps and high memsys and EMM386sys, if anybody's old enough to remember. You literally had to tell it where in memory to put things. Like, your sound blaster card and which interrupt request on the hardware that your sound blaster card would actually otherwise talk on.


There were no abstractions. You had to actually know how a computer worked to get it to work in the first place. Between that and actually noticing that you could make some money writing code, that's how I kinda got sucked in.


[00:05:50] JE: Do you think that that has helped you a lot in your career, especially now when you're so much further away from the metal, so to speak?


[00:05:57] RT: Yes. It absolutely has, because have you heard that joke? It's turtles all the way down.


[00:06:04] JE: Oh, yeah. I did a whole interview on that last season.


[00:06:06] RT: Did you really? Oh, man. I am —


[00:06:07] JE: Miki Rezentes. I’d love to refer that. Which — is that originally from Gödel, Escher, Bach?


[00:06:15] RT: It's really funny. It might very well be and I don't know if that's truly a – it's an apocryphal story, or if it's true. Apparently, wasn't it Stephen Hawking, that “Very clever young man, but it's turtles all the way down.” He was trying to describe the nature of the universe, or some particular thing which was bound by physics. I think that was the story.


[00:06:31] JE: You know what? I want to say we looked this up and discovered it's actually an ancient, maybe Buddhist saying. Where's my Jamie? Maybe look that up. No, I’m just kidding. That's a reference to my producer, Eric.


[00:06:41] RT: No, it's like, the abstraction does matter. What it's done is it always gives me an appreciation for that all resources are finite. I started off my first machines were — the stuff first off I was programming on, we literally had 32K of RAM and 32K of ROM. And that was for text code, data, everything. We had hand-optimized assembler on 8051s. The compilers couldn't be trusted to optimize it away, so we would literally go and look at the assembler that was produced, read it, and do things like, “No. We know that this clock cycle is actually two clock cycles, so we can remove this node up here and move the assembler one line up.” Because literally, it was we could tell it how to count the number of cycles for instructions for registers.


[00:07:22] JE: Wow. I’m getting knowledge envy right now. Indeed, Eric is a terrific producer. And the turtles all the way down quote has been incorrectly attributed to folks as far back as William James and Bertrand Russell. But the earliest allusions in print to this mythological story could be found in the 17th and 18th centuries, as far back as 18 — 


Well, okay. The first publication of turtles all the way down is attributed to Joseph Berg in 1854. Yeah, this definitely goes a long way back. It's a philosophical notion, just as much as a — I mean, recursion is a philosophical concept, as much as we think of it as a consputer. 


[00:07:58] EO: What is that? 


[00:07:59] JE: A computer specific thing.


[00:08:01] SM: I thought you were trying to say conspiracy theory.


[00:08:04] RT: So did I, actually, I’m like, recursion is —


[00:08:06] SM: Recursion is a conspiracy theory?


[00:08:07] RT: A conspiracy.


[00:08:08] JE: Oh, that's so out.


[00:08:10] RT: Actually, you know what? Recursion could be a conspiracy theory, because it has many of the properties. It's self-referential. It can't be optimized away and it's very easy to blow the stack, if you're not sure what you're doing.


[00:08:20] JE: I think we might have just landed on something here. We can call it a day. This has been a great interview. Thank you. Now leapfrog forward in time a little bit, just like a good conspiracy theory, there should be a lot of time travel. Where did you first learn about Elixir and how did you get into the Elixir community?


[00:08:39] RT: There are two parts about Elixir. One was if you remember maybe in the, I don't know, maybe 2008-2009 maybe, there was this thing called RubyMotion. And everybody was really excited in the Ruby community about being able to build iOS apps using Ruby. Because Objective-C, if you've ever written it, Objective-C looks so bizarre to your standard Ruby programmer, that they say no to Objective-C based on principle of where they put the square brackets.


I want to say, I think it was at BaRuCo, Barcelona Ruby Conference, we were actually giving a talk on RubyMotion. I remember having a conversation with José and he's like, “No, no, no. I’m going to get Rubyist working on this language, Elixir.” I’m not even sure he called it Elixir then, but like, “I have this idea that we could get it running on the Erlang ecosystem.”


Having tried to learn Erlang and failed miserably — I think everybody does their first time. I bought the prog book and thought that I was going to go write me some Erlang and it did not happen. “Why is there a modulus operator opening this entire thing? I don't understand. Where are these curly braces everywhere and why are their arrows just randomly inserted in places?” I was like, I abandoned that entire attempt. What I remember thinking to myself is there's no way you're going to — ever going to be able to get Rubyists to go into the Erlang ecosystem.


Flash forward a couple years and a lot of smart Rubyists, I was talking to them and I’m like, “I haven't seen you for a while. What have you been doing?” It's like, “Oh, I’ve been doing this Elixir thing.” — “Elixir. Okay. I don't know. What have you been doing?” — “Oh, we don't build Rails apps anymore. We’re building this thing on this thing called Phoenix.”


All these people who are way smarter than me started talking about Elixir and Erlang. I looked into it and I’m like, “Wow, there's a lot here.” I fell down the hole. I did Dave Thomas's book in a weekend and I’m like, “This is amazing. This is really good.” That was it. It would have been about 2018, I think. 2017-2018.


[00:10:33] JE: Really? Do you remember your first ElixirConf?


[00:10:37] RT: Yeah, 2019. I was really lucky in that at the behest of a couple of different people saying, “Hey, you should submit a talk to ElixirConf.” I got to talk, accepted to ElixirConf about how much of a struggle it was for me to learn Elixir and learning Elixir was my first talk at Elixir.


It's really a weird thing, if you've been in procedural languages for so long to try and pick up the way Elixir thinks about things. Strangely, one of the connections was Bruce Tate. Bruce was the one who suggested I should give a talk. It was because myself and Patrick had signed up to do a programming class with Bruce, only two people showed up and he's like, “Ah, I think I should cancel it.” We're like, “No, no, no. We're willing to travel and go do this.”


We basically sat around for three days, or two and a half days doing nothing but programming with Bruce Tate. I always say like, I didn't really know Erlang or Elixir before I got a chance to spend two days programming with Bruce.


[00:11:34] SM: Wow, that's another thing we have in common, because that was my real big intro. I mean, I was programming Elixir for about two months before I took a training with Bruce. I similarly sat down in a room with him for a day and walked out of it like, “I understand.”


[00:11:50] RT: Yeah. That was the idea that really bridged my conceptual gap, because what I didn't realize before taking that class with Bruce — shameless plug for Bruce and Groxio, some of the best Elixir training out there. I realized what I was doing is, I was actually writing Ruby apps in Elixir, which I think is what a lot of people who have a Ruby background. I mean, I don't know. Have you guys noticed that when you have a Ruby background, that it's difficult to stop writing Ruby and start writing Elixir?


[00:12:17] JE: I will admit. When I first started writing Elixir, when I joined SmartLogic, probably in 2016, 2017, I remember there being quite a learning curve. And just pattern matching being the concept that, when it clicked, I became productive. Then I remember coming back to continue writing on Ruby apps that I had been developing, that to me was the bigger —


[00:12:38] RT: Oh, interesting. Was it hard to go back?


[00:12:41] JE: It was hard to go back initially. Then, I later was struck by how many of the features in Ruby I really like and how nice it looks. I had a secondary resurgence of appreciation for Ruby, which I don't think many people talk about very often.


[00:12:59] SM: I only had a brief stint with Ruby, so I didn't come into Elixir knowing Ruby beforehand, truly. Because I came from JavaScript and then learning Ruby was just such a 180 for me. Having learned Elixir, I feel I could probably go back and understand Ruby better. I don't know why. Maybe it's just having another language under my belt, but I just feel a little more confident that I could pick it up this time.


[00:13:26] RT: It's super interesting, because I actually think there are certain languages, I have no scientific evidence to back this up, but my pithy summary is I’m a shitty Haskell programmer. As a shitty Haskell programmer, it makes me a much better everything else programmer.


[00:13:39] JE: As opposed to not being a Haskell programmer at all?


[00:13:41] RT: Yeah, exactly. I mean, I hate to say it, but after all these years, the Haskell guys were right, because Haskell forces you to think about computation in a very different way. I think it's the same way that if you ever pick up Racket, or Scheme, or Lisp, or any new language. There are two ways to go about it. There are certain languages which lend themselves to not learning a new way of thinking.


For instance, if you're a C++ person, you can pretty much go to Java, or even more importantly, C#, Java. In fact, if you've written C# and Java, I think this has happened to everybody, at one point, you're about halfway through a class file, until you realize when some system call comes up that you're not actually reading Java. Or the way that you import something as your first indication that it's not a Java file, it's C#, because the languages look so similar. It's like, okay —


[00:14:27] EO: That or the method names are capitalized.


[00:14:29] RT: Yeah, exactly. It's almost like the snake casing, or camel casing is your first indication you're not in Kansas. It really doesn't challenge you to think about how you build a program differently.


One of the things which I find very inviting about Elixir is Elixir doesn't force you to build your programs differently. You can actually build some very poorly structured programs in Elixir that will work perfectly fine. It does not beat you over the head and say, “You know what? I’m not going to run. I’m not going to work, unless you actually do this and fix all these problems.” Elixir is pretty forgiving. Good when compared to Haskell. Haskell is like, “You will.”


[00:15:07] JE: This is an excellent segue, because the very — before we started recording, you mentioned something that you've got to grind, an ax to grind with the myth of the polyglot programmer. Now I feel like at this point in the conversation, you firmly established yourself as a polyglot programmer, thus proving that it's not a myth. Go on.


[00:15:26] RT: Wait. No, okay. Here's the thing. I think all programmers are polyglots, because — so let's think of all the things that you have to do before you can even get to writing a line of code. Bash, or ZSH, or phish. Are you on Linux, Unix, or Windows? Do you have a package manager? Are you using ASDF, chocolaty? What are you doing? Did you get the right version of SSL to match the libs that are currently being compiled? Are you sure? Did you export which lib open SSL? Is that actually in your environment? Okay, good. Now, we've got that. Emacs, Vim, Ruby Mine. Visual studio code?


[00:16:04] JE: It’s Vim.


[00:16:06] RT: I mean, of course it is. I understand that you haven't quite evolved to Emacs, but there are lots of you.


[00:16:11] JE: Someone told us you were a VIM guy. Was it you, Sundi, that mentioned — that you thought he was a Vim guy?


[00:16:17] SM: I said that in our class, we had a Vim user and an Emacs user. It made it, for my wanting to use emojis during our code, made it a little difficult.


[00:16:29] RT: It did. Emacs didn't have some emoji support in there for a little bit. Eric S. Raymond, represent. Anyway. No, so what I’m saying by that is we are all polyglot programmers. Perfect example, if you build a web app, okay, I will tell you right now, I think I’ve been using Babel for six years and I still have no idea what the hell my Babel configs are really doing.


[00:16:51] EO: I 100% agree with that.


[00:16:53] RT: Right. Exactly. In reality, what I do is something breaks, I Google answers, I read two competing answers on either Stack Overflow or Medium, where one says, “No, no, no. You need ES6 short line in-lining functions.” —“No, no, no. You need optional ES6 non-inlining, but short line functions.” What? Okay. Try them both. See which one actually complains less and go about your daily. That's just the way it is.


There is no such thing as a homogeneous system anymore. It's not like you can just write some C and compile it. There's so many different tools that you're already building a tool stack. I think the idea of polyglot programming is really just what programmers do intuitively. We're trying to — what you're really trying to say is how far down the stack can you really understand? How many of these things are you proficient with? It's really hard for me to think of being proficient in more than about two languages at any given point in time.


I haven't written Ruby in so long, that if I were to go back to a Ruby project right now, I seriously doubt I would recognize a Rails 5 project. I’d still be thinking in Phoenix. I’d be like, “Oh, crap. No ecto. Okay, how do we do a partial? How do I do an order by? How does that work?”


Human brains being finite, I think developers have this idea that they should know Go and Java and JavaScript and CSS and pick your flavor of CSS. SCSS, or Tailwind, or whatever, and that they should know all that and be proficient with all of it. I think the polyglot programmer myth drives people to think that that's actually possible and it's something to strive for. Versus, I think it's much more useful and much more utilitarian to be like, “Yeah, I know enough about CSS in the underlying meta problem what CSS does and it will only take me a couple weeks to pick up Tailwind, or it'll only take me a couple weeks to pick up the new version of bootstrap. Or, it'll only take me a couple weeks to get back to being proficient in something.”


[00:18:47] JE: Do you use Tailwind?


[00:18:48] RT: No, I haven't yet. I’ve just started using Tailwind, mostly because I'm one of those late followers until somebody can write a blog post to tell me everything — exactly how to solve all my problems, I don't want to do it. I’m lazy. I’ve been using bootstrap for — I found zero reason not to use bootstrap forever, because any problem I have with bootstrap, I can Google it and I can find six answers that are probably right.


[00:19:08] JE: Totally right.


[00:19:10] SM: Very practical.


[00:19:10] JE: I’ve heard so many good things about Tailwind. I suspect one of these days, someone at SmartLogic is going to start making us use Tailwind. That's going to happen.


[00:19:19] SM: I thought we already were using it. I guess it's just made up in my head.


[00:19:24] JE: I’ve definitely heard it mentioned a few times. We've got a really head of the curve designer over here, who probably is using it. So Randall, I’ve got some more questions about your early days using Elixir, but I want you to tell us a little bit about Thunderbolt too, because I’m curious about — I mean, the theme of this season is adopting Elixir. I want to know how your personal adoption curve and you've been the founder of Thunderbolt for a lot longer than you've been using Elixir, right? Can you tell us a little bit about Thunderbolt and the intersection there?


[00:19:54] RT: Sure. Thunderbolt was originally started off after I left a Ruby company called Engine Yard. Specifically, we were focused on doing Ruby on Rails solutions. We've always been pragmatic engineers. Essentially, what we were was contract product development for companies throughout Silicon Valley. We would ghostwrite products for people. If either their product team was failing, or their product team was not up to snuff, we would come in and help shadow-pair, do hiring, training, mentoring, or in some cases, firing.


For us, it was always about being effective and being efficient. We went through, I think three phases. One was our big Ruby phase and then we did some mobile apps and iOS. We actually did some RubyMotion. Then later, we did a lot of JavaScript, everything from Angular to all the versions of React.


My favorite thing was, of course, getting a new point release of React and rewriting everything from scratch, because that's what you had to do. Or, my personal favorite was also, finding out that Angular versus Angular 2 was not the same thing. Strangely enough, the move to Elixir came out of frustration with the JavaScript ecosystem. I will admit to being a downer on JavaScript. When your language has JavaScript, the good parts, and that's Douglas Crockford, I like to make fun of JavaScript in Node, not because — well, it is easy, but it also keeps us all humble, but there for the grace of God go away.


If you remember early on in the Ruby community, we almost ended up with the same problems that NPM had. Yehuda Katz and a bunch of other people put a lot of work into bundler and trying to fix the package management problem. Like, Ruby had terrible package management early on.


[00:21:38] JE: This is something I almost mentioned when you were talking about Babel earlier, which is why is Ruby and the community around Ruby — you also said, sometimes you'll go look something up and they'll have all these competing ways of doing things, but that doesn't really happen in the Ruby world. Ruby world seems to converge at one preferred way of doing things.


I know that people say, “Oh, it's a Rails thing and Rails conventions. Blah, blah, blah, blah, blah.” It's actually a really strong cultural thing and I’m really curious, how do they do that? It doesn't exist in the Elixir world, for sure.


[00:22:07] RT: That's an interesting question. That's a great question. I don't know. What's interesting to me is, I think, the reason languages feel different. Like, C++ feels different than C, which feels different than Ruby, which feels different than Java. I think a lot of the reason languages feel different has to do with the communities around them. I think the Ruby community actually had a big thing about competition, but consensus.


If you remember the great, “Hey, back in at ‘07, ‘05, we had the Great Merb. We had the Great Merb Schism. Back in the day before rails 3.0 came out, we actually might have to do with the Merb versus Rails.” Do you remember this?


[00:22:48] JE: Yeah. I do remember that. At the same time, it didn't actually happen, right?


[00:22:54] RT: Yeah, but —


[00:22:55] JE: How many Merb apps are out there? 10. This is when people say they use Elm. It's like, no. You used Elm.


[00:23:04] RT: There's a certain truth to that. Well, see, the nice part is actually, that's a different thing. I used Elm as a gateway to Haskell, because it's like, Elm is the thing where they wake up from a dream and it's like, “And it was Haskell the entire time.”


I think the Ruby community had a great job of letting a whole bunch of possible solutions go out. Remember at one point in time, we had Pumas, Thin, god, Passenger, Straight Engine X with Byprocs. These were all ways of running your Ruby app, remember?


Then finally, we had said, okay, some of these need to go away. Which one's the best? So we pick one or two. If you also, you remember they were for a long time before we just had raw rack apps, there were Sinatra, there were a bunch of micro-frameworks out there. Full disclosure, Sinatra was written by a friend of mine, Blake. Blake Mizerany. He wrote it, so I’m not going to be unbiased. — 


The one thing I like about the Ruby community is that they have no shortage of solutions that people can put forth. And they will always evaluate them in the context of “How well does it solve the problem?” It seems to solve the problem well, that's what spurs the adoption. I think that's one of the things that's really high quality there. Versus in some languages, especially ones that have much more of a corporate backing, oftentimes, the most sane solution, or the best solution doesn't win.


[00:24:20] JE: I agree 100% that Ruby has this — it's almost like an idiomatic blackhole type of scenario, where the best solution has gravitational pull. Then you're absolutely right with Java, and like corporate backing, leading to bad patterns. Then there's JavaScript, where you just get all the solutions and there doesn't seem to be a preferred way of doing things and nobody's willing to take a stand and be like, “You know what's better?” What are the options now? Yarn versus NPM versus Bower or something?


Nobody was willing to say it, until it's so clear. No one was willing — even now, I think people are not really willing to say, “Oh, React is better than Amber, or Angular 2, or whatever are the options.” Although, everybody knows React is the better option.


[00:25:02] RT: I’m sorry, React what? React 16 with Hooks, or React 15? Or are you using React with Cycle.JS?


[00:25:08] JE: Excuse me. We got to take a break. I need to breathe.


[00:25:10] RT: I totally got into this fight with a JavaScript person. And every language has its good parts and bad parts. There is no ecosystem that doesn't. And probably, Sundi's the only person who's qualified to talk, really talk about JavaScript, because I’m sure she's written more of it than all of us put together.


The thing that I said is, he's like, “Oh, I love writing JavaScript.” I’m like, “You don't write JavaScript.” He's like, “What do you mean?” I’m like, “Nobody has written JavaScript in 10 years, because you have a Babel.rc. Are you using ES6 really? Great. Are you using ES6 with Bode? Are you using — which version of Node? 8, 10, 12, 12LTS, whatever, all these versions of node that are out there that actually have slightly different conventions and slightly different optimizations?” None of us actually write JavaScript anymore. Are you using —


[00:25:57] SM: — We actually did yesterday. We did.


[00:25:59] RT: Raw JavaScript?


[00:26:01] SM: We were in accessibility training and we were trying to write some raw HTML and JavaScript to get some accessible tabs going on.


[00:26:09] RT: How was that?


[00:26:11] SM: We couldn't quite get there. Not in the time allotted.


[00:26:17] RT: This is like a programmer version of hell. It’s clear.


[00:26:20] JE: Regular Java. Yeah


[00:26:22] RT: “Before you is a bomb. It will go off in 24 hours. All you need to diffuse it is to write plain JavaScript to otherwise, disconnect the red wire and leave the green wire intact.” 
“We should use promises.” — “We can’t.” — “We should use an arrow function.” — “We don't know.” — “Underscore has something that'll do this.” — “We can't use underscore.”


[00:26:43] JE: It’s a nightmare.


[00:26:44] RT: “Oh, my God. This won't work. Why? This isn't Chrome. We have no idea what's going to happen now.”


[00:26:49] EO: Are we allowed jQuery in this world?


[00:26:50] RT: Exactly. See. Can we use jQuery? That's the thing about the JavaScript ecosystem, which drives me nuts is that JavaScript has ubiquity on its side; quantity, has a quality all its own. But, man, there are just some things that remind me of JavaScript. When I see it sometimes, it reminds me of VBScript, like in the early days of the web. Does anybody remember Internet Explorer used to run VBScript and there were these websites that were vbscript only? Oh, good God. Never mind. I’m old. Never mind.


[00:27:21] SM: — You have some interesting points though, about JavaScript. It's just like, we all know, it's the necessary evil. Then for the programmers who feel very particular, especially me, who, when I saw Elixir, I thought it was the greatest gift in comparison to having to write JavaScript. I’m curious as to, when you've confronted, maybe you've had to teach a developer and they didn't — were they always excited to learn Elixir? Have you ever come across clients who were like, “We don't know this language. Why are you going to build us an application in Elixir?” I’m curious about that.


[00:27:54] RT: Yeah. Oh, you mean, seeing as, I guess we should probably get the theme. One of the things I’ve been doing for the past years, I’ve been the CTO as a technology incubator. It's kinda stealthy. Basically, we're too lazy to put up anything about it. 


[00:28:09] JE: — Isn't that what stealth is?


[00:28:10] RT: — Yes, exactly. Right. Nobody knows.


[00:28:12] JE: “The plane is invisible, if you haven't built it yet.”


[00:28:15] RT: — “But the budget's intact. All 62 billion dollars for our stealth plane.” No, so we actually ended up using a lot of stuff in Elixir doing COVID response. Part of it I find, of the attraction of Elixir is that Elixir for good, or strong developers. I know that's going to be a very loaded word. Well, what's a good developer, or a strong developer? I don't know. For certain developers, you give them a tool like Elixir and they are just wildly more productive. It doesn't work for everybody. I don't think everybody grocks it.


There are definitely teams of developers that if I were to look at the team and evaluate the team, I’d be like, “Yeah, C# is great for you guys. C# it is. Let's go guys.” Or Java. “Yeah, we should definitely stay on Groovy. Grails is a great choice.” But for the devs who wear clicks, you can get so much done with a small team.


We were able to rewrite and short using Broadway. We were able to prototype a data import process. It was having a lot of problems. They were able to get it down to running once every couple hours. We were able to get literally, hundreds of thousands, or millions of records processed in about 90 seconds, by just rewriting it using Broadway and Elixir and then doing some baseline optimizations and looking at the way that Elixir allows us to scale out in parallel for things.


[00:29:32] JE: For anyone that's new to the ecosystem, could you tell us what Broadway is?


[00:29:35] RT: Yeah. Broadway is a — you can think of it as a way to create, easily, data flow pipelines that are inherently parallel. It's basically, it's MapReduce, but it's one of the ways you can do MapReduce inside of Elixir, from an Elixir application.


[00:29:49] JE: I wanted to take us back a little bit. That's a good answer. I want to take us a little bit back to when you're telling us about when you found Elixir. Can you talk about your very first Elixir project as an individual, if it was at Thunderbolt, if it was paid, tell us about the paid one.


[00:30:05] RT: The first couple projects, we actually did not do paid. What we did is we had the paying work and what we would do then is we would rewrite portions of it in Elixir on the side to see what it would look like.” 


[00:30:17] JE: — Brilliant. 


[00:30:17] RT: — Because, pragmatically, it wasn't worth the risk. I was like, “Oh, maybe there's something there.” And what we found was that the Elixir versions, from a maintainability perspective and from a readability perspective and a compact code perspective, I was blown away with how expressive Elixir is.


You can do so much in so little. Perfect example is, I can't imagine language without pattern matching now. I went back to trying to write Ruby without pattern matching, you're like, “Oh, God. What do I have to do here?”


[00:30:46] SM: Hands tied behind your back.


[00:30:48] RT: Yeah. And a perfect example, multi-head functions. “What do you mean I can't just pass you the same functions and you'll match on the argument? You figure it out. Don't make me figure it out.” 


The other thing that actually — oh, that's another thing. The error messages. The error messages in Elixir, I love. I just love the fact that Elixir has so many error messages. What we did is we rewrote a bunch of stuff that we were already working on and we just found that we liked the Elixir versions better.


[00:31:14] SM: Did you ever take that back to the clients and be like, “Look, we took a look at this and this is going to work for us better.”


[00:31:21] RT: Almost never. Here's the reason why. Unless we put the client on Elixir from the get-go, we always found it was really difficult if we weren't going to be the ones to maintain it. Partially, for two reasons. One, early on, if you remember 2018-ish, there weren't a lot of great resources on getting up and started with Elixir. I still think that getting up and started with Elixir can be really challenging.


[00:31:42] JE: It is.


[00:31:43] RT: I mean, if you want to tell somebody how to write a Rails app, there are so many to do — or even better yet, the actual, the ubiquitous JavaScript to do app. The one place that I will give the JavaScript community full props is that they have accessibility and getting new people onto JavaScript, writing JavaScript apps, easy down pat. Between serverless, pick your framework. It doesn't matter.


You can write a to-do app in 15 minutes in any JavaScript framework out there and it makes that user feel empowered and therefore, it gives them an early incentive to actually stick with learning it. Elixir can feel really — hostile isn't the right word, just challenging to get into.


[00:32:22] SM: I feel I had the opposite reaction. I feel when you have so many frameworks that you can — if you were like, “I want to write a to-do app in the next 15 minutes” — and you didn't know much, except for doing it with JavaScript, I’ve often run into the situation where I look at all the options and I try three of them. One of them doesn't work, the second one doesn't work, the third one, okay, I’m tired of troubleshooting and I just give up.


With Elixir, I was able to spin up a project in one line of code, or a terminal code and I was just going and I never had a problem with that. I actually liked the lack of things available to me to try, because it helped me focus.


[00:33:01] RT: That's as sturdy as a feature. It's not a bad perspective. I think it's also different though for professional software developers and professional teams, versus — there's a bridge between hobbyists. Let's face it. Most software that's written actually isn't written professionally, right?


[00:33:18] JE: Right. That's exactly what I was going to say is that Sundi's an experienced programmer who knows a lot of practices etc., that you could translate from one experience to another. For someone who's new to programming, or just out of school to not have a variety — well, this actually goes back to what we're talking about Ruby, with the idiomatic convergence, with this idea that we're going to find the best solution to make that the norm. And then explore it from many angles. That's different from JavaScript world, where you've got a billion different to-do lists, all made with different patterns and none of them are asserting that they're better for any real good reason.


[00:33:56] RT: Here's the other thing, which people, I think oftentimes don't acknowledge seeing as, I don't want this to turn to ragging on JavaScript. It's turning into —


[00:34:03] JE: It’s okay, ragging on JavaScript is what we do here.


[00:34:06] RT: — Here's the thing, right? Who made React?


[00:34:08] JE: Facebook, right?


[00:34:09] RT: Right. Who made Angular?


[00:34:11] JE: Google.


[00:34:12] RT: Right. Those frameworks were designed for their use cases in mind. And I think, one of the things that people always mistake is that, literally, what makes sense for Facebook does not necessarily make sense for your three-person team trying to ship software today. Or your professional consulting firm, even though that — Facebook is behind this, so it's got to be good, right?. Well, yeah. For Facebook, their use cases could very well differ from yours in very key ways that make it not the best choice for you.


[00:34:45] JE: We do rag on JavaScript. But, in fact, I love it, I especially love React. I’ll be honest. No more ragging on React. No, I’m just kidding. That's not what I’m talking about here. What I’m talking about is I want to ask you a little bit more about how, because you said that with those initial Elixir projects, you were just testing to see how it worked. What about your first clients? How did you sell them on Elixir?


[00:35:07] RT: The first clients working on Elixir were either things which were going to be left alone. Like, the client was never going to actually ever have to touch it again. That was actually one of the other things. It's really funny. You don't appreciate the ability for something to restart itself until you basically understand that, oftentimes with OTP, you get self-healing systems for free. Which reduces, translates directly into fewer calls from an angry person at 3 a.m. saying, “Why is my website down?”


It was almost like just a random discovery of like, “Oh, shit. These things are cheaper to maintain. So let me get this straight. They're faster to write?” — “Yeah.” 


 You can install something ungodly on an EC2 micro. In fact, to this day, I’m not sure. We might have something that's deployed on an EC2 large, but it was over-specked for one of the other projects. I don't think we've ever installed anything on more than a small, in terms of memory consumption. Maybe a medium. It's hard to say.


[00:36:03] JE: Eric, have we?


[00:36:04] EO: I remember our one app, I think we also launched on — we launched on two smalls only to get load balancing. Anything on Heroku, like our first app ever that was production, we were like, do we need a 2X? I don't know. Let's do it for the cores, I guess. Then it runs at a tenth of the RAM, I think.


[00:36:26] RT: Right. That was another thing. It was just we realized it was so cheap to run these things. We basically picked a niche where the requirements for picking was a good example to learn, or do some learning on the client's dime, so to speak, was that the client didn't care. We told them we were doing this upfront. It was normally not a long-term implementation and we weren't turning it over to another team.


It was the sort of thing where, it's like, “Yeah, I don't care. Just write it for me, so I can have it. I don't really care if it ever goes down. I’ll give you a call.” It’s like these. We didn't do them very often, but we would occasionally do these smaller one-off apps, where it was like, “Hey, we'll build you this thing. It'll be up and running.” Those were a lot of the earlier apps. They were just small tiny things.


[00:37:10] JE: Is it a universal rule that the hands-off client gets the best results?


[00:37:14] RT: That's a really good question. Actually, I think it's a universal rule that the client who trusts their consultants gets the best results. I need you to be involved, but much in the same way that I don't walk into the back of a kitchen and be like, “Hey, shouldn't that stove be 20 degrees cooler?” I expect you to cook my steak and make my potato. I don't come into the kitchen and basically second guess. “Wait, wait, wait. Why are you rubbing 2 grams of salt into that baked potato? Shouldn't it be 3 grams?”


[00:37:42] JE: I might’ve done this.


[00:37:44] RT: No, seriously. Some clients, they think that when they hire you that they own you in the decision-making process, versus trusting what you're trying to tell them. I find that clients who get the best results are the ones who trust you when you say, “Hey, I think this is going to be a good fit for something like Erlang or Elixir.”


[00:37:59] JE: I didn't really do that, but I do think about it every time I get a steak that's not perfect. Or I get a cheeseburger that's not perfect, I just think, “Dude, I could teach you. Let me teach you.” I also want to ask, so you've had the experience of trying to persuade clients and generally, the ones that are trusting are the ones that let you go with Elixir. What about other developers? Have you had to persuade other developers on Elixir and how did you do it?


[00:38:21] RT: Oh, so that's interesting. I actually have a script. I actually, at this point, I have an email that's just a template, that has all the baseline resources. I’ll tell you, we actually worked on a JavaScript developer. I make some bold claims about Elixir and Erlang in the ecosystem and then I’m like, “But you don't have to take my word for it. Go take a look at Dave Thomas's book. If you don't like it, I’ll buy the book for you. I’ll give you the 20 bucks you spend on the book. If you find nothing of use there, if you don't find something, I get it.” I have yet to pay out on that.


[00:38:58] JE: This is the perfect way to open this season. What about training developers in Elixir?


[00:39:03] RT: We actually got a subscription to Grox.io, so they could try it in the browser. I use a three-prong approach for getting new developers onto Elixir. I try and find out what their learning modality is. Some people are better with video, some people are better with tutorials, shorter tutorials. Some people will sit down and read a book. I always make sure that they always have an option of three or a mix. I use Grox.io, Prag Studios videos. Prag Studio has an entire Elixir series, which I love. Because in it you build your own little micro-version of Phoenix, so that, that way when you get to Phoenix, Phoenix is less mysterious. You realize it's Elixir all the way down.


Then I use Dave Thomas's book, because I just — most of the people have a Ruby background, so they're familiar with the way that the pickaxe was written. They can quickly get through Dave Thomas's books on Elixir. For people who are looking at a production thing, I actually don't send them Elixir books. I send them Erlang in Anger. Have you ever seen that book? Yeah, I’m pretty sure it's Erlang in Anger is the title. —


[00:40:02] JE: Stuff goes Bad.


[00:40:03] RT: Yeah, that's it.


[00:40:04] JE: Erlang in Anger. I will add these to the show notes.


[00:40:08] RT: It's a great thing, because I’m pretty sure Fred was at Heroku when he wrote that book. I think he was, because the router, if I remember correctly for Heroku is actually a big Erlang app. The thing that basically maps you up to your dyno, that thing is an Erlang app, I believe, or it was at one point in time. I don't know if it still is. Maybe it's moved on.


I use that book for people to basically get them out of the sense of thinking that Elixir is just Elixir. I always tell people, you need to learn Elixir and Erlang, because if you're only using Elixir, you're missing out on, I say, I don't know, pick a number, 60%, 80% of the power.


A perfect example is I saw some guy who was new to Elixir. He was doing something with ASN.1Certs, or whatever, those crypto certs, one of those weird version of a crypto cert is. I’m like, “Well, did you look to see if Erlang already had that X509 cert thing or whatever it was that you needed?” He's like, “What?” It turns out, the Erlang crypto module already had the function you needed to code the cert or whatever. It was already written. He just didn't have the Erlang documentation installed, so he didn't know it was there.


[00:41:20] SM: Yeah, that's something that we definitely learn in Bruce’s class, that I never really did before. It was actually dig into the modules and see why something is the way it is, which I love, because I’m not about magic in programming. It's really helpful.


I wanted to comment and ask a question about your three-prong approach. When we were emailing about this interview, you mentioned that your company actually considers Elixir as a strategic advantage. I was wondering if you could elaborate on that a little bit.


[00:41:51] RT: There are three parts to it. One is you actually have to have the right people and the right developers. Companies, not all developers are going to get the best out of Erlang. Some companies use Haskell as a strategic advantage. They have lots of great Haskell devs or whatever. If you have the right developers and you give them the right tools, and by the right tools, I mean, they understand both the problems, the domains and they're free to explore and actually learn how to use those tools effectively. Then you have management that leaves them the hell alone.


One of the things I was able to do was let the team use Erlang when we actually had some good projects that would showcase the power of Erlang and Elixir. I let the team do that and I was able to give them enough air cover as being part of management to help them report on the results.


I think you have to actually have some executive buy-in, really buying in. You have to have a good test case, so that you can prove what those metrics are and those metrics need to be picked beforehand. You can't pick the metrics after the fact. Then you need to have the right people who are able to go off and do that. That's worked pretty well, because generally speaking, in terms of developer happiness for certain developers, Elixir and Erlang is a big win. They get productivity. They get some functional programming.


Another thing is — what is it? I can't remember what the numbers were, but it's something like 80% of all code is actually refactoring our maintenance or something like that. Only 20% of code is new. I don't know if that's really the ratio, but it's something. Like some minute number of lines in every project is actually new. One of the things I find for getting developers onboard and proving that there's long-term value in this is showing how easy it is to go in and make changes to Elixir code and not break fucking everything.


Anybody who's ever gone in and made a small change and not had everything just explode, all of a sudden, starts to see the power of things like Elixir and good error messages and pattern matching. And the way that you can defensively program, but you don't have to defensively program. I just like the way that there's so many tools in Elixir that allow you to be expressive and solve the problem. I think Stu Holloway always talks about ceremony. I don't know if you've ever heard his talks on ceremony with code. A lot of the stuff you do in code has nothing to do with solving the problem at hand.


The perfect example of this is I always give the example of in C++. Before you can define a class that's working on your problem, you've got to define what type of the copy semantics are? What are the memory layout semantics? Is this a copyable class? Is it a not copyable class? Does it have deep copies or shallow copies? Is it a struct? Is it allocated on the stack, or on the heap? All those things. Is it thread safe? What type of thread safe is it?


All those things, you have to figure out for your class before you can even just start solving the problem, when all you wanted to do is, I don't know, reverse a string or snake case a string.


[00:44:39] JE: I was going to make the point that I make probably, every fourth episode or something about Paul Graham's book, Hackers and Painters, where he talks about how dynamic languages enable the hacker to basically act like a painter and experiment and very quickly, make things happen and get immediate feedback. Yeah, Elixir is very much a hacker's best friend in that way.


Sundi, you're going to uh ask a very important question, I think.


[00:45:04] SM: Yes, I am going to ask a question. For our listeners who didn't quite get this backstory, Randall and I took a class on LiveView with Bruce Tate at Grox.io. And during this class, at some point, I said something along the lines of, “I’m bad at math.” Randall very, very strongly disagreed with me. You said something along the lines of, “Anyone can do math.” I’d love for you to elaborate on this thought idea.


[00:45:28] RT: Oh, gosh. Okay. Good heavens. That probably does sound like something I’d say, especially in an off-moment moment. Now, I guess I have to own up to it. I say this as a person who, one of my other great passions and one of the things that I actually gave a lot of talks about is machine learning and applied statistics. And I say this as a person who went back and taught themselves back from the ground up, applied statistics. Even though I took statistics in college, statistics for engineers and calc and calc 3. It was all taught so poorly that it makes a lot of people I run into thinking that they're bad at math. What it is is they've actually just had some person who has a PhD and in real analysis who's been dreaming this stuff for 20 years and understands everything about it and they're trying to explain that to somebody who's new.


In fact, at — was it Lonestar Elixir? Dave Thomas gave this great talk about expertise and the Dreyfus model of expertise. I think you were there right, Justus?


[00:46:22] JE: I was. I might have been hosting.


[00:46:24] RT: Yeah. I think I think you were. I think you were hosting —


[00:46:26] JE: I got to introduce you, remember?


[00:46:28] RT: That's right.


[00:46:29] JE: We made fast friends, I think.


[00:46:30] RT: He gives a great talk about this. His point is just that you have to have somebody who is not an expert explaining things to you. I think most of us in our entire lives have had experts explain math to us.


[00:46:44] JE: Really? I wish we had put way more time into this interview for this conversation, so I could argue with you. Sorry, finish your point. Finish your point.


[00:46:55] RT: You know what? We can schedule an off. We can have a coda, where instead we pour some whiskey and we have the great math debate about this.


[00:47:01] JE: I would love to, because I feel like most of my math teachers were imbeciles.


[00:47:05] SM: My teacher definitely wrote the book. He was the prime example of the PhD who dreamed about it for 20 years. It was an 8 a.m. class with the guy who wrote the book. I did everything wrong my freshman year.


[00:47:17] JE: I would also say this. Math is misdefined in school. People go through 12 or 15 years of math and they think that it's about numbers. Math isn't about numbers. Math is about logic. Why does everybody think that it's about numbers? Why does everyone think math and arithmetic are the same thing?


[00:47:36] RT: Well, I look at it this way. For people who are, I think, if you're a professional software developer, what's your job?


[00:47:42] JE: Math.


[00:47:43] RT: Well, I would say problem solving. You're paid to solve a problem. At the end of the day, your clients don't really care whether it's — “What you use?” — “Well actually, I’m so glad you asked. I went and I found out this great library in Golang that was written by a friend of mine —” it’s like, eyes glaze over. “Yeah, yeah, yeah. Does it move the money out of my account into that guy's account?” — “Well, yes.” — “Great. That's all I care about.” Which is one of the reasons frankly, nobody cares whether it's a Node app, a Ruby app, an Erlang app, an Elixir app, a Haskell app. Those things are immaterial. We're actually paid to solve problems.


I think the problem is that math is always presented in this pristine ivory tower, like abstract. Imagine a perfect car traveling at a perfect 60 miles an hour down a perfectly 45 degree slope. No, it’s not that at all. Most people don't realize, calculus is useful.


[00:48:36] JE: I think we will have to do the whiskey math conversation.


[00:48:40] RT: Whiskey and math. That could be good. Actually, you know what? Hey, you know it'd be great. I will tell you this. I would gladly sit on a conversation, fill up like 8 ounces of whiskey, and we find some mathematician that's interesting and talk to them about how they would apply it. I would do that with you, Justus. I would gladly sit around and do that.


[00:48:57] JE: Well, I think we've got a date. We like to give you a few minutes at the end of the episode to make any final plugs, or asks for the audience, where they can find you, anything. This is your time, so please.


[00:49:10] RT: I would say, if you're into programming, this is actually — so I’m going to go plug to turing.io which is basically, it's a way for people to get in. It's more than a programming bootcamp. It's actually education. I’m going to reiterate something I told there. If you're looking at getting into programming, don't underestimate the impact the community has on your ability to be happy and successful in your job. I think that's something that people way underestimate, right?


I have met so many unhappy enterprise level, Java enterprise architects, or, “I’m a .Net enterprise architect,” or pick whatever. And our community, one of the things — actually going back, I don't think we actually ever finished any of these things, but one of the things I really liked about the Elixir community is one, all the smart people from Ruby were there. And two, as a random nobody in this community with no rep, whatsoever, I walked in, and I got — was such a huge welcome from people and everybody was willing to share.


One of the things I actually love about Elixir, specifically, are the people. I mean, think about it. Sundi and I were in a class for what? Two days, three days together online, had never actually met. And here we are, yet again. In fact, actually which at the time, I think you were looking for an Elixir gig too, right?


[00:50:27] SM: I was and I was losing hope that I would ever find one and I was resigning myself to JavaScript jobs.


[00:50:34] JE: But she found it.


[00:50:35] SM: Yeah, I found it.


[00:50:37] EO: But then also, started this one and immediately wrote JavaScript.


[00:50:43] RT: Tradeoffs, right? My plug would be don't underestimate your own happiness as a software developer. Think about what community has to offer you, because you certainly have a lot to offer that community. I think that's something that people, as techie nerds, we like to focus on. No, no. Excuse me. Clearly, IEX is actually the best shell for working with. Yeah, blah, blah, blah. Yeah, okay. That's great.


It's actually way better to the people you work with and the jobs and the problems you get to solve. And that has a huge impact on your long-term, or your longevity in being a programmer. I mean, I’ve been doing this professionally for over 30 years. It was an accident. I was going to be a lawyer. I wanted to be an attorney. I thought I was going to be a lawyer when I grew up, or a classical musician. I spent a lot of time playing classical music as a kid.


What really kept me in was that there were lots of interesting problems and lots of people willing to take somebody who knew nothing and share everything they knew, to somebody who probably didn't appreciate half of it at the time.


[00:51:37] JE: Well, let's hope that Elixir can be that community for some people that are listening.


[00:51:42] RT: Yeah, let's hope.


[00:51:44] JE: That's it for this episode of Elixir Wizards, everybody. Thank you again to our guest, Randall Thomas and to my co-host, Sundi Myint and our producer, Eric Oestrich. Once again, I am Justus Eapen.


Elixir Wizards is a SmartLogic podcast. Here at SmartLogic, we're always looking to take on new projects, building web apps in Elixir, Rails, React. We like to do infrastructure projects in Kubernetes and mobile apps using React Native. If you got a project you think we could help you with, well we'd love to hear from you.


Don't forget to like and subscribe on your favorite podcast player. You can also find us on Instagram and Twitter and Facebook, so add us on all of those. You can find me personally @JustusEapen, and Eric @EricOestrich, and Sundi @Sundikin. Join us again next week on Elixir Wizards for more on adopting Elixir.


[END]


        © 2020 Elixir Wizards