_dky
_dky on Hacker News
Good observations. It made me realize how I had tuned myself to understand the thought process of the PR author looking at individual commits and how they add up. With most AI written code, I see large commits and that does not help understand how the solution evolved.
Forges catering to public should follow standards. This limits your ability to get creative. Git client has become the defacto standard.
One similarity I noticed was the intermediate representation from GCC frontend looks and feels very Lispy. Could be just a coincidence too.
If implementation is task based and task always runs on same virtual CPU (slots equaling CPUs or parallelism), wonder if something like below might help.
RW lock could be implemented using an array of length equal to slots and proper padding to ensure each slot is in its own face line (avoid invalidating CPU cache when different slot is read/written).
For read lock: Each task acquires the lock for their slot.
For write lock: Acquire lock from left most slot to right. Writes can starve readers when they block on in-flight reader at a different slot when moving from left to right.
I do not know how Rust RW locks are implemented.
Back in 2003, implemented a Win32 profiler using Berkeley DB for offline indexing and visualizing profiler data.
https://github.com/mechanicker/cramp
Later in ~2011, used BDB for indexing filesystem metadata at a large storage vendor for enhancing data management in a storage cluster.
Clean API with language bindings makes it easy to integrate with different languages.
I guess it is more about captured user base than the technology.
What other differentiating factors can you implement that can steer the masses from one messaging platform to the other. I cannot think of any.
If C++ had a contract on what exceptions a function can throw with compile time check to enforce caller catches those exceptions, would it make it better?
Guess Java does that, not much experience in Java here.