CppCast - Julia

Episode Date: March 31, 2022

Logan Kilpatrick joins Rob and Jason. They first talk about a GDB frontend and an IDE like autocompletion tool for the terminal. Then they talk to Logan Kilpatrick about the Julia programming language. They discuss the origin of the language, and where it fits in today amongst other languages in the scientific computing domain. News Seer - a new gui frontend to gdb IDE style autocomplete for your terminal Nvidia: 'We are a Quantum Computing Company' Links Julia Sponsors Use code JetBrainsForCppCast during checkout at JetBrains.com for a 25% discount

Episode 343 of CppCast with guest Logan Kilpatrick, recorded March 30th, 2022. This episode of CppCast is sponsored by JetBrains. JetBrains has a range of C++ IDEs to help you avoid the typical pitfalls and headaches that are often associated with coding in C++. Exclusively for CppCast, JetBrains is offering a 25% discount for purchasing or renewing a yearly individual license on the C++ tool of your choice, CLionLine, ReSharper, C++ about another GDP front end. Then we talk to Logan Kilpatrick. Logan talks to us about the Julia programming language. Welcome to episode 343 of CBPCast, the first podcast for C++ developers by C++ developers. Our host, Rob Irving, joined by my co-host, Jason Turner.

Jason, how are you doing today? I'm all right, Rob. How are you doing? I'm doing okay. I'm not going to go over everything we were talking about before the show, but I have had some issues on my home PC. I had to reinstall Windows last night. Everything seems to be working now. Came down to the wire. Yes, came down to the wire having to install Audacity

and all the other stuff we use while doing the show, but everything is set up now. I am doing well. I did end up officially announcing the Game Jam that we did a pre-announcement on with the show. And the game jam is going to officially start tomorrow at, excuse me, not tomorrow, tomorrow from the airtime of this video, maybe something like that, at Friday, 12 UTC, noon UTC. And I will announce the topic then, but I already know that there's plenty of people

that are trying out the template project that I have as the basis that I want everyone to start from. And a few little issues being reported, nothing major. So if anyone's interested, when you listen to this, it's definitely still not too late to join in because you have a full weekend, a full week and a full weekend to get it done. It's not one of these tiny short game jams. I didn't want people to burn themselves out and their first experience with game programming. That would be terribly ironic, wouldn't it? So yeah, I think it'll be good. That's good. I'm glad you said they have some time because I was wondering if listeners don't tune into this until the weekend, but it's good to know they can still check it out. Yeah, if they tune in the weekend, then they still have a full week and a weekend to get to it.

And I think that's, you know, a lot of game jams are more like three or four days or something like that, and I'm giving people basically nine days. Okay, very cool. Well, at the top of every episode, I'd like to read a piece of feedback. We got this tweet from last week's episode from Hoodie saying, Hey, CPPcast, I really enjoyed listening

to your most recent two episodes on Swift and Zig Interop. Have you by any chance already planned to complete the trifecta and talk to David Tolney about his CXXRS project? If not,

I think it would be a great topic. CXXRS, I believe I clicked on the link and it's a C++ Rust InterRS project. If not, I think it would be a great topic. CXXRS, I believe I clicked on the link and it's a C++ Rust interop project. I think it would have to be with that URL, the Rust people like.rs. Yeah, safe interop between Rust and C++. So we have not talked about this before. We did do a Rust episode a long time ago, didn't we? We did, and we touched on the topic, right? I've touched on

the topic with my cousin a while back, but last I knew the story still had a lot to be told. So it'd be interesting to get someone on for sure. Yeah, definitely. We can look into this and maybe find a good guest for it. Well, it looks like they're recommending a guest. So right. Yeah, true. David Tolney and it's his project. So yeah, we'll have to reach out to him. it. Well, it looks like they're recommending a guest. Right. Yeah, true. David Tolney. And it's his project. So yeah, we'll have to reach out to him. Well, we'd love to hear your thoughts about the show. You can always reach out to us on Facebook, Twitter, or

email us at feedback at cppcast.com. Don't forget to leave us a review on iTunes or subscribe on YouTube. Joining us today is Logan Kilpatrick. Logan is the developer community advocate for the Julia programming language, as well as a senior technology advocate at Path AI, where he leads machine learning and open source advocacy.

Logan is on the board of directors at NumFocus, the organization behind open source projects like Jupyter, NumPy, Pandas, and more. He's also on the board of Django Events Foundation North America, the nonprofit behind DjangoCon US. Logan, welcome to the show. How's it going? I'm super excited. This is going to be a blast. You've got lots of different open source advocacy. I just chucked my personal curiosity of like, which of these things are like official paid roles and which of these things are things you're doing just for fun?

Yeah, no, that's a great question. So my full-time job is at Path.ai. I was previously at Apple working as an applied machine learning engineer. And then technically, I do get paid for the Julia work that I do, but it's a very part-time, much less official sort of thing. But again, I just do a ton of stuff in the Julia ecosystem in half of the last two years. And then the board positions that I have are both unpaid board positions. So is it correct to say numpy or should we say numpy? That is a contentious question. And I say numpy, but I do think that there's people who say numpy. So I don't want to step on anyone's toes.

