Welcome to another episode of the Console DevTools podcast. I'm David Mitten, CEO of Console.dev, a free weekly email digest of the best tools and beta releases for experienced developers. And I'm Jean Yang, CEO of Akita Software, the fastest and easiest way to understand your APIs.

In this episode, Jean and I speak with Jeff Bezanson, one of the co-creators of the Julia programming language. We start with the history of Julia and why it took a while to take off, the key principles behind the language, how it provides the speed of C with the ease of Python, and what it's been like running such a large open source project. We're keeping this to 30 minutes, so let's get started. We're here with Jeff Bezanson. Let's start with a brief background. Tell us a little bit about what you're currently doing and how you got here.

Hi, thank you, David. Great to be here. So I'm Jeff Bizanson. I'm one of the creators of the Julia programming language and developing that is most of what I do. I'm also a co-founder of Julia Hub, which is a company that grew out of that project. And that's the pretty much the rest of what I do.

Cool. Well, Jeff, I'm really excited that you can be on this podcast with us. And I'd love to start by just talking about the original motivation for working on Julia. I mean, I still remember when we were teaching fellows together and you were doing side jobs and working on Julia on the side. And so can you tell us about the state of the world before Julia and what gave you the motivation to start working and keep working on it?

I think back to the 90s and the early 2000s, which was kind of the heyday of Moore's Law, right? And I remember there was a big culture among programmers that it would be silly to worry about performance because the hardware will give you free performance. So everybody was kind of rushing to try to trade away as much performance as possible.

And that was sort of the in vogue thing to do. And that's where we got these kind of scripting languages that became really popular. It was in, people might disagree with this, but in the way I've always seen it is like people are almost trying to make them as slow as possible because that was sort of in fashion. If you weren't giving up performance, you know, you didn't understand Moore's law. Any particular languages you're referring to there? Or do you want them to remain nameless? Oh, there's a whole host of them. Everything from Tickle to...

Python, Perl, you name it. There's a whole bunch of them. The result of that was that people in certain programming communities ended up using certain languages, right? Because you tend to use the same language that the people you work with. So you get these network effects and you ended up with these communities and bubbles of language users. And in the scientific realm, that certainly happened. People ended up using mostly MATLAB, R, and Python.

And it became kind of an article of faith in those worlds that they were sort of the fun to use, productive languages that they enjoyed using and worked really well for them, but were slow. You had to give up performance.

That was just a law of the universe that they all learned. And then if you wanted performance, you had to use C or Fortran or something. And this was just the way it was. And so I got kind of introduced to that world of thinking in college. And I thought it was really surprising because I knew that high-level languages could be fast. You know, I knew there were good Lisp implementations. You had the ML family languages. There were really good high-level languages that had really, really good compilers and could be fast. And nobody seemed to be using them.

which I just thought was amazing. So I made it this kind of mission to, can we get all these people to realize that high-level languages can be fast and they should be using a high-level language that's fast?

And so this is my attempt to do that. I wasn't really able to do it until I kind of learned a lot of stuff and met the right people to figure out what the design should really be and how to position it, which took quite a few years to get into that position where I could actually do that. Right, that makes sense. So I suppose...

several years and what was it like going through that journey? How did you keep yourself motivated? And then I suppose, what was it that you learned from those people that made things change for you? I learned a lot more about how R and MATLAB worked. So I was mostly a computer science person. I didn't do that much with applied math kind of stuff.

So I didn't spend as much time on MATLAB, R, Fortran languages as most of the applied math people who would have been my user audience. So I happened to learn a lot more about those. For example, at my job at Interactive Supercomputing, which was a kind of short-lived startup out of MIT that did a parallel computing platform.

And I learned a lot about MATLAB and what those kind of programmers were looking for and wanted. It's a group that is very, very focused on notation. And if A star B doesn't do matrix multiply, you know, they won't use your language. One simple example.

Something I find very inspiring about the Julia story, especially in the age when people talk about this chat GPT app became an instant multi-million user super hit overnight, literally, is how

how long it took you to really get Julia right, you and the team. And so I was hoping you could walk us through the timeline of what was it like when you started? And I think that a lot of the years really were necessary to get the right idea, have the world be ready for it. And so I'd love to just walk through that whole story.

