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

201–210 of 459 posts

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

#201

Post by ninetyninenine »

jltsiren wrote: post #25

This reminds me of something that was popular in some bioinformatics circles years ago. People claimed that Java was faster than C++. To "prove" that, they wrote reasonably efficient Java code for some task, and then rewrote it in C++. Using std::shared_ptr extensively to get something resembling garbage collection. No wonder the real Java code was faster than the Java code written in C++. I've been writing C++ for a…

There is such a thing of languages that align with human intuition. C++ and Rust are not these languages so you have to really learn these languages in depth. Languages like typescript or python or go align more with intuition and you don't really need to learn as much about the details or patterns as these just naturally flow from your intuition. This is a huge huge thing as it makes the language literally take about a week to develop proficiency and two weeks to develop mastery. A language like C++... you can't even develop mastery in a year.

That is not to say these languages are better. Intuition is just one trade off.

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

#202

Post by ameliaquining »

School-Cotton wrote: post #23
littlestymaar wrote: post #20

I really struggle to understand the PoV of the author in his The rules themselves are unergonomical section: > But what's the point of the rules in this case, though? Here, the ownership rules does not prevent use after free, or double free, or data races, or any other bug. It's perfectly clear to a human that this code is fine and doesn't have any actual ownership issues I mean, of course there is an obvious ownersh…

The whole point is that `Id` doesn't have a destructor (it's purely stack-allocated); that is, conceptually it _could_ be `Copy`. A more precise way to phrase what he's getting at would be something like "all types that _can_ implement `Copy` should do so automatically unless you opt out", which is not a crazy thing to want, but also not very important (the ergonomic effect of this papercut is pretty close to zero).

I think the primary reason Rust doesn't do this is because it's a semver hazard. I.e., adding a non-Copy field would silently break downstream dependents. Yeah, this is already a problem with the existing auto traits, but types that don't implement those are rarer than types that don't implement Copy.

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

#203

Post by jemmyw »

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…

I find Rust quite ergonomic in most cases. Yes there is more code, but in terms of thinking about it, it's usually "I have this and I want that", and the middle almost fills itself out.

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

#204

Post by comonoid »

mavelikara wrote: post #103
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.

The first version of Rust compiler, I think, was written in OCaml.

It was a bootstrap implementation.

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

#205

Post by mcdoogal »

pif wrote: post #155
gdbsjjdn wrote: post #123

Earlier quoted context omitted.

Agreed. As a comparison Golang was sold as "CSP like Erlang without the weird syntax" but people realized channels kind of suck and goroutines are not really a lot better than threads in other languages. The actual core of OTP was the supervisor tree but that's too complicated so Golang is basically just more concise Java. I don't think this is a bad thing but it's a funny consequence that to become mainstream you ha…

[flagged]

Yikes, language flamebait in 2025?

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

#206

Post by LunicLynx »

Rust is pain when you want to be super basic with your types.

This is actually a learning lesson for the user to understand that the bugs one has seen in languages like c++ are inherent to using simple types.

The author goes about mentioning python. If you do change all your types to python equivalents, ref counted etc. Rust becomes as easy. But you don’t want to do that and so it becomes pain, but pain with a gain. You must decide if that gain is worth it.

From my point of view the issue is that rust defaults to be a system programming language. Meaning, simple types are written simple (i32, b32, mut ..), complex types are written complex (ref, arc, etc.). And because of that one wants to use the simple types, which makes the solutions complex.

Let’s imagine a rust dialect, where every type without annotation is ref counted and if you want the simple type you would have to annotate your types, the situation would change.

What one must realize is that verifiable correctness is hard , the simplicity of the given problematic examples is a clear indication of how close those screw ups are even with very simple code. And exactly why we are still seeing issues in core c libs after decades of fixing them.

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

#207

Post by ChadNauseam »

ramon156 wrote: post #175
ChadNauseam wrote: post #105

> [The pain of the borrow checker is felt] when your existing project requires a small modification to ownership structure, and the borrowchecker then refuses to compile your code. Then, once you pull at the tiny loose fiber in your code's fabric, you find you have to unspool half your code before the borrowchecker is satisfied. Probably I just haven't been writing very "advanced" rust programs in the sense of doing…