Okay, cool. Right. Well, Logan, we got a couple news articles to discuss feel free to comment on any of these and we'll start talking more about julia okay i love it okay so this first one is a post on reddit it's a link GUI for GDB, which I've never really used much of GDB, but it looks painful to me. I think this might be the second or third front end of GDB that I've thrown in some random news article about just because, you know like tools yeah yeah this has some interesting visualizers in it yeah you can just click on a q array or whatever and it will like actually show you the data that's in it not just as a table but what could give you a graphic visualization

or whatever it's pretty cool looking yeah got a memory visualizers you can just look at a block of memory and there's like some actual string encoded data. You could read it. It's pretty cool. Logan, do you have a chance to look at this? Yeah. And truthfully, I think it's above my pay grade. I was looking, I've never used GDB before, so I don't know what the front end situation is. I mean, as far as front ends go, this looks nice and actually useful, but I'm unfamiliar with the context in which I would actually use this as a developer. Ah, so for the sake of our listeners too, then, if you don't know anything about GDB, it's basically just a command line interface to your program. Like you have just a, I guess a REPL, for lack of a better word, and you can step through instructions, step through

statements, set breakpoints, whatever, but you have to know all the commands to better word. And you can step through instructions, step through statements, set breakpoints, whatever, but you have to know all the commands to do that. And there's a handful of front ends and visualizers. CLion comes with one where you can actually click and set a breakpoint on this line of code and not have to know exactly what line and what file and whatever and know the command for setting the breakpoint, whatever, for debugging.

Yeah, it seems cool. It also seems like it's very early on, which is also kind of interesting, like only a two-month-old project, which you don't usually see. It looks like they've made a lot of progress in those two months, too, which is also kind of cool. Sometimes you see a project like this and you don't hear anything about it until it's ready to go. And then all of a sudden you're like, yeah, like 1.0 whatever go for it and it's like a super awesome project and I'm just like waiting for the day where I managed to come up with some super awesome project and I release it on the world and it's amazing and everyone says this is amazing

there's no fun in that you got to release it and it you know, pre-alpha stage just so you can get all the feedback. Yeah. Okay, next is another post on Reddit. And this one is an IDE style autocomplete for your terminal. And looks pretty cool, like being able to get autocompletion in the terminal. And it has, you know, support for lots of C++ tools. Definitely a cool project. Yeah, something escaped me when I first saw this

and I had to dig into it to realize it is Mac OS only. Oh, is it? Okay. I don't realize that either. Only one of the three of us could use it. I'm sorry. Well, if you are a Mac user user definitely go check it out and then last thing we have here is a post from nvidia it's just an announcement saying we are a quantum computing company there's a note in here about they're working on a quantum c++ compiler i believe

sounds pretty interesting i don't really know what that means, but... I was reading this article. It's interesting. The person who is making the statement that we are a quantum computing company is the person who is leading quantum computing stuff at NVIDIA. So I'd be interested to see if they,

you know, if this is more of this person's personal opinion because it's the work that they do on a day-to-day basis or whether the whole company is really bought into the vision of, you you know we're going to build quantum computers well i do know because one of the nvidia team came and shared at my not officially shared at my meetup but shared at my meetup last time i had one that nvidia is hiring a lot of compiler engineers right now so there's a lot of job openings if you're interested in that.

And from what I understand, many of them are around this quantum compiler thing that they're doing. So I think there's a fairly large investment at NVIDIA happening for real on this topic. I think I saw on Twitter someone saying compiler experience is definitely a huge plus for that type of role, and they'll teach you the quantum stuff. What if I only understand the quantum realm and I don't know anything about compilers?

I just watched Ant-Man. So, yeah, it feels appropriate. It's relevant. Yeah. All right. So, Logan, for listeners who haven't heard of Julia, could you start us off by telling us a little bit about the language? Yeah, sure. So Julia is a high-level dynamic programming language. I would say it's, for people who are very deep in programming language, it's sort of similar to Lisp.

For people who don't know what Lisp is or sort of aren't exposed to it, I actually like to think that it's kind of similar to Python as far as functionally how you use the language. So it's a high-level language, tactically sort of similar to Python, but you can sometimes, in many cases, get sort of execution speed with your code that's similar to a language like C or C++. Obviously, that's not every situation, so you can't just rewrite all your code. And Julia, if you're using C++ and get that performance out of the box, there's oftentimes things that you have to do. But sort of the general idea is that Julia is set out to solve the two-language problem, which is that you do all your prototyping in a language, high-level language like Python.

And then when you want to take something into production, you would have to rewrite it in C++ or C. So Julia is hopefully high-level enough that it's easy to use. And it's also fast enough that you won't have to rewrite anything when you go into production. So we generally don't talk about that kind of performance when we talk about a dynamic, and I assume you mean dynamically typed programming language when you said exactly. Okay. So is it still compiled? Does it do like internal gradual typing or something like this? Yeah, Julia is still compiled. It's, I think, split between just-in-time compiled. There's some people say just-ahead-of-time compiled. So it is technically compiled. Oh, interesting. But you never have like a make script. You just run it and the interpreter does

