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

221–230 of 459 posts

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

#221

Post by fpoling »

ChadNauseam wrote: post #115
majormajor wrote: post #10

Earlier quoted context omitted.

This seems to be a golden rule of many languages? `return 3` in a function with a signature that says it's going to return a string is going to fail in a lot of places, especially once you exclude bolted-on-after-the-fact type hinting like what Python has. It's easier to "abuse" in some languages with casts, and of course borrow checking is not common, but it also seems like just "typed function signatures 101". Are…

My interpretation of the post is that the rule is deeper than that. This is the most important part: > Here is the most famous implication of this rule: Rust does not infer function signatures. If it did, changing the body of the function would change its signature. While this is convenient in the small, it has massive ramifications. Many languages violate this. As another commenter mentioned, C++ templates are one e…

Lifetimes for a function signature in Rust are never inferred from the function code. Rather Rust has implicit lifetime specs with straightforward rules to recover the explicit full signature.

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

#222

Post by [deleted] »

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…

[deleted]

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

#223

Post by e-dant »

The author does point out that these problems come up when implementing various data structures.

It might be surprising to some folks, but there is a lot of unsafe code in Rust, and a lot of that is in the standard’s data structure implementations.

Also —

Common in network programming, the pain of lifetimes, is in async.

The model sort of keels over and becomes obtuse when every task requires ownership of its data with static lifetimes.

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

#224

Post by ethan_smith »

duped wrote: post #183

> My examples code above may not be persuasive to experienced Rustaceans. They might argue that the snippets don't show there is any real ergonomic problem, because the solutions to make the snippets compile are completely trivial. In the last example, I could just derive Clone + Copy for Id. No, you could use destructuring. This doesn't work for all cases but it does for your examples without needing to derive copy…

Your example has an undefined 'source' variable - you likely meant 'curr' - but more importantly, this pattern can be solved with indices + interior mutability or split_at_mut() rather than unsafe, giving you safe simultaneous mutable access to different nodes.

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

#225

Post by johnnyanmac »

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…

It was interesting towards the latter half of the article where the author talks about how much of the correctness may be culturally enforced:

>More amorphous, but not less important is Rust's strong cultural affinity for correctness. For example, go to YouTube and click on some Rust conference channel. You'll see that a large fraction of the talks are on correctness, in some way or another. That's not something I see in Julia or Python conference talks.

And it creates an interesting chicken and egg approach. The borrow checker may indeed be too strict (and of course, has its edge cases and outright bugs), but its existence (rather than the utility it brings) may have in fact attracted and amassed an audience who cares about correctness above all else. Even if we abolished the borrow checker tomorrow, this audience may still maintain a certain style based on such principles, party because the other utilities of Rust were built around it.

It's very intriguing. But like anything else trying to attract people, you need something new and flashy to get people in the door. Even for people who traditionally try to reject obvious sales pitches.

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

#226

Post by Narishma »

coldtea wrote: post #136
pyrale wrote: post #94

Earlier quoted context omitted.

> and yet it’s basically a hobby language. The difference between academia languages such as ocaml or haskell and industry languages such as Java or C# is hundreds of millions of dollar in advertising. It's not limited to the academy: plenty of languages from other horizons failed, that weren't backed by companies with a vested interest in you using their language. You should probably not infer too much from a langua…

C, C++, Python, Perl, Ruby, didn't have "millions of dollars in advertising", and yet. Java and C# are the only one's that fit this. Go and Rust had some publicity from being associated with Google and Mozilla, but they both caught on without "millions of dollars in advertising" too. Endorsement by big companies like MS came much later for Rust, and Google only started devoting some PR to Go after several years of it…

I don't know about the others but C and C++ certainly did. They had a number of commercial compiler vendors advertising them in the 80s and 90s when they established themselves.

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

#227

Post by johnnyanmac »

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.

C++ is a stretch, but I sort of understand GP's point. I'm slowly learning Rust now and it feels like a deep evolution of C type syntax. Not dissimilar to Javascript in the most base sense of language constructs.

But you use it more and see actionscript types of function notation, funtional language semantics where you just "return" whatever was the last expression in a statement, how structs have no bodies (and classes aren't a thing) and instead everything is implemented externally, and it starts to really become its own beast.

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

#228

Post by ninetyninenine »

fpoling wrote: post #219
ninetyninenine wrote: post #201

Earlier quoted context omitted.

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

Typescript is not a language that matches intuition. Typing complex code while avoiding the any hatch resembles fighting limitations of the borrow checker in Rust.

I find it highly highly intuitive. But my background is haskell like languages.

I feel with practice basic type checking is something that helps you rather then hinders you. It can be learned easily imo. People coming from js tend to have a hard time but that's understandable.

The borrow checker is not easily learned imo. It's always me running into a wall.

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

#229

Post by krupan »

int08h wrote: post #30

> In that sense, Rust enables escapism: When writing Rust, you get to solve lots of 'problems' - not real problems, mind you, but fun problems. If this is true for Rust, it's 10x more true for C++! Lifetime issues are puzzles, yes, but boring and irritating ones. But in C++? Select an appetizer, entree, and desert (w/ bottomless breadsticks) from the Menu of Meta Programming. An endless festival of computer science s…

Came here to comment on the same thing. I've never been able to articulate this as well as the author did, and it is so true! Every programming language requires you to solve some puzzles that are just in the way of the real problems you are trying to solve, but some much more than others.

People have compared Rust to C++ and others have argued that they really aren't alike, but I think it's in these puzzles that they are more alike than any other two languages. Even just reading rust code is a brain teaser for me!

I think this is why C and Zig get compared too. They apparently have roughly the same level of "fun problems" to solve.

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

#230

Post by burntsushi »

loeg wrote: post #212
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…

Indices can be dangling in almost exactly the same way as pointers. Worse, it's easier to accidentally use-after-free clobber some other item in the same structure, because allocations are "dense." (Pointer designs on systems where malloc/free is ~LIFO experience similar problems.)

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