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 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
This package demonstrates Rust-like ownership and borrowing semantics in Julia through a macro-based system that performs runtime checks. This tool is mainly to be used in development and testing to flag memory safety issues, and help you design safer code.
That's pretty neat as an experiment, but I would guess that doing this in Julia would lead to a language that has the worst properties of Rust and Julia.
Like, one of the advantages of Julia over Rust is that GC languages are way easier to write code in. With a borrowchecker, you get a fat runtime and the cost of garbage collection with none of the convenience
>With a borrowchecker, you get a fat runtime and the cost of garbage collection with none of the convenience
I find the borrowchecker with its checking of mutable references can really assist you well in writing correct code more easily. Especially when it comes to parallelism. But also in not accidentally mutating something that some other function still holds a reference to.
So I wouldn't say the borrow checkers utility is limited to checking allocation scopes.
This also seems to be the motivation according to the readme.
[+] [-] nostradumbasp|1 year ago|reply
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?
[+] [-] adgjlsfhk1|1 year ago|reply
[+] [-] minetest2048|1 year ago|reply
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
[+] [-] darboux|1 year ago|reply
[+] [-] BiteCode_dev|1 year ago|reply
[deleted]
[+] [-] jakobnissen|1 year ago|reply
Like, one of the advantages of Julia over Rust is that GC languages are way easier to write code in. With a borrowchecker, you get a fat runtime and the cost of garbage collection with none of the convenience
[+] [-] carlmr|1 year ago|reply
I find the borrowchecker with its checking of mutable references can really assist you well in writing correct code more easily. Especially when it comes to parallelism. But also in not accidentally mutating something that some other function still holds a reference to.
So I wouldn't say the borrow checkers utility is limited to checking allocation scopes.
This also seems to be the motivation according to the readme.
[+] [-] andyferris|1 year ago|reply
[+] [-] pjmlp|1 year ago|reply
[+] [-] arksingrad|1 year ago|reply