the right thing compiling it as you need the code. Exactly. So that would be the big difference between other compiled languages in Julia. Okay. That explains how you could sometimes get the performance you're talking about. Yeah. So we've mentioned Julia a couple times recently on the podcast in various show notes, news articles. But I was surprised to see the language has actually been around for 10 years. Could you tell us a little bit about how it got started, what the motivation was? Yeah, the language was actually, development started back in 2009. And at the time, basically all of the folks who co-created the language, Stefan Karpinski, Veral Shah, Alan Adelman, Jeff Vizanson, and some other folks,

were sort of all working in different capacities together on separate projects. But they all had this idea, which is they were trying to use sort of the computational tools at the time, MATLAB, maybe R, I don't know if R was around then, or popular, but mainly MATLAB. And they were trying to do all this computational modeling stuff. And the reality is, is for them at the time, MATLAB wasn't fast enough to be the tool to solve a lot of these problems that they were trying to solve. And it isn't free, you have to pay MathWorks every time you want to use MATLAB, which nobody wants to do. So their thought was, hey, can we build an open source programming language that sort of basically eliminates the need for MATLAB. And, you know, they spent the

last, you know, 10 years working on this project. The language was sort of officially announced in 2012, which is where you see that Julia's been around for 10 years now. But yeah, it's been a wild ride. I think the language officially hit its 1.0 release in 2018. It's been around for 10 years, but really it's only sort of been a viable tool for somebody to use for the last four years or something like that so within those last four years it's been a

tremendous amount of growth from the ecosystem the language community and I'm really excited about what the future looks like just because of all the cool stuff that's happened in the last four years. How did you personally end up getting interested and involved? It's another interesting story. So, you know, it's the serendipity of life and just getting involved in random things. Like I actually joined a team at NASA as an intern and then a contractor. And the team that I happened to join at NASA was actually using Julia in the 0.6 days. So before the 1.0 release, and I had the chance to actually help rewrite some of that code from 0.6 to 0.7 and then to 1.0 release, and I had the chance to actually help rewrite some of that code from 0.6 to 0.7 and then to 1.0.

And that was a super formative experience, like to be a part of the Julia community at that time. And I'm so glad that I was. And before that experience, I really hadn't done very much in the open source community. So it was an opportunity for me just because things were breaking and I didn't know what to do because, you know, it was a very like sort of niche environment at the time that I got the chance to get involved in the community, ask a bunch of questions, and then ultimately over time got more involved, helped run some programs, and then sort of officially became part of the project in 2020. It's really interesting. You would think that a large government organization like NASA might be a little hesitant to use a beta, you know, programming language like that. But I guess they must have seen a lot of value in Julia at that time. Yeah, it's interesting that you say that. I think,

you know, there's a lot of groups that, so the project when I joined was very much in a research stage. And I think a lot of the questions that you just raised are things that, you know, I'm sure that the folks before I joined the team actually had to make these arguments to sort of their bosses and things like that, that, hey, this is actually a tool that we should use. But specifically, the reason why that team ended up using Julia was because basically, we were using Julia to do the planning of lunar traverses. So given you're on some specific location on the moon, how can you find a traverse that is optimal and fulfills all the mission requirements, like to a very granular level? And it's very different than what you would normally

do without this traverse planning tool, which is you would literally have a bunch of scientists in a conference room with a big map and you'd'd sort of draw out where you wanted to go. And obviously, that's not the mathematically optimal solution. So all the tools that we were using to do this came from Stanford's Intelligent System Lab, and they built all this POMDP, Partially Observable Markov Decision Process infrastructure in Julia. So it was really that research group at Stanford that sort of took the initial dive, built all these tools, and sort of made it so that the team that I was on at NASA was able to leverage a lot of that work that they did and sort of build this tool that we did. Just as an aside, Rob, we didn't mention this during the news items, but when we're talking

about the quantum computing NVIDIA thing, two of the major first users that NVIDIA lists is Oak Ridge National Lab, which is a Department of Energy lab in Tennessee, and Lawrence Berkeley National Lab, which is another Department of Energy lab in California, Berkeley area. Whenever I hear stories like this, I don't find it surprising at all that the federal government is spending money on research projects and things that could be considered research projects. No, that's interesting. And Jason, I also wanted to point out that another sort of interesting caveat to this story is my team at NASA used this software that the folks at Stanford built. But actually, I think one of the initial use cases for this software was a piece of software called ACASX, which is the collision avoidance system that the FAA uses. And that was built using Julia, I think, before my team at NASA even started using it. So there were early adopters of this. And it's so interesting that the government, you would think, are so risk averse in a lot of cases, but they do end up making sort of gambles on some of this

more niche technology. I think it has a lot to do with the people who are involved in these projects. Yeah. So there's another comment that you made when you were first telling us about Julia. You said that one of the original goals was to replace MATLAB, basically. Now, personally, for my undergrad work, I used Mathematica, not MATLAB. But I always found this kind of like real-time visualization, programming, mathematical kind of environment like really cool. Like I tend to keep a version of Maxima installed on my laptop or on my cell phone or whatever just to play with that from time to time, which is another open source computer algebra system.

So does Julia offer that kind of like also like visualization of the work that you're trying to do like that kind of aspect also? Yeah, that's a good question. So there's a lot of visualization stuff that is sort of available in the Julia ecosystem. I think the difference between sort of Julia and at least my experience using MATLAB at the present moment was and still is that I think when you download MATLAB, you sort of get a package of a bunch of things, like you get that visual interface and all this other stuff. And I think in the context of Julia, part of the decision that was made early on was to sort of decouple a lot of the tools and things like that from the core language

