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

371–380 of 459 posts

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

#371

Post by brabel »

zozbot234 wrote: post #290
brabel wrote: post #286

Earlier quoted context omitted.

> This is an example where ownership semantics would have prevented that bug. It’s also a bug prevented by basic good practices in Java. You can’t cache copies of mutable data and you can’t mutate shared data. Yes it’s a shame that Java won’t help you do that but I honestly never see mistakes like this except in code review for very junior developers.

The whole point is that languages like Java won't keep track of what's "shared" or "mutable" for you. And no, it doesn't just trip up "very junior developers in code review", quite the opposite. It typically comes up as surprising cross-module interactions in evolving code bases, that no "code review" process can feasibly catch.

Speak for yourself. I haven't seen any bug like this in Java for years. You think you know better and my experience is not valid? Ha. Ok. Keep living in your dreams.

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

#372

Post by noncoml »

gdbsjjdn wrote: post #123
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 ha…

> 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

Immutability is the actual core and power of Earlang

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

#373

Post by projektfu »

zozbot234 wrote: post #255
mcdoogal wrote: post #205

Earlier quoted context omitted.

Yikes, language flamebait in 2025?

Flamebait? It's literally what the designers of Golang said publicly about the background of prospective developers, and how that constrained the language design: "The key point here is our programmers are Googlers, they’re not researchers. They're typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant lang…

That's one interpretation but I think Pike was using a sarcastic meaning for brilliant. I think he's saying that he wants to mentor people to become programmers, not to learn a difficult, sublime language. It's like when a top scientist tells you they're not smart enough to understand what's going on in some part of his field. It's not necessarily a compliment.

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

#374

Post by jpc0 »

vips7L wrote: post #335
jpc0 wrote: post #277

Earlier quoted context omitted.

> Golang has a whole lot of weird, pointless quirks in both its base language and standard library Having used go in anger I don’t necessarily agree with this, could you point out an example. Maybe I just accepted it and work around it without paying much attention. If you are referring to interface types being able to be null, well they are allocated on the heap and have dynamic dispatch, this isn’t particularly a s…

Here’s a great read on its quirks, and where it really isn’t “simple”: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... https://dave.cheney.net/2014/03/19/channel-axioms

> A send to a closed channel panics

And the related read is purely a misunderstanding about how concurrency is modelled. Channels are not meant to be written from multiple writers, maybe this gets discussed in the next article. I can understand why it is confusing and you consider it unintuitive.

The read situation is literally not understanding or even looking up the interface, there is another return value that will tell you the channel is closed.

Nil channel reads make sense for it to do what it does if your familiar with the interface but at the same time you are literally holding it wrong. Vs a language where that would be UB its an improvement. Compared to a language like rust sure the information isn’t available at compile time but on the same not you would need to be developing in rust, and no offence but if you think golangs concurrency story is difficult to grasp just wait until you meet async rust…

These are the unintuitive, these are generally complaints of you failed to even begin to read the documentation and then complain when things aren’t doing what you expect, leave your preconceived notions at the door and you will be fine.

The faster than lime take needs to be updated, comparing golang from 5 years ago to modern golang is about as useful as comparing rust fron 5 years ago to rust now.

And you can happily make Cgo calls to the windows libraries if you want to access windows APIs, the language provides an abstraction for the normal use case not the specific use case, theres an escape hatch if you want it. And regarding the complaint about timeouts, context is a thing.

Because you don’t know how doesnt mean it’s unintuitive, it means you don’t know how.

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

#375

Post by torginus »

airstrike wrote: post #361
torginus wrote: post #345

