7 ms·

As someone who dabbles in both Rust and Julia, I agree there's a lot Julia can learn from Rust. Rust has made a lot of good technical decisions, and I think man

As someone who dabbles in both Rust and Julia, I agree there's a lot Julia can learn from Rust. Rust has made a lot of good technical decisions, and I think many of these decisions came from having a team of experienced systems programmers. In comparison, Julia's decision making process seems much more informal, and snap decisions are sometimes made from the narrow perspective of academic programming rather than carefully considering the goals of the language, future uses, and forwards compatibility.

xianwen 5y ago
I'm very interested in Rust. However, it seems that Rust is not yet able to do symbolic math.
- hexane360 5y ago
  I'm sure there are some crates out there, but probably nothing very stable. If there's one thing Rust is not, it's a good "glue" language. It seems to do best in large, densely coupled projects. This is where there's the least cost to defining all your own types, and also where a strong type system provides the most benefit. I think there will always be a place for more dynamic languages that tend to do better at interfaces.
- miguelraz 5y ago
  Author here: I specifically mentioned the `egg` crate because of it's capabilities for symbolic math. You can check a minimal application of arithmetic differentiation and some simplification rules in their repo here: https://github.com/egraphs-good/egg/blob/main/tests/math.rs https://github.com/egraphs-good/egg/blob/main/tests/math.rs
  - xianwen 5y ago
    Thanks. I'll give it a try!
ForHackernews 5y ago
I like both languages, but they seem to have extremely different goals and target users to me. Julia aims to be better than R and Python at statistics and data analysis. It's not there yet, but I could easily see it replacing a great deal of academic use of Numpy and Python in Jupyter notebooks (the 'ju' is Julia). On the other hand, Rust seems like it's aiming at being a safer alternative to C for low-level systems programming. I'm sure there's things Julia could learn from Rust, but the design decisions are going to differ wildly because they just aren't trying to do similar things.
- awaythrowact 5y ago
  Fair. But to play devils advocate: one stated goal of Julia is to solve the “two languages” problem where developers prototype in {scripting language} and then reimplement in {system language}. So while Julia is meant to be as easy as Python, it also needs to be as powerful and flexible as Rust (or C or whatever). It’s supposed to be the “best of both worlds” and Rust lives in one of those worlds. If developers are better off prototyping in Python jupyter notebooks and then reimplementing in Rust than they are implementing in Julia, then I’d say the comparison is relevant. Maybe it’s an unfair standard and Julia can be a “better Python” without needing to be a full replacement of a systems language, but then Julia isn’t fully solving the two language problem, right?
  - duped 5y ago
    The two language problem exists for a bunch of reasons, some good and some not. The biggest reason is because some function of the high level language is incompatible with the application domain. Like garbage collection in hot or real-time code or proprietary compilers for processors. Julia does not solve these problems. Other reasons are practical, like portable executables in Go or Rust (portable in the sense they do not require dependencies on their target systems, usually). Julia does not solve this problem. Then there are the reasons to use scripting languages over the system languages, like expressive syntax with low cognitive overhead. Julia definitely helps here. But this comes at the cost of execution and startup time. Julia only kind of solves this problem. So if Julia is trying to make a more performance scripting language then that is admirable. But for most of the projects where I have needed to prototype in a script and implement in a systems language, Julia would not have worked. Even today I don't have a good reason to use it over MATLAB for day to day work, since I already have the license and their ecosystem is more mature.
deleted 5y ago
[deleted]
iamcreasy 5y ago
Agree with this sentiment. Its especially evident when you look at their package manage. Here is a nice talk from the guy who wrote it 3 times: https://www.youtube.com/watch?v=HgFmiT5p0zU https://www.youtube.com/watch?v=HgFmiT5p0zU
- adgjlsfhk1 5y ago
  It might be worth noting that the current one (the third that he wrote) is probably one of the best package managers of any language. It supports environments, multiple package servers, installing packages from url, easy local development, is completely immutable, and reasonably fast.