itself. So that I think, again, this is one of the problems with MATLAB is that you're sort of very constrained to this MATLAB, MathWorks environment that they give to you. And I think the idea was, let's make sure that that doesn't happen in the context of Julia. So you can just use the core language itself. And there's a bunch of visualization tools and packages that are out there, but they don't sort of come together by default. You mentioned Jupyter as one of the things that you're involved with as well. That's that like notebook where you can like do life programming and stuff inside it. Does Julia have integration with Jupyter as well? Yeah, so interesting story. And it's so funny that you say that because I find it so interesting that so many

people don't know this, but the J-U in Jupyter actually stands for Julia. So Julia is one of the sort of core parts of a Jupyter notebook. I get stuck on the P-Y part. Yeah. I think we kind of already have a sense that Julia is used by a lot of kind of data scientist type applications. Is that the predominant field of Julia? Are there other big use cases for Julia as well? I would say that data science is probably actually not one of the most, at least where we're seeing the most penetration.

I think there's people who are probably using Julia to do data science stuff, but the most sort of significant adoption is from a, probably from like a percentage perspective is in a lot of the more computational science areas. So like the team that I was on at NASA, we weren't necessarily doing data science. It was more of like niche simulation and modeling stuff, a lot of simulation and modeling people, whether they're modeling, you know, chemical systems or physics-based systems, pharmacology stuff, a lot of that climate models. There's a ton of climate model stuff that's happening in Julia. And I would say that's probably from a percentage adoption standpoint where the most folks are. I think just because data science is such a bigger field than a lot of those fields, we might have the same number of people.

But obviously, Python is much more widely used in the data science domain than I think Julia is at the present moment. I'm going to make a couple of leaps here. You're going to have to tell me, like, stop me when I get wrong. But hearing the research work that you talked about at NASA, and then what you just described Julia is using, I'm imagining, okay, I'm going to use Julia to do the decision-making pathfinding for where my lunar rover is going to go. But you also told us that it's a dynamic language with just-ahead compilation. And I think real-time system, dynamic language, these things don't tend to go together in my head. I don't know if pathfinding is soft real-time or hard real-time kind of scenario. But can we actually deploy Julia on our next Mars rover and use it for our pathfinding system and have some kind of guarantee that we'll have the answer before we need to make the next decision or whatever? some very specific context Julia is being used in embedded systems like on the actual device

making those real-time decisions. I think in the context of the team that I was on at NASA, our software was designed to live and it will live in mission control. So it's not yet at the point where for that specific project we were actually on the rover making the decisions. But I do think that Julia is used. I've read some articles of folks who are doing robotics and self-driving car stuff who are using Julia. And I actually think self-driving car stuff is one of the more compelling use cases for Julia, just because of the way that companies do self-driving car software development I was wondering if there's a deeper connotation. Well, the way they're doing it now is terrible. And they really should be using Julia. Did I misread that? No, no, you're totally right. I saw a tweet a few months ago from Elon Musk talking about Tesla's self-driving car software stack. And they basically said exactly, you know, they described the two language problem in one tweet, which was that, you know, they're doing all their prototyping in a language like Python. And then when they actually want to take the self-driving software that they're prototyping with into production

onto people's cars, they basically rewrite everything, redo all the work, and then deploy it in C++. And again, that's a prime use case for where you can sort of save yourself having to waste the time of doing development twice and just write it in julio once which is yeah it's something to think about i'm not sure that elon musk is listening but elon if you are we need to talk about julio as far as we know he is not a regular listener he seems like he liked this podcast i don't know maybe can you tell us a little bit about what the learning curve would be to get into Julia? Is it syntactically similar to Python or other languages like that?

Yeah, 100%. So definitely very similar syntactically to Python. So I actually spend a lot of my time doing Python programming. So I think it's nice for me to keep that perspective as I use Julia, as I write about Julia, as I talk about Julia, because I think that, at least at the present moment, Python is like the gold standard for how you can make a language accessible to people and sort of have the syntax that's easy to use and sort of helpful for a developer. So I do think that Julia has a lot of similarities in that sense. There's, you know, of course, some nuance and weird syntax things like every language has. But in general, like a lot of the same sort of mental paradigms that you would use when you're programming in Python,

you can also use when you're programming in Julia, which is really nice. Initially, you said for people who are deep into programming languages that it's got a lot to share with the Lisp. And now I'm confused. You know, I say that because so many people, like Julia is technically like a Lisp-related language, but like I have never used Lisp or seen any syntax. I've just seen, like just everyone always says that. So I'm more of repeating the talking point in that sense, and I don't actually use or ever program Lisp at all. So hopefully it's not an incorrect statement. But I do know that very, very regularly, I see people talking about how Julia is similar to Lisp. And I'll have to dive in now and actually go look at why people say that.