That's a really good point because now I'm actually worrying that it took so long that we no longer maybe need programming languages or system software of any kind. The chat GPT thing almost makes me think the concept of reuse that has been one of the guiding stars of computer science for decades might just be over now. I think it could go that far. I'm worried about is there any future in system software at all?

Well, I think if there's any language well poised for chat GPT, it seems like Julia with its reuse and high level scripting nature would be the forefront of being chat GPT. So it's a feature. Well, that's certainly an optimistic spin. I love your retellings of the story of like, well, first we did this, then we did this. And this is when Julia finally took off.

I was working at Interactive Supercomputing. Well, actually, even before that, I had a summer job as a research programmer at

Starting at the end of high school, I had seen what the work was like when you had to take in a bunch of data and look at images and make lots of plots and write programs to process them. And people actually in that group mostly used C, and it was just incredibly inefficient. And yet I saw that it's at that time, that was quite a while ago, the whole Python and NumPy tool chain was not nearly where it is today. So this was quite a long time ago. There wasn't really anything out there that could have handled it a lot better.

That's one of the things that got me thinking that, boy, there's this entire programming that is so inconvenient to do. All the other programming I had done fits neatly in the available tools of the C toolchain, essentially, because that was for doing systems and most application stuff. It worked fine. For this stuff, it was just clearly the wrong level of abstraction. So that's one of the things that got me thinking about needing some totally different kind of platform.

And then many years later, I ended up in interactive supercomputing. I mean, I applied for that job because I said, aha, this is a place I can go that I can maybe solve this problem. These are people who are working on this. So I should go there, which is why I was interested in it.

But of course, we're working on MATLAB and Python and R in that shop. Python is a pretty good language, but I really don't care for R and MATLAB very much. So I was sort of constantly ranting at everyone there about how it's too bad that we have to shoehorn our parallel computing platform into MATLAB and R because if we just had a good language, it would be a lot easier. And I was just sort of ranting at people about this. And there was this one guy there, Veral, who would have listened to me about it.

And he said, you know, you sound a lot like this guy, Stefan. He says the same things that you say. You guys should talk to each other.

So he put us in touch and we started this furious email exchange where we were sending our ideas back and forth about how it should be. It should work like this. If everything was just like this, then these problems wouldn't exist. And there was just like thousands of emails or something over a couple of years where we started talking about this and hashing it out and starting to design a language. Yeah, I remember Jeff was the one who taught me about how bad MATLAB was. I just accepted it and I just thought that it was supposed to be slow.

if you're doing such computationally intensive things. But I love that story. My favorite story about that is I've heard people talk about their MATLAB programs and how long it takes to run as a feature.

They talk about, you know, our simulation is so sophisticated, it has to run for two days to produce a result. You know, it never occurred to me that that would be a good thing to someone. So it's just kind of surprising the things you find out. But then, oh, of course, I should add the next step that was crucial is that when that company was acquired, I had to look for something to do next and verify.

Verhal suggested I talk to Alan Edelman, who I could pitch on this whole project. And I showed him what we were talking about and what we wanted to do. And he thought it seemed like a pretty crazy and hopeless idea. So he decided to support it.

Yeah, I was very happy when I showed up to grad school one year and Jeff was there. He was there working on Julia. What are the core principles behind the language for someone who hasn't seen it perhaps or has only used Python or I suppose R as well? If you're in an academic circle, what are the principles behind it? The principle is in these kinds of technical computing platforms,

There's a lot of polymorphism and objects and types that have these really complex behaviors that you don't get in some other domains. If you think about something like units, for instance, units are very much like numbers in many ways, but they're not closed under multiplication, for example. Or you have matrices where you've got multiplication is now not commutative. The size of the matrices goes into whether they're compatible with

And there are also lots of different kinds of structured matrices. You know, there's a whole zoo of matrix structures like bi-diagonal, tri-diagonal. So you just have such a large diversity of objects and combinations that are possible. So it leads to these kind of libraries that have lots of very complex behaviors built into them.

