Borrowchecker.jl – Designing a borrow checker for Julia | Hacker News Reader

Borrowchecker.jl – Designing a borrow checker for Julia

github.com

77 pointsdarboux14 comments

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.

> While Rust doesn’t fill the same niche as Julia with respect to scientific computing, I really like the safety guarantees around ownership and borrow checker.

From the same discourse thread.

Interoperability across languages with FFI is an option, but it comes at a cost. Even if the two languages have polymorphism, e.g. with parametric types, the interfaces are almost always monomorphic.

I agree Rust's scientific computing is still in it's early phases. Which is super exciting but can leave a bit of wanting for more. Also agree on the bothers of FFI across programming paradigms. I've felt them.

I do still wonder if there is some boundary where it would be reasonable to split the responsibilities of the code up. In this case to avoid FFI which strips language features away, the author decided to try to add language features.

I did a quick crates.io search and it looks like there are already some symbolic regression projects available. Maybe it would even make sense to say "the cost of maintenance is worth a mostly major re-write in a language with lower long-term costs". The author was willing to write another package to try to scaffold language features to make debugging issues with the project/language easier. That's a lot of work with 2x the maintenance costs and adds what looks to me like sincere cognitive over-head.

Every design decision has a trade off. I don't know much about the project that required this one, but when I see things like this they make me scratch my head a bit and wonder if it's a stretch in the responsibilities in the tool being used. Sometimes that is good and forwards a broader picture in a community. Sometimes its a sign that the wrong tool is being used for the job or something like that.

Either way I'm sure it was a lot of fun to do this, it just raises questions for me in general.

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.

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?

Reply on news.ycombinator.com