Well, that's okay. I'm going to ask some questions. And we'll, for the sake of our listeners, maybe we'll find the edges here. Julia has four loops. Are functions first class objects? Can you pass functions around easily? Yes. Is it a common thing to do like higher order functions, functions that take functions and return new functions? I know that it's supported. I don't know if it's super common or not. I don't have the context, but I know it's definitely supported as part of the language. If statements, those exist? Yeah. Okay. Do you end up using lots and lots of parentheses? No, there's no parentheses around like function arguments or anything like that. Or actually, that's not true. There is. I don't know why I said that.

Okay. How easy is it to create like an anonymous, unnamed lambda function, something like that to pass into another function? Easy. Okay. So it sounds like Python, but with a more functional leaning, if you were to ask. I mean, I haven't looked at the syntax at all. I should have looked at the syntax before the podcast, but I didn't.

So yeah, I can see, okay, if it's got more of a functional bend to it, maybe that's why people say that it's closer to Lisp. But Lisp doesn't have for loops. I mean, pure Lisp doesn't. Everything is recursive. And it's all functions being recursively called. It's like everything is a function, is a reasonable way to look at the original Lisp,

which is why I asked the questions I did. I'm excited to do some research after this and figure out why people think that Julia is similar to this. Because I don't think that everything's not a function in the context of Julia. And I see recursive calls being made sparingly, so it's interesting. But yeah, I'm going to dive in after this. Is everything an expression? Like if I execute a for loop, does it implicitly return a value that I can then use?

That's a good question. I don't think so. I don't think so. Okay. These are good questions, though. Our listeners will have some. Ooh, do I have to put braces around blocks? No, you don't, thankfully.

But it's meaningful whitespace like Python? Like Python. I think for our listeners, that gives them a pretty good idea what they'll be looking at now. Does Lisp use curly braces? No, everything is parentheses. That's why I asked you if you use lots of parentheses. But everything is a function call. Like everything's a function call. Like you want to declare variable, technically, that's a function call. Julia uses the end keyword, which is a little bit of a nuance. So when you define a function at the very end, you'll write end at the end of an if statement, you'll write end at the end of an if statement,

you'll put end at the end of a module, you'll put end. So no curly braces, but you do have to put those end keywords, which I actually like. A lot of people, when they're learning the language, say that they don't like it.

But I've actually, when I program in Python now, I actually write a comment and then the word end at the end of, because it just like helps me. It's so hard. When you write deeply nested Python code. Oh visually it's impossible i'm like where do all these things line up and it's so hard to tell and i think putting the comment with the word end really

helps me as i like quickly skim through some code as a c++ programmer i totally agree with you like when i look at python i find it difficult to. I'm looking for the end of the block. I don't love the meaningful white space, so I'm on board with the end statement. Plus, I grew up programming in BASIC, so having begin and end kind of keywords, I'm kind of on board with this. But as someone who does professional code reviews,

I have to point out that if you've got deeply nested code that's hard to follow, you should just make another function call. That's a good point. Very, very good point. Yeah, I think it's a fair perspective. I wonder if the discussion for just a moment to bring you words from our sponsor. C-Line is a smart cross-platform IDE for C and C++ by JetBrains. It understands all the tricky parts of modern C++ and integrates with essential tools from the C++ ecosystem, like CMake, Clang tools, unit testing frameworks, sanitizers, profilers, oxygen, and many others. CLion runs its code analysis to detect unused and unreachable code,

dangling pointers, missing typecasts, no matching function overloads, and many other issues. They are detected instantly as you type and can be fixed with a touch of a button while the IDE correctly handles the changes throughout the project. No matter what you're involved in, embedded development, CUDA, or Qt, you'll find specialized support for it. You can run debug your apps locally, remotely, or in a microcontroller, as well as benefit from the collaborative development service. Download the trial version and learn more at jb.gg slash cppcast dash clion. Use the coupon code jetbrains for cppcast during checkout for a 25% discount off the price of a yearly individual license. interop story was, as I mentioned, as a feedback, we did do episodes on Swift and Zig. And we talked about the interop with those languages. Can you tell us a little bit about what the story is between Julia and C or C++? Yeah, this is a very interesting situation. When you sent that question,

I started diving in and just looking at the current state of things. So it looks to me like there's a bunch of different packages that are doing some of this stuff, one of which, and I think the most popular, is a package called cxx.jl. The problem with cxx.jl right now is that it is not set up to work with current versions of Julia, and that's because of the LLVM changes that different Julia versions use different versions of LLVM, which is like a compiler. I didn't realize you used LLVM as the back end. A few things just clicked in my head. I'm glad.

I should have said that earlier. Yeah. So Julia uses LLVM and CSX is not set up to work with current versions of Julia, though I'm happy that it is under active development. So I was just looking and I was actually talking to the happy that it is under active development. So I was just looking and I was actually talking to the person who's doing this active development. So hopefully that is all set up and merged in the next few weeks or month. There's also a few other ways that Julia interfaces with C++. There's cxxwrap.jl, as well as a package, which I didn't actually know about that Rob, you sent over, which is JLuna. And folks who haven't seen JLuna, check it out because

they have a really cool logo. And I love the logo. It's a little moon with the Julia logo, and it looks like pixelated from like an old retro video game. So it looks really cool. I am truthfully not an experienced enough C++ developer to speak to some of the differences. I need to probably actually, I'll end up writing up a article on sort of what the difference is between all these different packages and the C++ features that they sort of integrate.

