RH predicted the issues of concurrency will cause a major shift in lang design but in my experience, concurrency capabilities of software remain largely untapped. Most code is just single threaded. Only a few specialized libaries utilize parallelism. We've simply avoided concurrency as much as possible. I haven't seen good concurrent first implementations in the small, only something larger like building a microservice from the start.
After some days of intense problem solving I feel like I have been rubbing my brain directly all over everything I have come across that day. Maybe that's what I am doing wrong. 😀
About halfway through the talk it falls apart... he so grossly underestimates how much practical programs rely on individual states, and how much of a problem copying everything each time you had to "perceive" something or change a value would cost. Parallelism isn't "saved" by having multiple copies, it's made that much worse because instead of one logic which could be wrong, you now have N things all coming to different conclusions! It's good practice to make your reads and writes as small and non-distributed as possible, but if you're going parallel, functional is fundamentally broken.
I'd guess that you're talking about the performance comparisons he makes around 44:20 and the slides leading up to that? I don't think he underestimates anything. I think you're misunderstanding the "path copying" step he describes around 41:47 - we're not "copying everything," we're just making a new reference to some new state, plus most of the old state. We're using references the way they're supposed to be used. The concurrency primitives in Clojure provide exactly the semantics (immutable values, discrete states, no in-between state that "could be wrong" as long your application logic is actually sound) he's talking about, _and they're really fast._
You have no idea what you are talking about. Functional programming is superior especially when it comes to parallel and distributed programming and you have no idea how "copying" is implemented in functional languages, see persistent data structures.
it doesn't seem like you paid attention to the persistent data structure model in the talk. it is, however, true that you do have to reconcile divergent outcomes, but with time-aware history-preserving programming and transactional reconciliation you have much better tools for doing this. there is some overhead, so this kind of programming works best when you're io bound, in a situated system -- not when you eg need things to go as fast as possible on one machine and your rate limiting step is data structure memory layout. But almost everything else Rich says still applies in that context, re: object skepticism. If you look at people like mike acton, casey muratori, jonathan blow w/jai, etc who write high performance interactive code in games, or what ML frameworks like jax aim for (a good example that links the two worlds -- immutable data structures, referentially transparent pure functions, w/a built-for-purpose jit compilation path that produces the correct device specific memory layout for high perf code), you will see that the shortcomings of OO and principles of pure functions on plain data structures apply broadly, even if persistent data structures and transactions are only the optimal solution in a few domains.
