I met Prof. Alan Edelman (one of the co-creator of Julia) in Singapore in 2016. They were promoting the language as sort of replacement for Matlab and Python. One story he told me that, Singapore being a small island nation wanted to buy nationwide Matlab license for their HPC and NUS. Matlab asked them a fee of somewhere around a million dollars (forgot the exact amount). The director said if my super computer doesnt cost this much and why should I pay a mil dollars for a single software. They started looking for an alternate, they wanted a better option than Python which made them choose Julia. They invited Alan Edelman and few other folks from Julia computing and organised a three day workshop. And that is how I met Julia (or learnt).
@@ThePC007 Agreed! A very cool story and they ended up supporting the "vendor" by hiring them for the workshop. Probably support too and way better than $1M for a proprietary alternative.
Been programming in Julia since 0.4. Today I feel like I nailed the choice of language. edit: by the way, I loved the idea of browser tabs showing examples of the current topic.
Looks like I'm the third person to say this, but: good idea to show web pages for topics as the interview proceeded. Hope to see more interviews like this!
Great interview! Had no idea that Julia was dynamically typed, I somehow always assumed (because of Numerical computing) that it was statically typed. I guess they do a lot of type inference
Could you maybe make a video on multiple dispatch focusing on julia? It always seemed more like a detriment to me than a feature. The syntax method(object, ...) takes away the suggestions you get after typing object.| which then offers you possible object.method(). It also stops method-chaining from working, which can make code very readable. And if you really wanted to have a "method" not attached to a particular object, then you are really looking after a function in my opinion. People countered this, by arguing, that you can not modify a functions behavior depending on the inputs, but that (again) seems more like an antipattern to me. Even symmetric operations like add(a,b) often make sense to be a.add(b), if the result is then saved in a. And last but not least "traits" like in rust, could easily achieve any customization (e.g. Addable) by trait implementation. I concur, that you can not implement traits/interfaces for foreign objects in most other languages, so I can see why you would maybe (in a few edge cases) benefit from multiple dispatch if compared to something like Java maybe. But I definitely see Rusts approach as strictly superior. And if you consider the fact, that Julia is supposed to be used in Statistics, the average Julia user will import their data into a data frame, then import some statistics package, hand over their data to a function from the statistics package and receive a result. Then they probably want to analyse/plot the result. If the imported statistics package was an object instead of a namespace, statisticians (which often do not have good knowledge of best coding practices) can not possibly "use the entire namespace" like they often do in R, instead they would be forced to use statistic_library.method(data). Which nudges them to write more readable code (cf. Python: pandas, numpy, seaborn, etc.). And since the result from the library function is an object. It needs to be very discoverable (i.e. what can I now do with this result?). So if you could just write "result.|" and get a list with .plot, etc. you would immediately find out what you can now do with this. Instead of having to browse the documentation. So multiple dispatch seems to take away ergonomics, without actually providing tangible benefits (which you could not get with functions and traits). At least that is my view as of now. But you said a couple of times that you find Julia to be an interesting Language, and you seem to be very mindful of ergonomics in languages, so maybe you know something I don't know? So that is, why I would love a video on multiple dispatch from you.
I'm actually planning a video on overloading and multiple dispatch in the near future but I wasn't planning on highlighting much in the way of your related topics here. I'll try to chew on that as well and put that on the list. (It's a long list, though. I mostly cover whatever's on my mind at the moment.) Thanks for detailing all your thoughts. Could be useful reading for others stopping by.
@@contextfree I am looking forward to that - your content is great. Just discovered your channel a couple of days ago and I am through most of your videos by now :D
I know I used to think like you, but this is really about what you are used to. Now I find this object-oriented way of thinking very frustrating when I am in OOP languages. For instance while programming Julia I am used to picking functions first. I am primarily thinking about what I want to do, not what objects to use. So I use Julia's completion to find functions. If I am doing statistics, I may write "Statistics." and hit tab to get completions of what kind of statistics functions exist. Once I have found a function I want to use, only then do I explore WHAT I can put into it. The objects are quite secondary to how I approach programming. Using an OOP language is very frustrating in this manner because all the functionality is hidden behind objects. You cannot start trying to search for a function in a module, because most of them are attached to an object. Hence you need to engage in a guessing game where you need to find the object that has the function your are interested in first. Yes I know this sound super strange to you, but that is only because for you picking the object first is what you have been conditioned to thinking after years of OOP based programming. And if you want to know what you can do with a particular type in Julia you can just write `methodswith(NameOfType)` The problem with object.method() kind of syntax is that it works really poorly with functional programming. You want free function to do functional programming. You cannot do in Rust what you can do in Julia with multiple dispatch. Rust will typically dispatch on multiple arguments at compile time, not at runtime. Multiple dispatch gives a long list of benefits which are kind of hard to explain in a short post. One important thing is decoupling libraries and making it very easy to combine libraries made by different people. Mathematical code also naturally fits multiple dispatch. E.g. if I write `intersect(shape1, shape2)` then the algorithm that should run will be entirely different if the pair is two circles, two squares or a circle and a square. There is no way to decide which algorithm to use by the first argument alone. This helps Julia work really well with things like Linear Algebra working with all sorts of different matrix and vector types used in combination and allows the generation of highly optimized code paths. It is not without reasons that in many real world examples Julia kicks both C, C++, Fortran and certainly Rust to the curb when it comes to performance, despite being a dynamic language. In particular in the scientific domain. It is not without reason that the next generation climate model running on some of the worlds fastest super computers is being written in Julia.
love julia. biggest problem for me with it, is the compile time. it gets ridicously slow sometimes... talking like 5-10min for loading plotting libraries...
They are working hard on solving that. For now the simplest approach is probably to compile the plot libraries into your image with PackageCompiler: julia> using PackageCompiler julia> create_sysimage([:Revise, :Plots, :Debugger], replace_default=true) Also keep in mind that some of the plotting libraries compile faster than others.
Why is installing packages in Julia too slow?....while in R and Python, it is quite instantaneous. R ofcourse, the installation happens in matter of seconds. I have been facing this situation with Julia since the 0.6 version (my first Julia installation) all through to the latest 1.4.2 version.
This is a cool and underestimated language. I do hope that it overtakes Python within time. Too new of a language, so adaption will take LOTS of effort.
Julia is very interesting language.. I wish it had hot code reloading though, I think it could have it since it's quite dynamic / jitted but I guess most of the users don't have a use case for it. I know about revise.jl but I don't think it can replace running code. Otherwise, very nice language and I would be head over heels about it if only it had HCR.
Couldn't you implement that quite easily yourself? Just have a piece of code running that re-compiles your Julia code if it detects a change in one of your source files.
@@itellyouforfree7238 Yeah that's indeed a gap. Apparently, it's a tough problem to solve. Fortunately, I don't tend to change my structs all the time and so it does not bother me as much.
I haven't followed closely, but a quick glance suggests they currently support 1.5: github.com/JuliaGPU/CUDA.jl#requirements - Had it broken at first? If so, that is unfortunate. I personally prefer when things stay compatible. (Matching TensorFlow and CUDA versions can be a huge pain, for example.)
There is always going to be people who are more willing to beef up their computer or increase cloud computation cost rather than choosing an efficient tool.
I met Prof. Alan Edelman (one of the co-creator of Julia) in Singapore in 2016. They were promoting the language as sort of replacement for Matlab and Python. One story he told me that, Singapore being a small island nation wanted to buy nationwide Matlab license for their HPC and NUS. Matlab asked them a fee of somewhere around a million dollars (forgot the exact amount). The director said if my super computer doesnt cost this much and why should I pay a mil dollars for a single software. They started looking for an alternate, they wanted a better option than Python which made them choose Julia. They invited Alan Edelman and few other folks from Julia computing and organised a three day workshop.
And that is how I met Julia (or learnt).
That is actually quite a cool story, lol. I'm glad to see a free open-source project being used in favor of a proprietary (and costly) one.
@@ThePC007 Agreed! A very cool story and they ended up supporting the "vendor" by hiring them for the workshop. Probably support too and way better than $1M for a proprietary alternative.
I love your interviews. The way you show relevant context in browser, demo stuff on terminal, makes this much more interactive and understandable.
I was going to say this, too. This is the first Context Free interview I've watched and I hope they all provide this running context.
Been programming in Julia since 0.4. Today I feel like I nailed the choice of language.
edit: by the way, I loved the idea of browser tabs showing examples of the current topic.
Best language ever. Nicest syntax, great performance, awesome libraries.
Really well made, great interview! Thanks for making and sharing!
Looks like I'm the third person to say this, but: good idea to show web pages for topics as the interview proceeded. Hope to see more interviews like this!
These interviews are so nice. From the mouths of the designers themselves.
I really love the browser presentation and you highlighting the authors. Great stuff.
How about an interview with Zig's author Andrew Kelley? That'd be nice!
Zig is my personal favorite of all emerging languages...
I intend to. Waiting until I feel like it's the right time. But I think he'd be interested.
Great interview! Had no idea that Julia was dynamically typed, I somehow always assumed (because of Numerical computing) that it was statically typed. I guess they do a lot of type inference
They just seem soooo nice and refreshing, I want to get into Julia any time
I was considering Julia for my PhD, but went with python because of more libraries regarding digital image processing
Yeah, I have the same situation. but I'm learning julia in my spare time for the future! :-)
How about an Interview with Brien Fiete, the creator of Beef programming language?
I would like to interview him for sure. Lots of cool topics there.
great idea of using browser tabs instead of slides
The Julia mean version probably uses SIMD out of the box
I've been suspecting that, but I haven't checked.
@truthseeker dont write `sum=0.0`. write `sum = zero(eltype(values))`.
Could you maybe make a video on multiple dispatch focusing on julia? It always seemed more like a detriment to me than a feature. The syntax method(object, ...) takes away the suggestions you get after typing object.| which then offers you possible object.method(). It also stops method-chaining from working, which can make code very readable. And if you really wanted to have a "method" not attached to a particular object, then you are really looking after a function in my opinion.
People countered this, by arguing, that you can not modify a functions behavior depending on the inputs, but that (again) seems more like an antipattern to me. Even symmetric operations like add(a,b) often make sense to be a.add(b), if the result is then saved in a. And last but not least "traits" like in rust, could easily achieve any customization (e.g. Addable) by trait implementation. I concur, that you can not implement traits/interfaces for foreign objects in most other languages, so I can see why you would maybe (in a few edge cases) benefit from multiple dispatch if compared to something like Java maybe. But I definitely see Rusts approach as strictly superior.
And if you consider the fact, that Julia is supposed to be used in Statistics, the average Julia user will import their data into a data frame, then import some statistics package, hand over their data to a function from the statistics package and receive a result. Then they probably want to analyse/plot the result.
If the imported statistics package was an object instead of a namespace, statisticians (which often do not have good knowledge of best coding practices) can not possibly "use the entire namespace" like they often do in R, instead they would be forced to use statistic_library.method(data). Which nudges them to write more readable code (cf. Python: pandas, numpy, seaborn, etc.). And since the result from the library function is an object. It needs to be very discoverable (i.e. what can I now do with this result?). So if you could just write "result.|" and get a list with .plot, etc. you would immediately find out what you can now do with this. Instead of having to browse the documentation.
So multiple dispatch seems to take away ergonomics, without actually providing tangible benefits (which you could not get with functions and traits). At least that is my view as of now. But you said a couple of times that you find Julia to be an interesting Language, and you seem to be very mindful of ergonomics in languages, so maybe you know something I don't know?
So that is, why I would love a video on multiple dispatch from you.
I'm actually planning a video on overloading and multiple dispatch in the near future but I wasn't planning on highlighting much in the way of your related topics here. I'll try to chew on that as well and put that on the list. (It's a long list, though. I mostly cover whatever's on my mind at the moment.) Thanks for detailing all your thoughts. Could be useful reading for others stopping by.
@@contextfree I am looking forward to that - your content is great. Just discovered your channel a couple of days ago and I am through most of your videos by now :D
I know I used to think like you, but this is really about what you are used to. Now I find this object-oriented way of thinking very frustrating when I am in OOP languages.
For instance while programming Julia I am used to picking functions first. I am primarily thinking about what I want to do, not what objects to use. So I use Julia's completion to find functions. If I am doing statistics, I may write "Statistics." and hit tab to get completions of what kind of statistics functions exist.
Once I have found a function I want to use, only then do I explore WHAT I can put into it. The objects are quite secondary to how I approach programming.
Using an OOP language is very frustrating in this manner because all the functionality is hidden behind objects. You cannot start trying to search for a function in a module, because most of them are attached to an object. Hence you need to engage in a guessing game where you need to find the object that has the function your are interested in first.
Yes I know this sound super strange to you, but that is only because for you picking the object first is what you have been conditioned to thinking after years of OOP based programming.
And if you want to know what you can do with a particular type in Julia you can just write `methodswith(NameOfType)`
The problem with object.method() kind of syntax is that it works really poorly with functional programming. You want free function to do functional programming.
You cannot do in Rust what you can do in Julia with multiple dispatch. Rust will typically dispatch on multiple arguments at compile time, not at runtime.
Multiple dispatch gives a long list of benefits which are kind of hard to explain in a short post. One important thing is decoupling libraries and making it very easy to combine libraries made by different people.
Mathematical code also naturally fits multiple dispatch. E.g. if I write `intersect(shape1, shape2)` then the algorithm that should run will be entirely different if the pair is two circles, two squares or a circle and a square. There is no way to decide which algorithm to use by the first argument alone.
This helps Julia work really well with things like Linear Algebra working with all sorts of different matrix and vector types used in combination and allows the generation of highly optimized code paths.
It is not without reasons that in many real world examples Julia kicks both C, C++, Fortran and certainly Rust to the curb when it comes to performance, despite being a dynamic language. In particular in the scientific domain. It is not without reason that the next generation climate model running on some of the worlds fastest super computers is being written in Julia.
love julia. biggest problem for me with it, is the compile time. it gets ridicously slow sometimes... talking like 5-10min for loading plotting libraries...
They are working hard on solving that. For now the simplest approach is probably to compile the plot libraries into your image with PackageCompiler:
julia> using PackageCompiler
julia> create_sysimage([:Revise, :Plots, :Debugger], replace_default=true)
Also keep in mind that some of the plotting libraries compile faster than others.
Why is installing packages in Julia too slow?....while in R and Python, it is quite instantaneous. R ofcourse, the installation happens in matter of seconds. I have been facing this situation with Julia since the 0.6 version (my first Julia installation) all through to the latest 1.4.2 version.
Is this programmed in Atom?
It's vscode, and I like it a lot. (Too many extensions installed by now, though.)
@@contextfree ok I might see about adding that. For some reason I can't get Juno to work in Atom, so I'm stuck.
This is a cool and underestimated language. I do hope that it overtakes Python within time. Too new of a language, so adaption will take LOTS of effort.
Julia is very interesting language.. I wish it had hot code reloading though, I think it could have it since it's quite dynamic / jitted but I guess most of the users don't have a use case for it. I know about revise.jl but I don't think it can replace running code. Otherwise, very nice language and I would be head over heels about it if only it had HCR.
What's an example from another language that you like in this regard?
AFAIK, Revise just works and it replaces code without having to restart the runtime. Did you encounter any issue?
Couldn't you implement that quite easily yourself? Just have a piece of code running that re-compiles your Julia code if it detects a change in one of your source files.
@@tomkwong7098 but you can't redefine structs
@@itellyouforfree7238 Yeah that's indeed a gap. Apparently, it's a tough problem to solve. Fortunately, I don't tend to change my structs all the time and so it does not bother me as much.
Viral's comment on GPU computing has not aged well with CUDA.jl not working on Julia 1.5.
I haven't followed closely, but a quick glance suggests they currently support 1.5: github.com/JuliaGPU/CUDA.jl#requirements - Had it broken at first? If so, that is unfortunate. I personally prefer when things stay compatible. (Matching TensorFlow and CUDA versions can be a huge pain, for example.)
There is always going to be people who are more willing to beef up their computer or increase cloud computation cost rather than choosing an efficient tool.
Just another language, do the same things as others do (python, c , c#, java, etc..)
Ohh nooo! Another white space language. It is a profound mistake to have your semantics depend on invisible characters - Rob Pike.
Julia actually doesn't use whitespace. It's more like Matlab for its blocks, using end to end them.