Cause it seems like each of them has done like part of the work as far as how you can integrate c plus plus and julia together but it's unclear to me sort of where the delta is between all these different tools right now so i need to write up an article and that'll be my motivation to do it the mentions of the jluna and cxx wrap we've talked about both of those libraries recently in past episodes as news stories. And that's kind of what prompted us to want to have you on to talk more about Julia. Yeah, it's interesting. And I'm glad that people are doing this work. Something that we haven't

talked about that is, I think, definitely worth mentioning is the interoperability is such a challenging word to say. But it's also not a sort of challenging concept in the context of programming in Julia, which is something that I appreciate so much. Like there's an entire organization on GitHub that just has all the different languages that Julia can interrupt between. And I think it's one of the things that makes the language so powerful today. And I would say for anybody building a language sort of in the current state of things where there's so much wide adoption of all these other languages, making sure that your programming language has interop with Python, with R, with C++, with C, with, you know, even MATLAB can interop with Julia. And I think that that's super powerful. And it makes people who are making the transition to a new language a little bit less worried that,

oh, I'm going to this new language. I have to rewrite every single piece of code that I've ever written, which is a huge ask for somebody. So I think the ability to just, you know, hey, you have this Python code or this R code, just keep it. You can just call it directly from the Julia file. You can be happy about it. And then you can build new stuff using Julia, which I think is really awesome. That does sound pretty cool. Do you have any idea like, what the cost for that interop tends to be? I mean, obviously calling our function from Julia is going to be more expensive than calling a Julia function from Julia, right? Like it just naturally has to be just out of curiosity, if you have any idea what that cost looks like. Yeah, my understanding, and if

there's anyone who's deeply involved in this Interop community and the Julia community who's listening to this, feel free to send me a message and correct me if I'm wrong about this. My understanding is that you aren't paying a significant burden as far as the cost of calling these other languages, but you're also not going to, like a lot of the people ask me like, hey, am I going to see a speed improvement if I call my Python or R functions from inside of Julia? No, you're definitely not. Yeah, so that's the only caveat that I'm aware of. But other than that, I 100% think that it's a very similar computational cost as just calling it as you normally would.

Because my understanding is it's just sort of making the call under the hood to whatever that language is. And it would be the same as if you were going to call it independently by itself. Okay. Interesting. I'd be curious personally to see what they've done to avoid reinstantiating the Python interpreter each time or whatever. I'd be curious to dig into that. Yeah. I'm not, admittedly, sadly, not a low enough programmer that I understand a lot of the sort of performance costs and things like that. But, you know, just from my experience of using PyCall, for example, you can really sort of do everything that you would normally do in a Python environment Python syntax with the Julia syntax. It's super PyFly. I used it once to do a bunch of machine learning stuff where the package to actually interact with some of the machine learning infrastructure

was written in Python and I could just PyCall it and it worked flawlessly and perfectly. It didn't seem like it was taking any longer. Obviously, that's not the scientific measure that we'd be looking for. But yeah. Yeah, I feel like you would know if it was like, you know, so slow that it's useless. Obviously, yeah. I was chatting with my cousin before doing this, and he has a lot of experience with

different programming languages and mentioned that Julia has this help mode built into its REPL that makes it stand apart from any other language they've seen. And I'm curious if you could tell us something about that. Yeah, the help mode actually, and sort of more broadly, I think, the REPL in general as a tool for you to program in Julia is actually one of my favorite things about the language. Like there's independent of the help mode, there's a shell mode, there's a package mode. All of that stuff is sort of integrated and tightly coupled with the language. Like there's independent of the help mode, there's a shell mode, there's a package mode, all of that stuff is sort of integrated and tightly coupled with the language, which makes it so that it's super feature rich, I can add packages, remove packages, I can switch directories

using sort of native shell commands, which I love. And I don't have to like remember the Python or Julia specific CD, PWD, all that stuff. And then help mode, yeah, is a great addition to the features that are provided. And for that, it's, I imagine that other languages actually do have something like this. Literally, you just put a question mark, and then you can type in like the name of the function that you want or something like that. And the documentation shows up right away. So I think this is analogous to, I know that Python has like a help function, which you can like pass things into, I believe. I'm not 100% sure about that,

but that's the basic gist. You can put in functions, get or types or any other sort of Julia object or language paradigm into help mode and sort of get the information that you would need, see examples. And there's also extended help mode, which is really nice,

which not a lot of developers use, but you can put two question marks and sort of get even more information if developers want to like give you like a super extended example of like how you would use some feature of their package or something like that. It can go into the extended help mode

just so that it doesn't balloon and take up too much space in the regular help mode. This made me think of the three equals operator, whatever in JavaScript, that's like, no, is it really equal? So what about the rest of the ecosystem? Is there IDE support? I mean, does JetBrains, I don't know, support Julia or package management? Yeah, like that kind of thing. Yeah, so IDE support definitely across the board. So the whole ecosystem used to be embedded with Atom as Microsoft acquired GitHub, and they basically shot the Atom project in the leg, and it's no longer really being actively developed. But that means VS Code probably supports it well then. 100%, yeah. So we have full

