Julia from the perspective of a pythonista

actually I took Julia Academy courses. this is the proof :smiley:

This course was not bad but compared to something like CS50 it could became better in the future.

I read this book, it can help in the beginning of the learning journey.

You are right, if the educational materials are not updated regularly, they will gradually become obsolete.

1 Like

“really wants” is something subjective. When I teach something I want that the students that really want (or need) learn and enjoy, but that is generally easy. It is harder to make things enjoyable and profitable for the ones that want (or need) less. My suggestions are hopefully to catch the attention of those as much as possible.

I really cannot evaluate that and I trust your judgment. I liked many things I have viewed and read, but I have no parameter because I never used those resources in other languages. I think anyway that this feedback is important, because there might be people and companies willing to invest on that. To be truth, I myself have written quite extensive materials for the courses I teach. But they are not for the general public.

I really like and hope that this happens because Julia has great potential and more importantly, it is fun to write code in it.

a “problem” is defined after someone makes a claim and that “problem” prevents achieving that claim. There is no expectation from Python to have high execution speed, whereas there is such an expectation from Julia, based on Julia’s claim about speed. This makes Julia’s time-to-first-plot an important issue comparing to Python’s execution speed.


While I would also love to see startup times further improved, where does Julia make a claim about its time-to-first-plot speed? It’s the runtime speed it makes claims about.


I don’t think this is true if you run a business that would benefit from Python being faster.


Thank you for introducing this training course. It would be great if there was a topic that every time someone prepares a training course add its link to it.

If it doesn’t need to be a discourse thread, everyone can easily submit a one-line PR to add a video/book/whatever to https://julialang.org/learning (to be precise, here is the GitHub repo: GitHub - JuliaLang/www.julialang.org: Julia Project website). This should also be more prominent.

(You can even edit the source code and create the PR directly via githubs web interface.)


I would agree that Julia’s speed (fast execution but with a significant compilation penalty up front) can be more easily be misleading for beginners than discussing Python’s (snappy for anything lightweight or anything done in complied libraries behind the scenes, slow for anything heavy and written in Python). I would also agree that Julia’s latency issues are much more visible to beginners than Python’s. In fact, I would bet that quite a few Python users never even notice Python’s slowness, because for a wide range of use cases, the differences aren’t meaningful.

However, it is also true that people really, really want to make Python faster, and a prodigious amount of effort has gone into doing just that. So my original point does apply to both of the examples mentioned, regardless of any semantic disagreement we may have about the scope of the word ‘problem’.


Although having faster execution speed can help dozens of businesses using python but it is wrong to expect high execution speed from a programming language that its goal is having a clear syntax or sth other than speed; in general we can’t expect sth that wasn’t been claimed.

1 Like

Higher runtime speed is number 2 on the wishlist (after strict type hints) of Python users according to

Other top wishes in this direction are better parallelism and an official JIT.


I was wondering if there is such a survey in Julia or not?

I could’ve sworn we added a weaknesses/“why not Julia” section… somewhere… (to either the main website or the docs)… following a thread similar to this one to help set expectations. Maybe it’s still a PR? Anyone with better search-foo or memory on this one?

Yes, we run an annual survey: 2020 Julia User and Developer Survey

1 Like

This is the second point I wanted to talk about, and thank you for mentioning it.
Most python users, as you said, don’t face the problem of execution speed because, for a wide range of use cases, the differences aren’t meaningful. although @lungben referred to JetBrains Python Developers Survey 2020 and mentioned that “higher runtime speed” is the 2nd item in users’ wishlist, we don’t have any information about their main problem with python. Besides, this problem would not occur for a wide range of users that doesn’t need higher speed (although all agree that having a higher speed is better than a lower one!). But Julia’s long initial start time problem occurs to anyone who starts using it. If it was a problem for a small group that needed a feature, it wasn’t a big deal.

Thank you, you are quite right about my confusion. I did read the posts you mentioned and am now slightly less confused. I still don’t know what the difference between AbstractVector{<:Real} and Vector{<:Real} is though. I had declared it as Vector{Real} which obviously didn’t work.

A major difference is scaling:
Run times scale with the size of the problem - doubling of the sample result in double run time.
Compile times, in contrast, are constant. They are always a few seconds (depending only on the software you are using), independent of the calculation sample size. Thus, they become insignificant for numerically challanging stuff. On the other hand, they are rather annoying if your calculations themselves are very quick.

1 Like

64 bit

Probably that should be split in a new topic. But if you use AbstractVector your function will accept, for example, views, StaticArrays, and other array types which are not Vectors in the strict sense:

julia> f(x::Vector) = 1
f (generic function with 1 method)

julia> g(x::AbstractVector) = 1
g (generic function with 1 method)

julia> x = [1,2,3];

julia> f(@view x[1:2])
ERROR: MethodError: no method matching f(::SubArray{Int64,1,Array{Int64,1},Tuple{UnitRange{Int64}},true})
Closest candidates are:
  f(::Array{T,1} where T) at REPL[1]:1
 [1] top-level scope at REPL[3]:1

julia> g(@view x[1:2])

julia> using StaticArrays

julia> x = zeros(SVector{3,Float64});

julia> f(x)
ERROR: MethodError: no method matching f(::SArray{Tuple{3},Float64,1,3})
Closest candidates are:
  f(::Array{T,1} where T) at REPL[1]:1
 [1] top-level scope at REPL[8]:1

julia> g(x)

Concerning Real vs. <:Real I like my way to explain this, for obvious reasons.

1 Like

Honestly, I feel like python gets too much credit here. It is easy to end up with python installs that have serious usability problems. I regularly have 5-20 time to first being able to type in ipython. I don’t really know why, because it varies from system to system and it’s not worth my time to debug a transient problem one system that isn’t a 100% show stopper (I work on many very similar, but slightly different computer systems running very similar, but slightly different pieces of equipment). I regularly (many times in the past few years) have issues where matplotlib is nearly unresponsive or hard freezes my terminal. At least some of the blame may fall on the somewhat opaque security settings my organization applies to our machines I always see these threads that take it as given that the python world has plotting and interactivity nailed, and it is not true. It’s mostly true, but I see exceptions on a regular basis.

Absolutely. Here’s how I think about this:

Once you get familiar with a tool, and you come to understand it’s deficiencies and find workarounds for those deficiences, they stop bothering you as much. You get used to them and sometimes even stop noticing them.

Later, if you try out a different tool that has a different set of tradeoffs, strengths and weaknesses, you’ll maybe notice the strengths, but you’ll also definitely notice the weaknesses. When you compare that new tool to the old tool, it becomes very difficult to make objective comparisons because you’ve trained yourself to not notice the problems with your old tool.

This effect is why a lot of Python programmers will brush off complaints about speed, expressiveness or composability and say “nah it’s not that big a deal”. It’s also why a lot of julia programmers (myself included) will just brush off complaints about compiler latency, documentation and such.