Keno Fischer, Co-founder @ Julia Computing: Developing The Programming Language Of The Future

This episode features Keno Fischer, Co-Founder and Chief Technology Officer of Julia Computing. He shared stories behind the creation of the popular programming language Julia, as well as the development of the community and spin-off company Julia Computing over the past years with the rise of machine learning. Interview: Keno Fischer, CTO & Co-Founder @ Julia Computing

Julia is a modern open-source language for data science, machine learning and scientific computing that has gained increasing attention. It combines the functionality of quantitative environments such as R and Python with the speed of production programming languages like Java and C++ to solve big data and analytics problems. It has been downloaded over 3 million times and adopted by numerous enterprises, research institutes and financial organizations.

Keno Fischer began contributing to Julia when the language was first released in 2012, when he was a high school student. He then co-founded Julia Computing in 2015 and graduated from Harvard University in 2016. Keno was named to its ‘30 Under 30’ list of young leaders in enterprise technology.

Full interview:

Listen to podcast on: Apple Podcast | Spotify | Google Podcast is a content platform dedicated to helping engineers and researchers develop leadership, entrepreneurship, and AI insights to scale their impacts in the new tech era.

Subscribe to our newsletter to stay updated for more CVPR interviews and more inspiring talks:

Full Transcripts

Margaret Laffan: I'm with Keno Fischer from Julia Computing here in Boston, beautiful day in getting ready for the long weekend as well. Thank you for joining our show today, Keno.

Julia has attracted lots of users and partners from financial companies like BlackRock, Federal Reserve Bank of New York, to universities like MIT, Harvard, Stanford, and so forth. It's known for the high level productivity and ease of use of Python and R with the fast speed of C++. Can you explain to us how you achieved such progress technically?

Keno Fischer:

When you look at the languages that you mentioned, like Python and R, those sorts of languages were designed really with the singular goal of user productivity. The end users are scientists, domain experts who need to be really fast in exploring that new algorithm, getting to that new solution, getting something done without the language getting into that way. So that was the singular design focus.

And the way they do that is that they tend to string together pre-written libraries in lower level languages like C and C++. And those languages, C, C++, Fortran - you could count Java, though it's a bit debatable where it falls - those languages were written with a singular focus on performance, on taking the optimal advantage of at least hardware that was available when those languages were designed.

As a result of that, you tend to end up with these two very different camps of programmers, programmers that care about productivity, data scientists, people at the Federal Reserve, people who do economic modeling, social scientists, people who do various kinds of analysis and simulation with very, very high level tools. On the other hand, you have people who care a lot more about the performance of the code they're writing, so they'll write very low level code. They all need to be very careful about what kind of code they write, how did they write it, taking advantage of the memory hierarchy optimally, making sure to scratch the last 50% of performance out of the hardware.

When Julia was started in 2009, the question was, is this divide between high performance languages and high productivity languages? Is it a fundamental aspect of programming language design? Or is it an artifact of who wrote these kinds of languages? Because the people who knew about performance wrote high performance languages and the people who knew about what an end user would actually want in a high productivity system, were writing the high productivity languages, but they may not actually be computer scientists, have all the low level expertise required to make that happen.

What happened at the creation of Julia was the question: Can we do this and the bringing together of people from computer science who have the necessary expertise to do programming language development, to do low level systems engineering, to get a language to actually perform well, and people from the application side who have used tools like R and MATLAB, SAS and Python, and all of these various tools to really bring in their perspective of, is this a language I would actually use? So that was the background.

The way we're able to achieve it technically is through very clever design of the programming language. There's two aspects to that. One is looking at what features of dynamic languages make it hard to compile efficiently. And those can be things like arbitrary nonlocal effects. So you're doing something over here, and that has long ranging implications over here that are sometimes useful and are sometimes used for tricks, but aren't fundamental to the expressivity. So if you restrict a little bit of that and are a little bit clever with the way that you design the language, you can get something that feels very much like that dynamic language and feels very much like a high productivity language. But this allows a lot of the things that cause performance problems in traditional dynamic languages.

Another core aspect of what makes this possible in Julia is a system we call “dynamic multiple dispatch”, which is the core paradigm of the Julia language, and allows us to do dynamic selection of optimal algorithms for particular types of parameters. Dynamic multiple dispatch has been known for many years, but there has never been a system that really optimizes it from start to finish. So the benefits of this paradigm of programming before Julia, I don't think have ever been really realized in the system.

So that I think was the core technical innovation on the programming languages side. There's a decent amount of compiler technology and lots of optimization, but I think that's the core technical innovation. And then on top of that, there’s more and more social factors like people who work on the language care that it's fast, people who work on the language care that it's really usable for end users, that is a good language to teach students in. And you've mentioned the universities, there’s several hundreds of them now that are using Julia as a good introductory language for teaching, either programming on numerical subjects like linear algebra, mathematical optimization, numerical methods, image analysis, those kinds of subjects. I think having a community that cares both about the performance and the usability to the scientists, the domain experts as an end user, is a huge factor in addition to the technical factors.

