Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The borrowchecker is what I like the least about Rust

viralinstruction.com

Post reply on HN
Print view View original

251–260 of 459 posts

Re: The borrowchecker is what I like the least about Rust

#251

Post by zozbot234 »

tptacek wrote: post #231
nine_k wrote: post #179

Earlier quoted context omitted.

Due to lack of many abstractions, and lack of exceptions, Go is a less concise Java. It's a language where the lack of expressiveness forces you to write simpler code. (Not that it helps too much.) Go's selling points are different: it takes a weekend to learn, and a week to become productive, it has a well-stocked standard library, it compiles quickly, runs quickly enough, and produces a single self-contained execut…

People sometimes say this like it's a dunk, but there's a finite amount of complexity any given programming task can shoulder, you have to allocate it somehow between the programming environment, the problem domain you're working on, and the algorithmic sophistication you bring to bear on that problem, and it's not clear to me what the benefit is in allocating more than you need to your programming language. A lot of…

Unfortunately, Golang has a whole lot of weird, pointless quirks in both its base language and standard library, compared to something with a more elegant and from-the-ground-up design, like Rust itself or perhaps OCaml/ReasonML. Not very good news if you want the language to just "get the hell out of your way". I suppose it's still way better than the "enterprise" favored alternative of Java/C# though!

Re: The borrowchecker is what I like the least about Rust

#252

Post by blub »

nemothekid wrote: post #158
timmytokyo wrote: post #97

Earlier quoted context omitted.

If using indices is going to be your answer, then it seems to me you should at least contend with the OP's argument that this approach violates the very reason the borrowchecker was introduced in the first place. From the post: "The Rust community's whole thing is commitment to compiler-enforced correctness, and they built the borrowchecker on the premise that humans can't be trusted to handle references manually. Wh…

> OP's argument that this approach violates the very reason the borrowchecker was introduced in the first place. No it doesn't. I just don't think author understands the pitfalls of implementing something like a graph structure in a memory unsafe language. The author doesn't write C so I don't believe he has struggled with the pain of chasing a dangling pointer with valgrind. There are plenty of libraries in C that e…

C doesn’t have objects, which are great for encapsulating data structures, but in C++ it’s not at all hard to write a graph data structure.

One wraps it behind a reliable interface, writes automated test and runs them under valgrind/sanitizers and that’s pretty much it.

It’s normal for life and software development to have a certain degree of risk and to spend some effort solving problems. Too many HN comments make it sound like it’s a jungle out there and a use-after-free will chop your head clean off.

Re: The borrowchecker is what I like the least about Rust

#253

Post by oneshtein »

eigenspace wrote: post #96
roland35 wrote: post #37

Earlier quoted context omitted.

I'm not sure.. without the borrow checker you could have a pretty nice language that is like a "pro" version of golang, with better typing, concise error handling syntax, and sum types. If you only use things like String and Arc objects, you basically can do this, but it'd be nice to make that not required!

That's my whole point. Without the borrow checker it would have been a nice language, but I believe it would not have gotten popular, because being nice isnt enough to be popular in the current programming language landscape.

You can use a garbage collector in Rust to circumvent borrow checker. You can use simple reference counting (Rc, Arc), or trace and sweep, arenas, or generation based garbage collectors. Even a simple .clone() can help a lot in many cases.

Borrow checker is my friend, it helps me write better code, but it doesn't stops me when I don't care about code quality and just want a task to be done.

Re: The borrowchecker is what I like the least about Rust

#254

Post by conradludgate »

I personally don't think I would want to use a language that doesnt have a borrow checker ever again. I would like a Rust-like language with GC, but I still want the borrow checker.

