Julia from the perspective of a pythonista

First of all, thank you.

As @oxinabox indicated, many of your examples do in fact have Julia pendants. Perhaps in some cases not yet as feature rich but I fail to see in these cases that the existence of PyCall eliminates the need to write these packages in Julia when there are packages and solid attempts available.

What I’m more confused by though is that it feels to me that, for some reason, Python wrappers to C/C+±libraries like Tensorflow (used in python) are ok for you but wrappers to the same libraries in Julia are somehow hindering package development. Also, I fail to see why binding a library through PyCall is any more eliminating the need to rewrite this library in Julia than binding the library in any other way (say on LLVM/C level). If anything (and I tend to disagree with you on this), the mere existence of wrappers, independent of how they are implemented, would have such an effect.

Personally, I believe that wrappers are awesome. They give you access to established functionality which you would otherwise be unable to use in Julia. Would I love to see more pure-Julia libraries? Definitely and I see lots of promising progress! This will just take (a lot) of time. I doubt that anyone (other than Google itself) will every rewrite Tensorflow in Julia and that’s fine.


Given how much great insight you’d had to offer about the challenges you’ve faced as a potential Julia author, I wonder if you might consider avoiding assuming negative motivations for things you’ve disliked. Just as a good open source project needs to try to address user issues like you’re seeing, I think users of OSS should also avoid imputing negative motives to other members of the community.

Does that seem fair to you?


The reason for this is the goals set by the creators of the language themselves. check this presentation from guido:

according to this presentation from the creator of python:

Python is a simple, yet powerful programming language that bridges the gap between C and shell programming, and is thus ideally suited for "throw-away programming’’ and rapid prototyping.

The fact is: Python is not written for quick computation. according to Jeremy Hylton, core developer of python since 1995:

In the '90s, our goal was to be more popular than Perl

The reason for the vast data science ecosystem around Python is that people like Python, not because Python is fast. In fact, Python is too slow to do machine learning and data science! People write fast packages in C for python because Python can’t do it.

But on the other hand Julia is not slow! according to julia home page:

Julia was designed from the beginning for high performance. Julia programs compile to efficient native code for multiple platforms via LLVM.

The point is you do not need anything else other than Julia itself to write practical code in Julia.

I do not see trying to impress as a negative motivation. If we look at the subject from the author’s point of view, he knows interesting things about language that we do not know. As human beings, I think we can sometimes get excited about what we know, and that enthusiasm becomes the main theme of our writing.


And time. Lots and lots of time to replicate an old tested and well optimized library from other language to any new language. Julia base library uses BLAS for Linear Algebra, that is one of the domains Julia shines on, because too much effort was dedicated to that library to rewrite it from scratch in Julia just because we can. There are better uses for such effort.


I think the “problem” is that the authors do have familiarity with the language, and with other languages that have similar features (like lisp). I agree with you in the sense that the manual is hard to follow for someone that has not familiarity with the features Julia has. It is hard to write that “manual for beginner” because the “official” manual is forced to be always absolutely precise in the language, which many times does not help from a didactic point of view. That being said, I think the manual is mostly very, very good, after one has understood more or less how the language works. And it is probably very good for someone more experimented in programming languages in general.

Is there such a thing as an “oficial” Python manual?

I recommend reading other sources. Like this book. It was almost for free some weeks ago, and books and other material don’t have the constraints that the official manual have, and thus can be more relaxed and instructive many times.


I remember the days when I started learning Python. I started learning Python with SoloLearn and then read No Starch Press books. After these steps, I watched Microsoft and Google training courses for Python. There were so many resources along the way that I never felt the need to read official sources.
I tried to repeat the same path for Julia. Unfortunately, there is no Julia course on programming training sites like SoloLearn. If you know a site, please introduce it.
Lack of learning resources leaves the entire burden of education to official documentation.

Thank you very much, I will go for it.

Actually I think there is quite a lot of books, videos, tutorials about Julia now. I asked about the Python manual because I have the hypothesis that having an official manual is sometimes playing against Julia, because people get frustrated by how it is written and quit without searching for other sources. The manual perhaps could start by pointing to other sources of information and state clearly that it should not be considered as the ultimate and unique source of learning resources.


Excerism has a julia track.
It is (from what i hear) pretty well regarded
Several members of the community (not me) mentor for it.


Try Julia Academy for some basics, though maybe it falls short of a full “Julia course”. 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). I have not tried this Julia course from Coursera since I knew the basics before I discovered it, but it seems to have good reviews (4.5/5 stars). 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.

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.


Something like you’ve written here I think should be written in the first paragraph of the Manual, in the “Getting Started” section. And should updated without much ceremony every time a good learning material comes by.


With a background in engineering where I do a fair bit of vibration testing and analysis, some using major packages and some using MathCad, and Matlab, I was attracted to Julia because it is open source, high level, Matlab like, and seems like it has great promise.

