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.
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.
As an aside, I don't see why Rust couldn't seep into "anything seriously academic". C++ is widely used, and I've seen a gradual uptick in the usage of RAII. Rust seems like the next step, especially with the effort put into the ecosystem and learning materials. Sure, it might come slower than in domains where safe memory management is critical, but I don't think the needs of academics are fundamentally different here.
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.
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.
Is there a reason why it's not well-founded to consider scopes to be regions?
You're running into a colloquial vs formal distinction, I think. Yes, a scope is a "region" in the sort of general sense, but in PLT, "region based memory management" is jargon: https://www.cs.umd.edu/projects/cyclone/papers/cyclone-regio...
If you check 2.1 of that paper, you'll see it's something sort of like "arenas with optional GC if you want to reclaim memory", which is quite different than what Rust does by default.
"Garbage collection" implies dynamic lifetime determination.
Rust's ownership system is static lifetime determination.
For those instances where dynamic lifetime determination is necessary, Rust provides types like Rc (which can be considered a very rudimentary garbage collector).
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...
(And you can call `alloc` and `free` from Rust, https://doc.rust-lang.org/std/alloc/fn.alloc.html)
It's also weird that you call out `Rc` specifically. `Box` also allocates and free memory, as does `Vec` and other types from the `alloc` crate.
That’s not a property of the language, only of the standard library. You could design APIs that do require you to manually call alloc and free; it’s just less ergonomic to do that
Looking at generated assembly code for a Julia function is a pretty normal thing to do. I am an old C/C++ developer and find myself very much at home with Julia.
Sure I have used Python and Ruby before but those always make decisions around memory layout and code generation inaccessible.
Thinking about Julia as yet another Python, R, Ruby or a JavaScript is just wrong. It doesn’t really fit existing categories well.
Mathworks: the company that I wouldn't pay paying money to, if it wasn't such a ridiculously large sum. I don't have any issue paying for Jetbrains IDEs, but it's an order of magnitude smaller than Mathwork's yearly take.
[1]: https://www.youtube.com/watch?v=gQ1y5NUD_RI
Concretely, I joined the Julia slack and ran into a very welcoming community of people who helped me learn. Julia's like that so far.
Yes, I agree many data science people don't dive into internals - but for some reason these low-level details keep fascinating me so I don't mind some of the pain.
There is a lot of people wanting to use things like JuMP and handle numeric types where a single value is things like probability curves, and you want to use regular libraries with them, without having to rewrite those libraries.
Julia is really it's own beast, way way beyond R / Python.
It is friendly towards R dev's but, people who normally had to hack stuff in Fortran, C++, etc love it.
Also another wannabe replacement, Chapel is relatively smart, trying to mix Fortran productivity for HPC code with Rust like memory management.
That's definitely a valid approach, but it's far from the only one employed in HPC.
So love the idea, but regret the execution.
Such a 2021 moment! Kind of envious. The first programming language follows you through your career. Mine (C++) has been a curse and a blessing at the same time. Wish you luck, sincerely. People like you define the next decades.
I disagree. My first language was C64 BASIC (in which I wrote quite a lot of games). I assure you that it did not follow me through my career :-)
Thanks, cheers to you too!
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).
It's fun to compare things in general but the two languange concern very different areas of computing so much so that the "differences" will actually be the differences in the domains rather than the languages actually.
I don't see a lot of crossover there. One is expected to be very interactive for analysis and the other not interactive at all and for building infrastructure more or less.
C++ and C (somewhat of an exception here) have some good numerical libraries for things like sparse matrices, but Rust did not have mature libraries for that last time I checked, but I suppose you could do some FFI stuff.
Julia is less interactive than Python (mostly due to the just ahead of time compilation model), but can match the speed of Fortran/C/Rust etc... so in this domain it has a strong overlap with what you use the systems languages for.
Before I transitioned my group to Julia I was looking very heavily into going to Python/Rust (and Python/Numba which I spent the most time prototyping and investigating). And I can imagine that for some groups a Python/Rust hybrid would be a better fit than Julia.
For doing some data wrangling I still prefer Python for it's smooth interactivity. But, for example, Julia now has by far the most complete, flexible and all around amazing differential equations solver library in existence. This library also wraps the Fortran stalwarts like Sundials, but it's implemented entirely in Julia. There is no C/C++/etc... backend doing the heavy lifting in the background (well if you don't count LLVM at least), and the pure Julia solvers are now beating the Fortran/C++/etc... solvers pretty much across the field.
I've been meaning to get to your Z3 tutorials soon, they rock too! See ya around!
Also, I think you can totally tell that this is part of my brain-dump that's been pouring out to the #formal-methods channel on the Julia Zulip.
