I guess the bitcoind devs have never worked with multithreading then*? Such a pity. And such a cutting-edge 1990's technology. If inordinately large signature transactions ever become A Thing, miners employing bitcoind will be bankrupted by smarter miners.
C'est la guerre. To the wiser go the spoils.
*Yes, unnecessarily provocative. But it certainly points out just one more instance where devs are working on the wrong things.
It is a bit too harsh. While I'm continually frustrated by some of the limitations of the bitcoind client and the lack of emphasis on things that I am concerned about (since mining with it is my personal interest), it does not pay credence to how such code realistically evolves and the difficulties of keeping massive rewrites safely in check while evolving the client in multiple directions. I'm not much of a c++ coder myself so I can't do anything much to help but at least I do understand what's involved in maintaining such a massive project. It is impossible to know what issues will become problematic in the future when first starting a project; they only become apparent as it evolves and need to be tackled in a methodical manner. Emphasis has only been placed on speed of block processing, propagation, and work template generation in recent times and the improvement is already substantial but has a very long way to go. If the client was written from the ground up now with emphasis in those areas, knowing what we already do now know, it would no doubt look very different. Some things, though, are protocol limitations and not the client. Things like the quadratic scaling issue are in the current bitcoin protocol design and no amount of client rewrites without a protocol change will get around that. I'm not arguing for one only. Both need to be addressed.