jsunderland323

I agree. I had to double take on this. I think the difference is that react is really an abstraction, unlike micro services. It would be kind of like accusing Bell Labs of making C or Unix as some sort of conspiracy — if you don’t write your own bootloader you’re someone with a hammer complex?

I was sort of expecting him to go after SSR mania, which would make a lot more sense to me (I am guilty of of this). But railing on an abstraction pattern that literally brought JavaScript out of the dark ages seems way off.

I have noticed in myself and other developers with a decade plus that there is new tech fatigue eventually. With enough cynicism it can look like everyone is trying to use their new hammers on everything (sometimes they are). But I think that’s the flip side to this article and I’m glad he made the React point because it really elucidates the whole thing. Everyone looks like they have a hammer complex when you aren’t interested in learning new things. I think there’s so much value in experience and until he got to React, my internal dialogue was shouting “amen” after every sentence but it’s painfully clear the author did not want to engage or think about the problems React solved.

This is really cool. I’d imagine this helps with datasets skewed by errors and actually allows incident losses to be quantized in ways that are usually pretty cumbersome. I think SREs would love this

It’s not like the FANG dev lives in a separate universe devoid of the same AI developments as everyone else. If anything I’d imagine the barrier to producing the FANG products of today goes down but the interview process of FANG is still mostly on a curve relative to whatever technology is available at the time. I sort of expect their operating expenses to drop with more AI development, meaning a FANG job becomes more coveted since less employees are required to produce same revenues but you would expect the wages of those fewer employees to increase, no?

To answer your question 2. I don’t think you can realistically delete a key, contend with network partitions, and have a true eventually consistent data structure. I think you’re sort of running into the uncommit problem. Feels solvable but at the expense of another trade off you don’t want to make. The solution here is really in workflow. Git solves it by separating the act of committing and pushing. If you push a commit containing a secret, the only thing you can do is invalidate the secret or not push your offline branch containing the commit in the first place.

Hi Joseph,

This is a hard problem and something that I think has to be intrinsic to the serialization method of your CRDT. Unique IDs of any kind are really risky in CRDTs because they basically break the mathematical links between potential partitioned duplicates. Lists make this problem even harder because you have to contend with if you should incorporate the ordinal of each element into the hash value.

I’m working on a version control system for visual programs. You wrote a response to someone on structured edits a few months back about how the UNIX fs not being schema/structure aware is the core problem with collaborative edits and destroys open interoperability. I think you hit the nail on the head. I’ve been working on something for nearly a year now to try to address that problem. Let me know if you want to compare notes.