Julia from the perspective of a pythonista

General Usage
1

Julia from the perspective of a pythonista

Intruduction

I will start this post with a brief description of myself. I have been writing code in the Python programming language for about 3 years. My main interest is in artificial intelligence and in addition I am also interested in data science. As someone with a background in engineering, I am no stranger to scientific programming and I enjoy it. I am generally interested in programming languages and would like to know more about them.

Recently, after testing popular programming languages such as Java and C, I came across the Julia programming language. At first glance, this language seemed very promising, and the more I read about it, the more I became interested in it. First I want to describe the features of Julia that I like and then I will explain the things that I think prevent the full utilization of this beautiful programming language.

What I Like About Julia

In my opinion, the most attractive feature of Julia is its multiple dispatch idea. This feature makes me think differently about the problem when I write code in Julia, because I have not seen a similar feature in Python.

Another interesting feature of Julia is the ability to specify the type of variables optionally. This feature allows the programmer to specify the type of variables if he likes and in return enjoy high speed execution.

The next feature that makes Julia a promising programming language is its jit compiler. This compiler potentially allows the programmer to expect a fast code if the Julia features are used properly.

And last but not least, the Julia language has an active community around it. Although the size of its community is not as large as older languages, it can be expected to attract more people if Julia continues to address it’s problems.

What I Wish was Different about Julia

What motivated me to write this text was saying the problems I encountered in my first encounter with Julia. Hopefully, maybe people like me who have had these problems can help me.

The first problem was the lack of an efficient programming environment for Julia. For example, the only Julia IDE I found was Juno, which is actually an extension for the atom code editor. The disadvantage of juno is the long initial start time.

After my frustrating encounter with Juno, I decided to try the Julia extension for VS code. Unfortunately, this extention takes so long to start, so that the initial start of the extension takes about two minutes. The initial launch of the Python extension for VS code takes about 30 seconds.

As someone who spends most of coding time in the Jupyter notebook environment, I was very happy to have an official Julia kernel for Jupyter. But after installing this kernel, I realized that there is the problem of a very long initial start in this environment too. The start time for the Python kernel for Jupyter is almost instantaneous, while the Julia kernel takes about 30 seconds to start.

After watching computational thinking course in youtube, I became familiar with Pluto’s environment and told myself to try it as well. Surprisingly, I saw that in 2021 a coding environment does not have Dark Mode.

After searching for solutions to these problems, I realized that the Julia community is more interested in enduring the current situation, whereas in open source culture, when there are such problems, we should try to solve them with each other, not accept them or to say that very well, we do not have this feature at the moment and we have to wait for someone to write it for us.

After unsuccessful attempts to create a comfortable environment for coding in Julia, it was time to deal with the slowness of the first plot. However, compared to matplotlib, the next plots are also very slow.

After all these steps, I realized that ironically coding and achieving a specific goal in Julia is a slow process. In my opinion, in research work, development and coding time is much more important than execution time. In addition, for everything Julia offers, you will find a fast enough alternative in languages like Java, C, C++, or Python. I mean, contrary to what the Julia community thinks, the strength of Julia’s language is not its speed, but the beauty of its design and how it makes you think differently.

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.

Finally, I think I should point out the ambiguity of the language documentation. So to understand many of its useful features we have to use sources other than official documentations. For example, to understand meta-programming in Julia, after much effort and failure to read the official documentations, I decided to read the wiki book, and it explained this much more clearly than the official documentations. I think one of the reasons for the lack of suitable packages for Julia is due to this ambiguity in the documentation. The more people understand the language, the more likely they are to produce better quality packages.

Conclusion

I find Julia language very beautiful and I hope it will be used more in the future. In my opinion, language, in addition to its role in achieving a specific goal, can greatly influence the way you think about problems. In the past, this different thinking existed in languages such as Lisp and Erlang, but unfortunately these languages are not widely used now. I think Julia could be a new way of thinking in the world of programming languages.

Finally, I hope that the current problems of this beautiful language will be solved with the help of a healthy community.

19 Likes
2

Thanks for your feedback!

In >99% of the cases, specification of variable / parameter types is not required for performance purposes, see add basic overview of when to use type declarations by stevengj · Pull Request #39812 · JuliaLang/julia · GitHub for more details.

This is strange, the startup time for VSCode, Julia extension and Julia REPL is about 30s for me, even including precompilation of VSCodeServer (which is only required if the Julia extension is updated).
What Julia version are you using? I recommend using 1.5.3 or 1.6-rc1.

The well-known time-to-first-plot problem in Julia has significantly improved in versions 1.5 and 1.6 and expected to be improved further in the future.

14 Likes
3

Currently I am using julia version 1.5.3. this is how Julia extension for vscode work for me:

slow_vscode_julia_extention

And this is how python extension work for me on the same system:

python_vscode_extention2

I tried different machines and operating systems.

Yes I saw this in my searches but this is not a Pluto feature. every time you enter the environment you need to do some extra work for having dark mode. The point is for programming environment that is so strange to not supporting dark mode.