And yet the compiler wants to know about it, as the compiler would like to be able to reason about all of these things, usually for performance. I mean, some people, of course, would want to check the program, but we knew that performance is what sells, so we were really only interested in compiling for performance at first. We looked at these kind of complicated library behaviors, and the other thing about it is that not everyone wants the same thing. So in different domains, people use different definitions of things.

There's one Julia package called infinite arrays, where it has, it gives you array types where some of the dimensions can be infinity. And to a lot of people, the size of an array dimension is better, better be an integer. And infinity is not an integer.

So that can potentially break a lot of things. Depending on who you talk to, that may or may not make sense for that to exist, right? So there's this great diversity of kinds of objects you might want. You can't just build it into one standard library and then say there it's good, not even to the level of just the type signatures, right? You can't even say, you know, the size of an array dimension must be an int, which is something we'd all be used to. Of course, that's a reasonable constraint to have, right? Well, no. So there's just this great diversity of possible behaviors, right?

And so therefore they can't be built into the language because you can't just set them once and for all. So they all have to be written in libraries. So the guiding principle was that you could just write all of these behaviors as libraries and then let the compiler figure it out. There was a research program that did something kind of like this for compiling MATLAB programs. It was called Telescoping Languages by Ken Kennedy, I think. It was a research project many years ago.

I had heard about that and that kind of inspired some of this thinking where the idea was that they would take libraries of MATLAB code and annotate them with types in various ways and analyze them thoroughly using program analysis techniques and sort of turn those libraries into a compiler where you could then compile other programs against those libraries. And so we do a similar kind of specialization where the idea is to just analyze the libraries thoroughly to be able to compile code against things that have these kind of potentially wacky behaviors.

Cool. So Jeff, you have this tagline, the speed of C with the ease of use of Python. And I'd love to dig in on, is there a core way to summarize what Julia does differently from other languages that enables this? Or is it really just a series of good, smart decisions and language design and implementation? Yeah.

It's based on design decisions. There was a paper from Northeastern where we tried to write some of this up called Dynamism and Performance Reconciled by Design. What we did was, you know, that people have been trying to speed up dynamic languages of various kinds, you know, for a long time. That's been one of the long-running research threads in computer science is starting with a language like small talk, for instance, you know, how do you make it run fast? And there's a, you know, a whole zoo of both dynamic and static techniques that

There's some really cool stuff people have invented to take these languages that you can't necessarily statically analyze using standard compiler techniques and yet nevertheless generate fast code from them. So it's kind of, you know, it's a fun game to play is how do we compile these languages that are not cooperative languages

So that makes it a challenge, which makes it a good research problem. But to me, it's kind of annoying because why do you always have to fight the language design? So instead, I kind of approached it from the opposite direction and said, all right, what are all the techniques that are known and available for doing this? And then how would you design a language to make those techniques work well? Right. Because those techniques aren't perfect.

They work pretty well in practice, but you often run up against things where, okay, not every program can be optimized. You might get unlucky and you don't hit the fast path. So we said, okay, we're going to be using these techniques. What can we do to make them work as well as possible? And so we kind of cheated because we could just design it from the beginning so that we'd be able to optimize programs better. Yeah, I love that. Do you have any specific examples that could help illustrate the kind of techniques you've used?

There's certain things you want to avoid. So definitely you want to enable local reasoning. So you want to minimize the impact of possible action at a distance kinds of things.

So like, for example, if I have a variable on one line, maybe I've figured out its type. And then I call a completely unknown function on the next line, right? Because these kinds of analyses are going to be approximate. You're not guaranteed to ever get any information about something, right? So you might hit a bad case where there's a totally unknown function call. You don't know what happens. So then on the next line after that, do I still know anything about the variable that I set before that?

Like, is it possible, for instance, that that totally unknown function might have reached into my local scope and changed that variable, for example? Because if so, now I have to throw out that information. So that would be bad. So you want to avoid those kinds of effects so that you can have a partially analyzed program and still be able to kind of keep the information you have as much as possible. Okay. Yeah, that makes sense.