noobermin 5y ago
Kinda betrays your bias by uplifting "experienced systems programmers" and shitting on the "narrow perspective of academic programming". God, calling it a "betrayal" softens how explicit your disposition is actually. On the other hand, Rust will probably in its current form not be used for anything seriously academic (well, may be cs academic which is different) because honestly the memory paradigm is difficult to understand for people in the field. May be one day, assuming the rust mentality becomes more mainstream but computational science has always been its own thing that doesn't really follow cs trends (both good and bad in its own respects) and it certainly isn't moving in the direction of more intelligent memory management.
- neolog 5y ago
  I agree with GP. It's not just about the differing goals of the projects. Julia is developed by numerical computing people. Imho the community really needs help from some PL and systems people.
  - noobermin 5y ago
    Why? EDIT: Expounding on "why": On what aspects specifically does the Julia community need help from system programmers and programming language experts?
    - deleted 5y ago
      [deleted]
    - deleted 5y ago
      [deleted]
  - BadInformatics 5y ago
    The biggest group outside of numerical computing in Julia land are the PL and systems people though? This includes type theorists [1], database folks [2], distributed systems people ([3] to name just one). There are also a fair number of compiler nuts, hence the existence of multiple projects [4][5] in this space. And this is before getting into things that bridge more than one of the domains above, e.g. [7] or [8]. FTR, I think it's fair to question whether numerical computing should have an outsized influence on the direction of the language. I also think it's a pretty fair comparison to point out how standardized and consistent the Rust governance process is compared to Julia's (the Rust RFC system is an exemplar here). That doesn't mean there is a dearth of PL and systems knowledge in the Julia community though. [1] https://github.com/AlgebraicJulia/Catlab.jl https://github.com/AlgebraicJulia/Catlab.jl [2] https://www.youtube.com/watch?v=tRBl-6uEJJE https://www.youtube.com/watch?v=tRBl-6uEJJE [3] https://github.com/JuliaParallel/Dagger.jl/ https://github.com/JuliaParallel/Dagger.jl/ [4] https://github.com/FluxML/IRTools.jl https://github.com/FluxML/IRTools.jl, https://github.com/FluxML/MacroTools.jl https://github.com/FluxML/MacroTools.jl [5] https://github.com/JuliaCompilerPlugins https://github.com/JuliaCompilerPlugins [6] https://github.com/0x0f0f0f/Metatheory.jl https://github.com/0x0f0f0f/Metatheory.jl [7] https://2020.splashcon.org/details/splash-2020-rebase/13/Non-local-compiler-transformations-in-the-presence-of-dynamic-dispatch https://2020.splashcon.org/details/splash-2020-rebase/13/Non... [8] https://github.com/JuliaSymbolics/Symbolics.jl https://github.com/JuliaSymbolics/Symbolics.jl

xianwen 5y ago

I'm very interested in Rust. However, it seems that Rust is not yet able to do symbolic math.

hexane360 5y ago
I'm sure there are some crates out there, but probably nothing very stable. If there's one thing Rust is not, it's a good "glue" language. It seems to do best in large, densely coupled projects. This is where there's the least cost to defining all your own types, and also where a strong type system provides the most benefit. I think there will always be a place for more dynamic languages that tend to do better at interfaces.
miguelraz 5y ago
Author here: I specifically mentioned the `egg` crate because of it's capabilities for symbolic math. You can check a minimal application of arithmetic differentiation and some simplification rules in their repo here: https://github.com/egraphs-good/egg/blob/main/tests/math.rs https://github.com/egraphs-good/egg/blob/main/tests/math.rs
- xianwen 5y ago
  Thanks. I'll give it a try!

ForHackernews 5y ago

I like both languages, but they seem to have extremely different goals and target users to me. Julia aims to be better than R and Python at statistics and data analysis. It's not there yet, but I could easily see it replacing a great deal of academic use of Numpy and Python in Jupyter notebooks (the 'ju' is Julia). On the other hand, Rust seems like it's aiming at being a safer alternative to C for low-level systems programming. I'm sure there's things Julia could learn from Rust, but the design decisions are going to differ wildly because they just aren't trying to do similar things.