Yes it is better but still it takes too long in comparison to other visualization tools. Plots after the first one still takes too long.

However thanks for your suggestions.

2 Likes
4

Yes, these kinds of reports are invaluable — thanks for taking the time to write this all up. I’m sorry it was so frustrating.

The only specific point I’ll comment on is this meta-comment:

I’m rather discouraged this was your takeaway. I do think that we (as a community) can sometimes be a little overzealous in jumping to suggest workarounds that have worked for us — especially for the “big” problems like the time to first plot that are frequently lamented and have posed relatively challenging to fix. That said, the compiler team has been working to improve Julia’s startup latency and the time-to-first-plot over the past year, and things are definitely getting better.

I’m guessing you’ll get lots of such suggestions here. :slight_smile:

26 Likes
5

I’m glad to hear this from you

2 Likes
6

One thing that’s important to mention is that we really appreciate as many specific doc complaints as possible. User complaints are the best way of making doc changes align to what new users need.

7 Likes
7

I think it is worth noting that Pluto is rather new. According to the very first commit of the repository it is about one year old (apparently it turned one yesterday! :smiley: ). While dark mode is a standard feature of modern programming environments it certainly isn’t the top priority at an early stage of development. IMO, Pluto is lacking much more important/basic features than dark mode.

Also, note that Jupyter notebooks (don’t know about lab) don’t have a built-in dark mode either.

In case you didn’t know, the “Ju” in Jupyter stands for Julia :slight_smile: So it shouldn’t come as a surprise that there is an official Julia kernel.

9 Likes
8

You really will, and I am sorry about that.

ModellingToolkit.jl is the answer that I am sorry no one gave you.

Its a bit confusing, because it looks like a highly domain specific tool, especially in its docs.
But it is actually a general purpose CAS. Does all of your simplify and Symbolic Differentiation that you would want from a CAS.
Not just ODE modelling stuff.
Soon that confusion will be resolved as the general CAS parts of it is being moved to its own package, leaving ModellingToolkit to be just the domain specific frontend

15 Likes
9

Honestly, after the “Getting Started” section, by reading the documents, I feel that the author has assumed that the reader has an initial familiarity with the language.

2 Likes
10

I think the first priority of a coding environment should be a comfortable user interface because when it is annoying it is difficult to continue coding in that and in case of dark mode it is impossible for many users, me included, to deal with that.

:smiley:

11

Thank You very much for your suggestion, I will definitely try it

I do not know, perhaps writing comprehensible documents is more difficult than writing a complete and complex package.

2 Likes
12

I think it is historical, the CAS grew around the domain specific tool.
So the domain specific docs are still first.

2 Likes
13

I’m not entirely disagreeing. But typically, the first priority when you create something new is to promote your decisive novel feature and convince users that it is worth to “invest”. Without a decisive novelty often no one will care. I think we both agree that Plutos novel feature is reactivity and not dark mode :slight_smile:

Just be to be safe here, I’m not joking :slight_smile: Taken from wikipedia:

Project Jupyter’s name is a reference to the three core programming languages supported by Jupyter, which are Julia, Python and R,

11 Likes
14

I totally agree with you, but that does not justify a bad user interface.

I learned something new today, thank you

15

I think this depends on what you are working with. I am finishing my PhD on Combinatorial Optimization and you will hardly find someone using a language different of C++ or Julia exactly because of the speed of execution. Also, papers often report the execution time, and is hard to publish if you do not have good execution times.

8 Likes
16

I wish you success in your work.

I agree with you, as someone who is mostly testing different models and methods in Deep Learning, the prototyping and idea testing phase is more valuable to me. Run time is also very important to me, but in the next priority.

17

Yeah sorry, @shashi will get to that when we’re done writing the big paper these next 2 weeks :sweat_smile: .

14 Likes
18

Yeah, that’s fair. Most of the docs have been written for people very familiar with julia, and all the review is by people very familiar with julia. It turns out that writing good docs is really hard. It’s part of why I really wish our docs were in a more wiki-like format. Right now, doc changes require using github to make a PR, which takes at least a few hours to fix something. If anyone could automatically make changes, I think our docs would be in much better shape.

5 Likes
19

In >99% of the cases, specification of variable / parameter types is not required for performance purposes

Maybe by variables he means struct fields? That’s where type annotations are usually useful for performance.

2 Likes
20

Honestly, after the “Getting Started” section, by reading the documents, I feel that the author has assumed that the reader has an initial familiarity with the language.

This is very true. It would have been very helpful for me if there was a “docs for beginners” that prioritizes basic knowledge of Julia’s syntax, a few common performance tips, and a bit on how Julia works (compilation process outline, method =/= specialization, type stability with the extra bit of leeway via union-splitting). Just enough to allow newcomers to play around in the REPL and read the main docs site more smoothly.
Without one, I tried to go through the manual in order, and trying to understand “Metaprogramming” before “Multi-dimensional Arrays” was a big-M mistake.

6 Likes