That makes sense. And how does this lead into Julia's use for parallel and distributed computing and the optimizations there and why Julia is a particularly good language for that kind of workload? The parallel and distributed cases are pretty different. I mean, you can kind of do distributed in any language because you can just start up processes on lots of machines and you send messages and, you know, that's that. So it's sort of equally impossible in every language, right? Yeah.

And unfortunately, equally too easy. Yeah, yeah. There's some things we could do. We knew we wanted to do distributed computing very early on. So we've always had a pretty good serialization library. So we know we at least could send any object around. But any language can do that, really. So I don't know if there's anything that distributed specific. But in terms of the parallel, I think it does help that

The language is kind of function-oriented, I would say. Like, it's not purely functional, but it's very function-oriented, so people tend to write purely functional code anyway. A lot of the stuff, we were adding threads several years ago. In the beginning, you know, even before everything was sort of thread-safe, stuff sort of, by luck, sort of ended up working because people tend not to randomly mutate things and stuff like that just because the design of the language lends itself to it. Cool.

Jeff, something I want to dig into is the formation of Julia Hub, because it seems like Julia has gone through many stages. There was the pre-academia stage. There was the period of time when you were in grad school and Julia was an MIT project. And then you formed a company and then you took VC funding for the company. What was the transition from forming a company to taking funding like? And I'd love to just hear more about that.

Things really picked up quite a bit very soon after we released it in 2012. So pretty much since that point, we've all been really, really busy developing the language and helping people use the language.

So to me, it sometimes just feels like since that first blog post by Stefan where we released it, it's just been that all day, every day on some level. So we did get consulting requests within a couple of years. So we started doing consulting, helping people adopt the language in various environments to help them get the most out of it. That's how it started, of course.

Then this investor, Donald Fisher, showed up. He showed up at Alan Edelman's office one day. Wow. Turned out he was an investor who specialized in open source languages, and he had been watching.

he somehow saw all of this that was going on and he showed up to talk to us and we were kind of you know confused about you know what we don't really have a company you know what's and he said oh no there's something here trust me so he was quite early to it it was quite impressive yeah i had no idea at what an early stage some of these investors smell what's happening and jump in so it was pretty amazing and he just turned up at your office unannounced

Probably wasn't unannounced. I mean, the way I remember it is he just sort of walked in, but I'm sure it was scheduled. Somebody got announced too, wasn't you? And what about the open source side of things? What have you learned running a project that's used by so many people? It is a fun thing to do. I mean, I do like it working with all these people all over the place, many of whom I don't even know who they are.

It's kind of fun, but it's getting pretty busy. It gets pretty chaotic. Many days, I am not really sure how we're able to keep it working as well as it does. There is just a lot of activity. I can't really keep up with it anymore. For me personally, I'm going through kind of a difficult transition where it's

For a surprising amount of time, I could kind of keep my head above water and sort of know everything that was going on. Now it's just really not possible. And so I'm still learning how to cope with that. Lots of changes coming in. Sometimes I open up a source file and, oh, what happened here since I last looked at this? You know, that makes it difficult. Hopefully, ChatGPT is faster at understanding large code bases than I am, which I suspect it is. And so maybe that'll save the day.

So become like your assistant, your product manager who will feed everything back to you in a summarized form. Yeah, sounds like a hard problem, but good one to have. That would be the hope. So Jeff, have there been tensions between the desire to keep the open source community happy and the commercial needs of Julia? Yeah, we've never really thought so because...

The open source community is the base of the pyramid for everything we do. It's the base of the pyramid of my career at this point. So that's always been something that it's going to remain as it is. Of course, the project and the core language itself

and the community around it keeping that working the way it does now is a very high priority. Everyone involved can have a voice in that, and that's still going. We'd never give that up for any commercial reason. So then it's on us to find a way to fund the whole thing under those principles, which we think is fully possible. It's not so easy, but we think it's completely possible.

by just having a very clear separation between the things that are for particular markets that they would be willing to pay for versus just a language. Is that the large-scale data processing and machine learning type applications that you advertise on the JuliaHub website? Is that where you feel like the commercialization opportunity is? Yes, it's a little more targeted than that. It's focused in particular areas of modeling and simulation specifically.

So pharma simulations or physical systems and now hopefully soon circuits.

