elendilm

Programming is special in the sense that it is one of those direct experiences of mere language instructions being used to make things work - a form that resembles incantations and sorcery of the old times. Where literal stones can speak and obey our commands.

Of course there are many other indirect instances of language being used as the primary tool to move. But programming happens to be a direct raw unadulterated first hand experience into building things with nothing but raw language primitives.

Where code is ideas willed into existence.

Vpsdime is pretty nice. IIRC they provide linux servers for $7 per month.

Have used them for years. I don't use them anymore but that is because I no longer have a requirement.

> body on a GET means nothing

Why because a bunch of guys in a committee said so? Sorry your committee is broken if they put idiotic ideas out there in the open asking everybody to conform.

But at this point I don't think you would get it. All hail the almighty spec.

I can't argue for the original person, but when 500 large projects are different instantiations of just a handful of fundamental primitives, it is not hard to keep track of large number of projects which might look like completely different non overlapping projects for an outside observer.

With enough competence, it boils down to an exercise in organizing discipline and first principles derivation. As I have mentioned in the past, skillsets at sufficient granularity are transferable across domains.

What you said would be true when looked at each different project as a separate domain, but real world is rarely a collection of isolated domains.

To put that in perspective, our app SlypBusiness has memberships, products, services, gift cards, privilege cards, etc. which all look like different domains to a user but is fundamentally the same primitive instantiated differently.

Nope. The spec is broken. Hence they were forced to patch the spec with the addition of the QUERY method this year.

Spec is not Bible/Quran requiring religious adherence. If the spec is idiotic, developers have and will circumvent it until either the spec adapts or developers move on abandoning the spec leaving it to rot in the dust.

Screaming at every original thought as LLM generated is funny. English is not even my native language. I heartily accept your compliment about my english being well structured.

If you read my older comments, say on Paul Graham's article titled "Making startups powerful", I talk of upfront costs and resilience and how being aligned with truth makes a business more resilient - but from a startup survival context.

Here, I merely rephrased many of my earlier comments/thesis by taking it a little too far into the land of epistemology and metaphysics. There is a lot more to discuss for those curious and interested in the topic, but apparently it appears not here and not now.

LLM content is generally easy to identify. Original thought is usually not their forte. And most of their sentences hedge (atleast in some way) so as to appease all factions or to be politically correct. They include qualifiers to distance themselves on grand claims, they lack consistency, etc. and the list goes on.

I am sorry if every comment appears to you as LLM generated. It exposes them and how much work of substance they have done in their life. I have no help to offer you.

Remarkable article.

It gets to the heart of the dichotomy between true and false where 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, also has inherent costs which is high upfront and gets lower as time progresses.

This upfront cost of truth involves embarrassment and usually the work itself required for having stated the truth in the first place.

This leads me to hypothesize 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.

The hypothesis effectively explores the compounding cost that affects the liar's relationship with reality (statements that are true - in a platonic world). This hypothesis has implications that span truths, falsehoods, life and death.

And yet many don't, Istio/Envoy for example. There are enough usable applications that utilize it that ignoring the body comes with a cost.

Or any compliant implementation is free to not ignore it like istio/envoy, infrastructure tooling, etc.

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

As I have noted elsewhere here in this thread, spec saying one thing has nothing to do with how many libraries implement something. If the libraries are critical and provide value, then no matter how much you scream for your adherence to the spec, people will use it and depend on it.

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

Many GraphQL clients/libraries use GET with body to workaround hitting URL query limitations like length, etc.

Spec is not the same as compatibility.

QUERY, added in 2026, does not resolve existing or legacy applications.

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.

Your "bug-for-bug" compatibility ensures Axios, Elasticsearch, many GraphQL implementations, etc. works. Hence I will use node as mentioned in my original comment.

You should use bun :)

Thinking about an issue doesn't equate to building.

> 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.

Wrong.

Hint: Elasticsearch, GraphQL, Axios, etc..

No. There are use cases for GET with body. Curl allows it. Node allows it. Bun doesn't.

Node allows it. Curl allows. Not having it is a breaking change and undesirable for node compatibility.

You would be surprised how many technologies expect GET with a body. In practical backend engineering, tools like Elasticsearch, GraphQL, complex query engines, and legacy internal APIs rely on GET with a body every day. Apparently even axios messes up on curl GET requests with a body as mentioned in the associated github issue.

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.

I never found Deno compelling enough compared to Node.

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.

Nice.

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.

It is the norm for capable developers. You don't need AI slop for it. Linus Torvalds took a week or two off to out-build the version control industry.

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

Glad to know. Rollout of our apps Slyp and SlypBusiness remains our current priority.

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.

Nice.

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.

Focus on costs. That is the whole argument.

Glad I was helpful.

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

The original comment by PunchyHamster was about cost, i.e how AWS S3 base tier costs cannot be justified if you purchase your own SSD.

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.

You are shifting the goalpost.

If you don't pay the premium for redundancy, your S3 is the same sitting duck as the single SSD in your office, albeit an expensive one. Thinking AWS and therefore integrity and security is magical thinking.

Ask those who lost their data in Bahrain AWS.

But you are entitled to your expensive opinion. Some of us just don't buy it is all.

You seem to have misunderstood. What you said is exactly my argument. I am with you :).

The parent commentator is under the illusion that AWS automatically means security and scale and reliability.

I was merely pointing out to him that Iranian attacks must serve as a wake up call for him.

What use is data that is never read unless it is for redundancy, disaster recovery, legal, or audit purposes, etc.

Yes you can make the argument for that specific use case.

For everyday use case, using s3 as your primary storage is costly and is not at all ideal.

I find Cloudflare R2 to be much cheaper as there are zero egress fees irrespective of data size. One is only billed on the count of requests with 10 million free download requests per month (check pricing for precise info).

If you do a clever bit of caching work in your app like we have with our apps Slyp and SlypBusiness, you could even make it insanely cheap.

We have a file manager that is ultimately responsible for images, files, videos and whatnot. It loads the images/files from the downloaded local cache when requested by a feature in the app.

A standard feature uploads and downloads using signed urls obtained from the backend service. The manager increments the file's version in the backend on each successful upload. For download, the manager compares the version against the locally cached version. If there is an update, the new file is downloaded in the background and overwrites the local cache and notifies all features using the file inside the app.