support of VS Code. I wrote the documentation on the VS Code website for Julia. So it definitely is supported. And sort of you can use it in all the other places that you would usually do your development. JetBrains PyCharm is one that I'd have to double check on. I don't know off the top of my head. I'm guessing it is. But so many people use VS Code now that it's like if you can get something with VS Code, you've got like 90% of all the people using an IDE, which is crazy. I did not realize it was kind of becoming the defective standard. You know, it's an open source project, which is good, but it's also Microsoft, which you want to be sort of, I like Microsoft and I like GitHub, but you always want to be

sort of level-handed and level-minded about basically we're giving Microsoft a monopoly on the IDE experience. And I think there's obviously trade-offs and downsides of that. So it's good to make sure that we have support for all these other things so that when Microsoft does something that every developer is unhappy about and doesn't want to change, you know, we have sort of recourse and don't have to sort of sit on our hands when something like that happens that's all right we'll just end up with the kill patrick code fork that everyone moves to because it has so much better support for whatever yeah hopefully hopefully i won't have to do that but and to answer the other question about package managers this is another

thing where i you know one of the funny jokes about, not even a funny joke, but it's just a saying in the Julia community is like, you come for the speed and you stay for some other reason. I think for me, honestly, the reason is like, I came for the speed and I stay for both the community and for the package manager. Like the way that you can, I have never, bar the early 0.6 days when I was doing stuff at NASA, I've never had any package management installation headaches. It's just so simple and it just works. And that's so the opposite of experience of what I have doing Python stuff. I still regularly, before I left Apple, would run into problems where I'm sitting there for an hour trying to figure out, I just want to run this code. I know that I have these packages installed on my computer in Python, and I cannot figure out how to actually run this. It just continues to tell me that things are not

working the way that they're supposed to. Like a lot of the image, I forgot, it's like one specific library that would always give me trouble. But yeah, it's just not a problem in the Julia ecosystem, which is what I love so much about using Julia. And a lot of the work that's actually happening in the context of the package manager to make, you know, binaries available is actually sort of hopefully serving as an example to a lot of the other communities, like the way that Julia packages are built in the package manager ecosystem, you can watch and read more about it at the annual Packaging Con, which took place last year.

And there was a bunch of Julia talks there, but yeah, it's super cool. And I appreciate it so much as a developer. I was getting ready to ask you, oh, is it even better than Pip? And you just kind of answered that right out. But I know people who are fans of Python or Ruby hate it when I say this, but in my head, Python and Ruby are morally equivalent.

It's like, does gem contain the package I want or pip? Otherwise, I don't care. I'll use the language that has the package I want and I move on with my life. But the fact is, I always think of their package management tools as just being so easy to use that I can do that. Like if I'm doing OctoKit work, I'm going to use Ruby because OctoKit for GitHub is, you know, most well supported into Ruby, whatever, you know, like I don't really care. But that's interesting that you said it's that much better again. So do you, Jason, you never run into problems installing packages using Python? I don't use it enough to have the experience to say that. I use it when I need to.

And when I've needed the packages to be there, it's worked for me. Got it. I've probably spent at most a 20th of my career programming in Python and Ruby combined. Okay, got it. I mean, that's not a tremendous amount, but that's probably a fair enough amount to give an assessment. So I think it's, again, that's not a tremendous amount, but that's probably a fair enough amount

to give an assessment. So I think it's, again, I'm with you in that, you know, it works a lot of the time, but the times that it doesn't is when I am sitting in whatever environment I'm sitting in thinking, gosh, I wish I was using Julia to be doing this and didn't have to deal with all these installation headaches.

I will say whenever, so I run Arc Linux, or Manjaro specifically, and whenever the system Python interpreter gets upgraded, the next time I go to use a Python tool of any sort, it can't find the binaries and everything's like angry. And I have to just pip install like the thing again. I don't even know if it does anything

except like update a few symlinks or something. I could just have to poke it install like the thing again i don't even know if it does anything except like update a few sim links or something i could just have to poke it and then it works and i'm like okay right i just have to remember to do this each time that is where the one case where i do regularly run into issues yeah any other like highlights in the julia community of like you know resources or tools i kind of you think put you above other languages like python you know, resources or tools that kind of, you think, put you above other languages like Python? You know, I don't think in any ways we're above Python or any of these other languages. So I'll just make that disclaimer so I don't start the language war. I actually think in general that the future of all these languages is going to be, you know, Python's still going to be popular in the future. Julia will hopefully be popular. R will as well. Really, again, the sort of goal for,

you know, the folks who created Julia was to take out MATLAB, like they're not in the open source community. It's a for profit company, nobody will feel bad if MATLAB gets erased. Hopefully, no MATLAB engineers or people going to be upset about that. But yeah, I do think that, you know, Python is popular for a reason. And there's obviously a lot of folks who are using it. So I always try to thread the needle of talking about Julia is a great tool and not sort of making Python seem like a bad option. To go back to the question about resources for Julia, the Julia language website has a lot of them sort of highlighted. I think the one that I like to call out to folks is MIT has a class that they made open to the world. It's called Introduction to Computational Thinking. And it has a bunch of MIT actually

