It gets to the heart of the dichotomy between true and false were lies are just deliberate false statements.

As the author correctly pointed out, walking extensively in the path of the false comes at an inherent cost. The cost increases with each false statement.

Walking extensively in the path of the truth, where one tries to speak true statements all the time is, also has inherent costs. This incurs a high cost upfront and gets lower as time progresses.

This cost of truth upfront involves embarrassment and usually the work itself required because of having stated the truth.

This leads me to hypothize that progressively lying again and again (accumulated false statements) will inevitably lead to a state where one increasingly loses touch with reality (gradually one at a time like evolution) where necessary life saving precautions are increasingly discarded eventually increasing the odds of premature death itself. This hypothesis has implications that span life, death, true and false.

What is the use of spec adherence if it leads to unusable/broken applications.

The QUERY method is a step in the right direction but it came too late.

Spec is not the same as compatibility.

Sticking to RFC is one thing. Advertising as node compatible is completely different altogether. Many people cannot see the difference.

Atleast a flag would suffice as that would ensure existing infrastructure tooling doesn't break while keeping the RFC spec folks happy.

You should use bun :)

> Not counting the years ...

Never knew a capable/competent developer who didn't spend years.

Unix, C, etc.. constitute other historical examples of having been built in a very short time apart from Linus's git.

Hint: Elasticsearch, GraphQL, Axios, etc..

Perhaps the broken thing might be how you expect existing softwares to break so that your expectation can be satisfied. You should look at GET more closely.

There is a reason curl allows to send GET requests with a body. There is a reason node allows to receive GET requests with a body.

Bun was promising, but as long as they don't fix their http GET implementation to accept the request body, its broken for me.

Note: Many real world tools like Elasticsearch's GET /_search with a JSON query DSL is one example. It breaks Axios. Many custom infrastructure tools expect it.

Advertising as node compatible and having this breaking change is undesirable. Hope it gets fixed soon.

Ideally, a specific well optimized code for a problem domain could always outperform a generic optimized code for the same problem domain.

This is because the specific solution can make assumptions that generic cannot.

This usually holds true everywhere, not just for compilers.

This is not an excuse for avoiding generic solutions. But where performance matters absolutely and where the problem space is sufficiently constrained, specific solutions become the valid path.

Competent developers have, can, and will out-build entire industries in a week.

Would have been useful for us if we'd known about it earlier.

Monolog's use case goes beyond resource usage, but Redpanda users coming across this would definitely find this helpful.

Our Monolog is similar in spirit.

Instead of building Monolog on object storage (R2, S3), we built it on our Dip, thus achieving extreme low latency and parallelism for ingestion and consumption.

Our novel architecture enables scaling to infinite consumers without upfront partitions (no magic, different tradeoff). This plays nicely with Slyp's data locality and application architecture.

Monolog is built on Rust, is lightweight, and runs on mobiles and servers alike.

The original reason for building Monolog was comically outlandish, Kafka was slow and required JVM, Redpanda was eating too much RAM - 2GB min which is absurd for our use case. Redpanda was also consuming so much CPU that the disgusting CPU fan noise had us feel emotional pain.

We would very much like to build object storage on Dip, but we are currently preoccupied and hence don't have any immediate plans to build one in the short term. Hence, it is R2 for now.

Any technology that lowers latency, memory, or cost must be appreciated and recommended.

You shifted the conversation to redundancy and how AWS provides bells and whistles. You are consistent in your position, just not with me and not with PunchyHamster because we both are comparing costs by self hosting.

And for those of you who are willing to pay the premium and don't care about costs, like you, would obviously find AWS attractive.

For a startup like ours and many others, cost is everything. And spending a day or two for bitrot protection and having a couple of SSDs for redundancy and scalability is a no brainer.

You don't need big buildings for resilience. I suggest building things that require real scaling and resilience and you would know that it is about being distributed, having low cost, and owning your systems.

Your argument that it is expensive and tedious to maintain compared to AWS S3 is false. No it isn't.

Fear mongering only works against those who haven't built reliable systems. Building an S3 equivalent with cheap providers for redundancy or having one's own small resilient distributed hardware with staffing most often dwarfs the horribly insane premium paid for AWS S3 services.

But this is only if you want the redundancy which is a different topic altogether.

If all you want is a single replica, which was what PunchyHamster originally commented on, the base price of what AWS S3 provides, which does not include redundancy, makes even lesser sense compared to having your own SSD.