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

141–150 of 459 posts

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

#141

Post by mmoskal »

timmytokyo wrote: post #97
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…

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…

I think this is like unsafe - most of your code won’t have it, so you get the benefits of borrow checker (memory safety and race freedom) elsewhere.

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

#142

Post by matja »

andai wrote: post #138

I used Rust for about an hour and immediately ran into an issue I found amusing. The compiler changed the type of my variable based on its usage. Usage in code I didn't write. There was no warning about this (even with clippy). The program crashed at runtime. I found this amusing because it doesn't happen in dynamic languages, and it doesn't happen in languages where you have to specify the types. But Rust, with its…

Did you file a bug?

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

#143

Post by zer00eyz »

roland35 wrote: post #37
eigenspace wrote: post #11

I don't use Rust much, but I agree with the thrust of the article. However, I do think that the borrowchecker is the only reason Rust actually caught on. In my opinion, it's really hard for a new language to succeed unless you can point to something and say "You literally can't do this in your language" Without something like that, I think it just would have been impossible for Rust to gain enough momentum, and also…

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!

> without the borrow checker ... golang... concise error handling syntax

Except both of these things are that way for a reason.

The author talks about the pain of having other refactor because of the borrow checker. Every one laments having to deal with errors in go. These are features, not bugs. They are forcing functions to get you to behave like an adult when you write code.

Dealing with error conditions at "google scale" means you need every one to be a good citizen to keep signal to noise down. GO solves a very google problem: don't let JR dev's leave trash on at the campsite, force them to be good boy scouts. It is Conways law in action (and it is a good thing).

Rust's forced refactors make it hard to leave things dangling. It makes it hard to have weak design. If you have something "stable", from a product, design and functionality standpoint then Rust is amazing. This is sort of antithetical to "go fast and break things" (use typescript, or python if you need this). It's antithetical to written in the stand up requirements, that change week to week where your artifacts are pantomime and post it notes.

Could the borrow checker be better, sure, and so could errors in go. But most people would still find them a reason to complain even after their improvement. The features are a product of design goals.

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

#144

Post by palata »

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 there: I'm a lot happier having to make the borrow-checker happy than tracking tricky memory errors in C.

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

#145

Post by [deleted] »

don-bright wrote: post #129

Regarding Indexes: "When the same borrowchecker makes references unworkable, their solution is to... recommend that I manually manage them, with zero safety and zero language support?!?" Language support: You can implement extension traits on an integer so you can do things like current_node.next(v) (like if you have an integer named 'current_node' which is an index into a vector v of nodes) and customize how your ne…

[deleted]

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

#146

Post by ashdksnndck »

ActorNightly wrote: post #120
IshKebab wrote: post #8

This post pretty much completely ignores the advantages of the borrow checker. I'm not talking about memory safety, which is it's original purpose. I'm talking about the fact that code that follows Rust's tree-style ownership pattern and doesn't excessively circumvent the borrow checker is more likely to be correct . I don't think that was ever the intent behind the borrow checker but it is definitely an outcome. So…

> is more likely to be correct. This is a moot statement. Here is a thought experiment that demonstrates the pointlessness of languages like Rust in terms of correctness. Lets say your goal is ultimate correctness - i.e for any possible input/inital state, the program produces a known and deterministic output. You can chose 1 of 2 languages to write your program in: First is standard C Second is an absolutely strict…

This claim makes some sense to me if your development life cycle is: write and compile once, never touch again.

Working at a company with lots of systems written by former employees running in production… the advantages of Rust become starkly obvious. If it’s C++, I walk on eggshells. I have to become a Jedi master of the codebase before I can make any meaningful change, lest I become responsible for some disaster. If it’s Rust, I can just do stuff and I’ve never broken anything. Unit tests of business logic are all the QA I need. Other than that, if it compiles it works.

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

#147

Post by marcianx »

forrestthewoods wrote: post #102
lblume wrote: post #87

Earlier quoted context omitted.

> No bumpalo doesn't count. Mind explaining why? I have made good experiences with bumpalo.

Everytime I try to use bumpalo I get frustrated, give up, and fallback to RAII allocation bullshit. My last attempt is I had a text file with a custom DSL. Pretend it’s JSON. I was parsing this into a collection of nodes. I wanted to dump the file into an arena. And then have all the nodes have &str living in and tied to the arena. I wanted zero unnecessary copies. This is trivially safe code. I’m sure it’s possible.…

To make sure I understand correctly: did you want to read a `String` and have lots of references to slices within the same string without having to deal with lifetimes? If so, would another variant of `Rc` which supports substrings that also update the same reference count have worked for you? Looking through crates.io, I see multiple libraries that seem to offer this functionality:

[1]: https://crates.io/crates/arcstr [2]: https://crates.io/crates/imstr

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

#148

Post by noodletheworld »

don-bright wrote: post #129

Regarding Indexes: "When the same borrowchecker makes references unworkable, their solution is to... recommend that I manually manage them, with zero safety and zero language support?!?" Language support: You can implement extension traits on an integer so you can do things like current_node.next(v) (like if you have an integer named 'current_node' which is an index into a vector v of nodes) and customize how your ne…

> If you go out of bounds, Rust will panic and tell you exactly where it panicked

This arguement has a long history.

It is a widely used pattern in rust.

It is true that panics are memory safe, and there is nothing unsafe about having your own ref ids.

However, I believe thats its both fair and widely acknowledged that in general this approach is prone to bugs that cause panics for exactly this reason, and thats bad.

Just use Arc or Rc.

Or, an existing crate that implements a wrapper around it.

Its enormously unlikely that most applications need the performance of avoiding them, and very likely that if you are rolling your own, youll get caught up by edge cases.

This is a prime example of a rust antipattern.

You shouldnt be implementing it in your application code.

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

#149

Post by eldenring »

> Borrowchecker frustration is like being brokenhearted - you can't easily demonstrate it, you have to suffer it yourself to understand what people are talking about. Real borrowchecker pain is not felt when your small, 20-line demonstration snippet fails to compile.

As someone who writes Rust professionally this sentence is sus. Typically, the borrow checker is somewhere between 10th and 100th in the list with regards to things I think about when programming. At the end of the day, you could in theory just wrap something in a reference counter if needed, but even that hasn't happened to me yet.

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

#150

Post by [deleted] »

Spivak wrote: post #12

> In that sense, Rust enables escapism: When writing Rust, you get to solve lots of 'problems' - not real problems, mind you, but fun problems. This is a real problem across the entire industry, and Rust is a particularly egregious example because you get to justify playing with the fun stimulating puzzle machine because safety —you don't want unsafe code, do you? Meanwhile there's very little consideration to whethe…

[deleted]
Post reply on HN