[1f60c]

Ideally, Android wouldn’t have any security vulnerabilities, but that’s not realistic. Rust won’t prevent every bug (and it’s even possible to cause segmentation faults in an ostensibly safe language like Python), but “better” is still a huge leap forward.

[kupopuffs]

just.... no more buffers overflown

[vitiral]

Or dead pointers used, or race conditions

[tialaramex]

Nope. Race conditions are an ordinary fact about our universe, Rust has those. (Safe) Rust doesn't have data races which are much stranger.

Race conditions are just an ordinary effect where several actors are doing things and you need to be careful to ensure that they're co-ordinated properly if that's important. If Alice and Bob both conclude there's no milk, both then go to the store and buy milk, now there is too much milk.

Data races are because it's not possible to deliver what you intuitively expect from a computer which is capable of multiple notionally simultaneous operations. They have no analogue in our real world experience, which is why they're baffling for real programmers on non-trivial software. The world stops making sense.

Most programming languages which allow parallel computation have data races. In C and C++ they're just Undefined Behaviour. Game over. In Go they're sometimes not Undefined Behaviour if your race only touches very simple things like integers. In Java, interestingly, they're always defined behaviour but it doesn't help very much because the behaviour is extremely hard to reason about. Still, your program does do at least something sane even if your head hurts when you think about it. In safe Rust this never happens.

[kaba0]

Just to add: OCaml also recently introduced a new memory model which promises that data races can only corrupt a bounded part of the program (basically, even stronger guarantees than Java does). It comes with some runtime overhead, but quite interesting development, you might find worthwhile to check out.

[jon_richards]

Speaking of race conditions, I recently looked into the current state of “make sure something is in the db and then retrieve it”. Absolutely bonkers that “on conflict do select” still doesn’t exist.

[samus]

PostgreSQL's `INSERT... ON CONFLICT DO NOTHING` gets you there most of the way. You can add a `RETURNING` clause which will return the record that it inserted. But the manual reads like nothing will be returned if no insertion actually happened. So you'd have to follow up with a `SELECT`.

[vitiral]

Man, I used to have the terminology right. I'm slipping since not doing async stuff in a while :)