I guess I'm a bit confused how you can write rust professionally dor 3 years and never encounter this. When I started writing rust in ~2020/2021 i already had issues with the brorow checker. Maybe its an idiom you already picked up in OCaml and did it mostly right in rust too?

I think I don't end up doing very complicated things most of the time. If you're writing a zero-copy deserialization crate or an ECS framework or something, I'm sure you're bound to run into this issue. But I almost never even have to explicitly write lifetimes. I rarely even see borrowck errors for code I intended to write (usually when I see borrowck errors, it's because I made an error in copy-pasting that resulted in me using a variable after it's been moved, or something like that).

You might have a point with my OCaml background though. I rarely use mutable references, since I prefer to write code in a functional style. That means I rarely am in a situation where I want to create a mutable reference but already have other references floating around.

Here's an example of some of my code: https://github.com/not-pizza/tysm/blob/main/src/chat_complet... . I wouldn't be surprised if there's not a mutable reference or lifetime specifier in this whole project

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

#208

Post by ajross »

creata wrote: post #200
ajross wrote: post #191

Earlier quoted context omitted.

> adding a generational counter (maybe only in debug builds) to allocations can catch use-after-frees. At the cost of making the use of the resulting heap significantly slower and larger than if you just wrote the thing in Java to begin with, though! The resulting instrumentation is likely to be isomorphic to GC's latency excursions, even. This is the biggest issue that bugs me about Rust. It starts from a marketing…

> At the cost of making the use of the resulting heap significantly slower and larger than if you just wrote the thing in Java to begin with, though! Lower throughput, probably. But it introduces constant latency. It has some advantages over doing it in Java: * You're never going to get latency spikes by adding a counter to each allocation slot. * If you really want to, you can disable them in release builds and stil…

> * You're never going to get latency spikes by adding a counter to each allocation slot.

The suggestion wasn't just the counter though. A counter by itself does nothing. At some point you need to iterate[1] through your set to identify[2] the unreferenced[3] blocks. And that has to be done with some kind of locking vs. the unrestricted contexts elsewhere trying to do their own allocation work. And that has costs.

Bottom line is that the response was isomorphic to "That's OK, you can work around it by writing a garbage collector". And... yeah. We have that, and it's better than this nonsense.

[1] "sweep", in the vernacular

[2] "collect", in some idioms

[3] Yup, "garbage"

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

#209

Post by creata »

ajross wrote: post #208
creata wrote: post #200

Earlier quoted context omitted.

> At the cost of making the use of the resulting heap significantly slower and larger than if you just wrote the thing in Java to begin with, though! Lower throughput, probably. But it introduces constant latency. It has some advantages over doing it in Java: * You're never going to get latency spikes by adding a counter to each allocation slot. * If you really want to, you can disable them in release builds and stil…

> * You're never going to get latency spikes by adding a counter to each allocation slot. The suggestion wasn't just the counter though. A counter by itself does nothing. At some point you need to iterate[1] through your set to identify[2] the unreferenced[3] blocks. And that has to be done with some kind of locking vs. the unrestricted contexts elsewhere trying to do their own allocation work. And that has costs. Bo…

No, sorry, in case I wasn't clear, I was talking about manual deallocation. I wasn't talking about a garbage collector. You still allocate and free cells. Here's an example of what I am talking about:

https://docs.rs/generational-arena

If you're implementing a tracing garbage collector you obviously don't need any such counters to detect use-after-frees.

This is clearly a different compromise entirely to the one made by tracing garbage collection. I'm actually not sure how you confused the two.

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

#210

Post by packetlost »

dgfitz wrote: post #181
creata wrote: post #57

Earlier quoted context omitted.

I think there are two other big differences that also helped Rust become popular: * Rust has a C++-flavored syntax, but OCaml has a relatively alien ML-flavored syntax. * Rust has the backing of Mozilla, but I don't think OCaml had comparable industry backing. (Jane Street, maybe?)

> rust has a C++-flavored syntax I do not at all agree with this. Rust is by far the most complex language in terms of syntax that has ever become popular enough to compare it to anything.

I 100% disagree with this. Typescript is syntactically far more complex.
Post reply on HN