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

191–200 of 459 posts

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

#191

Post by ajross »

creata wrote: post #78
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…

> The trouble is that you've re-created dangling pointers That's true, but as a runtime mitigation, adding a generational counter (maybe only in debug builds) to allocations can catch use-after-frees. And at least it's less likely to be a security vulnerability, unless you put sensitive information inside one of these arrays.

> adding a generational counter (maybe only in debug builds) to allocations can catch use-after-frees.

At the cost of making the use of the resulting heap significantly slower and larger than if you just wrote the thing in Java to begin with, though! The resulting instrumentation is likely to be isomorphic to GC's latency excursions, even.

This is the biggest issue that bugs me about Rust. It starts from a marketing position of "Safety With No Compromises" on runtime metrics like performance or whatever, then when things get hairy it's always "Well, here's a very reasonable compromise". We know how to compromise! The world is filled with very reasonably compromised memory-safe runtimes that are excellent choices for your new system.

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

#192

Post by ameliaquining »

School-Cotton wrote: post #18
airstrike wrote: post #4

The borrow checker is also what I like the least about Rust, but only because I like pattern matching, zero-cost abstractions, the type system, fearless concurrency, algebraic data types, and Cargo even more.

Fearless concurrency is only possible because of the borrow checker.

This isn't really right; Pony does static concurrency safety without borrow checking, and while Swift sort of has borrow checking it's mostly orthogonal to how static concurrency safety works there. The relationship between borrow checking and concurrency safety in Rust is closer to "they rhyme" than "they use the exact same mechanism".

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

#193

Post by ameliaquining »

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…

If you don't want memory safety, it seems like it'd be easier to use C++ with a static analyzer to disallow the parts you don't like. I suppose the lack of a good package manager would still be a problem.

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

#194

Post by bastawhiz »

dismalaf wrote: post #161
bastawhiz wrote: post #156

Earlier quoted context omitted.

React was never written in SML or Ocaml. It was originally called FaxJS, and the source code is published online. A version of React was built to run in ReasonML, which is a flavor of Ocaml for the web, but Reason didn't even exist before React was fairly well established.

https://news.ycombinator.com/item?id=15209814

That's a nonsensical point, though. Building a proof of concept in a language and then rebuilding the practical implementation of it in another language and runtime doesn't make the two the same thing. If Notch had built a proof of concept of Minecraft in Python before building the Java version, we wouldn't say Minecraft was originally written in Python. There wasn't even a robust way to compile OCaml for the web in 2010/2011 even if you wanted to try to use the same code. My understanding is that zero SML or Ocaml related to React ever ran in production, which makes the assertion that it was used in anything other than an academic capacity moot.

Hell, Facebook's own XHP's interface (plus PHP/Hack's execution model) is more conceptually relatable to React, and its initial development predates Jordan's time at Facebook. It wasn't JavaScript, but at the very least it defined rails for writing applications that used the DOM.

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

#195

Post by ameliaquining »

School-Cotton wrote: post #21
airstrike wrote: post #2

I'm far from a Rust pro, but I think the dismissal of alternatives like Polonius seems too shallow. Yes, it is still in the works, but there's nothing fundamentally wrong about the idea of a borrow checker. This is true both in theory and in practice, as you can write any program with a borrow checker as you can without it. TFA also dismisses all the advantages of the borrow checker and focuses on a narrow set of pai…

Polonius will not fix the "issues" the author is complaining about, because contrary to his assertion, they are actual fundamental properties of how the Rust ownership/borrowing model is supposed to work, not shortcomings of an insufficiently smart implementation.

That's not true of the get_default example, which is fixable without fundamental type-system changes but requires Polonius.

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

#196

Post by ameliaquining »

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.

I can't really get over Gleam's position that nobody really needs type-based polymorphism, real programmers write their own vtables by hand.

(It also needs some kind of reflection-like thing, either compile-time or runtime, so that there can be an equivalent of Rust's Serde, but at least they admit that that needs doing.)

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

#197

Post by ameliaquining »

_dain_ wrote: post #52

>The first time someone gave be this advice, I had to do a double take. 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 supp…

Different meanings of "unsafety". A cool thing about Rust's references, when used idiomatically, is that not only are you guaranteed no memory corruption, you're also guaranteed no runtime panics. These are not "unsafe" by Rust's definition, but they're still a correctness violation and it's good to prevent them statically when you can. Indices don't give you this protection.

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

#198

Post by crackrook »

palata wrote: post #144

I choose a language that is as ergonomic as possible, but as performant as necessary. If e.g. Kotlin is fine, there is no way I will choose Rust. Many projects are written in Rust that would absolutely be fine in Go, Swift or a JVM language. And I don't understand: it is nicer to write in those other languages, why choose Rust? On the other hand, Rust is a lot nicer than C/C++, so I see it as a valid alternative ther…

Personally I like my programs to be as performant as is reasonable, not just as is necessary. Rust's low-cost abstractions strike the right balance for me where I feel like I'm getting pretty solid ergonomics (most of the time) while also enjoying near-peak performance as the default.

> It is nicer to write in those other languages, why choose Rust?

Honestly I don't think it is nicer to write in those other languages you mention. I might still prefer Rust if performance was removed from the equation entirely. That is just to say I think preference and experience matters just as much, if not more, than the language's memory model.

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

#199

Post by ameliaquining »

ok123456 wrote: post #114
aapoalas wrote: post #46

Earlier quoted context omitted.

You can always use `Box ` to get the same result in Rust :)

It's not the same because putting it in a box semantically changes the program, adds a level of indirection. It's not just telling it to go away.

There's no avoiding that in a language that's designed to offer low-level control of runtime behavior, regardless of whether it's memory-safe or not. You have to tell the compiler something about how you want the data to be laid out in memory; otherwise it wouldn't know what code to generate. If you don't want to do that, use an interpreted language that doesn't expose those details.

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

#200

Post by creata »

ajross wrote: post #191
creata wrote: post #78

Earlier quoted context omitted.

> The trouble is that you've re-created dangling pointers That's true, but as a runtime mitigation, adding a generational counter (maybe only in debug builds) to allocations can catch use-after-frees. And at least it's less likely to be a security vulnerability, unless you put sensitive information inside one of these arrays.

> adding a generational counter (maybe only in debug builds) to allocations can catch use-after-frees. At the cost of making the use of the resulting heap significantly slower and larger than if you just wrote the thing in Java to begin with, though! The resulting instrumentation is likely to be isomorphic to GC's latency excursions, even. This is the biggest issue that bugs me about Rust. It starts from a marketing…

> At the cost of making the use of the resulting heap significantly slower and larger than if you just wrote the thing in Java to begin with, though!

Lower throughput, probably. But it introduces constant latency. It has some advantages over doing it in Java:

* You're never going to get latency spikes by adding a counter to each allocation slot.

* If you really want to, you can disable them in release builds and still not give up memory-safety, although you might get logical use-after-frees.

* You don't need to use such "compromises" for literally everything, just where it's needed.

> It starts from a marketing position of "Safety With No Compromises"

I haven't seen that marketing, but if it exists, sure, it's misleading. Yes, you have to compromise. But in my opinion, the compromises that Rust lets you make are meaningfully different from the compromises in other mainstream languages. Sometimes better, sometimes worse. Probably worse for most applications than a GC language, tbh.

Post reply on HN