awaythrowact 5y ago
Fair. But to play devils advocate: one stated goal of Julia is to solve the “two languages” problem where developers prototype in {scripting language} and then reimplement in {system language}. So while Julia is meant to be as easy as Python, it also needs to be as powerful and flexible as Rust (or C or whatever). It’s supposed to be the “best of both worlds” and Rust lives in one of those worlds. If developers are better off prototyping in Python jupyter notebooks and then reimplementing in Rust than they are implementing in Julia, then I’d say the comparison is relevant. Maybe it’s an unfair standard and Julia can be a “better Python” without needing to be a full replacement of a systems language, but then Julia isn’t fully solving the two language problem, right?
- duped 5y ago
  The two language problem exists for a bunch of reasons, some good and some not. The biggest reason is because some function of the high level language is incompatible with the application domain. Like garbage collection in hot or real-time code or proprietary compilers for processors. Julia does not solve these problems. Other reasons are practical, like portable executables in Go or Rust (portable in the sense they do not require dependencies on their target systems, usually). Julia does not solve this problem. Then there are the reasons to use scripting languages over the system languages, like expressive syntax with low cognitive overhead. Julia definitely helps here. But this comes at the cost of execution and startup time. Julia only kind of solves this problem. So if Julia is trying to make a more performance scripting language then that is admirable. But for most of the projects where I have needed to prototype in a script and implement in a systems language, Julia would not have worked. Even today I don't have a good reason to use it over MATLAB for day to day work, since I already have the license and their ecosystem is more mature.

deleted 5y ago

[deleted]

iamcreasy 5y ago

Agree with this sentiment. Its especially evident when you look at their package manage. Here is a nice talk from the guy who wrote it 3 times: https://www.youtube.com/watch?v=HgFmiT5p0zU https://www.youtube.com/watch?v=HgFmiT5p0zU

adgjlsfhk1 5y ago
It might be worth noting that the current one (the third that he wrote) is probably one of the best package managers of any language. It supports environments, multiple package servers, installing packages from url, easy local development, is completely immutable, and reasonably fast.

noobermin 5y ago

Kinda betrays your bias by uplifting "experienced systems programmers" and shitting on the "narrow perspective of academic programming". God, calling it a "betrayal" softens how explicit your disposition is actually. On the other hand, Rust will probably in its current form not be used for anything seriously academic (well, may be cs academic which is different) because honestly the memory paradigm is difficult to understand for people in the field. May be one day, assuming the rust mentality becomes more mainstream but computational science has always been its own thing that doesn't really follow cs trends (both good and bad in its own respects) and it certainly isn't moving in the direction of more intelligent memory management.

neolog 5y ago
I agree with GP. It's not just about the differing goals of the projects. Julia is developed by numerical computing people. Imho the community really needs help from some PL and systems people.
- noobermin 5y ago
  Why? EDIT: Expounding on "why": On what aspects specifically does the Julia community need help from system programmers and programming language experts?
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
- BadInformatics 5y ago
  The biggest group outside of numerical computing in Julia land are the PL and systems people though? This includes type theorists [1], database folks [2], distributed systems people ([3] to name just one). There are also a fair number of compiler nuts, hence the existence of multiple projects [4][5] in this space. And this is before getting into things that bridge more than one of the domains above, e.g. [7] or [8]. FTR, I think it's fair to question whether numerical computing should have an outsized influence on the direction of the language. I also think it's a pretty fair comparison to point out how standardized and consistent the Rust governance process is compared to Julia's (the Rust RFC system is an exemplar here). That doesn't mean there is a dearth of PL and systems knowledge in the Julia community though. [1] https://github.com/AlgebraicJulia/Catlab.jl https://github.com/AlgebraicJulia/Catlab.jl [2] https://www.youtube.com/watch?v=tRBl-6uEJJE https://www.youtube.com/watch?v=tRBl-6uEJJE [3] https://github.com/JuliaParallel/Dagger.jl/ https://github.com/JuliaParallel/Dagger.jl/ [4] https://github.com/FluxML/IRTools.jl https://github.com/FluxML/IRTools.jl, https://github.com/FluxML/MacroTools.jl https://github.com/FluxML/MacroTools.jl [5] https://github.com/JuliaCompilerPlugins https://github.com/JuliaCompilerPlugins [6] https://github.com/0x0f0f0f/Metatheory.jl https://github.com/0x0f0f0f/Metatheory.jl [7] https://2020.splashcon.org/details/splash-2020-rebase/13/Non-local-compiler-transformations-in-the-presence-of-dynamic-dispatch https://2020.splashcon.org/details/splash-2020-rebase/13/Non... [8] https://github.com/JuliaSymbolics/Symbolics.jl https://github.com/JuliaSymbolics/Symbolics.jl