Would you like me to add this distinction to my conclusion in the blog post? Would that be more fair for Julia?
Yeah, that would be most reasonable, I think. I also hope that Julia will close the performance gap between it and Rust in the future, and I’m somewhat optimistic that that will happen. In my experience, the performance gap is not due to language design, but simply that functions implemented in Julia is full of small inefficiencies, whereas Rust prioritizes performance higher.
And I do warn about dead locks in the blog post. I do not claim that Rust prevents all race conditions. I said that it makes data races impossible as @sijo explained. It sounds “sexy” and is accurate.
Yes you are right. I see you even have a disclaimer attached to “fearless concurrency”, stating you can still have deadlocks. I was not reading carefully enough, I apologize.
I did use
@report_optbut since it only generates warnings, I did not want to mention them. There were also warnings aboutprintln. Should I not trustprintlnthen?
You should not trust any code you haven’t tested, and that includes Rust code. Nonetheless, I agree that dynamic dispatch is currently too hard to avoid because IO operations and thread fetching is inherently type unstable. That is most unfortunate.
In my experience though, at least for medium-sized Julia programs (a few thousand LOC), these false positives tend to be few enough that one can manually review all type instabilities.
Also IMO, static checking in Julia still needs to be better in several ways:
- There are too many type instabilities in Base
- There are too many type instabilities in packages throughout the ecosystem
- There is no good way of statically checking an entire package. Maybe that’s not possible in Julia.
Luckily, JET has improved a fair bit since it appeared about 2.5 years ago. I’m fairly optimistic it will continue to improve.
One more thing I want to comment on: In your blog post, you write:
On the other hand, if you want the highest performance in Julia, you have to write a
forloop.
As I’m sure other people in the thread has told you already, that’s not really the case 
Iterators in Julia, just like in Rust, can automatically elide bounds checks, SIMD, and are zero-cost.
It sounds like we mostly agree, broadly. Perhaps the difference comes down to the kinds of programs we write. In my job, I tend to write packages that are used fairly generically (so code reuse matters), and where the requirements constantly shift. I also write a ton of data analysis one-time-off code. I don’t write a lot of application-like code.
I feel like at least 50% of the Rust vs Julia discussion comes down to the old dynamic vs static language discussion. Rust and C++ provide more guarantees, but Julia and Python is easier to write and iterate on. Rust doesn’t fundamentally change this calculus, although it does nudge the balance a little by providing more guarantees than C++ while (alledgedly, I have no C++ experience) being nicer to write. On the other hand, Julia also nudges the balance by being fully dynamic, while also statically analyzable.
The proponents of static languages - whether C++ or Rust - tend to place correctness as the top priority and be relatively less worried about programmer productivity. Some people, not you, but the most ardent proponents of static languages, even claim that one should always prefer static languages because the time saved by static checks outweighs any gain dynamicness brings. I think it’s safe to say that scientists and programmers historically have overwhelmingly “voted with their feet” and ignored this advice. There is a reason dynamic languages like Python and Javascript are the most popular languages, and I don’t really see Rust changing this picture.