3 ms·

just.... no more buffers overflown

by kupopuffs 3y ago

vitiral 3y ago
Or dead pointers used, or race conditions
- tialaramex 3y ago
  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.
  - jon_richards 3y ago
    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 3y ago
      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`.
  - kaba0 3y ago
    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.
  - vitiral 3y ago
    Man, I used to have the terminology right. I'm slipping since not doing async stuff in a while :)

just.... no more buffers overflown

vitiral 3y ago

Or dead pointers used, or race conditions

tialaramex 3y ago
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.
- jon_richards 3y ago
  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 3y ago
    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`.
- kaba0 3y ago
  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.
- vitiral 3y ago
  Man, I used to have the terminology right. I'm slipping since not doing async stuff in a while :)