Margaret Laffan: You started to work on Julia in 2012 when you were still 16 years old in high school, and that led to the Julia port to Windows. What triggered you to contribute to a new programming language at such a young age? Did you have a specific goal in mind at the time when you were doing this?

Keno Fischer:

Yeah, I did. At that time, I was an exchange student at a small school in Maryland. What I was doing at the time was, I was taking high school classes online, through a program at Stanford University - an online High School Program, which gave very advanced students the opportunity to take one or two years of college level classes while still in high school.

Through that program, I was participating in a competition called “Mathematical Competition in Modeling”. They have a high school version and a college version. And we did both in high school, so the high school students can enter the college version, if they want to, but very few do that. So we did both through this high school program. And the way that this competition works is, you have 96 hours, and at the start of the 96 hours, you get a statement of a mathematical problem. The one I remember doing was calculate the total mass of all leaves on a tree. So it's a very open ended problem, it's not something that has much practical benefit, perhaps. But it's an interesting problem to think about, how would you even do that? What kind of data do you need? What kind of models would you apply? How do you do it in 96 hours without going to a forest? There's a huge variety of trees. So it's a very open ended problem, but the goal of the competition is just to help you think about how do you establish assumptions? And then based on those assumptions, how do you get your results?

Essentially over the course of these 96 hours, you need to figure out what you're going to do, collect whatever data you need, usually by downloading it from the internet, but you still need to find where on the internet you get data on masses of leaves on the tree, and then you write some program to do it, and then you do some simulation or some analysis or whatever you want. And then you write a paper about it, all in the course of 96 hours.

I was participating in this and had done some programming in Octave and a fairly competent C++ program. I had some open source experience, but it took us 48 hours to come up with a model we want and collect all the data and write the program. But then, after one run of a simulation, simulated for one tree species, how large are these leaves? How heavy are they? I wrote it in Octave, it took about four and a half hours. For the rest of the 96 hours, I was awake every four and a half hours, looking at the result of the simulation, and plugging the results into a paper and tweaking a little bit and hitting start again. So I didn't sleep very much.

At the end of the 96 hours, I thought to myself, I don't think this should have taken that long. Four and a half hours for this relatively simple simulation is way too long. I have a lot of programming experience and know how to do this, maybe I can improve Octave to make it faster. And then about a week later, MIT announced that they were working on a new programming language called Julia to solve these kinds of problems. So I said, that is the correct thing to do. That is what is needed. And I felt maybe overconfident at the time, but I thought how hard could it be? And I started contributing. As you mentioned, I was using Windows at the time. And Julia wasn’t working on Windows, I tried downloading it, it didn't work on the Windows version. So I started working on that.

Margaret Laffan: So it all started from you counting tree leaves.

Keno Fischer:

Yeah. That is correct. It all started with the question of how heavy are the leaves on a tree? I still haven't found out the answer. I have simulation results. That seemed reasonable to me at the time, but I never had the time to actually go up and count the leaves on the tree. Who knows? Maybe I'll find out eventually.

Margaret Laffan: You've been involved in Julia language for the last seven years. How has Julia evolved over this time, and what has stayed the same? What's been the most interesting part in this journey?

Keno Fischer:

It's certainly been quite a ride, I would say. I mean, back in 2012, when it was announced, and I was one of the first people outside of the lab at MIT that started it, to start using it. I think we had maybe 40, 50 people who were part of those initial users, when it was announced, who downloaded and tried it, and there was lively mailing list activity for a couple of weeks, then it went down a little, the people who were initially excited dropped off again.

But since then it's just grown so enormously, from the couple of tens of people who are there to - we just had JuliaCon a month ago, we had 400 people at the conference. And in terms of the community in general, I think we have around 250,000 users, it's a bit harder with an open source project to figure out how many users are there actually, what is the user? If you have Julia installed, are you a user? Because in that case four or five million downloads, is that where the users are? Or if you're using Julia once a week as a calculator, are you a user? Or if you're doing all your research using Julia? So it's a little hard to figure out, but 250,000 is about the number that we think is reasonable based on various metrics of active users.

From a couple tens of people that are using the language to hundreds of thousands of people is obviously an enormous growth in the community. And then from a language that was a prototype and crashed fairly often and lots of things were slow, but overall, things weren't working back in 2012, to a language that a year ago reached 1.0, having long term stability and having actually a foundation, that now other people are building their crazy new research projects. Having dozens of people’s efforts on top has certainly been a change in the kind of project that we are in. In the professionalization, the fact that if you break something, now you're going to have hundreds of angry people sending you an email. That happened gradually and making sure that our processes are up to date with that has certainly been the major change over this time that I've been involved with it.

