# Rust vs Julia

**URL:** <https://discourse.julialang.org/t/rust-vs-julia/11979>\
**Category:** Offtopic\
**Tags:** rust\
**Created:** [June 26, 2018, 7:35pm UTC](https://discourse.julialang.org/t/rust-vs-julia/11979 "2018-06-26T19:35:49Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [June 27, 2018, 7:54am UTC](https://discourse.julialang.org/t/rust-vs-julia/11979/10 "2018-06-27T07:54:12Z")

</div>

Reading through these discussions, I get the impression that while Rust _could_ be extended with all the relevant linear algebra operations and friendly syntax (as it is a powerful general-purpose language), this would involve quite a bit of work, which is not currently a priority at the moment for enough developers to make this happen quickly.

This is natural: language communities usually focus on capitalizing on the comparative advantages of the language first, to solve the problems which lead them to creating the language. Filling in all the niches for libraries usually comes later. This reminds me of [a recent discussion about databases](https://discourse.julialang.org/t/highly-concerned-with-the-state-of-database-libraries/11877) in Julia.

I echo @ChrisRackauckas’s point about interactivity, which would be very relevant if the algorithms of the library are not fully specified. While one can translate a known and well-tested algorithm to any language and in the worst case just use some BLAS/LAPACK bindings, exploratory programming is painful without interactivity.

---

_[View the full topic](https://discourse.julialang.org/t/rust-vs-julia/11979)._