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

121–130 of 459 posts

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

#121

Post by estebank »

creata wrote: post #92
IshKebab wrote: post #84

Earlier quoted context omitted.

We do admit it needs work. The issues the author highlights can be annoying, a smarter borrow checker could maybe solve them. The point is the borrow checker has already gone beyond the point where the benefits outweigh those annoyances. It's like... Static typing. Obviously there are cases where you're like "I know the types are correct! Get out of my way compiler!" but static types are still vastly superior because…

> The issues the author highlights can be annoying, a smarter borrow checker could maybe solve them I don't think a smarter borrow checker could solve most of the issues the author raises. The author wants borrow checking to be an interprocedural analysis, but it isn't one by design. Everything the borrow checker knows about a function is in its signature.

Making partial borrows to be expressable in method definitions would allow the design pattern to be expressed without breaking the current lifetime evaluation boundary.

Allowing the borrow checker to peek inside of the body of local methods for the purposes of identifying partial borrows would fundamentally break the locality of the borrow checker, but I think that as long as that analysis is only extended to methods on the local trait impl, it could be done without too much fanfare. These two things would be relaxations of the borrow checker rules, making it smarter, if you will.

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

#122

Post by MaulingMonkey »

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.

As a Rust fan, I 100% agree. I already know plenty of nice, "safe", "efficient" languages. I know only one language with a borrow checker, and that feature has honestly driven me to use it in excess.

Most of my smaller projects don't benefit so much from the statically proven compile time guarantees that e.g. Rust with it's borrow checker provide. They're simple enough to more-or-less exhaustively test. They also tend to have simple enough data models and/or lax enough latency requirements that garbage collectors aren't a drawback. C#? Kotlin? Java? Javascript? ??? Doesn't matter. I'm writing them in Rust now, and I'm comfortable enough with the borrow checker that I don't feel it slows me down, but I wouldn't have learned Rust in the first place without a borrow checker to draw me in, and I respect when people choose to pass on the whole circus for similar projects.

The larger projects... for me they tend to be C++, and haven't been rewritten in Rust, so I'm tormented with a stream of bugs, a large portion of which would've been prevented - or at least made shallow - by Rust's borrow checker. Every single one of them taunts me with how theoretically preventable they are.

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

#123

Post by gdbsjjdn »

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 have to (1) announce a cool new feature that isn't in other languages (2) eventually accept the feature is actually pretty niche and your average developer won't get it (3) sand off the weird features to make another "C but slightly better/different"

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

#124

Post by zoky »

dismalaf wrote: post #112
littlestymaar wrote: post #98

Earlier quoted context omitted.

Non-hobby languages is a narrow club, yes. Your list is at least missing PHP, Typescript, Swift, Go, Lua, Ruby and Rust though. But Ocaml really doesn't belong anywhere close to this list.

Ummm Lua? It's a nice little scripting language, but literally never seen a job ad for a job using mostly Lua. It's almost the definition of hobby language... OCaml runs software that billions use, is used by financial and defense firms, plus Facebook. But Lua? By that metric I'm throwing in every language I've ever seen a job for... R, Haskell, Odin, Lisp, etc... Edit - this site is basically a meme at this point. R…

Roblox apps are built in Lua.

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

#125

Post by [deleted] »

estebank wrote: post #121
creata wrote: post #92

Earlier quoted context omitted.

> The issues the author highlights can be annoying, a smarter borrow checker could maybe solve them I don't think a smarter borrow checker could solve most of the issues the author raises. The author wants borrow checking to be an interprocedural analysis, but it isn't one by design. Everything the borrow checker knows about a function is in its signature.

Making partial borrows to be expressable in method definitions would allow the design pattern to be expressed without breaking the current lifetime evaluation boundary. Allowing the borrow checker to peek inside of the body of local methods for the purposes of identifying partial borrows would fundamentally break the locality of the borrow checker, but I think that as long as that analysis is only extended to methods…

[deleted]

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

#127

Post by epcoa »

dismalaf wrote: post #112
littlestymaar wrote: post #98

Earlier quoted context omitted.

Non-hobby languages is a narrow club, yes. Your list is at least missing PHP, Typescript, Swift, Go, Lua, Ruby and Rust though. But Ocaml really doesn't belong anywhere close to this list.

Ummm Lua? It's a nice little scripting language, but literally never seen a job ad for a job using mostly Lua. It's almost the definition of hobby language... OCaml runs software that billions use, is used by financial and defense firms, plus Facebook. But Lua? By that metric I'm throwing in every language I've ever seen a job for... R, Haskell, Odin, Lisp, etc... Edit - this site is basically a meme at this point. R…

Lua has petered out a bit but it has been used as a scripting and config language for a ton of games and commercial embedded. Not a hobby language, not typically a main implementation language but that doesn’t mean no commercial use. posix/bash shell isn’t a hobby language either, but unless you’re Tom Lord or something (RIP) you’re not doing the entire project in it.

Do realize that luajit for years was bankrolled by corporations.

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

#129

Post by don-bright »

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 next() works.

Also, I disagree there is 'zero safety', since the indexes are into a Rust vector, they are bounds checked by default when "dereferencing" the index into the vector (v[i]), and the checking is not that slow for vast majority of use cases. If you go out of bounds, Rust will panic and tell you exactly where it panicked. If panicking is a problem you could theoretically have custom deference code that does something more graceful than panic.

But with using indexes there is no corruption of memory outside of the vector where you are keeping your data, in other words there isn't a buffer overflow attack that allows for machine instructions to be overwritten with data, which is where a huge amount of vulnerabilities and hacks have come from over the past few decades. That's what is meant by 'safety' in general.

I know people stick in 'unsafe' to gain a few percent speed sometimes, but then it's unsafe rust by definition. I agree that unsafe rust is unsafe.

Also you can do silly optimization tricks like if you need to perform a single operation on the entire collection of nodes, you can parallelize it easily by iterating thru the vector without having to iterate through the data structure using next/prev leaf/branch whatever.

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

#130

Post by coldtea »

mr_00ff00 wrote: post #26
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…

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.

I wouldn't read too much into its lacking the borrow checker.

It's not about not having a C-like syntax (huge mainstream points lost), good momentum, and not having the early marketing clout that came from Rust being Mozilla's "hot new language".

Post reply on HN