Julia from the perspective of a pythonista

[dariush-bahrami]

@mihalybaci

Try Julia Academy for some basics, though maybe it falls short of a full “Julia course”.

actually I took Julia Academy courses. this is the proof

@mihalybaci

It seems you’ve found the MIT Computational thinking class, which I really like myself (replace “Spring21” with “Fall20” to get to last years one that has completed).

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

@mihalybaci

I also was a big fan of “Think Python” by Allen Downey – it’s how I learned classes – and there is an equivalent Think Julia book that is very nice as well.

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

@mihalybaci

Though with any training material, be very mindful of the Julia version being used. For instance, “Think Julia” uses v1.1.0, so there may be some syntax differences if you’re on v1.5.3. If you’re not sure of the Julia version, just look at the publication date.

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

[lmiq]

@dariush-bahrami

really wants to learn a subject,

“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.

@dariush-bahrami

is much lower than educational materials in other languages.

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.

[dariush-bahrami]

@lmiq

I think anyway that this feedback is important, because there might be people and companies willing to invest on that.

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

[SadeghPouriyan]

@sswatson

Whenever you see a major, long-standing problem in a widely used piece of software (e.g., Julia’s time-to-first-plot, or Python/R/MATLAB’s execution speed), the safe bet is that a ton of effort has gone into addressing the problem, and any lack of success in those endeavors is due to the inherent difficulty of the problem.

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.

[carstenbauer]

@SadeghPouriyan

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.

[johnmyleswhite]

@SadeghPouriyan

There is no expectation from Python to have high execution speed

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

[dariush-bahrami]

@mihalybaci

I also just saw this Discourse post about beginner videos for Julia that may be useful.

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.

[carstenbauer]

@dariush-bahrami

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 Get started with Julia (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.)

[sswatson]

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’.

[SadeghPouriyan]

@johnmyleswhite

if you run a business that would benefit from Python being faster.

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.

[lungben]

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

Python Developers Survey 2020 Results

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

[dariush-bahrami]

@lungben

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

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

[mbauman]

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

[SadeghPouriyan]

@sswatson

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.

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.

[Jake]

@stevengj

Probably you are confused about invariance , e.g. you should have declared a parameter as AbstractVector{<:Real} but you declared it as AbstractVector{Real} instead — the former allows Vector{Float64} and the latter does not. This comes up a lot in the forums, e.g. here and here and here and here etcetera.

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.

[lungben]

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.

[Jake]

@lungben

Was the Win7 system 32 bit or 64 bit?

64 bit

[lmiq]

@Jake

AbstractVector{<:Real} and Vector{<:Real}

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
Stacktrace:
 [1] top-level scope at REPL[3]:1

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

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
Stacktrace:
 [1] top-level scope at REPL[8]:1

julia> g(x)
1

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

[ggggggggg]

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.

[Mason]

@ggggggggg

Honestly, I feel like python gets too much credit here.

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.