I'd argue the very reason Rust was created to get rid of the aliasing problem that's plaguing C-family languages, (meaning that there's always a chance 2 pointers refer to the same piece of memory, meaning all writes might potentially invalidate all variables). This isn't really solvable in C/C++, and its worked around with a bunch of hacks, which might be overly convervative at times, and at others, generates buggy…

> It's essentially impossible to write a Rust program without relying on many of its escape hatches like RefCell and unsafe, that make the borrow checker go away. I get this may be hyperbole but it's also just factually incorrect. Not only that, why is this even a goal? RefCell isn't a wart. It is part of Rust and meant to be used where it makes sense.

Not really hyperbole - I can't iamgine how one would build a fully borrow-checked app, that doesn't use these escape hatches (either directly or through a library). The only thing you could do maybe is to pass down everything that could possible be mutable as parameters everywhere, but that would not exactly be a nice way to program.

And what's wrong with RefCell (and friends)? It's extra complexity, memory footprint, and runtime cost. Also you gave up on the ability of the compiler to check you program's correctness. Granted it's not much, but neither is std::shared_ptr or Swift's automatic reference counting. Once you go from zero overhead to some overhead, there's a ton of quality of life features you can offer to the programmer.

If Rust's borrow checker was smart enough to allow multiple mutable borrows of the same variable, provided some conditions are met (like if you're borrowing struct S, you could borrow it's fields), it would eliminate the need for much of RefCell hacks, as well as solve the gripes in the article.

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

#376

Post by ajross »

nemothekid wrote: post #370
ajross wrote: post #191

Earlier quoted context omitted.

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

> 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". Well, yes. The other compromise is the one Java gives you: write a state of the art garbage collector and include it in your program. This complaint is very annoying because it assumes a garbage collector is "free" an…

Well, in some sense. But in practice, come on: "write your own slow simple reference-counted GC" is a rather more expensive compromise than "just use Java or Go or whatever, it's faster and simpler for your problem".

Aside from all the nitpickery about runtime implementation, the rustacean community has a serious problem with compromise in general. If you whine in a python/Go/Java/whatever forum about performance, they'll point you to their FFI and show you how to get what you want via C++ integration, because clearly no environment is going to be perfect for everyone. But come at rust with a use case (cyclic data structures here) for which it's a poor fit and everyone goes blue in the face explaining how it's not really a problem. It's exhausting.

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

#377

Post by airstrike »

torginus wrote: post #375
airstrike wrote: post #361

Earlier quoted context omitted.

> It's essentially impossible to write a Rust program without relying on many of its escape hatches like RefCell and unsafe, that make the borrow checker go away. I get this may be hyperbole but it's also just factually incorrect. Not only that, why is this even a goal? RefCell isn't a wart. It is part of Rust and meant to be used where it makes sense.

Not really hyperbole - I can't iamgine how one would build a fully borrow-checked app, that doesn't use these escape hatches (either directly or through a library). The only thing you could do maybe is to pass down everything that could possible be mutable as parameters everywhere, but that would not exactly be a nice way to program. And what's wrong with RefCell (and friends)? It's extra complexity, memory footprint…

Try out iced https://iced.rs next weekend

No need for RefCell anywhere

I'm active on the Discord if you need help getting started

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

#378

Post by stouset »

tptacek wrote: post #231
nine_k wrote: post #179

Earlier quoted context omitted.

Due to lack of many abstractions, and lack of exceptions, Go is a less concise Java. It's a language where the lack of expressiveness forces you to write simpler code. (Not that it helps too much.) Go's selling points are different: it takes a weekend to learn, and a week to become productive, it has a well-stocked standard library, it compiles quickly, runs quickly enough, and produces a single self-contained execut…

People sometimes say this like it's a dunk, but there's a finite amount of complexity any given programming task can shoulder, you have to allocate it somehow between the programming environment, the problem domain you're working on, and the algorithmic sophistication you bring to bear on that problem, and it's not clear to me what the benefit is in allocating more than you need to your programming language. A lot of…

From my point of view, the significant tradeoffs made in the design of go make it better suited toward software that has to change a lot: e.g., things closer to customer-facing that are constantly being iterated on.

Rust is more appropriate for areas where the problem boundaries are relatively fixed and slow-moving: libraries, backend services, and infrastructure.

By better allowing you to model your program domain, Rust actually lets you finish projects that are feature complete. I have multiple Rust projects in production for years that have needed at most one or two bugfix releases after their initial rollout on top of a half a dozen feature updates. For a very slight additional startup cost in doing that modeling, I’ve gotten massive dividends back in the volume of maintenance programming that hasn’t needed to be done.

But if your problem domain changes frequently enough that the model needs to be changed all the time, that extra inflexibility isn’t worth it. On the other hand, I don’t know much go software that isn’t beset by the same number of bugs as every other modern language.

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

#379

Post by littlestymaar »

dismalaf wrote: post #363
littlestymaar wrote: post #236

Earlier quoted context omitted.

As others already pointed out, Lua is used in tons of video games as the scripting language. The most famous example being World of Warcraft, but it's far from the only one. If you play, or have played, games, you almost certainly have run software built with Lua without realizing it. It's not because a language isn't relevant in your personal coding niche that it's not industrially relevant.

I'm simply pointing out the irony in calling a (mostly game) scripting language like Lua "industrial" while calling a language used by FAANG, defense companies and finance companies a "hobby" language.

There's no irony, bash and VB6, no matter what you think about the quality of the said languages, are also scripting language and neither are in the “hobby language” category as their use is (or was) very broadly distributed.

OCaml's use is comparatively very, very narrow.

And, in case you are wondering, I have absolutely nothing again OCaml. In fact, my first ever programming language was, as a significant fraction of French engineer from my generation, the “Lite” dialect of Caml. And I suspect that its OCaml heritage is a significant fraction of the reason why I love Rust.

But being used by exactly one FANG company, a single finance one and allegedly a defense company (aren't you confusing Dassault System with Dassault Aviation ?) isn't enough to change its status, especially when it's not the dominant language in two of those (AFAIK Jane Street really is the only one where OCaml has such a central place).

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

#380

Post by zk4x »

noodletheworld wrote: post #148
don-bright wrote: post #129

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

> If you go out of bounds, Rust will panic and tell you exactly where it panicked This arguement has a long history. It is a widely used pattern in rust. It is true that panics are memory safe, and there is nothing unsafe about having your own ref ids. However, I believe thats its both fair and widely acknowledged that in general this approach is prone to bugs that cause panics for exactly this reason, and thats bad.…

Indices are the way to go for a whole range of programs - compilers (IR instructions), GUI (widgets), web browser (UI elements), databases, games (ECS), simulations, etc. It is however without borrowcheck guarantees.

Rc and Arc are definitely a bad way to avoid borrowchecker. GC is used because it is much faster than reference counting. OCaml and Go are experimenting with smarter local variable handling without GC. At that point they may outperform Arc and Rc heavy Rust code.

Post reply on HN