Posts by therealfakemoot@techhub.social
 (DIR) Post #AT1O2DA3znIfyve3G4 by therealfakemoot@techhub.social
       2023-02-25T00:37:33Z
       
       0 likes, 0 repeats
       
       @nicole I think it really boils down to two degrees of freedom:1) make the work easierThis includes you examples about managers running interference, as well as finding algorithms with smaller big O2) do more work at onceParallelism obviously falls here, but as I write I realize I'm on the fence about concurrency. The latter isn't intrinsically connected to running more code at the same time, although well written concurrent code can usually be parallelized. Concurrency is more about separating concerns, which to my mind is making the work easier (to observe and optimize).
       
 (DIR) Post #AT2ViUa4Vx2x0UsWAa by therealfakemoot@techhub.social
       2023-02-25T13:38:18Z
       
       0 likes, 0 repeats
       
       @nicole Preface: my understanding of concurrency comes from my time with Golang, but I'm relatively confident the principles translate. Writing (good) concurrent code effectively reduces to this: separate I/o bound work from CPU bound work. Pure (in the math sense) functions get lifted out of network operations. This separation of concerns lets the runtime spend its time more effectively: when it's waiting on I/o it can context switch to computations that aren't bottlenecked .And it's hard to write good concurrent code that separates these concerns until your API has been cleaned up and had other concerns separated.I'm on mobile till tomorrow so my usual eloquence is gonna take a hit
       
 (DIR) Post #ATuyDjs2aSKV0F6VfM by therealfakemoot@techhub.social
       2023-03-23T20:12:08Z
       
       0 likes, 0 repeats
       
       @nicole find has to be in my top three, next to vim and tmuxI use it almost every day, -exec is great because it's just map() for your filesystem