Comment by nostradumbasp
13 hours ago
Its a cute idea but, why does a GC language need this? For shared mutable references across threads I get it for some data race conditions? Can it handle that with awareness of smart pointers, etc?
Honestly, I'd write Rust. Or write Julia. Whatever one you want.
Kudos on the project though, looks like it was fun to make. Who knows maybe it will evolve into something else that makes more sense to me?
Forced avoidance of shared mutable state helps prevent all sorts of logical bugs. Memory safety just happens to be the one that leads to trivial UB in C/C++. (I say this as a full time Julia dev who is unlikely to use Rust or use this package, but respect Rust's choices a lot).
I am someone who has written a lot of Rust, enough C++ to know better, and is loosely familiar with Julia. I think its awesome people are becoming aware of the benefits of writing Rust. In the same breath, this is missing probably the biggest advantage. These checks should be compile time guarantees. Maybe the language will move that way? This is my opinion and it is a philosophical one but opting in and out of safety checks means you don't care how sturdy your software is until you personally have observed an error. In a lot of cases that's "too late" for production.
For debugging after an issue is found this is maybe helpful though.
> For shared mutable references across threads I get it for some data race conditions
Exactly this: https://discourse.julialang.org/t/package-for-rust-like-borr...
> I guess I’ll just add my motivation – I’ve had to debug multiple race conditions in [SymbolicRegression.jl](https://juliaregistries.github.io/General/packages/redirect_...) which nowadays is quite a complex library with deep call stacks, a lot of memory optimizations, asynchronous stuff, buffers, etc. Every race condition is an absolute pain to debug
As a Julia user myself sometime I missed a borrow checker, and destructive move
I see. I don't know almost anything about symbolicregression.jl but it sounds like a good use case for Rust if it's intended to be used for important/mission critical applications. Sounds like there is a lot of opportunity for use-after-free, race conditions, and the like. Also looks like the code base is becoming increasingly complex probably to the point where maintenance is becoming hazardous for an open source project.
I'd heavily consider abstracting out whatever logic was possible into Rust and FFI'ing into Julia. Seems like some Python, and otherwise projects have started going in this direction and I haven't heard any complaints. Usually performance benefits and cleaner code.
I don't do much of science compute, but I would imagine correctness and stability really matters for end users. Unless its kind of a nichey write a paper and run sort of thing. Then whatever.