Hacker News Reader

Comment by throwaway894345 | Hacker News Reader

At least with Rust, very few domains involve so much parallelism that one benefits from the overhead that the borrow checker adds to the development process. And many times the borrow checker is completely inadequate at preventing race conditions (frequently the case with distributed computing). Of course, Rust can recoup those losses elsewhere, by having better tooling or competing in domains where performance matters a lot, but I’ve not found the safety to be worthwhile in my domain.

EDIT: s/data races/race conditions

View on HN

> And many times the borrow checker is completely inadequate at preventing data races (frequently the case with distributed computing).

The borrow checker (in safe rust) always[0] prevents data races. It can't, however, prevent race conditions (but neither can pony do[1])

[0] https://doc.rust-lang.org/nomicon/races.html

[1] https://www.ponylang.io/faq/#data-race

Right, I should have said "race conditions"; it hadn't occurred to me that the two weren't synonymous. My point wasn't that Pony does prevent race conditions, but rather that non-data-race race conditions are much more common in my domain (distributed computing) or really any domain where multiprocess architectures are common so I don't benefit much from the static guarantees that Rust affords.

Pony does not prevent race conditions. Two actors can wait forever for the other to send a message, deadlocking.

I didn’t say that Pony prevents race conditions. I agree that Pony (nor indeed any language) prevents race conditions.

I misread then. Though you did ironically just say that pony does prevent race conditions :P

grrrrr

Is deadlock considered a race condition?

I typically think of a race condition an issue with concurrency where data might be modified by another thread which causes the program to return incorrect results.

I think this might help:

Data race vs race condition:

https://blog.regehr.org/archives/490

That is helpful. I was thinking that a race condition would only include a data race, but this blog defined it broader, so that it would include deadlock.

Deadlock is one common symptom of a race condition.

You can have race conditions with message passing.

Yes, that makes sense.

A race condition happens when data/state is mutated because of the order in which concurrent processes occur. This could happen with threads, message passing, or many other ways.

I think this is distinct from deadlock which occurs when there is at least one circular dependency in the order when different "processes" must perform their operations.

> The borrow checker (in safe rust) always[0] prevents data races.

As long as those data races originate from threads, it cannot prevent data races across processes, for example:

- Modifying the same file location

- Modifying the same table cell without transactions

- Talking to the same IO port

- Data sharing between CPU and GPU

In fairness to the OP, the link they cited defined "data race" explicitly and narrowly as race conditions on memory which I think makes all of your bullets out of scope, but also neuters the original claim pretty considerably.

Rust's borrow checker is not only for multi threading and memory safety. It allows someone designing an API for any kind of data structure to guarantee that the user is using it correctly, by making their code not compile when they are using it incorrectly (basically what any type system provides, but fancier). What you call borrow checker overhead, some would call fixing problems before they occur.

You’re right that there are other benefits of Rust’s type system beyond precluding data races, but even still, the overhead of Rust is too steep to make it a good fit for the kinds of applications I write.

What domain is that?

Distributed systems

Reply on news.ycombinator.com