I used Julia for a while and wrote a blog post about it: What do you think about this post?
I think your experience is entirely accurate - docs & error messages are the biggest problems julia has right now, but unfortunately I don’t see a lot of momentum happening in that direction. A lot of people seem to know that this is bad, but either willfully ignore it or efforts to make it better stall. We really could do with a Quality Of Life release that just improves on this, without adding big new features for once, like all releases since 1.0 have.
One thing I disagree with is Debian’ BenchmarksGame being a good or representative benchmark of a language’s performance - the benchmark is notorious for having some pretty arbitrary restrictions on what is and is not allowed for some subset of languages, while others can do pretty much whatever they want to squeeze out every ounce of performance possible.
4 posts were split to a new topic: Does Debian’s BenchmarkGames show representative performance?
Hello,
It’s a nice write-up of your experience.
I’m very sorry to hear you had a frustrating experience.
I think it is quite typical of what new people face when they start using Julia.
I’m not sure I understand all of your points, as my use is a bit different from yours.
I’m not a big library user, so I rarely need object definitions like you seem to need.
But I can relate very much with startup times and workflow issues.
I think most of those issues can be solved but it is certainly not easy to find out by oneself.
Best is to be shown by someone. This can put you on track in 10 minutes. Finding out the right workflow using the documentation can be very frustrating.
One reason for this I think is that there are many possible workflows, but many are not really optimal, so it can be very time consuming to fin out the right one.
I hope, still that you will consider Julia for your future projects as I think it is an extremely powerful tool with many advantages compared to matlab for instance (I don’t know anything about python).
Finally, I would say that if you face any difficulty using Julia, the best is to post concrete and specific questions here. You will most of the time get very helpful an quick responses.
Best,
Olivier
The problem is that this short code will take longer to write, because dynamic typing, bad reference documentation makes writing and debugging Julia code extremely hard.
I’d say this is a very opinioned claim. For me, Julia saves my life a lot in implementing numerical algorithms. The grammar is so similar and straightforward to most pseudo-codes in numerical publications that I can implement, e.g. an Anderson acceleration method exactly follows the pseudo-code in Walker, H. F. Anderson Acceleration Algorithms and Implementations ; 2011; Vol. 2280, pp 1–8 in about 1 hour or less including the testing stage! I am addicted to this experience.
It’s an interesting post, and useful. I do think the language indicates that it is written in frustration, and has some needlessly inflammatory phrases, such as saying Julia is not “a proper language”, and that it lacks a proper type system (which is manifestly incorrect.)
It’s also a bit unclear what the example linking to the SimpleDiffEq.jl repository is intended to demonstrate.
So, since you asked: you advance some reasonable criticisms, but couch them in language that appears somewhat agitated. Perhaps you could try to be more directed, that is, criticizing the parts that are really troubling you, and try to separate them from issues that are more about them being unfamiliar (such as lack of classes, external functions, etc.)
Edit: Also your “Variable bindings can be confusing” point is, well, confusing, since only the last snippet has anything to do with binding. I don’t think your confusion there is something specific to Julia.
I wander why Fortran was not an alternative to you?
I mostly agree with the post points, although the tradeoffs for me are different. As I follow more people using Julia I find that getting used to a confortable development workflow is one of the pain points. (I guess you used Revise, etc.).
IMHO, Julia (and dynamicly typed languages in general) is faster to type, but harder to debug.
I never used Fortran.
It reads like a rant. Not sure for whom that sort of post should be useful. As a package maintainer I get very frustrated when I read such negative and non-constructive blog posts. In particular statements like “The Julia ecosystem is quite immature and buggy” makes one sad seeing that many people put quite some effort into their packages often in their spare time.
Modern Fortran is definitely a nice option for numerical computing on the statically typed world.
Actually no. It is written months after my time with Julia.
Please don’t be offended, that’s just my style. Does not mean that I do not like you guys, I even met the lead devs on a conference and they were cool guys. It’s meant to be constructive ranting.
That Julia’s flagship libraries have good tutorial but bad references.
Then maybe you should reconsider your style. Just my feedback.
I think that example requires some elaboration, because it just confused me.
I don’t mean no offense, it is mean to be constructive. I think that it a good understanding of the challenges we face is important.
Don’t be sad. I know that many very smart people work very hard on it. Does not change the fact that other languages have better ecosystems.
UPDATE: I made some changes to my post to be politically correct. The old version can be found here: personal_website/julialang.md at c8b5b107f3931da45be438e73ae7be4662db8170 - personal_website - Codeberg.org
I really appreciate you taking the time to write this post! I think feedback like this is invaluable to improving the language and its ecosystem. I have come across very similar issues in the same ecosystem/environment you presumably worked on. While I still use Julia for research every day, these issues are a major impediment when trying to convince others to jump ship from, e.g. Python Thanks for the write up!
I don’t see where political correctness or lack thereof enters into the picture here
You claim this to be a fact and therefore I wonder:
- What is you measure to quantify the “buggy-ness” of an ecosystem?
- What part of the ecosystem do you take into account here? All? Just a subsample?
Let my correct myself:
Does not change my observation that other languages seem to have better ecosystems.
I don’t claim to have perfect sampling and measurement. Just my 2 cents.
Political correctness, politeness, non-inflammatory language, call it what you want. Here is the diff:
@@ -17,7 +17,7 @@ In 2021, I had to do some numerical calculations for my master thesis about theo
First I thought about using python. It is commonly used for scientific calculations, mainly because of its good ergonomics, i.e. python code is shorter than e.g. equivalent C code. Dynamic typing can lead to a horrible mess in larger projects, but I knew my code would stay small. The problem with python for my use case is its poor performance. Numpy is quite fast, definitely fast enough, but if I had to manually write a hot loop in python, it would be unacceptably slow.
-A faster alternative would be C/C++. While it is definitely fast enough, its poor ergonomics would inflate the time needed for writing the code. Also, I hate C++ with a passion, but this is a story for another post.
+A faster alternative would be C/C++. While it is definitely fast enough, its poor ergonomics would inflate the time needed for writing the code. Also, C++ has its own problems, but this is a story for another post.
Rust is essentially C/C++, but without their ugliness. But Rust is quite a verbose language, which is fine for large projects, but not what you want for short scientific calculations.
@@ -85,11 +85,11 @@ Julia made me realize how great `cargo doc` is.
### The problem with free functions
A tutorial alone is not enough, you need a chain of links from a starting point to the function/argument/datatype you want.
-The authors of Julia argued that member functions are a bad idea, because it connects a function to a specific datatype instead of multiple datatypes. But this is not without disadvantages: Let's say you want to know the methods to modify a `Dict`. In [a proper language](https://doc.rust-lang.org/std/collections/struct.HashMap.html) you can find those methods in the documentation of the `Dict` datatype. But if you execute `apropos("Dict")` in Julia you find both functions like `Base.mergewith`, but also stuff like `Base.setenv` or `Base.Cmd`.
+The authors of Julia argued that member functions are a bad idea, because it connects a function to a specific datatype instead of multiple datatypes. But this is not without disadvantages: Let's say you want to know the methods to modify a `Dict`. In e.g. [rust](https://doc.rust-lang.org/std/collections/struct.HashMap.html) you can find those methods in the documentation of the `Dict` datatype. But if you execute `apropos("Dict")` in Julia you find both functions like `Base.mergewith`, but also stuff like `Base.setenv` or `Base.Cmd`.
## Hard to debug due to bad error messages
-I would consider myself a semi-experienced programmer. Less experienced than people who worked in the industry for years or decades, but certainly more experienced than the average scientist programmer. Julia made me feel like an absolute beginner again. **Unlike other languages, even those I spent less time learning on, I hade trouble writing certain code or debugging certain errors that I would consider extremely basic.** And I don't mean that my solution looked unelegant, like the code of a beginner. No, I was literally not able to write certain *basic* things myself.
+I would consider myself a semi-experienced programmer. Less experienced than people who worked in the industry for years or decades, but certainly more experienced than the average scientist programmer. Julia made me feel like an absolute beginner again. **Unlike other languages, even those I spent less time learning on, I hade trouble writing certain code or debugging certain errors that I would consider very basic.** And I don't mean that my solution looked unelegant, like the code of a beginner. No, I was literally not able to write certain *basic* things myself.
An example can be found [here](https://github.com/SciML/SimpleDiffEq.jl/issues/48).
@@ -162,10 +162,10 @@ The idea of "You only need to start the interpreter once a day" failed for me.
## Conclusion
-Hot loops in Julia are quite fast, but you have to wait *forever* for your program to start up.
+Hot loops in Julia are quite fast, but you have to wait quite long for your program to start up.
The Julia ecosystem is quite immature and buggy, at least compared to rust or python.
-Julia has really nice, short syntax for mathematic equations. Compared to other languages, your numerics code will be much shorter. The problem is that this short code will take longer to write, because dynamic typing, bad reference documentation makes writing and debugging Julia code extremely hard.
+Julia has really nice, short syntax for mathematic equations. Compared to other languages, your numerics code will be much shorter. The problem is that this short code will take longer to write, because dynamic typing, bad reference documentation makes writing and debugging Julia code harder.
-After a while, I decided to rewrite parts of my code in Rust. Rust code is much more verbose and I had to implement basic numerical methods since rust has few numeric libraries, so the code was much longer. However, it was still faster to write, because rust has a proper type system, reference documentation, error messages and a mature ecosystem. My Rust code greatly outperformed the Julia code.
+After a while, I decided to rewrite parts of my code in Rust. Rust code is much more verbose and I had to implement basic numerical methods since rust has few numeric libraries, so the code was much longer. However, it was still faster to write, because rust has a better type system, reference documentation, error messages and a mature ecosystem. My Rust code greatly outperformed the Julia code.