What hasn't changed, I think, is the quality of the community and the kind of people that are part of the Julia community. We tend to get the world experts in whatever field Julia has been deployed in, contributing to the community and contributing the expertise and building state-of-the-art tools for their fields in Julia. I know of no other community where there's so many domain experts just available and talking to each other and hashing out, okay, these are the conventions in my field. How do we build a common foundation that shows everything? And I think that has mostly stayed the same. Obviously, the user community is broader now that we have so many, but I think the quality of discourse and the competency of the people involved in the community has been constant, has been one of the key factors in the success of the project from a very early time in the development.

Margaret Laffan: From an end user perspective, how has for what Julia's being used are being built in into applications? How does that change for you, what do you hear from your end users? What are they using it for? What are they ultimately creating?

Keno Fischer:

Julia is obviously a programming language, it's for general purpose. If you're doing computing, you could in theory use Julia. The addressable market for a programming language is very, very large. That said, Julia has traditionally been focused on scientific and numerical applications. That tends to be where a lot of the users are.

In academia, people doing things like image processing, machine learning research, and various sorts of simulation, economic forecasting, anything that involves simulation, or data analysis, astronomical image processing, those sorts of very demanding computational tasks you see a lot in academia.

In industry, the use cases tend to be slightly different. We see risk analysis, risk management in insurance. And in the finance space, forecasting of various sorts again. Things like pharmaceutical applications, drug discovery, modeling of various sorts of interactions in that space. Things like spacecraft simulation, things like oil and gas, things like engineering sorts of applications, optimization of various things. There's a company here in Boston who's using Julia for 3D printers, with all the computational geometry that's going on and figuring out how to go from a 3D model to a printed object.

Margaret Laffan: You’ve got a lot of depth and breadth.

Keno Fischer:

Yeah, definitely.

Margaret Laffan: I want to talk a bit around you starting and founding the company. Of course, there's a number of folks involved like Dr. Viral Shah, you've got Deepak Vinchhi, you've got Jeff Bezanson, Stefan Karpinski and Professor Alan Edelman. What was that like for you all coming together? Any interesting stories that you'd like to share about that?

Keno Fischer:

Alan, Jeff, Viral and Stefan were the original instigators of the Julia project at MIT. Alan is a professor over there, and he’s done research for several years, working out, okay, can we actually have a language that has both in the same system? Alan is a professor in the mathematics department actually, but he’s also set a foot in the high performance computing community, because he uses it for his research, his area of expertise is random matrix theory. So one of the very good ways in random matrix theory to make a discovery is to generate a lot of random matrices, see what properties they have. And then once you know it, you can prove it. So he's always done a lot of computing, but he is ultimately a scientist and user of systems like these. So he wanted a better system.

And then Jeff, Viral and Stefan all came on board back in 2009, to work on this. Jeff is mostly from the computer science perspective. He has a very, very deep background in computer science and language design. Stefan is from the numerics, statistical and data analysis perspective and we're all from the numerical computing perspective.

The four of them started working on this back in 2009, and then I started working on Julia in 2012. I ended up going to school up here, so I was fairly close to MIT. I spent a lot of time over there. Around 2015, we decided to turn this into a company, because we were seeing that academia was no longer able to sustain the volume of development required to keep this going. So that was when we brought Deepak on board, mostly on the business side, making sure with five technical co-founders, we have one person whose primary occupation is thinking about the business.

I think one of the key interesting things about the way that this has all played out is that both the Julia community and the company are extremely distributed. Our company has over 30 employees now but here in the Boston office, we only have four people. The company at this stage is still extremely distributed in that we have people all over the world. And that has grown from the way that the open source community operates. In an open source community, you don't have all the contributors sitting in the same spot, you operate on GitHub, with mailing lists, chat and remote communication. And that has translated over to the company. I think for the first year and a half of having founded the company, I didn't meet Deepak. He's based in Bangalore, India, a fair distance away. I think it was a good year and a half before we all got together and had an in-person company meeting. But of course, we talked many times.

Margaret Laffan: You obviously have a remote working model that's working for everyone coming together, it’s good for decision making, consensus building.

Keno Fischer:

Yeah. I think the experience of working on the open source project for many years and the ability to work effectively in a distributed team, and translating that culture into the company has really worked. I think having those several years where by the nature of the thing, we were forced to do things like record decisions on GitHub, making sure that there was a place where things were discussed and the reasoning for any change was visible.

