undefined | Better HN

0 pointsbrabel11mo ago0 comments

> Like, actors can trivially deadlock/livelock,

Oh my ... you never seen a proper Actor language, have you?

Have a look at Erlang and Pony, for starters. It will open your mind.

This in particular is great: https://www.ponylang.io/discover/what-makes-pony-different/#...

> Pony doesn’t have locks nor atomic operations or anything like that. Instead, the type system ensures at compile time that your concurrent program can never have data races. So you can write highly concurrent code and never get it wrong.

This is what I am talking about.

> You make it sound like there is some modern development superseding what java has, but that's absolutely not the case.

Both Actor-model languages and Rust (through a surprisingly different path: tracking aliases and lifetimes) do something that's impossible in Java (and most languages): prevent data races due to improper locking (as mentioned above, if your language even has locks and it doesn't make them safe like Rust does, you know you're going to have a really hard time. actor-languages just eliminate locks, and "manual concurrency", completely). Other kinds of races are still possible, but preventing data races go a very, very long way to making concurrency safe and easy.

0 comments

gf00011mo ago

Does preventing data races (which is not particularly hard if you are willing to give up certain properties, e.g. just immutability alone solves it) that much of a win?

You just made a bunch of concurrent algorithms un-implementable that would give much better performance for the benefit of.. having all the other unsolvable issues with concurrency? Like, all the same issues are trivially reproducible at a higher level, with loops within actors' communication that only appear under certain, very dynamic conditions, or a bunch of message passing ending up in an inconsistent state, just not on an "object" level, but on a "group of object" level.

brabelOP11mo ago

> much of a win?

It's a huge win. Absolutely game changing.

> You just made a bunch of concurrent algorithms un-implementable

Exactly! That's a good thing! You think you need those buggy algorithms, you just don't, at least in 99% of cases.

Yes, you can still end up with inconsistencies when you perform actions without the necessary checks, but those cases that remain are extremely easy to find and fix (and even make completely impossible by design), when compared to the horrors of mutable state with locks.

jbritton11mo ago

Perhaps there is some confusion here between data races and race conditions. Rust and Pony prevent data races, but not race conditions.

brabelOP11mo ago

There's no confusion.

j / k navigate · click thread line to collapse

0 comments

gf00011mo ago

Does preventing data races (which is not particularly hard if you are willing to give up certain properties, e.g. just immutability alone solves it) that much of a win?

brabelOP11mo ago

> much of a win?

It's a huge win. Absolutely game changing.

> You just made a bunch of concurrent algorithms un-implementable

Exactly! That's a good thing! You think you need those buggy algorithms, you just don't, at least in 99% of cases.

jbritton11mo ago

Perhaps there is some confusion here between data races and race conditions. Rust and Pony prevent data races, but not race conditions.

brabelOP11mo ago

There's no confusion.

j / k navigate · click thread line to collapse