Interesting. What's the infrastructure behind the scenes for that? Have you built a custom platform? What does that look like? Our kind of library-oriented design that I was talking about, that really was successful. It worked much better than we expected because there were a lot of people out there who had what you'd call the domain expertise to write, say, differential equation solvers. But it would be very difficult to do it in C++.

And especially, not only is the language harder to use, but once you want to add very advanced capabilities, lots of really fancy features, it just becomes kind of untenable to use a low-level language. And so a lot of people like that were able to pick up Julia in lots of areas, like image processing, various things. Were able to pick up Julia, write the libraries they needed, that had the features they needed,

And then the performance was basically just more or less automatic. So you already good performance and you have more capabilities than you ever had before. And so one of the more illustrious of those efforts was Chris Rakakis' differential equation libraries.

which I think now we have the best in class libraries for that stuff. There's just really incredibly productive tool chain for writing down equation systems in a very high level mathematical notation. And that will just go all the way to some of the fastest solvers out there with just very little effort. Cool.

Jeff, we've talked about this at various points along the way, but I'd love to hear about some of the lessons you've learned from working with a long-running open source project. How have you evolved with your community and what are some of the things you've learned from working with your community? Well, testing is certainly really important. I can say that. I mean, everybody knows this, but it always feels like you're learning it over and over again. Anything that is not tested is going to break.

There are a lot of things that don't seem like they could be easily tested, but you nevertheless have to find a way to test it or it is going to break. So that's just really, really important. That's, I think, what sort of keeps us going at this point. Have the people who showed up been different in profile over the years, or is it just a larger number of the same kind of people?

The profile has changed a little bit. Of course, it's still the typical Julia developer is still probably in applied math or sciences in some way. But there's certainly been a greater diversity of people from the initial small number of early adopters, I think.

It's a little bit hard to characterize because actually in many cases, as I said, I don't even know who the people are. Some people just use GitHub usernames. Sometimes I don't even know who they are. So it's a little bit hard to have informal demographic data, I guess. It's hard to say anecdotally. We do have a developer survey online.

that we send out every year. The results of that will kind of tell you maybe that's probably the best information we have. And there has been a slight increase in the diversity of kinds of people. And Jeff, I'm going to go off script with this question. But now that applied math is everywhere with chat GPT and AI everywhere, is Julia getting into the AI game?

We're kind of in the AI game. There are certainly frameworks for doing AI machine learning in Julia. And in fact, one place where we've been a little bit ahead of the curve is in this SciML tool chain, as it's called, where the program is to integrate

traditional kinds of scientific knowledge that's based on equations and deterministic rules with machine learning so that you can get the best of both worlds. Because if you have an agent that's trying to learn to do something in a physical environment, say, you can try to have it learn everything, but why not just also tell it what we know about physics? And then that will give it a huge leg up, in which it turns out that does indeed work. If you let an agent like that just already know the laws of physics,

it improves much, much more rapidly than having to reconstruct absolutely everything. So there's various things you can do as well, like using machine learning techniques to develop fast surrogates for components of simulations. It's a really fancy way to optimize a function effectively by just learning a neural net approximation of it that runs incredibly fast.

So the whole SciML ecosystem in Julia has lots of tools for doing that. And so I think if you want to combine those kinds of traditional mathematical models with machine learning techniques, that's actually the best package of stuff out there. But as far as I know, people are not using that to build, say, chat GPT. You kind of alluded to it at the beginning of the episode about how you think

programming in general is going to be changed by the likes of chat GPT. Are you optimistic or pessimistic? Because it wasn't entirely clear from your answer, which view you take? Everyone always asks the question is, are you optimistic or pessimistic? But I think it really has to be broken down to the technical question and kind of the moral question, right? Like, do I think the technology works and will be effective? Then yes,

In that sense, I'm optimistic. I do think it works. People are going to be using these coding assistants at the very least, plus things that maybe we can't even imagine yet. I am very curious how it's going to work out for maintenance programming, because I mostly do maintenance programming. I wish my job was to sit down and write a program that does X. That would be great, but I don't really get to do that. I do maintenance programming.

