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

91–100 of 459 posts

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

#91

Post by creata »

aapoalas wrote: post #88

To the author, I would be a borrow checker apologist or perhaps extremist. I will take that mantle gladly: I am very much of the opinion that a systems programming language without a borrow checker[^1] will not find itself holding C++-like hegemony anymore (once/if C++ releases the scepter, that is). I guess I would even be sad if C++ kept the scepter for the rest of my life, or was replaced by another language that…

> just reach for a GC library for those cases

Imo a GC needs some cooperation from the language implementation, at least to find the rootset. Workarounds are either inefficient or unergonomic. I guess inefficient GC is fine in plenty of scenarios, though.

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

#92

Post by creata »

IshKebab wrote: post #84
al_fanta wrote: post #65

Earlier quoted context omitted.

> makes you a better programmer If a language is bad, but you must use it, then yes learn it. But, if the borrowchecker is a source of pain in Rust, why not andmit it needs work instead of saying that “it makes you better”? I’m not going to start writing brainfuck because it makes me a better programmer.

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.

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

#93

Post by vineethy »

The author's motivation for writing this is well-founded. However, the author doesn't take into account the full spirit of rust and the un-constructive conclusion doesn't really help anyone.

A huge part of the spirit of rust is fearless concurrency. The simple seeming false positive examples become non-trivial in concurrent code.

The author admits they don't write large concurrent - which clearly explains why they don't find much use in the borrow checker. So the problem isn't that the rust doesn't work for them - it's that a central language feature of rust hampers them instead of helping them.

The conclusion for this article should have been: if you're like me and don't write concurrent programs, enums and matches are great. The language would be work better for me if the arc/box syntax spam went away.

As a side note, if your code is a house of cards, it's probably because you prematurely optimized. A good way to get around this problem is to arc/box spam upfront with as little abstraction as possible, then profile, then optimize.

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

#94

Post by pyrale »

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.

> 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 language's success or failure.

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

#95

Post by pyrale »

creata wrote: post #48
nine_k wrote: post #43

Earlier quoted context omitted.

Rather, an academia language. Also, OCaml had trouble with multithreading for quite some time, which was a limiting factor for many applications. Facebook made a large effort to thrust OCaml into the limelight, and even wrote a nice alternative frontend (Reason). Sadly, it did not stick.

I had the impression that SML was more popular in academia, and OCaml in industry. Old but funny comparison: http://adam.chlipala.net/mlcomp/

SML was a generation before ocaml. I would say the two languages from the same generation that competed for academia's mindshare were ocaml and Haskell.

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

#96

Post by eigenspace »

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!

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.

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

#97

Post by timmytokyo »

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. When the same borrowchecker makes references unworkable, their solution is to... recommend that I manually manage them, with zero safety and zero language support?!? The irony is unreal."

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

#98

Post by littlestymaar »

dismalaf wrote: post #83
littlestymaar wrote: post #38

Earlier quoted context omitted.

Realistically unless you want to work at Jane Street or Inria (the French computer science lab where Ocaml was made), if you want to use Ocaml, it's going to be as a hobby.

You can say that for almost any language that's not C/C++, C#, Java, Python and JS. Rust is just barely beginning to become "corporate". Even Ruby, which is pretty mainstream, has relatively few jobs compared to the big corporate languages.

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.

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

#99

Post by timmytokyo »

jrpelkonen wrote: post #36
School-Cotton wrote: post #6

IMO, it is reasonable that in the example given: struct Point { x: f64, y: f64, } impl Point { fn x_mut(&mut self) -> &mut f64 { &mut self.x } fn y_mut(&mut self) -> &mut f64 { &mut self.y } } the returned references are, for the purposes of aliasing rules, references to the entire struct rather than to pieces of it. `x` and `y` are implementation details of the struct and not part of its public API. Yes, this is occ…

I found the arguments in this article disingenuous. First, the author complains that borrowchecker examples are toys, then proceeds to support their case with rather contrived examples themselves. For instance, the map example is not using the entry api. They’d be better served by offering up some real world examples.

The author explained why he used contrived examples. It's because the pain arises most acutely only after your project has become large and mature but demands a small ownership-impacting change. The toy examples demonstrate the problem in the small, but they generalize to larger and more complex scenarios.

He's basically talking about the rigidity that Rust's borrow checking imposes on a program's data design. Once you've got the program following all the rules, it can be extraordinarily difficult to make even a minor change without incurring a time-consuming and painful refactor.

This is an argument about the language's ergonomics, so it seems like a fair criticism.

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

#100

Post by timmytokyo »

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…

You're right about C++. A fairer comparison would be to a simpler garbage-collected language like Go.
Post reply on HN