#111 The Rise of the Julia Programming Language
31 Oct 2022 · 43 min
In this Data Framed episode, host Richard Cotton interviews Julia veteran Zacharias Vulgaris. The conversation begins with a brief DataCamp promo and then moves into a deep dive on Julia’s origins, design goals, and how it bridges the gap between high‑level ease of use (Python, R, Matlab) and low‑level performance (C, C++). Zacharias explains who uses Julia—researchers, data scientists, engineers, finance and academia—and shares his personal journey from early experiments in version 0.3 to current production work. He compares Julia’s syntax and multiple‑dispatch model to Python/Matlab, highlights its “super‑power” of writing fast code without sacrificing readability, and outlines decision criteria for choosing Julia over other languages. The episode surveys the Julia ecosystem: essential packages (DataFrames, Stats, DecisionTree, ML libraries), visualization options (Gadfly, Plots.jl, Plotly.jl), package management (the built‑in Pkg REPL mode), IDEs (VS Code, Atom, Vim) and notebook environments (Jupyter, Pluto, Neptune). Zacharias discusses creating packages, the modest learning curve, and the importance of documentation. He shares success stories (cryptographic “Thunderstorm” cipher, deterministic clustering algorithm, data‑engineering framework) and notes that many corporate users keep Julia usage private. Advice is given for individuals (Wakelet resource list, hands‑on practice) and teams (lead‑by‑example demos, bridge libraries for Python/R/C, gradual migration). The conversation addresses common fears about ecosystem size, clarifies misconceptions about Julia’s speed, and points listeners to community support channels (Stack Overflow, Discord, Julia Computing, Reddit). Finally, Zacharias mentions his co‑founding of a conversational‑AI startup incubated at Antler in Amsterdam. The episode ends with encouragement to explore Julia as a tool that can both accelerate computation and empower developers.
Chapters
Hi, I'm Maggie, VP of Curriculum at datacamp, and I know firsthand how overwhelming it can be to keep up with the rapid changes in data and AI. But staying ahead doesn't have to be hard. That's why our curriculum team has curated the best learning content to help you and your team stay ahead. Covering everything from data and AI literacy for busy executives to cutting edge generative AI for developers, and everything in between. Whether you're upskilling yourself or your team, we make learning practical, engaging and flexible. It just works. Power your data and AI transformation journey. On datacamp.com. You're listening to Data Framed, a podcast by Data Camp. In this show, you'll hear all the latest trends and insights in data science. Whether you're just getting started in your data career or you're a data leader looking to scale data driven decisions in your organization. Join us for in depth discussions with data and analytics leaders at the forefront of the data revolution. Let's dive right in.
Welcome to Data Framed. I'm Richie and today we're talking about the Julia programming language. For the last few years, the big story in data science programming has been the rise of Python, which has overtaken R and taken the top spot for the most popular language. However, Julia has also quietly been gaining popularity and in the last year or two it seemed to have matured. Certainly I've started to hear examples of it being used by businesses to solve problems where Python wasn't a great fit for their needs. Feels like it's time to take the language seriously. So here today to tell us all about Julia is Zacharias Vulgaris. He's been the chief Science Officer at three startups. He's a longtime Julia user and he's the author of Julia for Data Science. I'm really looking forward to hearing his views on the language. Hi there, Zacharias. Thank you for joining us today on the podcast. So today we're going to be talking about Julia and yeah, I guess to begin with, can you just give us a little bit of context on what Julia is?
Sure, and thank you for having me here on this podcast. Well, Julia is a very particular kind of language because it is like in the middle between those two broad categories of languages that are either high level or low level. High level languages like Python, R and Matlab are very popular among people who are not very big on programming, while low level languages like C, C, Java and the like are very popular among developers who want to do some more efficient coding that usually lends itself to applications and anything that works on a computer basically very efficiently. So Julia tries to combine both being fast enough like low level languages, while at the same time accessible enough, which makes it more popular among people who are not very big on coding, but who know enough to code something interesting. So it is this kind of merge of the two paradigms, while at the same time it's also a merge of two different paradigms in terms of functional languages and object oriented languages. So it is a very interesting blend of different paradigms where at the same time something of a fun and interesting project.
So this is really interesting. I mean, I think of Julia as being in the same category as like Python, R, Matlab, sas, all these other sort of analyst programming languages. But you're saying it's also suitable for sort of more low level work as well because it's got this sort of increased performance, is that correct?
That's right. That's right. Although I imagine most people, especially nowadays, they use it for high level applications like designing and implementing a machine learning model, for example, or doing some data science work that involves engineering and things like that. But if you want to make a low level application, I don't see why not. Just because it was designed with a different audience in mind doesn't mean that it is limited only to that audience. And that's something admirable in the Julia team of developers that they really expand its functionality. Like originally it didn't have many libraries that made it useful for data science work, but over the years it got more and more of those because they saw there was a trend towards AI and this kind of advanced machine learning models that many people create for both in the scientific community and in the industry. So they are adapting language as time goes by to what is required. So I wouldn't be surprised if in the future they would find a niche in systems programming as well, because Julia can do all kinds of tasks really well, really efficiently.
Can you tell me a little bit more about who are the people using Julia? So you mentioned that it's a data analysis language, but are there specific like roles or industries that are really using Julia?
Well, anyone from a researcher to a data scientist to even a data engineer I would say could use Julia. I don't know many data engineers who use Julia, but I don't see why not. Like one of the first applications where I got involved in Julia was doing this kind of low level data engineering work to parse large amounts of text data. And you know, I could have done this with C because I already knew C at the time. But I said, okay, well, let's try this new language. It's easier to write than C and, well, at least for me and other people who are in this high level kind of programming paradigm. And it really paid off. So it appeals to this kind of people in terms of roles, but in terms of industries, I would say it appeals to people in data fields and also in finance and also academia, of course.
So that sounds like you have an interesting story in terms of how you came to be a Julia user. So you said you start off, you moved from C, so the Microsoft programming language for application development, into doing things with Julia. So can you just tell me a bit more about why you decided to use Julia for this?
Come to think about it, actually I started playing around with Julia even before then. So even before I joined Microsoft as a program manager, I was very much into programming and I had learned enough of Python to do something useful with it. And also I knew R before that. So at one point, okay, well maybe we can learn other languages that seem to be useful in this field. And I picked up Julia. Of course, I didn't go very far because it was still in version 0.3 or something. So there wasn't really that much to do with Julia. It was like one of these new languages that appear today and you say, oh, these are interesting, these are very promising, but will they be around in the next five years? I didn't know that and I had a career to worry about. So when I joined Microsoft and I said, okay, well this Julia language still exists. Now it's 0.4, I think, and why not use it? Why not use it parallel to other stuff? Because I wasn't obliged to use C or any other particular tool. In Microsoft there are people who are very open minded about what tools you use and as long as you deliver results, you don't really care. Because as a program manager you're not expected to code that much. If you do code, that's great, that's really great, they like that. But nobody says, okay, you have to use C or you have to use F or you have to use any other language. So that's why I said, okay, let's experiment with this. I also did a lot of Python during that time and I said, I saw that it actually worked. And over the years, even before it reached version 1.0, I saw that Julia had a lot to offer in my field as well. So I said, okay, well, maybe there's much more to it than just parsing large amounts of data in a data engineering Fashion, maybe there is something about predictive modeling that I can do with this language. So I explored it more and I discovered that not only can you do lots of interesting stuff in data science, but also you can develop new models, new processes, new heuristics, what have you.
And so for people who have come from like either a Python background or an R background, perhaps you can tell us a bit about how Julia is different. Like, how are the languages similar or different?
There are lots of similarities in the sense that, okay, it is code that you can look at and pretty much make sense of it. It's a bit like Python in that sense because the same Python is like pseudocode that runs Julia is not much different. If you are familiar with other languages that have this end command in their code, then it is very familiar. Like I was coming from a matlab background. Like, because I had mastered matlab at one point, I was even employing C scripts in Matlab to get more efficiency. So for me it was more intuitive. But also for someone who doesn't know about these kind of languages, but they understand the structure of a high level language, it is very intuitive and easy to adopt. And I remember seeing in this sext code editor on this site called Code Abbey where you can tackle different programming challenges in whatever language you like. And when I would write the Julia code to solve a problem, it would identify it as Python. So the syntax was close enough that they would get confused. Of course, then I would tell it, no, it's not Python, it's Julia. And I would say, okay, fine, so they're very similar, much more similar than people may think. Now, there are differences, of course, because every language has its own uniqueness, otherwise it would pass as a flavor of a matlab or Python. So Julia is first of all much more efficient. And the way it handles scripts is different. Like you can have the same function accepting different arguments and Julia is fine with that. And they call this multiple dispatch. So instead of having a different function for tackling matrices, for example, than the one you use for tackling specific vectors, you can have the same function name and the interpreter of Julia will understand, okay, well I'm being given this input so that the user must mean this. So I will call that right function, instead of having different ones, that can be confusing and difficult to remember. So there are differences like that. And I don't want to go into too much about the differences, but suffice to say that it's a different language, it has more in common with functional languages, although people can use it for object oriented language programming classes and use objects and such, but if you don't want to use that and you just want to use functions, that's also fine. So it's much more similar than different. That's the gist of it.
It is interesting that you mentioned matlab, because I noticed that the Julia syntax is incredibly close to Matlab syntax, and that's maybe it seems like that's the strongest influence on the Julia language, but. So while we're talking about the properties of Julia, what do you think Julia's superpower is? What's the thing where you go, oh, yeah, if I want to do this task, then Julia's the thing I have to use.
I don't know if it's a particular task or it's the whole environment, which allows you, even as a medium user who is not an expert in programming, to develop something that can run really fast. So instead of having to rely on someone else's code who may or may not maintain that code, you don't know that you can write your own code and expect it to be as fast as a library. That's not to say that you shouldn't use libraries, of course not. But if you can't find the library, you're looking for some specific task, maybe a niche application or whatever, you can develop the code from scratch, build it gradually, and have something powerful that you can use as a tool.
If you were trying to decide between Julia or Python or R or Matlab or whatever, do you have thought process for how you would decide to use one tool over another?
Well, it's not my decision always to make. It depends on the other people I work with. Because if everybody else in the team is comfortable with Python, I would use Python. So I would take that into account strongly. And I don't want to be like eccentric in the use of the language. If other people are open to using Julia, great, maybe I can lure them into using it more. But if somebody doesn't like Julia, I cannot really tell them, okay, use that, because I use it. And of course, it also depends on the problem domain, because if there's a very statistical problem that is tackled, maybe R is the best tool. I don't know it is designed for this purpose anyway. It has a plethora of libraries and sophisticated scripts around this kind of work. And the interface is pretty straightforward. So you can show it to someone who doesn't know much programming and they can understand what you're doing there with showing the notebook, for example. The same with Python. I mean, if somebody's used to using Python and they know the specific libraries, okay, maybe stick with those. I mean, if there's a particular library, that's what we need, really. Well, let's go for that. If we really care about efficiency and speed is of the essence, then maybe Julia is the best option. I'm generally more agnostic now about what language to use. As long as I can get the job done quickly without creating too much friction, I'll go with that.
That's a very interesting point about the idea that particularly in a corporate setting, when you're working in a team, the particular choice of language doesn't matter as much as just having the whole team agree that everyone's going to do the same thing. So you can sort of work in harmony. So yeah, that's very interesting. Perhaps it's different for individual develop where you get a bit more freedom in terms of choosing what you want to do. All right, so you talked about there being different libraries or packages for different tasks within Julia. So the functionality is split across into discrete areas. Can you talk us through what are the most common or most important packages for doing data science with Julia?
So, first of all, data frames is essential because it allows you to import tabular data in a dataframe object. There are things like DecisionTrees, JL, SciKit Learn, which is popular from Python, and several other ones like MLOps. I don't remember all of them by heart, but there's also different notebook packages, but I guess we can get into that another later. And there's also the statistics package, for example, which is very useful and people don't think about it. It's a very powerful library for a statistical kind of work. And there are also other packages that are more supplementary, like the pkg, which stands for package, which allows you to import other packages if you're on notebook in a notebook environment. So you don't have to go to the repl and do the package processing there and then reload the kernel. And that can be time consuming. So these kind of packages are, I think, a must. But what package you need is something you can easily find on your own. I wasn't really born with that knowledge or I didn't really read one book that found where I found all this, this information available to me like that. The documentation that the juju community has around the different packages is really good and really designed from a learner's perspective as well. So it's not like some impersonal kind of documentation that you think that it appeals to People who already know the language really well now they have designed it so that even a newcomer can understand what's happening, what packages are there and what you can do with them. And beyond that, there's also other people who are enthusiasts, Julia, who have websites where they explain different packages. So I wouldn't worry too much about remembering which packages are there and to use them, but remember that there is a package for the stuff that we need to do in data science and related processes that is there. Even if it's not really as mature as the packages in Python or R, they are functional enough to create something useful.
So I like that. The first package you mentioned was the Data Frames package. Obviously on the Data Framed podcast we're big fans of Data Frames, so that's really good to know. I'm curious as to what the sort sort of the culture is around packages. So for example, in Python for data visualization there are just lots of different packages available. So you've got matplotlib and Seaborn and Plotly and Plotline and Holoviz and all the rest. So there's all these competing different packages. But in some cases with for example machine learning, you've only got really SciKit, learn and Pycarat, they're the two main ones. So with Julia, do you see cases where you have lots of different packages competing with each other, or is it more that you just have one or two that are just the standard tool to use for a particular task?
There are some packages that are competing with each other, but they're not that many. You see that more often in the data visualization applications. Like there are several plotting libraries. If you don't really care so much about data visualization, you just want to get a plot out there and perhaps export it as a PNG or whatever. I think Gadfly covers you for the most part. And if you want to have the more established and more go to package that now is promoted with Julia Plots, JL is fine as well. These two packages can cover most use cases, I believe. Now if you want something more elaborate, I'm pretty sure you can find it. The people who make those packages are very happy to document them and promote them. But one thing that I really enjoyed about Gadfly is that first of all its name is really cool. But also it was all developed in Julia because other packages you find that, okay, there are more like wrapper functions around pre existing packages elsewhere. But Graph was developed natively entirely. And beyond that, if you're really very keen on Plotly for example, there is a plotly package as well in Julia, so you don't have to limit yourself to the packages you find in other high level languages.
So in Python, package management is this sort of horrendous thing where you've got a choice of anaconda or the pypy stuff. And just keeping track of having the right packages and the right versions is always a bit of a nightmare. So what's the package management situation like in Julia?
In Julia it's much more straightforward. You just press one key when you are on the repl, for example, and it takes you to the package management mode and there the only commands you have available to you are related to packages. So you can first of all list the packages that are installed, you can add a new package, you can update all the packages and things like that, and whenever you are done with it, you can just exit that mode and go back to the normal prompt. There's a variety of things that are really good in this particular package manager, and I believe this one of the first things that was tackled seriously in the language, one of the creators of the language actually handled this aspect, if I remember correctly, and that's one of the strong points of version one onwards, is that they had really got this down. And by that I mean that, okay, you don't have any problems with dependencies missing and things like that. Okay? When you install a new package, Julia recognizes that, okay, this package needs this and that to work properly, so it installs it automatically. Also, when you update a package, it doesn't update the package, you update everything that is that needs updating. So make sure that everything works well and together with each other. And that's a very strong point in my view. And the fact that you can also do that while you are on a jupyter notebook, for example, that also makes it easier so you don't have to go out of the shell and do PIP install or whatever package manager you're.
Using if you want to develop your own Julia package. Is that something that's easy to do or what do you need to do to get started creating your own Julia package?
I can't speak out of experience on this part because I haven't developed a package and I don't really plan to, but I know someone who is not a developer professionally, but he knows Julia well enough, like he probably knows it more than most people and he developed a package on his own without too much concern. So from his experience I can draw that it's not really that difficult. Also, I have seen people develop new packages over the years. So it's not really that challenging to develop a package, a new package. But I imagine the hardest thing would be not to make the package, but also to create enough documentation for it to make it useful and also to maintain it. Because over the new versions of gui, the package may not work properly. So you need to update the code, maybe add new features and functionality to it. So it is a big project. It's not something to be taken lightly.
Okay, fair enough. All right, so I'd like to talk a bit about the sort of the tool ecosystem for working with Julia. So Julia is of course like the due part of Jupyter notebooks. But are Jupyter notebooks the standard way that people will write Julia code or other other tools?
It depends on who you're asking. Because people in my line of work prefer to work in a code notebook kind of environment, or code book as I call it often, because it's much easier, you see the results right away. You can also demonstrate your work to someone else who doesn't really understand programming that well, but they understand, okay, well, you write this code and creates this, and it's also neat and tidy. You can put markdown as well in it, and also lots of text. You can also put hyperlinks and things like that. So it's like a fully blown kind of report kind of of thing, which also includes code, so you can actually change it on the fly. So for someone in this kind of work, it makes more sense to work there. But if you want to develop something that is more coding related rather than results oriented, then perhaps an IDE will be a better choice. I work with both Jupyter notebook, even though it's by far the most mature codebook environment is not the only option. And there are a couple of other ones that are native to Julia, like Pluto and Neptune. And just to be clear here, we're not talking about the Neptune things that you find on aws. The Neptune notebook is a different project in Julia which works with Julia code only.
Interesting. So these are sort of rival formats then, you're saying?
In a way, yes. But at the same time. I mean, you can use both at the same time and not feel that you have to choose one or the other. Like there are different packages in Julia that allow you to to write code in Jupiter or Neptune or whatever you like. If you want to showcase code to someone who already has Jupyter, maybe it's best to write it in a Jupyter notebook. If you just Want to write code in a notebook environment and then make a PDF out of it. For example, Neptune will work fine. And the plus of this particular option is that the Neptune notebook is written in Julia code. So it's not a JSON file, it's a Neptune file, which is basically a Julia file. So you can access it through an IDE as well or a text editor, and you can actually use the code even if you don't have Neptune installer. You don't care about Neptune. You can just take the Neptune notebook and put it on a text editor and make a script out of it. Because in essence, it is a script, the whole thing. The drawback is that you don't see the results of what you have done. It doesn't store the results.
So it sounds like the Neptune files are fairly close to something like R markdown or quarto reporting files from the R community. So you also mentioned IDEs. So what are the IDEs people use for writing Julia code?
Well, there are several ones. The ones that are quite popular depend on who you're asking. But this Atom id, which is popular across different languages, including Bash, also works with Julia and has a really good dictionary that can recognize Julia code and also alert you of potential errors. And there is also the Microsoft one too.
Oh, VS code, is it?
That's right, yes. And it used to be a different IDE that was only for Julia, but now this is part of VS Visual Studio from Microsoft. So these are the main ones, I think. But you can also use Vim if you are into that, and other editors. I mean, it's not really that important what editor use, as long as you, you know it well and you're comfortable with it environment. It helps you develop code and edit code fast.
Absolutely. I'm sure there's like three people listening going, everyone should use Emacs, but it's a very niche choice, I think. Have you seen any success stories with people using Julia?
I've seen some, yes. And the problem is that it's not really something you read about often. Like you won't see many people on LinkedIn talking about, I have a an amazing project in Julia. Unless they are usually tied to the Julia community, usually directly. But there are lots of success stories and these manifest usually in particular presentations in conferences, especially the juliacon and places like that. So there are many people who have done great work, at least in the scientific community and elsewhere using Julia. The one small success story that I have to for myself is that I have developed algorithms that I wouldn't even think possible to make them in another language using Julia because they involve lots of computation and to make them scalable and work in a deterministic fashion is not something you can easily do elsewhere. Like I was always into making niche algorithms and implementing them, and I have tried that in different languages. But after a while you realize that the speed of a language is also important, but also the fact that you can make applications easily and have them optimized using specific tools in Julia can also facilitate that. So I think the best success stories in Julia are yet to come.
So you were talking about writing your own algorithms in Julia. Can you give us an example of an algorithm that you wrote?
Sure. Although I haven't publicized them. One of them involves cybersecurity as a cryptographic system that handles large files as well and make sure that they're encoded in such a way that it's not easy at all to understand what's happening and to try to reverse engineer and break the cipher. This is what I call the Thunderstorm cipher. Beyond that, I did most of my work in data related applications. I think it was last year I made this script Optimal Clustering because it's a deterministic clustering algorithm that is pretty much self directed. It doesn't need much input from the user, and it can handle scenarios where there's not a very clear blob of data. K means does, for example. I employed a series of different heuristics to make that possible and it can still use improvement, but this is something that I'm pretty content with so far. Also, another algorithm which is more like a series of algorithms is like a framework I have developed for analyzing different kinds of variables for data engineering kind of work to facilitate this kind of processing without having to worry too much about what are the variables, like what are distributions, are there outliers and stuff? No, this framework handles all that on its own, so it's entirely data driven. And the data driven approach, I think can shine in places with tools like Julia, because Julia can handle computations really well, lots of computations really fast, so you don't have to rely too much on assumed knowledge about the data.
That seems like a pretty useful feature, just like not having to make too many assumptions about what your data is like. So we talked a bit about successes with Jupiter. I'm also curious as to where people might go wrong when they try and adopt Jupyter themselves. So have you heard about any cases where people tried to use Julia but then decided it wasn't a great fit?
I Haven't heard any cases like that. But I can understand why some people may be discouraged or deterred, but probably has to do more with the company dynamics. Like if the company doesn't endorse the use of new languages, for example, or it's focused on specific languages because they have lots of legacy code in those. I can imagine how somebody who wants to do something in Julia, even though they can't, they're not allowed to. But I don't know anyone who said, okay, I tried Julia and it actually sucks. No, I never heard anyone like that. I have heard people who said, okay, I tried Julia, but I actually found that Lua is fast. Okay, maybe in some cases Lua is faster, I don't know. I mean, Lua is a very fast language. It has been around for longer than Julia. It always depends on the application, I guess.
So maybe taking that on a personal level, is there anything you wish you knew when you started learning Julia?
Well, lots of things. First of all, I wish I knew that it was going to blow up so much. Like in the beginning it was like a niche language. And the only book I could find about Julia, which I didn't really bother to buy even because it only had a couple of chapters about it, was like an introduction to some new up and coming languages. And it had three languages at least in that book, and one of them was Julia. So you can imagine the covering of that language was very basic, very shallow even. And yeah, I understand because somebody didn't want to put all their money in an up and coming language which they didn't even know it was going to make it. So yeah, I wish there was. There were more resources. I wish there was a bigger community when I was learning it. But. But at the same time, I don't know if that would have intrigued me as much in the language. I may have learned it faster for sure, but I don't know if I would have learned it deeper. So it's really hard to think about these hypotheticals. But I definitely wish I would have met more people in proximity to where I was who also used Julia. Like the first person I think I actually met in person who used Julia and was actually any good at it, was in Seattle at least a year or two after I started training, playing around with Julia.
Alright, so I guess now the ecosystem is a little bit more mature and there are some other resources out there. Just if you're an individual, how do you think you should get started learning about Julia?
I believe I have contributed in the resources of this Episode a particular Wakelet. A wakelet is a kind of collection that has a lot of material in various formats, usually links, and allows you to, with one link to share lots of content. So I have developed this quick as an introduction to different resources that somebody can use, most of which are for free. And that can be a good starting point. So instead of telling you try this and the other, and you probably forget half of what I say, just try this stuff in the wakelet or most of this stuff to get not just knowledgeable about Julia, but also inspired about its potential. And another thing I would say is, okay, don't rely on just on what you learn theoretically, intellectually, but build some muscle memory about it. Because the only way to really know the language is when you start using it. Find some interesting problem that you are tackling, even if it's already solved either by you or someone else, doesn't matter, but try to solve it in Julia and see how it goes. See where you get stuck and how you can get unstuck. Talk to other people, even if it's in a problem solving kind of fashion, to see how you can tackle different challenges in Julia. And this is how you actually can learn it better and this deeper.
And suppose you just want to have like your first few hours of Julia coding. What are the things that you need to know first in order to get started?
I think some knowledge of programming would be useful. If you don't have any of that, then start with something very simple, like the simple programming challenges that you may find on places like Project Euler and things like that, some mathematical application to get you started. Also try to see how you can implement something you have already done elsewhere. The code Abbey actually is a good place to start for any language that it supports. And that's one of the places I actually, I still use to refine my programming skills. So things like that, like very trivial examples, but done properly, can really help you develop confidence and skill at the same time.
Moving from thinking about an individual to a corporate setting. How would you go about adopting Julia for your team?
First of all, it depends on who you are, what your role is in that team. If you are the team leader, it's a bit easier because you can tell them, okay, well this is Julia. I can provide them with resources to learn it and I can show them code I have developed and let them play around with it and get acquainted with it and understand it's not really something they can't handle. Because I imagine in a data science team people would already know A bit of programming already, especially, especially if they are more senior to the scientists. So that's one approach. If I were in a team, not as a leader but as a member of the team, I would try to showcase it with an example, try to do something that would normally do with Python or whatever other tool I was using in Julia and show them side by side. Okay, this is the Python code, this is the Julia code, and this is the performance in one and this is the performance in the other one. And show that this can also live in a jupyter notebook that we normally use. And this is a more convincing approach, I believe, than telling them, okay, well look, Jude is great. Look what this other person says about it. Look at this nice book about it. No, these are intellectual knowledge, but this is not convincing enough. If you show them that this thing actually works and I can do it and I don't need to go to a course, although that would be nice. But it's not something that is too far ahead. Like it is something we can do relatively soon. And look, there's also these libraries that you can run either in Python or in Julia to migrate code from one to the other. I should have touched upon this sooner, I guess, but there are bridge libraries between Julia, Python and R and also other places like, I think there's also for C as well. So you can import C code in Julia and probably other ones as well. Since the time I have done this research, I've even written an article about this on AI Gen 3. So if you have already code in Python, you can easily use it in Julia and vice versa. So you don't have to one day say, oh, we don't use this anymore, we go to the new language and forget about the old one. This can be done gradually, so if you have a plan of this migration, then it is much more feasible and much more risk free in a way.
So I really liked your point about showing some sort of business impact really quickly because that's going to be important to make the managers sort of see that this is going to be a viable thing. But I'd like to talk a little bit more about this interoperability because it does seem a bit like if you're adopting a new language, then there's going to be existing projects already there. So is it, Are you saying that it's possible to have Julia and Python within the same project? Does it work like that?
It depends on what you mean by project. Like if it's a very large project. Yes, definitely. There's some Components, maybe certain parts of the pipeline can be done in one language and others in another one. So one language can yield its outputs in a CSV or JSON or whatever, and the other one can pick them up. Some of these functionalities can also merge in the same notebook with a bridge package. But if you really want to go for efficiency and less maintenance overhead, it's best to have one language. So this having both languages at the same time is more like a temporary situation. I wouldn't recommend it for the long term.
Okay, so you're saying that ideally you want to standardize like all the projects or all your work, all the analyses in your team on a single programming language just for efficiency?
Yes. And that's doable? I mean, you can easily migrate from one language? Not easily, but it is doable to migrate from one to another, especially if they can work together.
All right, and is this interoperability you mentioned with Python, is this also available for other programming languages?
Yes, you can have interoperability between Julia and R as well as Julia and.
C. And how about low level languages? Because I know things like Python are, if you want to make your code go faster, you can call C or Fortran or C. So is the same true of Julia, or is that not a necessary thing because it runs faster?
It is possible to leverage C if you want, but I don't know anyone who does that. And to be honest, I was surprised there was even a bridge package between Julia and C because they're comparable in efficiency. So it doesn't make much sense to do that. It's like for someone to have a bridge package between Nim and C, like Nim compiles in C, so it doesn't need to have a bridge package in C. The same with Julian doesn't compile in C. It's completely different in terms of how it works. But it's comparable to C, so what's the point?
Fair enough. So that seems like C is sort of not necessary to worry about for most people. All right, so I'd like to address one of the sort of big fears that a lot of people have in terms of getting started with Julia, and that's that maybe the ecosystem isn't big enough. Because I think Julia is sort of like the fourth most popular data science language after sort of Python, R, Matlab. So for companies in particular considering adopting Julia, how justified are those fears that the ecosystem isn't big enough yet?
They're not really realistic fears. Like, I understand where they're coming from. Okay, well, yeah, it's best to bet on a language that is more established, there is more people, more libraries and all that. But 30 years ago Python was very new. Would you have thought of investing in Python back then? And if everybody thought the same way that those people with those fears think today, nobody would have ever shifted from Fortran and C ever, or Java. So the fact that there are new languages coming about over the years shows that there are people willing to take a chance on something new. And in the case of Julia, even if it's not as big an ecosystem as other more established languages, I think the risk is minimal. And partly because of the bridge libraries I mentioned before, and partly because it is a growing community. So it's not like other community has been stagnant for the past few years. So you're entering some kind of niche territory that only you and a few other people are going to care about. No, this is a growing community and it's not like a growing community of amateurs. There's also people like vested in education who are investing in Julia. There are people who are teaching courses in Julia, There are people who are doing serious projects in Judea. So it's not a hobbyist language. I think I have to make this very clear. There are languages out there and I always like to explore, explore new languages that come about because maybe there's the next Julia out there that's now in the works, but I haven't seen anything like that, at least in the data science area.
Okay, so are there any sort of notable companies or organizations that are making use of Julia?
I know that many universities are looking into that and they have already had courses in Julia about companies. I don't think I know many. And there's a good reason for that. Virial Shah said once, I think it was in a conference, is that he and his team had advised some people in the fintech industry about Julia, how to optimize the use of Julia, and he found that those people didn't really want other people to know they were using Julia. That was a few years ago, so maybe now it's more well known. But if you are a company right now and you found that actually you can do things much more, much faster using this new technology, which is not that new. But if you have discovered that you have proved it to your stakeholders, would you go about demonstrating that to everyone, even to your competitors? So I think that's how it is now with Julia. There are many companies who may be using it, but they don't really, they're not very open about it yet.
So that actually sort of aligns with the things I've heard. So the main companies I've heard that are using Julia have been involved in financial technology, but but they're so secretive about what they're doing. It's very hard to find out many details on what's going on, but it seems like maybe that's where the heart of the Julia community is. So on that note, I'd actually like to know a little bit more about like who's involved in the Julia community. So for example, where do you get community support if you want help with Julia?
Well, there are different areas where you can get support, like immediate support. Like you have a problem, a bug now and you want to solve it as soon as possible. One of them is stack overflow. It's pretty well known among all people who do any kind of coding that you know. It's a very big community of users and many of them are experts as well who offer some kind of help. Maybe it's not the answer that will they solve the problem straight away, but they will guide you towards the answer. You can have online conversations with them in text format, so other people can see that and benefit from that. So if you can't find your question already there, you can always ask a new question and get some feedback from that. Beyond that, there's also the Discord server of Julia community, which is. I haven't used it much, but I know it's there and there are many people talking about anything Julia related. And beyond that, if you are like a company especially, you can also ask the Julia Computing company who provide this kind of consulting professionally, like they know the language better than anyone. So any question you have probably have heard before, so they can answer it pretty well now. Beyond that, I think there's also the Reddit subreddit somewhere that has Julia. So people ask questions there. If you are into this platform and I'm sure if you search beyond that, you can find other places like Quora even. I don't know.
So, last question on Julia. Are there any misconceptions about Julia that you'd like to clear up?
There's this misconception that, you know, just because it's fast and everything. No, it is fast in general. Yes, it is really well done. It can handle certain computationally heavy tasks really well, but it doesn't mean that it's going to be fast. In your application specifically, you may have a very niche kind of simulation that involves a very particular kind of data that actually it may not be the best option for you. So just like you see someone who's really good at math, okay, that person may not be very good at physics, for example, and vice versa. It's the same with the programming languages. Julia is good overall and there are lots of benchmarks that have have done and they continue the update the benchmark graphics where they show how they compare with other languages for specific simple scripts they run. But it doesn't mean that it's going to be perfect for you. So in this case, I would say approach the whole matter with a bit of, with a grain of salt, like yes, Julia is fast, but it could be that there's another language out there that is faster. So if you are into programming and you want to experiment with a different language, go for it. Don't take any one's word for it.
So before we finish, I know that you've just founded a new startup. Perhaps you can tell us a little bit about that.
Well, I'm actually more of a co founder. My co founder had the idea and started working with it and then he got me involved and I jumped to the opportunity straight away because it was a really interesting idea and it seems to have a lot of merit, not just as technology but also commercial aspects of it. So yeah, I'm now one of the two co founders at the moment of this company that started in this incubator in Amsterdam called Antler. Antler is the incubator. We don't have a name for the company yet, but we are looking into conversational AI to help training of specific professionals. So the idea is to use AI for helping people instead of replacing people, which is something that many other AI based companies tend to do do. So it seems like a simple idea but the complexities of it are more than meets the eye for sure. But it's a very interesting challenge. It's definitely doable and it enables us to not just get to know the technology, but also the usefulness of this technology in the real world, helping real people with real problems they face every day. So I don't know if any of the listeners are interested to work as developers or data engineers or some something along these lines with us. If so, yeah, we can always have a chat about this and available on LinkedIn to connect and take this further.
Super. Sounds like a very exciting new idea and certainly I like the idea of AI being used to help people rather than to replace them. So thank you very much, Zacharias. I learned a lot about Julia. This has been really interesting and good luck with your new startup.
Thank you very much and thanks for having me.
You've been listening to Data Framed, a podcast by Data Camp. Keep connected with us by subscribing to the show in your favorite podcast player. Please give us a rating, leave a comment, and share episodes you love. That helps us keep delivering insights into all things data. Thanks for listening. Until next time.
More from Richie
#359 My Best Friend is AI with Valerie Tiberius, Professor of Philosophy at University of Minnesota
#358 How AI Agents Will Work While You Sleep | Ruslan Salakhutdinov, Professor at Carnegie Mellon
#356 The Forecast for Time Series Forecasts with Rami Krispin, Senior Manager of Data Science at Apple
#355 AI's Impact on Databases with Shireesh Thota, CVP of Databases at Microsoft
#354 Beyond BI: Decision Intelligence with Graphs with Jamie Hutton, CTO at Quantexa
#352 AI Agents at Work: What Actually Breaks (and How to Fix It) with Danielle Crop, EVP Digital Strategy & Alliances at WNS
#351 Will World Models Bring us AGI? with Eric Xing, President & Professor at MBZUAI
#350 How to Make Hard Choices in AI with Atay Kozlovski, Researcher at the University of Zurich
#349 From AI Governance to AI Enablement with Stijn Christiaens, CEO at Collibra