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

81–90 of 459 posts

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

#81

Post by lblume »

nine_k wrote: post #49
dejawu wrote: post #33

Earlier quoted context omitted.

I've similarly thought about building a language that compiles to Rust, but handles everything around references and borrowing and abstracts that away from the user. Then you get a language where you don't have to think about memory at all, but the resulting code "should" still be fairly fast because Rust is fast (kind of ending up in the same place as Go). I haven't written a ton of Rust so maybe my assumptions of w…

Why, macros that put Arc > everywhere might just be it.

Arc> is redundant, for the contents of the Arc are already stored on the heap. You may be thinking of Arc> for multithreaded access or Rc> for singlethreaded access. Both enable the same "feature" of moving the compile-time borrow checking to runtime (Mutex/RefCell) and using reference-counting instead of direct ownership (Arc/Rc).

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

#82

Post by norskeld »

int_19h wrote: post #24

I've recently wondered if it's possible to extract a subset of Rust without references and borrow checking by using macros (and a custom stdlib). In principle, the language already has raw pointers with the same expressive power as in C, and unlike references they don't have aliasing restrictions. That is, so long as you only use pointers to access data, this should be fine (in the sense of, it's as safe as doing the…

Very tangential, but I couldn't help but remember Crust [1]. This tsoding madlad even wrote a B compiler [2] using these... rules. Or lack thereof?

[1]: https://github.com/tsoding/Crust

[2]: https://github.com/tsoding/b

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

#83

Post by dismalaf »

littlestymaar wrote: post #38
dismalaf wrote: post #31

Earlier quoted context omitted.

Hobby language? Plenty of commercial and important software has been written in OCaml. Hell, the early versions of the Rust compiler were written in OCaml...

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.

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

#84

Post by IshKebab »

al_fanta wrote: post #65
mikepurvis wrote: post #13

Earlier quoted context omitted.

There's the practical end goal benefit of safer and more robust programs, but I think there's also the piece that pg talks about in Beating The Averages which is that learning how to cooperate with these conventions and think like there's the borrow checker there makes you a better programmer even when you return to languages that don't have it .

> 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 of all the benefits they convey in spite of those occasional times when they get in the way.

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

#85

Post by lblume »

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…

It would not just be "confusing". It would be fundamentally unacceptable because there would just be no local reasoning anymore, and a single private field change might trigger a whole cascade of nonlocal borrowing errors.

Unfortunately, this behavior does sometimes occur with Send bounds in deeply nested async code, which is why I mostly restrain from using colored-function style asynchronous code at all in favor of explicit threadpool management which the borrow checker excels at compared to every other language I used.

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

#86

Post by lblume »

dhbradshaw wrote: post #50

If a friend told me they liked Rust but didn't like the borrow checker, I'd probably point them to Gleam and Moonbit, which both seem awesome in their own niches. Both have rust-like flavor and neither has a borrow checker.

Someone should create a DAG of programming languages with edges denoting contextual influence and changes in design and philosophy, such that every time a PL is critized for a feature (or lack thereof), the relevant alternatives exactly considering this would be readily available. It could even have a great interactive visualization.

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

#87

Post by lblume »

forrestthewoods wrote: post #22

One day I will write a blog post called “The Rust borrow checker is overrated, kinda”. The borrow checker is certainly Rust’s claim to fame. And a critical reason why the language got popular and grew. But it’s probably not in my Top 10 favorite things about using Rust. And if Rust as it exists today existed without the borrow checker it’d be a great programming experience. Arguably even better than with the borrow c…

> No bumpalo doesn't count.

Mind explaining why? I have made good experiences with bumpalo.

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

#88

Post by aapoalas »

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 didn't have something like a borrow checker.

It doesn't need to be Rust: Rust's borrow checker has (mostly reasonable) limitations that eg. make some interprocedural things impossible while being possible within a single function (eg. &mut Vec and &mut u32 derived from it, both being used at the same time as shared references, and then one or the other being used as exclusive later). Maybe some other language will come in with a more powerful and omniscient borrow checker[^1], and leave Rust in the dust. It definitely can happen, and if it does then I suppose we'll enjoy that language then.

But: it is my opinion that a borrow checker is an absolutely massive thing in a (non-GC) programming language, and one that cannot be ignored in the future. (Though, Zig is proving me wrong here and it's doing a lot of really cool things. What memory safety vulnerabilities in the Ziglang world end up looking like remains to be seen.) Memory is always owned by some_one_, its validity is always determined by some_one_, and having that validity enforced by the language is absolutely priceless.

Wanting GC for some things is of course totally valid; just reach for a GC library for those cases, or if you think it's the right tool for the job then use a GC language.

[^1]: Or something even better that can replace the borrow checker; maybe Graydon Hoare's original idea of path based aliasing analysis would've been that? Who knows.

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

#89

Post by bobajeff »

forrestthewoods wrote: post #22

One day I will write a blog post called “The Rust borrow checker is overrated, kinda”. The borrow checker is certainly Rust’s claim to fame. And a critical reason why the language got popular and grew. But it’s probably not in my Top 10 favorite things about using Rust. And if Rust as it exists today existed without the borrow checker it’d be a great programming experience. Arguably even better than with the borrow c…

This is something I've been thinking about lately. I do think memory safety is an important trait that rust has over c and other languages with manual memory management. However, I think Rust also has other attractive features that those older languages don't have:

* a very nice package manager

* Libraries written in it tend to be more modular and composable.

* You can more confidently compile projects without worrying too much about system differences or dependencies.

I think this is because:

* It came out during the Internet era.

* It's partially to do with how cargo by default encourages more use of existing libraries rather than reinventing the wheel or using custom/vendored forks of them.

* It doesn't have dynamic linking unless you use FFI. So rust can still run into issues here but only when depending on non-rust libraries.

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

#90

Post by lblume »

olq wrote: post #17

Skill issue

It is true that any sufficiently complicated technology requires a certain skill level to use it adequately. The question remains whether the complexity of the technology is justified, and the author presents an argument why this might not be the case. Remarking their supposed lack of skill does not seem particularly productive.
Post reply on HN