partnered with YouTubers and like all these other people to sort of build like what you would sort of actually want out of a college class, which is like really engaging content that has real world applications. So I think that resource is great. And I send folks to that class all the time. You've said several times that the goal was to replace MATLAB. And sorry, I just realized this. Like, is there a compatibility layer with MATLAB? Can I take my MATLAB code and plop it into Julia in some way and use it? I think you can. Yeah, there is interop between Julia and MATLAB. Okay. Yeah. A lot of the benefit that you'll see is if you rewrite things, like I've seen a lot of,

I think I read an article about Pfizer switching some of those simulation stuff that they were doing in MATLAB to Julia, and it was like 170x speed up improvement, which you can imagine for them, you know, doing really computational simulations that are potentially, you know, time sensitive, depending on what the nature of them are.

It has a lot of benefits to get that 170 speed up. Wow. Yeah, obviously, the note is that doesn't happen for everybody or every time I was going to make the disclaimers, because then someone's gonna, you know, send me an email and say, Hey, we wrote my code, and I only saw 10 or 15 x improvement. And you said it was 170 for this one case. So it doesn't happen for everybody. It's very context specific. Well, I mean, and since you're talking about Pfizer, it'd be very appropriate for us to scroll the list of disclaimers at the bottom of the screen right now. Your results may vary, like this may cause cramping, intestinal distress, whatever. Another thing, you know, on the topic of Pfizer, the folks at Pfizer and Moderna, I believe,

actually used Julia to do some of the development for the COVID vaccine, which is super interesting. So lots of the part of the speed and part of the results that they were able to achieve was because they were actually using Julia, which is super cool. Julia has, I don't want to say widespread adoption in the pharmaceutical space, but the pharmaceutical people are very keen on using Julia, which is really awesome. That's awesome, yeah. Is there anything else you can tell us about the performance characteristics of Julia? You said that's obviously a main goal of Julia is to be able to write your software once and not have to convert from Python to C or C++.

Is there much you can tell us about how that performance is achieved? Yeah, I think it's two pieces. One, of course, is obviously that it's a compiled language, so you can get that performance sort of out of the box. The other thing, too, is the intention and the design of Julia was sort of, it was built with this speed in mind. I think you can sort of see that contrasted against a language like Python, for example, which Guido, when he was building Python in 1991, wasn't thinking about, hey, I need to make

this language really fast so that people developing black hole simulations in 2019 have the performance characteristics that they need. It just wasn't a thought. And I think for the folks who created Julia when it was being developed at MIT, that was like a core principle of what they wanted the language to achieve. So it was just a different design philosophy that ultimately led them to make a bunch of probably small little choices that just built up over time. And now you have the language where, you know, every single release that we do, there's always some big performance improvement, which is always so fun to see. Where did they pull another 25%

speed up out of the rabbit out of the hat every time, which I love so much. But for folks who are doing development in other languages and you want to see this really in action, what I would suggest truthfully is go and try and write some of your code in Julia. See what the performance looks like after you've rewritten it. And if it's not what you would expect, go and post on our discourse platform, say that Julia not as fast as C++ question mark, and literally 15 or 20 people are going to jump into the thread and help you to your heart's content to make sure that you get the performance. I literally have seen this time and time and time again. People who actually want to sort of get the fullest out of the language just post some

slightly inflammatory posts somewhere and everybody will dive in and sort of help you get the performance that you want. And it shouldn't work, but it really does work just because people really want to see those using Julia succeed, which I love. So the official support platform is to nerd snipe the Julia community. That's what you just told us. It's an unofficial statement, but it's... I'm sorry, but I believe your official rule is developer community advocate. Well, Logan, it was great having you on the show today. Is there anything else you want to plug before we let you go on Julia? Obviously, we'll put the link to the Julia programming language website in the show notes. Anything else we should put out there for listeners?

I think the only quick plug is Julia Khan coming up in July, which seems far away, but also seems pretty close now. So if you're using Julia or dabbled with Julia at all, the conference submission deadline, if you actually wanted to submit a talk, I think is April 10th. So feel free to send in any interesting, cool stuff, C++, Julia related that,related, that folks would benefit from. So that's the only quick plug. But lots of learning opportunities at JuliaCon. So also, if you don't know anything about the language, want to get a feel for the community, the tools, what people are using the language for, it can be a nice way to get a quick sort of overview whirlwind tour. Is it planned to be virtual, in-person, hybrid?

We planned for in-person, but we ended up making the decision in December that we were going to do virtual this year. If you made the decision in December, that's the decision you would have made, for sure. Yeah, December was crazy. And now it seems like, you know, because of the war in Ukraine, everyone can only focus on one thing at once. So we're like, COVID's over, we have to focus on this other world problem. And yeah, so hopefully everything will be safe for those doing in-person conferences, but we'll be remote still in July. All right. Thanks for coming on the show today, Logan.

Yeah, this was a blast. Thank you both for having me. And also congratulations on, you said 340 something episodes, which is crazy. I'm like, keep it up and it's incredible work. Thank you. Yeah, thanks. It was great to get perspective on another language as well. Thanks. Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, we'd love to hear about that too.

You can email all your thoughts to feedback at cppcast.com. We'd also appreciate if you can like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who help support the show through Patreon. If you'd like to support us on Patreon,

you can do so at patreon.com slash cppcast. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode was provided by podcastthemes.com.