5 ms·

The symtoms that lead up to me learning about the need for locks in multi threaded servers was painful. That the state could change from one line of code to the

by z3t4 3y ago

The symtoms that lead up to me learning about the need for locks in multi threaded servers was painful. That the state could change from one line of code to the next line, how could it change when I just set it a micro second ago? Because the user clicked the button twice and the call was executed simultaneously but in different threads because my new server had many cores. Then I learned about async programming, but I no longer remember what was so difficult about it. Just that it took about a year and I basically had to rewire how my brain visualize program execution.

mrkeen 3y ago
> the state could change from one line of code to the next line > I no longer remember what was so difficult about it You or (your libraries) probably stopped mutating things. No mutation means you can rely on values you used several lines ago. This is the perennial HN discussion whenever the word 'functional' comes up. "But x=x+1 is simple to teach to beginners" is the rallying cry. Well, this is why not. Also, > the need for locks This goes away if you don't mutate.
- gpderetta 3y ago
  yet physical hardware has a finite amount of memory, so at some point you either stop your program of you have to modify a cell you already touched.
  - tialaramex 3y ago
    Mutation isn't confusing. On its own. Multiple references isn't confusing. On its own. The observation, which I don't think I saw being made twenty years ago (I could be wrong) is that you shouldn't mix these two things. No multiple references with mutation. In theory you can safely do so in serial programs if you were careful enough, in practice you won't be careful enough and we should write fewer serial programs than we do, so why not reject this outright. Rust is one particular (and notably successful) attempt to make a programming language about this big idea, but it's the idea in Val and several other newer languages. There are a lot of unknowns about the best way to approach this, but "Just pretend it's not important" is not a correct answer.
    - gpderetta 3y ago
      My point was simply that at some point the buck stops and someone has to write the code to mutate a memory cell. Regarding your point, shared xor mutable is nice, but databases are an example of a shared mutable (and even concurrent!) yet safe resource, so other models are possible.
      - mrkeen 3y ago
        > databases are an example Yes, it is possible because programmers have accepted the bargain that they must write purely-functional SQL. Then the db is able to decide how best to optimise/apply/retry/copy-on-write/abort as necessary. If SQL allowed you to directly mutate things, it would break everything. You couldn't 'LIMIT 10' if your loop might want to increment some data in row 40082.
- z3t4 3y ago
  I like to philosophize about the universe, how at every state change a new universe is created. Like if the version of you I see is someone else, almost identical, and the version I interacted with have branched off into a new universe.

by z3t4 3y ago

mrkeen 3y ago

> the state could change from one line of code to the next line > I no longer remember what was so difficult about it You or (your libraries) probably stopped mutating things. No mutation means you can rely on values you used several lines ago. This is the perennial HN discussion whenever the word 'functional' comes up. "But x=x+1 is simple to teach to beginners" is the rallying cry. Well, this is why not. Also, > the need for locks This goes away if you don't mutate.

gpderetta 3y ago
yet physical hardware has a finite amount of memory, so at some point you either stop your program of you have to modify a cell you already touched.
- tialaramex 3y ago
  Mutation isn't confusing. On its own. Multiple references isn't confusing. On its own. The observation, which I don't think I saw being made twenty years ago (I could be wrong) is that you shouldn't mix these two things. No multiple references with mutation. In theory you can safely do so in serial programs if you were careful enough, in practice you won't be careful enough and we should write fewer serial programs than we do, so why not reject this outright. Rust is one particular (and notably successful) attempt to make a programming language about this big idea, but it's the idea in Val and several other newer languages. There are a lot of unknowns about the best way to approach this, but "Just pretend it's not important" is not a correct answer.
  - gpderetta 3y ago
    My point was simply that at some point the buck stops and someone has to write the code to mutate a memory cell. Regarding your point, shared xor mutable is nice, but databases are an example of a shared mutable (and even concurrent!) yet safe resource, so other models are possible.
    - mrkeen 3y ago
      > databases are an example Yes, it is possible because programmers have accepted the bargain that they must write purely-functional SQL. Then the db is able to decide how best to optimise/apply/retry/copy-on-write/abort as necessary. If SQL allowed you to directly mutate things, it would break everything. You couldn't 'LIMIT 10' if your loop might want to increment some data in row 40082.
z3t4 3y ago
I like to philosophize about the universe, how at every state change a new universe is created. Like if the version of you I see is someone else, almost identical, and the version I interacted with have branched off into a new universe.