My style of learning is to jump in and try something, and then look for documentation, and particularly examples of something similar to what I am doing.

On one project, I wanted to read a data file that the Gantner data acquisition system wrote. I had available a shared library, a dll file that a matlab mex file uses to read the file. Based on this I was able to create a Julia file with many ccalls to read the data file. Another project was to read the MCC 172 vibration data acquisition card with Julia, again using many ccalls to a shared library. In this case, as a new Julia user, I found the manual chapter on ccall confusing, probably because I did not understand all the terminology. More examples, especially the use of Ref{} and Ptr{} would have been useful. I did find Julia discourse most helpful, with a senior Julia expert answering my questions on a Saturday. That was most impressive.

Trying to understand when to use Ref{} and Ptr{} for ccalls was not very clear in the manual. I think I decided that Ref{} is used for scalers, and Ptr{} for arrays. Correct me if I am wrong, and if I am right the manual could be clarified.

One of the styling tips suggests that variable Types be as general as possible for multiple dispatch. Yesterday I was experimenting with passing an array to a function using the most general Type possible. I finally decided that because arrays are passed by pointer, that they need to be very specific when passed to a function. I did not find that discussed in the manual. It probably should have a sentence or paragraph in the styling tips, and also somewhere in functions. Or maybe it is hiding in there somewhere and didn’t jump out at me.

I tried to recreate a Pluto environment I have on a Win 10 machine on a Win 7 machine. Julia runs fine on Win 7, but Pluto was a disaster. There should be something in the Pluto documentation steering us away from Win 7.

I have found MathCad to be a very useful environment for performing calculations as documenting them. The equations look like they would with pencil and paper, but they calculate automatically. The environment is ideal for Roark and Young type handbook formulas. It can show a figure which documents the variables used for say a moment of inertia calculation. It natively uses units for all calculations. (I have not yet tried units in Julia, so can’t comment on them.) It is not a good environment for large scale programming though. Overall it is still my goto environment for “back of the envelop” type calculations. The real challenge is how to integrate the good things of MathCad (inserting a photo or scanned image and equation formatting) into an environment like Pluto. MathCad Prime is available for trial, and after the trial period it is still available with basic functionality.

1 Like

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

I think that’s probably a good idea. It would be seem very natural to point to other non-official, but well-written, tutorials before diving into the docs.

[Edit: There actually is a link to the learning resources page at the bottom of the Getting Started section. But it’s very much a footnote rather than an advertisement.]


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.


Exactly, the hard work of curating the material is already done. For a beginner in programming a good advertisement and guidance to go for that material at the very start would probably avoid some bad initial experiences.


the worst feature I saw in Julia’s language is the lack of proper packages and libraries. For example, I was looking for a suitable package for symbolic algebra in Julia and found that instead of using the unique features of the Julia language, they suggest calling the Python SymPy module. The point is, if I want to work with SymPy, I can easily use it in Python, and I do not need to endure the long initial start times in Julia.

Most languages, including many very mature ones, don’t have a library like SymPy. Full-fledged computer algebra systems take a ton of work to build, and they don’t get built until someone with the time and wherewithal has a compelling reason to do it. Furthermore, the convenience of calling SymPy from Julia makes it more difficult to justify building a Julia-native version. So what ends up happening is that this functionality evolves in specific contexts where SymPy doesn’t meet the needs of a given application (e.g., ModelingToolkit.jl), and it grows from there.

So really what you’re observing here is that Python enjoys an impressively extensive collection of packages. For any user that prioritizes that, their options in the short-to-medium term are to use Python or call Python libraries as needed from Julia (or some other language). What Julia offers is better interoperability between packages, including ones that are just Python wrappers. For example, I prefer SymPy.jl to using SymPy directly in Python, because it’s less verbose and offers some additional functionality via generic Julia methods.

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.


I am wondering if you know PackageCompiler.jl. You can precompile PyPlot (or any other julia package) so that even your first plot take < 1 seconds.

# first command in my session
julia> @time begin; using PyPlot; ion(); plot(1:10); end
  0.339586 seconds (71.61 k allocations: 3.859 MiB)

Caveat: you need to recompile your system image every time you update PyPlot and for some reasons you need to explicitelty toggle the interactive mode with ion(). It would be great however if PackageCompiler (and Revise) would be somehow be integrated into Julia to make this simpler (and less confusing) for new users.


Was the Win7 system 32 bit or 64 bit?
In general, the problem with Win7 is that it is so old that it is not even supported by the Github CI (to my knowledge).

1 Like

Yes, there are some, but not enough, the quality of educational materials is much lower than educational materials in other languages.

I assure you that when someone really wants to learn a subject, they check all the available resources and complaining is the last thing they do.

I tried this but it is not like SoloLearn which has interactive and quiz based tutorial. Excerism is very similar to homework, but for doing homework you first need good tutorial.