People who only look at the past/present and conclude impossibility are never going to be the ones who invent the future. Even math and science evolve, let alone engineering. The problems described in this article don't even remotely feel like the kind of barriers we faced when Go was solved, when protein fold was predicted and when LLM was solving problems with one prompt. If there is a strong NEED for datacenters to be up in the space, there will eventually be datacenters in the space.

2. Eng teams that have mostly old-timers tend to get stale and slow in changes. This is bad for products that need rapid evolution or new ideas to break status quo. New engineers have way more incentives to make changes to prove themselves and collect credits, while old-timers tend to play safe and stay on the side of stability.

3. Bad coders, not new coders, write bad code.

Any attempt to build a simplified version of the ecosystem will face the same fundamental distributed system tradeoffs like consistency/reliability/flexibility/... For example, one of the simplifications may be mixing storage/serving/ETL workloads on the same node. And the consequence is that without certain level of performance isolation, it could impact the serving latency during expensive ETL workload.

For Rama to be adopted successfully, I think it is important to identify areas where it has the most strengths, and low LOCs might not be the only thing that matters. For example, demonstrating why it is much better/easier than setting up Kafka/Spark and a database and build a Twitter clone on top of that while providing similar/better performance/reliability/extensibility/maintainability/... is a much stronger argument.