mkarrmann

> In case you haven't seen it before... > Shares amazing link there was a 0% chance I'd ever see in my life if not for this comment

Ty, all good points

I'm pretty confused by this article.

It says docker compose is at the "wrong-level of abstraction", but I kept feeling the author was instead expecting docker compose to solve different problems that it was ever meant to solve.

In fact, they seem to be expecting a highly-opinionated, high-level interface which solves problems that I don't think anyone using docker compose in prod should even be worried about.

A lot of concerns seem to be around avoiding spinning up duplicate instances of reverse proxies, databases, and caches. First of all, why is this a concern? Idle threads have basically no impact on a system, so this generally isn't a concern. This is a nuanced and context-dependent issue, but generally it won't even make the list of top-100 performance bottlenecks for most applications. Yet the article takes for granted that the benefits of solving this problem outweigh the many cons of coupling them together.

Even if you wanted to enforce your applications sharing a postgres instance under the hood, why would you want that to be black-magic performed by the container orchestrator?

Other stuff like DB backups just don't seem like issues docker compose users have. If you need to orchestrate across multiple nodes in order to meet your SLOs, then don't use docker compose.

Finally, it seems like the actual solution is significantly under-discussed. I both have tons of questions about how it's supposed to work, and I see lots of shortcomings with the parts that I do understand.

Beyond the specific issues I see, the fundamental attitude seems to be "force everyone to architect their applications in a very specific way, and don't even try to support any use cases which fall outside of it". You need a damn good reason to be that opinionated about these sorts of things, and it by definition will only work well in specific contexts. I'd be interested to read an article which tried to articulate why such an opinionated API would improve SDLC-considerations over docker-compose, but I don't think that's the article I just read.

I actually like that analogy. It's somewhere in between. Enough that LLMs can help in many ways, but the current models are still far away from doing everything.

Is most code being written the equivalent of high-art or Shutterstock?

Why do you think a series which absolutely converges but whose first few terms are a poor approximation is related to a series which diverges but whose first few terms match the empirically expected value?

Not only is it a stretch to wonder about parallels between a basic Calc II concept and Quantum Field Theory, but is seems like the exponential function is the exact opposite of the example you provided.

I've recently taken to calling it llama.cpp plus ollama

They specifically said "compiling only proves correctness for the code being compiled, and for the properties covered by the type system".

What makes you think that the "selling point" of AI today is that it is significantly better at everything than humans?

Never forget that the world economy is probably being held together by a handful of these.

I believe they're being rhetorical, and agree that there are good reasons to use elasticsearch over postgres.

There's a difference between an accent and incorrect pronunciation, and using the wrong tone is the latter.

That's a good point.

I share that intuition, although I don't see any reason to trust the intuition of an outside (either myself or presumably yourself) making 2 second back-of-envelope calculations of that of the Alphabet board.

Why's it so hard to believe that a worse CEO for one year would result in a 0.01% lower market cap? Given that framing, 200m is a very drastic under estimation.

Neat :)

I personally feel like upgrading a database should be an explicit admin process, and isn't something I want my db container entrypoint automagically handling.