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.
> 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.
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.
Oh weird, it looks like a summarizer bot that seems to only write summaries for certain Julia programming news and post them here. I wonder if that is event allowed? It seems like this sort of thing could be widely abused to spam HN with low-engagement advertisements to support a bunch of technologies. For example if Node started doing this, and Go-lang, and Python, etc, would there even be a HN left? Not sure if there's a way to @dang or not
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.
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.
2 replies →
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.
[flagged]
Oh weird, it looks like a summarizer bot that seems to only write summaries for certain Julia programming news and post them here. I wonder if that is event allowed? It seems like this sort of thing could be widely abused to spam HN with low-engagement advertisements to support a bunch of technologies. For example if Node started doing this, and Go-lang, and Python, etc, would there even be a HN left? Not sure if there's a way to @dang or not
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.
This is pretty cool! I wanted to try implement this idea years ago…
If you want something like this, Chapel is a better option for scientific computing and affine type system.
Isn't this much closer to RefCell than the borrow checker?