I'll ask you, have you seen any exploration of using chat GPT for maintenance programming kind of tasks and not just, you know, write a function that does X kind of tasks?

So my sense is that Copilot should be able to help with some of this, no? Maybe. I haven't tried it, unfortunately. I would say from first principles, a lot of the people I worked with in program synthesis when I was in research, maintenance programming was one of the use cases because the goal of program synthesis is to drive down boilerplate. And so when do you have boilerplate? When you have to visitor pattern something a lot, when you have to do maintenance programming. And

I feel like those are the two big cases or when you have to string together lots of APIs. Those are the three big situations where you want to do automatic programming. So in the research area, I feel like Copilot is adjacent to you. There should be a lot of AI for maintenance programming, but as for how effective it is, I'm not sure. I've never personally tried to use Copilot for maintenance programming. I'm curious what happens if you try to ask it to do a complicated refactoring, say. Oh,

interesting. Yeah, in my mind, maintenance programming is sort of like you change one data type and you got to thread that through your entire system. I feel like Copilot would be great for that. But,

But a refactor would be harder. So at the moment, it's just generating, it's almost like advanced autocomplete when it's in your editor. And that's pretty helpful for the boilerplate stuff. But I suppose when it can understand a bug report and propose a solution, I haven't seen anything that can do that yet. But I have seen things like convert this code into a different

different language so from one language to another yeah the translation and stuff any refactor that's that's a transpile i feel like you know this ai stuff is good for but anything that needs a

core our fundamental understanding of the underlying program semantics, I feel like there would be some weird stuff going on. Yeah, that's kind of true. And actually, the use case of converting code from one language to another is actually was the first thing I was super excited about with this, because this is actually the perfect technology, in my opinion, for doing that.

Because when you are converting from one language to another, which we encounter a lot because we have, of course, you know, when you're trying to sell a language, a lot of people need to port their code from C++ or Python or MATLAB to your language. So that's the first thing that comes up. And this is a really particular kind of task.

that's really well suited to this because you actually, in a way, you want to kind of do it approximately because you don't want a compiler. If you tried to use like a C++ to Julia compiler, you would not get very nice code out. Yeah. Yeah. So Jeff, see this chat GPT business can help. It probably would not work very well. You wouldn't like the results. Yeah. Yeah.

Well, before we wrap up, then I have two lightning questions for you. So the first is what interesting dev tools or tools generally are you playing around with at the moment? My favorite toy by far is RR, the record and replay framework. Oh, cool. That has been the biggest life changer, game changer thing that I've encountered in quite a few years.

You can just do things that you couldn't do otherwise. A lot of things are kind of time saver kind of tools. Like even I think most of the stuff in the IDEs, like they're, it's convenient. But if you look at how much time does it actually save you, it's like a few seconds here and there, which is maybe worthwhile because it adds up. But this is just like, you know, a tool that comes pretty close to just finding the bug for you in five minutes instead of hours of frustration. It's a major step up.

Okay, great. And then what is your current tech setup? What hardware and software do you use each day? My tech setup is, I've got to admit, is pretty old school at this point. I mean, I have a, I use a Dell XPS laptop that comes preloaded with Ubuntu. I've used those for a long time because it has, yeah, it comes with Ubuntu preloaded. So I like those. And it's a nice machine. Yeah, it's gotten increasingly hard to install Ubuntu given the BIOS setups of these modern machines.

I've been using Linux for, I don't know what, how a very long time, more than 20 years. So the idea of a laptop freeloaded with it is still sort of like novel in some part of my brain. Other than that, it's pretty old school. It's like Emacs and Terminal is most of it. Which version of Ubuntu do you stay up to date? Yeah, I stay pretty up to date. I've got 2204 right now. Yeah, that's pretty recent. Excellent. Well, unfortunately, that's all we've got time for. Thanks for joining us. Yeah, certainly.

Thanks for listening to the Console DevTools podcast. Please let us know what you think on Twitter. I'm at David Mitton, and you can follow at console.dev. Don't forget to subscribe and rate us in your podcast player. And if you're playing around with or building any interesting DevTools, please get in touch. Our email's in the show notes. See you next time.