Every time I write Go, I find it so annoying all the defensive deep copying I see. In JS I always find myself getting confused on whether a mutation is safe (as in my program won't break some assumption) to do or not. Marking arguments as shared or exclusive is really great for me to know what kind of access I can have. It needs to be enforced so that the owner also doesn't accidentally mutate while a shared borrow is still active (again, not just for memory safety but for my own invariants). The classic example could be inserting into a collection while iterating over it

I think the borrow checker is necessary if you have ADTs like Rust and you want memory safety. You could pattern match a union into one of its variants and get a pointer to one of the fields, but without a borrow checker there's nothing to stop you from changing the variant stored in the union. This would obviously cause issues and the only way you'd solve this with GC alone is by allocating each variant individually where the union is just a tagged pointer.

Re: The borrowchecker is what I like the least about Rust

#255

Post by zozbot234 »

mcdoogal wrote: post #205
pif wrote: post #155

Earlier quoted context omitted.

[flagged]

Yikes, language flamebait in 2025?

Flamebait? It's literally what the designers of Golang said publicly about the background of prospective developers, and how that constrained the language design:

"The key point here is our programmers are Googlers, they’re not researchers. They're typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."

Re: The borrowchecker is what I like the least about Rust

#256

Post by zozbot234 »

amelius wrote: post #109
mr_00ff00 wrote: post #26

Earlier quoted context omitted.

This is also somewhat backed up by the fact that OCaml (to my understanding) is basically GC Rust without a borrow checker, and yet it’s basically a hobby language.

Idiomatic programming in a functional language requires garbage collection. There is a reason languages like OCaml and Haskell have a garbage collector. Without it, programming in these languages would be completely different. If you look at it from that perspective, then Rust is the hobby language.

> Idiomatic programming in a functional language requires garbage collection.

Rust has functional programming features and no garbage collection, because the borrow checker can tell when a closure will outlive the references in its captured environment. We used to think that would not be feasible other than perhaps in very special cases - hence the need for GC to keep that environment around - but Rust proved that wrong quite convincingly.

Re: The borrowchecker is what I like the least about Rust

#257

Post by conradludgate »

tptacek wrote: post #235
nemothekid wrote: post #158

Earlier quoted context omitted.

> OP's argument that this approach violates the very reason the borrowchecker was introduced in the first place. No it doesn't. I just don't think author understands the pitfalls of implementing something like a graph structure in a memory unsafe language. The author doesn't write C so I don't believe he has struggled with the pain of chasing a dangling pointer with valgrind. There are plenty of libraries in C that e…

Whoah, hold on, the author isn't comparing writing graph structures in Rust to writing it in memory-unsafe languages --- they're comparing it to writing it in other memory-safe languages . You can't force a false dichotomy between Rust and C to rebut them.

I think it's reasonable enough. The author already argued that there are reasons for non GC languages to exist, even if the performance doesn't matter to them.

One interpretation of the article is just the author doesn't personally like the borrow checker, but another interpretation is the author saying the borrow checker is just a bad abstraction.

So under the assumption that we don't have a GC available, what else can we compare the borrow checker against?

Re: The borrowchecker is what I like the least about Rust

#258

Post by conradludgate »

loeg wrote: post #241
burntsushi wrote: post #230

Earlier quoted context omitted.

Except for the fact that one leads to undefined behavior and the other doesn't. This is a massive difference.

Non-UB data structure corruption and other incorrect behavior isn't like, super obviously better than UB corruption and other incorrect behavior.

The obvious upside is that it's so much easier to debug when there's no UB. Debugging UB is never enjoyable.

Re: The borrowchecker is what I like the least about Rust

#260

Post by conradludgate »

palata wrote: post #144

I choose a language that is as ergonomic as possible, but as performant as necessary. If e.g. Kotlin is fine, there is no way I will choose Rust. Many projects are written in Rust that would absolutely be fine in Go, Swift or a JVM language. And I don't understand: it is nicer to write in those other languages, why choose Rust? On the other hand, Rust is a lot nicer than C/C++, so I see it as a valid alternative ther…

For a sufficiently large program, i am faster at writing a correct rust implementation than I am with Go. I find myself a lot more able to reason about the program thanks to the work the compiler makes me do upfront.
Post reply on HN