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

311–320 of 459 posts

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

#311

Post by rnikander »

ameliaquining wrote: post #184
teaearlgraycold wrote: post #163

Earlier quoted context omitted.

I wish Rust had syntax or a directive to make Rcs a bit less obtrusive.

This is being worked on: https://rust-lang.github.io/rust-project-goals/2025h1/ergono...

Interesting. My projects would benefit from those more convenient clones into closure captures. The other point where Rc is uglier than, say, Swift, is the explicit `.borrow()` and `.borrow_mut()` everywhere. I wonder if that could also be made more convenient/high-level without sacrificing the control over high performance (like C++) that got me to use Rust in the first place.

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

#312

Post by rollcat »

gdbsjjdn wrote: post #123
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…

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…

> The actual core of OTP was the supervisor tree but that's too complicated so Golang is basically just more concise Java.

Which is ironic, maybe kinda funny. The first "larger" project I've tackled in Go was a chat server. I wanted a simple supervisor for each connected client; in case a goroutine encountered a recoverable error but needed to be restarted. I don't have any practical experience with OTP, but I've always been a big fan of daemontools/runit/etc: just let it crash, restart, and recover.

So in Go, you can't (easily) obtain a handle to a goroutine. The authors' entire argument seemed to be that this would allow developers to implement "bad" patterns, like thread-local storage. You can of course still come up with some wrapper code, like this:

    type Service struct {
        err
But what you really wanted was something like:

    run := func() error { ... }
    g := go run()
    err :=
Now of course you still want some wrapper code to maintain client/connection state, etc. But if you wanted a "real" supervisor tree, you'd have to do this dance for every sub-goroutine you'd like to spawn. You'll soon end up with func(*Service, any) and throw away static typing along the way. Generics wouldn't be introduced until 18 releases after, and I don't think they would help all that much.

Correct me if I'm missing anything obvious.

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

#314

Post by zozbot234 »

amelius wrote: post #310
zozbot234 wrote: post #256

Earlier quoted context omitted.

> 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 wr…

"Having FP features" does not mean "allow an idiomatic FP programming style". If this were the case, we'd be seeing a revolution in functional programming now. It's not like the FP community is slow to adopt good ideas. In fact, many innovations that lead to the invention of the borrow checker came from the functional programming world (linear, affine types, effect systems).

What's an "idiomatic FP programming style"? Is typical LISP code "FP" enough? That uses GC of course, but other than that it's often high-level enough to be quite comparable w/ modern Rust.

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

#315

Post by zozbot234 »

jiggawatts wrote: post #305
Animats wrote: post #70

One of his examples of a borrow checker excess: struct Id(u32); fn main() { let id = Id(5); let mut v = vec![id]; println!("{}", id.0); } isn't even legit in modern C++. That's just move semantics. When you move it, it's gone at the old name. He does point out two significant problems in Rust. When you need to change a program, re-doing the ownership plumbing can be quite time-consuming. Losing a few days on that is…

> When you move it, it's gone at the old name . (Emphasis mine.) I just had a thought! It might make languages like Rust more ergonomic if movement could also update the reference to the new location so that moving a local variable into a container could also update the variable to reference the target also. The "broken" example can be trivially fixed: fn main() { let id = Id(5); let mut v = vec![id]; let id = v[0].0…

But why add a language feature (and a new symbol, even!) when by definition you can always fix the issue by shadowing the original variable and pointing it at the new location? At most, this calls for a change in compiler diagnostics to add a hint in cases that are trivially fixable.

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

#317

Post by burntsushi »

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.

Ummm. Yeah it is. I'm sure you can come up with some cases where the impact of the bugs is roughly equivalent, but generally speaking, UB is a terrible class of bug.

For example, if the aho-corasick crate accidentally tries to look up a dangling state node, you'll get a panic. But if this were UB instead, that could easily lead to a security problem or just pretty much anything... because behavior is undefined.

So generally speaking, yes, this is absolutely a major difference and it matters in practice. You even have other people in this thread saying this technique is used in C for this exact reason. Leaving out this very obvious difference and pretending like these are the same thing is extremely misleading.

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

#319

Post by spacechild1 »

aw1621107 wrote: post #281
spacechild1 wrote: post #107

Earlier quoted context omitted.

> In C++, the signature of a function template doesn't necessarily tell you what types you can successfully call it with, nor what the return type is. That's the whole point of Concepts, though.

Concepts are basically a half solution - they check that a type has some set of properties, but they don't check that the implementation only uses those properties. As a result, even with concepts you can't know what types will work in a template without looking at the implementation as well. Example [0]: #include template concept fooable = requires(T t) { { t.foo() } -> std::same_as ; }; struct only_foo { int foo();…

> they check that a type has some set of properties, but they don't check that the implementation only uses those properties.

I'd say that's a mistake of the person who wrote the template then.

Also, there are Concepts where you absolutely know which types are allowed, e.g. std::same_as, std::integral, std::floating_point, etc.

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

#320

Post by binary132 »

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]

There are a lot of those for sure. There are far more in Python and Java. Any popular, simple-enough language will attract a horde of jobseeking mouthbreathers, that’s kind of inevitable and normal really.
Post reply on HN