Also, from the other person’s perspective, I would really hate it if users of other languages would spend any significant effort trying to convince me, personally, to use it. It would mean that I have to endure a lot of spiels about something I am not, at the moment, interested in.
If you are their professor, students are probably polite when you do this. Don’t let this mislead you, it may still be tiresome for them.
I am perfectly fine with using Julia. They are probably fine with their own favorite language. Live and let live.
Somethings that I should clarify regarding my comment:
By students, I meant students I supervise (BSc final project, MSc, PhD), not students I teach classes.
I don’t try to brainwash students into using Julia. I simply recommend students I supervise to use Julia: I let them know it exists (many don’t even know about it), say it is a nice language for scientific computing, that it is what I personally use and am more proficient with, and therefore, the language I will be more capable in providing support in case they face problems (but still provide all the help I can in whatever language they end up using). I also tell them to use whatever they fell more comfortable. If it works for them, it works for me!
Why? Simple: to increase the number of Julia users. In part it is a selfish reason: the more people around me use Julia, the easier it is to share code with colleagues. I believe education (either via classes or supervision) plays an essencial role in promoting adoption (wasn’t that the way python became so popular?).
Now, I don’t mean that no students pick up Julia. Some are interested in it and end up using it. But many, just continue using python+numpy+scipy. And that is fine! I just expected that convincing science (physics) students to adopt Julia would be much easier than it actually is. Isn’t Julia (I know it is general purpose) main target technical/scientific/numerical computing?
Students who work with me on their PhDs have no choice: I use Julia,
and the collaboration will be mediated by Julia (and the body of work already
implemented in Julia). If they wish to use other software for anything else,
of course they are free to do whatever they want.
Having someone to provide support is extremely valuable when learning something new, especially a human who’s nearby.
The Julia discussion forums are also very good in helping. You might not get good answers to all of your questions, but reasonable questions should work fine. This is very different to say Python or Kubernetes. (I’m using these examples as I have relatively recent experience with them.) With these other two I got the impression that the discussion forums were populated with beginners asking questions from each other or if there were experienced users, they were silent and making money with their knowledge.
This is probably related to how new and improving some tech is. For instance nushell has a very nice and active Discord community, and I’ve been wanting to use nushell more.
In a class I taught, I told the students about the advantages of Julia, and then let them choose their language of preference for their first assignment, noting that I would be able to provide better support for them if they used Julia. Then I benchmarked the running times of their assignments and showed them the results. The students who opted for Python got 20X slower code because of for loops, and were convinced that Julia is worth it.
As for Julia vs Numba, you can check out my blog post. Not only there is a performance penalty in numba, you also lose a good deal of the high-level features available in Python. Finally, there is no numba-specific package system, so if you need somewhat efficient code you need to write it yourself. As a side note, I don’t think that Numba has been very actively developed for the last few years.
I agree that there is some dispersion here, or lack of a clear winner package. In my case, I have started to consider “Plots.jl” as the standard, as it provides a common API for a good number of existing backends. For more advanced visualization, I still haven’t decided if I’m going with Makie, or if I’d rather call an external software like Visit from LLNL
Hey, I’m interested in this as your research area looks similar to what I did in my PhD, and sometimes still do.
Maybe we should continue this “standardization” discussion in a separate thread, this one is already extremely lengthy.
When thinking about this, I always try to imagine how I would relate to someone trying to convince me to use a language that I recognize as technically very advanced, that solves some issues beautifully, but at the same time is not practical for what I do (Rust and Haskell come to mind).
Julia is an extremely powerful programming language, but at the same time it requires quite a bit of investment to reap its benefits. Convincing users who are not ready for it (yet) or don’t want to invest too much in the concepts may backfire and have the opposite effect: you get people who expected that it would magically solve all of their problems, and eventually they abandon Julia out of frustration.
I think it is best
not to try to convince people about Julia unless they ask to hear about the language,
to create a community where newcomers can get help,
not to take it personally if someone decides that Julia is not for them.
Thank you for sharing this post. It very clearly illustrates de limitations of Numba. However, by lloking at its github, it seems that numba is seeing active development
My problem with Plots.jl is that the promise of one interface to multiple backends is a bit unfulfilled. If you want more advanced options, you always have to deal with the fact that not all backends support the same features and you might have to use backend specific options via extra_kwargs. I would rather use one of the backends directly. For me that is PyPlot, but I might move to Makie in the future.
I am not sure I agree with that. For-loops are one of the simplest things you can do and in Julia they are fast. You don’t need any effort to get those benefits.
And while I don’t have any experience with that, I think that Julia could actually be a good introductory programming language. Possibly better then python. I think that the interactivity of Julia and type inference make Julia really easy to start with. At the same time the idea of type stability introduces just enough discipline in the code, that if the student later has to learn a statically compiled language, the jump is not so big as going from python. And most of time, making sure that the code is type stable is not that hard, e.g.: just make sure that if something will end up being an array, you don’t initialise it as an integer.
I partially disagree here. As I said many students haven’t even heard of Julia. Someone has to let them know it exists. Just like someone let them know that python exists.
It isn’t hard, but it isn’t obvious either. Understanding type stability and the global scope issue depends on getting some feeling about some concepts of programming. Either the students will find the “rules” just bizarre, or they will adventure in learning some programming at deeper level.
Note that these concepts are not an issue in python (slow) or in Fortran (fast). So, there is a learning curve.
All depends on if the users are just using a tool for a single time or are in the path of implementing custom methods and becoming regular programmers.
(Just for notice, I’ve been using Julia in courses for beginners just fine)
I use Numba to write simple fast loops when vectorized code wouldn’t make much sense, but there’s a lot of stuff I can’t write. Yes, there is active development and much room for improvement (gufuncs can’t be called in jit functions yet, ufuncs don’t specialize as readily as jit), but a fundamental limitation is the need to adhere to Python and NumPy. For example, instead of named structs, Numpy arrays have unnamed structured dtypes (similar to Julia’s eltype). But dtypes aren’t bona fide Python types, so you can’t make an instance of one; you can index a structured array, but the element is an instance of numpy.void no matter the particular structure. Likewise, Numba is incapable of making a vectorized ufunc that dispatches on or returns a structured element, and there doesn’t seem to be any active attempt to make it work somehow (Github issue #5329).
For loops are fast in a lot of languages (eg C/C++/…).
I see the comparative advantage of Julia in writing composable tools that can interoperate
to produce fast runtimes with little effort (compared to what it would take to do this in other languages), but no other language has combined the relevant building blocks before this way, so there are a ton of corner cases and problems one can run into. Especially in the course of a computationally intensive PhD thesis or something similar.
The Julia community, in general, is well aware of these problems, and people are working on solutions. Some can be managed at a package level, while at the other end of the spectrum some need new features in the core Julia compiler. So… things take time.
Julia is still a great language with amazing potential and it is eminently usable as is, but it is important to manage expectations: one should read the manual thoroughly, study some practical examples, make a lot of educational mistakes. Importantly, the user will run into bugs almost surely with nontrivial code, at least in packages, and then should be prepared to isolate an MWE, open an issue, and occasionally provide a PR to speed things up.
It is like a passenger train where you are advised to bring a wrench in case you need to fix stuff on the way to your destination. And of course wear clothes you don’t mind getting stained with machine oil.
Hit the nail on the head. Numba is designed to recompile the compiled bytecode of Python functions that use a subset of NumPy, so you must write valid Python. To deviate from Python syntax, you need something like Cython where the source files are compiled differently from the start. Considering that Numba has an LLVM-based just-ahead-of-time compiler, if implementing non-Python/NumPy features wouldn’t sacrifice the important aspect of Python compatibility, I’ll bet that the developers would overhaul their multiple dispatch, implement syntax for type parameters, introduce named structu- oh this is Julia.
I had the impression that since Matlab introduced JIT that its for loops increased in speed. After a very simple test I found Julia 10x faster! Comparing the current version of Matlab with the latest 32 bit version, 2015b, which I keep around for a 32 bit toolbox I need I found a >2x speed increase.
In this case there is no speed improvement in Julia using a function, probably because everything is local in the for loop anyway.
julia> function temp(n)
for i in 1:n
sin(π*i/n)
end
end
temp (generic function with 1 method)
julia> @btime temp(1000000)
8.696 ms (0 allocations: 0 bytes)
julia> @btime for i in 1:1000000
sin(π*i/1000000)
end
8.883 ms (0 allocations: 0 bytes)
julia>
and the matlab version
tic
n = 1000000
for i = 1:n
sin(pi*i/n);
end
toc
Elapsed time is 0.084775 seconds. % R2022a
Elapsed time is 0.180900 seconds. % R2015b (32 bit)
Conclusion, all the statements about for loops being slow in Matlab seems correct.
Those codes seem a bit unrealistic. They don’t return anything, so it’s anyone’s guess what the compiler could do with it.
I made two functions:
% Matlab
function out = foo(n)
out = zeros(n,1);
for i = 1:n
out(i) = sin(pi*i/n);
end
end
# Julia
function foo(n)
out = zeros(n)
for i in eachindex(out)
out[i] = sin(pi*i/n)
end
return out
end
Timings:
% matlab
>> timeit(@()foo(1e6))
ans =
0.0358
julia> @btime foo(10^6);
14.493 ms (2 allocations: 7.63 MiB)
That’s 2.5x difference. Versions are Matlab R2021b and Julia 1.8-beta3
I can relate as someone more in that middle. I remember this from JuliaCon that there are a ton of extremely talented and smart people who both know science and programming really well. Then there is the group of people from academics with minimal programming experience. More average developers like me who spent a lot of time in industry but not don’t really do science and academic work seemed quite rare. As someone who writes Julia books and make course material that has kind of been the group of people I want to appeal to as I think Julia has a lot of benefits for regular developers in industry.
Honestly I have had a lot less of the problems described as I don’t work on sophisticated enough problems to combine that may packages in novel ways. If you use Julia in a bit of a boring way it seems to work very well to me.
If I compare with the work I’ve done with JavaScript, C++, Swift and Go I am not sure Julia is really worse. Quite the contrary. A lot of this has to do with maturity and I have worked with a lot of languages in the early phase. There tends to be a lot of problems early on.
There is also something to be said about ability to diagnose problem. The REPL environment at least for me makes it a lot quicker to drill down to the problems I experience.