Being forced into that discipline by the open source community has really made the ability to have a distributed company quite painless. I think if we hadn't had that experience, and if we would have been used to being in the same spot and doing discussions by walking over to somebody's desk and saying, let's figure out how to sketch this out, I think it would have been a lot more painful to try to start a company in such a distributed way. But for us, it's actually been fairly painless.

Margaret Laffan: Considering Julia is an open source language for data science with the large and growing community, how did you and the other co-founders decide to transition into starting the company in 2017? I know you've talked a small bit about this, was there anything else in terms of determining factors that really pushed you in this direction?

Keno Fischer:

We've talked a bit about how Julia as a project has evolved. And I think the formation of the company was mostly a natural outgrowth of that development. We started seeing tens of thousands of users using this on a daily basis, we started seeing people in industry picking it up and saying, how can we pay you to make sure that this is working well for us. And at the same time, we were still at MIT in a research lab, and MIT said, well, with so many users, this isn’t research anymore. So at that point, it became fairly clear that if we wanted to keep this going and wanted to sustain it, and wanted to grow it to the point where we wanted it to be, we would have to go outside of academia and found the company.

That happened around 2015, I was still finishing school at the time and Jeff was also still finishing up his PhD. For the first year or two of the company, it was fairly slow. But we raised some venture capital from General Catalyst and Founder Collective about two years ago at this point to be able to grow the company and support Julia as the language, and to make sure that both commercial and open source users are able to use the language effectively, but also to be able to invest in developing new applications. Machine learning in particular has been a huge focus area, both for the Julia community and for the company as well.

We didn't really predict this back when the Julia project started, but the rise of machine learning over the past seven to eight years, has been really a fundamental change in the way that software is developed. And it just so happened that Julia was perfectly suited for this revolution because machine learning fundamentally is a lot of linear algebra, it’s mathematics, it's weird data types and novel hardware and new programming paradigms, all of which Julia was designed to be able to address because these kinds of problems have been challenges in the mathematical computing ecosystem for a really long time. It's just now happening with machine learning, that these kinds of problems, really high performance matrix algebra, have been pushed into a much, much wider field of endeavor, because machine learning is applicable in so many domains.

So being able to address the research and production demands of machine learning models, and making sure that machine learning researchers have a language that is fundamentally mathematical and supports their mode of thinking about high dimensional tensors named dimensions on GPUs, this combinatorial explosion of different modes of working with data and with numerical abstractions. Being able to support that kind of thing would have been very hard in the academic setting. You get a grant to do this and maybe you can siphon off a little bit to do programming language development. But being in the company has really allowed us to focus effort and to really put sustained manpower behind these various endeavors.

Margaret Laffan: And when you think as well as you look to the future of Julia Computing, what's in your roadmap for the next five years?

Keno Fischer

We released Julia 1.0 at JuliaCon, our annual conference last year. I think that really marked a transition point because before that it was still frantically working on, should we rename this function slightly? Polishing every single bit of the language actually took several years. But now we've reached 1.0, so we have this commitment to stability, there has been a bit of a phase change in the orientation of the community and the orientation of the language towards more long term and more stable support of our user community.

As Julia Computing, we obviously want to support that particularly for users in industry who want to use Julia for production-critical applications. There are several ways we're doing that. The key way is through a product called JuliaTeam. The idea behind JuliaTeam is, if you're using Julia in a company, developing lots of private packages, and trying to figure out, how do I do this? What's the development workflow? You may not be software engineers, maybe data scientists and machine learning researchers. Taking all that worry, how do I do the software management, taking that away from people and introducing JuliaTeam. It provides the software development workflow for your team of data scientists or engineers, or researchers or what have you. And we have a lot of experience doing that, because we've built a lot of those kinds of tools for the open source community. If today you're developing an open source Julia package, we have standards for things like continuous integration, continuous deployment, benchmarking, testing, code coverage, all of those software development best practices that we're providing for the open source community, we're trying to bundle up and give it a very easy way to users in the enterprise, to make sure that people who have restrictions such as I cannot use the internet, my code can't be public, I’m working on something proprietary, and I can't share it with the world, to make sure that they have the tools available to them with the open source community as well.

As a paid product in that instance, if you're not going back to the open source community, you can at least give back by supporting the development of the language through the products that Julia Computing is offering. That's the business roadmap for Julia Computing.

The other thing is, things like machine learning pushing Julia in key application domains have shown it needed for new and improved technology, machine learning, various sorts of data analysis, image processing sorts of applications, and taking advantage of modern hardware. I think that’s the key theme in the post-1.0 world for Julia itself). The language is fairly, fairly stable now, there’s still things we want to change eventually, making sure that Julia is now applicable, and the best tool available for end users in these various domains, I think is the major focus of the roadmap.

Margaret Laffan: Keno, we look forward to seeing how you guys evolve in the progress over the next few years. Thank you so much for your time today. We really enjoyed having our conversation with you.