Julia from the perspective of a pythonista

I doubt that anyone is trying to impress here. One reason for the verbosity of the documentation is that historically it was both a “tutorial” and a technical documentation and has been a strange mixture ever since. Maybe we should split these two variants at some point. One readable, verbose “getting started tutorial” and one technical documentation.

23 Likes

Yes, it will be great.

1 Like

Hey @dariush-bahrami ,

welcome to the community and thanks for your feedback. It’s very much appreciated.
I’m wondering whether you always execute a file directly in VS-code or the command line. I think the more standard way (after using Julia for quite some time) is to open the REPL and then use include to execute the file or include and track it using https://github.com/timholy/Revise.jl
This is by no means a critique of your current way of doing things more a critique to us who don’t publicly show others our workflow :wink:

Regarding some of your other points:
I agree that the number of packages isn’t that big yet and there are still quite a lot of packages missing whereas for others there are quite some which are unmaintained and overlapping. I do think that the PyCall package can be helpful as one can write stuff that is using multiple dispatch and speed on some additional code outside of a package in Julia and can use the size of the Python community to ones advantage in combining their two strength.

Hope you’re giving Julia another chance :slight_smile:

4 Likes

Is that by typing the command directly in the REPL?
I find that execution of code from the editor using Alt+Enter (“Execute Code and Move”) or Shift+Enter (“Execute Code Cell and Move”) remains unresponsive for quite a while after the REPL is already up and responding.

I am currently using the REPL or Jupyter environment to learn Julia. But these environments are not suitable for writing modular code and packages.

Thanks for your suggestion, I will try this

I do not agree with you, because for most problems you will probably find a Python package, and if you want to use Python to solve problems in Julia, Julia will never find the character it deserves. In addition, you can use Python to call Python code. I think the PyCall package has been overused.

For now, despite all the problems I have mentioned, I enjoy learning Julia.

2 Likes

As a shameless plug you might find part of my blog post interesting about workflow with Revise Julia Basics: REPL & Revise
I think most of us package developers use it all the time and load the Julia REPL once in the morning and leave it open for the rest :wink:

3 Likes

Thank you, I will definitely try it.

I have only tried PyCall recently so I’m not using it frequently I just find it quite interesting but one can probably argue the other way around works as well. Haven’t tried that though so I’m not sure how well it works.
For my personal project it was just that I used a lot of packages that I find very nice in Julia and was missing one thing I couldn’t find and found out how to do it in Python.
The main point is probably if more than 5% percent or even 10% of your code needs Python library then you might want to look into just using Python if it doesn’t have big downsides based on their huge community and number of packages. If you only need Python for one or two function calls inside your code because Julia is lacking that package then it’s nice that PyCall exists.

I agree with you, but not everyone uses PyCall this way. By overuse, I mean that they use PyCall to port a complete package to Julia as a wrapper for packages in Python. This is not a bad thing in itself, the problem starts with eliminating the need to write new packages in Julia.

1 Like

Yes, I typed it directly into the REPL.
Also right-clicking on a .jl file and select “Julia: Execute File” is rather fast for me.
Alt+Enter / Shift+Enter takes also for me a while after VSCode startup because it seems to wait until the indexing of Julia packages is finished - looks like this issue: [FR] Make inline eval responsive during "indexing packages" · Issue #1962 · julia-vscode/julia-vscode · GitHub

I’m curious, do you have an/a few example/s?

For interest:
As the co-author of TensorFlow.jl, do note that it was made for julia 0.4, which was when julia’s ecosystem was still young.
It’s now basically feature frozen, due to the fact that I have moved on to working on Julia tools like Flux.jl
These days there are a bunch of strong julia alternatives.
Flux.jl, KNet.jl, Avalon.jl (nicely all of which wrap NNLib.jl for many operations)

It’s also not correct to characterize it as a wrapper of python.
It doesn’t really use PyCall, not for most things.
It wraps the LibTensorFlow C-API, for over ten thousand operations.
Just like the python tensorflow library does.
(It technically uses PyCall, but only for a single graph manipulation that doesn’t actually have a C library back-end)
It’s (IMO) a good example of a library that is much easier to write in julia than other languages.
It uses julia’s metaprogramming to generate the wrappers of all the API.
For a while it was a few features ahead of the python tensorflow library, supporting things like xs[i; mask] when writing that in python would have been a bunch of calls to less idiomatic operations like gathernd.


I think more generally you will find that most of those libraries listed do have pure julia alternatives.
In some cases because they are old, and julia alternatives were not written.
in some cases because people have a particular liking the python API, or that they want it as a baseline, or that there is just the gains of a pure julia implementation is less than doing some other thing.
(No need to reinvent the wheel)

For interest, my employer has what is probably the largest production Julia code base (~450K LOC).
Last time I checked the only python dependency we have was for intereacting with SOAP.
At some point we plan to make a julia library for that, or wrap a C library.
Makes sense that there wouldn’t be a julia library, SOAP is almost a legacy format these days.

23 Likes

Can you give specifics? Which parts of the documentation are written to impress rather than inform?

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.

8 Likes

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?

22 Likes

The reason for this is the goals set by the creators of the language themselves. check this presentation from guido:
https://www.cwi.nl/events/2019/lectures-2019/2019-cwi-guido.pdf

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.

4 Likes

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.

13 Likes

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.

3 Likes