3 ms·

So many frameworks and dev-oriented features are sold with the claim that domain X is super complicated and full of esoteric useless trivia, so instead someone

So many frameworks and dev-oriented features are sold with the claim that domain X is super complicated and full of esoteric useless trivia, so instead someone has put a clean facade on that which simplifies everything and protects the hapless dev from having to learn. Which is nice, it’s a tidy abstraction, we all have other things to do, now we go fast. Except…the dev has to learn the new API, which we can call domain Y, and which can become quite complicated and hard to map conceptually to domain X (e.g. React events vs browser rendering, or Java GC vs real memory). And when the cool facade doesn’t quite work for some exotic use case, now what? The dev gets to learn the original domain X anyway, plus how X and Y interact. In the worst case they have rewrite all their Y-using code. Great abstractions are good magic; bad abstractions are evil magic. And yet good vs evil is often hard to tell apart when you pick up the problem.

dartos 2y ago
The only areas I’ve ever seen that were truly super complicated were when synchronization is involved. It’s so hard to wrap my head around how a CPU reorders instructions and I need to think very slowly and very carefully whenever I work with synchronization. Same with distributed systems. I implemented a toy version of raft forever ago, but just wrapping my head around it took a month, and I still think I don’t really grasp it. Haven’t even looked into paxos yet.
- xxs 2y ago
  Sync is easy. Concurrency is hard. Partly b/c as humans we can't multitask. CPU reordering instructions (and speculative execution) should be not be hard to understand. It tries to do as much work as it could before it has to stall due to lack of data
  - dartos 2y ago
    Synchronization is like a sub-problem of working with concurrency. In this context they’re the same afaics CPU reordering isn’t hard to understand, itself, but building systems that depend on it is (like building a time sharing OS… very difficult) because it’s difficult to reason about. The implications of it are hard to understand because, as you say, we’re not naturally apt at multitasking

dartos 2y ago

The only areas I’ve ever seen that were truly super complicated were when synchronization is involved. It’s so hard to wrap my head around how a CPU reorders instructions and I need to think very slowly and very carefully whenever I work with synchronization. Same with distributed systems. I implemented a toy version of raft forever ago, but just wrapping my head around it took a month, and I still think I don’t really grasp it. Haven’t even looked into paxos yet.

xxs 2y ago
Sync is easy. Concurrency is hard. Partly b/c as humans we can't multitask. CPU reordering instructions (and speculative execution) should be not be hard to understand. It tries to do as much work as it could before it has to stall due to lack of data
- dartos 2y ago
  Synchronization is like a sub-problem of working with concurrency. In this context they’re the same afaics CPU reordering isn’t hard to understand, itself, but building systems that depend on it is (like building a time sharing OS… very difficult) because it’s difficult to reason about. The implications of it are hard to understand because, as you say, we’re not naturally apt at multitasking