[HN Gopher] From Julia to Rust
___________________________________________________________________
From Julia to Rust
Author : miguelraz
Score : 62 points
Date : 2021-06-05 18:05 UTC (4 hours ago)
(HTM) web link (miguelraz.github.io)
(TXT) w3m dump (miguelraz.github.io)
| beforeolives wrote:
| The most fascinating thing about this is that the author's first
| two programming languages are Julia and Rust.
| miguelraz wrote:
| It is infrequent! Author here: I knew enough C and Fortran to
| turn in small assignments for my physics courses, but Julia was
| the first one where I started developing code.
| zamalek wrote:
| > Julia was the first one where I started developing code.
|
| This is fantastic! I think that Julia really has unseen
| potential for the scientific community, and even more unseen
| potential beyond that (most of Julia conf is scientific).
|
| FP also comprises of some really great habits to pick up
| early on, I'm still trying to unlearn dumb OOP idioms (which
| is why I'm targeting Julia as my next language).
| Diggsey wrote:
| > Rust people keep saying they have no Garbage Collector, when
| they have a Region Based Garbage Collector.
|
| Rust does not have a region based garbage collector. Memory
| management in Rust works exactly the same as in does in C++ (ie.
| destructors are automatically called when variables go out of
| scope, and those destructors may deallocate memory).
|
| The borrow checker is purely a check: not only does it operate
| entirely at compile-time, it does not even influence code
| generation. The only thing the borrow checker can do is prevent
| code from compiling.
| zamalek wrote:
| Correctly/academically speaking, a GC emulates infinite
| memory[1]. It's a misnomer (because the fact/name predated the
| theory). In the event that you actually have infinite memory,
| NOOP could be classified as a GC.
|
| Academically speaking, Rust is a managed language. The GC has
| simply been lifted to compile-time (or runtime in the case of
| Rc). You never call `alloc` and you never call `free`.
|
| [1]:
| https://devblogs.microsoft.com/oldnewthing/20100809-00/?p=13...
| hexane360 wrote:
| 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.
| [deleted]
| xianwen wrote:
| I'm very interested in Rust. However, it seems that Rust is not
| yet able to do symbolic math.
| miguelraz wrote:
| 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
| hexane360 wrote:
| 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.
| ForHackernews wrote:
| 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 wrote:
| 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 wrote:
| 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.
| miguelraz wrote:
| Yes, to explore those differences was the point of the post.
___________________________________________________________________
(page generated 2021-06-05 23:00 UTC)