HN user

tuhgdetzhh

239 karma
Posts0
Comments79
View on HN
No posts found.

If you follow the jurisdictional trail in the post, the field narrows quickly. The author describes a major international diving insurer, an instructor driven student registration workflow, GDPR applicability, and explicit involvement of CSIRT Malta under the Maltese National Coordinated Vulnerability Disclosure Policy. That combination is highly specific.

There are only a few globally relevant diving insurers. DAN America is US based. DiveAssure is not Maltese. AquaMed is German. The one large diving insurer that is actually headquartered and registered in Malta is DAN Europe. Given that the organization is described as being registered in Malta and subject to Maltese supervisory processes, DAN Europe becomes the most plausible candidate based on structure and jurisdiction alone.

Since MCP is a common language for all agents at Stripe, not just minions, we built a central internal MCP server called Toolshed, which hosts more than 400 MCP tools spanning internal systems and SaaS platforms we use at Stripe.

Are there ecisting open source solutions for such a toolshed?

One way to sharpen the question is to stop asking whether C is "fundamental" and instead ask whether it is forced by mild structural constraints. From that angle, its status looks closer to inevitability than convenience.

Take R as an ordered field with its usual topology and ask for a finite-dimensional, commutative, unital R-algebra that is algebraically closed and admits a compatible notion of differentiation with reasonable spectral behavior. You essentially land in C, up to isomorphism. This is not an accident, but a consequence of how algebraic closure, local analyticity, and linearization interact. Attempts to remain over R tend to externalize the complexity rather than eliminate it, for example by passing to real Jordan forms, doubling dimensions, or encoding rotations as special cases rather than generic elements.

More telling is the rigidity of holomorphicity. The Cauchy-Riemann equations are not a decorative constraint; they encode the compatibility between the algebra structure and the underlying real geometry. The result is that analyticity becomes a global condition rather than a local one, with consequences like identity theorems and strong maximum principles that have no honest analogue over R.

I’m also skeptical of treating the reals as categorically more natural. R is already a completion, already non-algebraic, already defined via exclusion of infinitesimals. In practice, many constructions over R that are taken to be primitive become functorial or even canonical only after base change to C.

So while one can certainly regard C as a technical device, it behaves like a fixed point: impose enough regularity, closure, and stability requirements, and the theory reconstructs it whether you intend to or not. That does not make it metaphysically fundamental, but it does make it mathematically hard to avoid without paying a real structural cost.

Slop Terrifies Me 5 months ago

Historically, every major general-purpose technology followed the same trajectory. Printing reduced the quality of manuscripts while massively increasing access. Industrialization replaced craftsmanship with standardization. Early automobiles were unreliable and dangerous compared to horse-drawn transport, yet they won because they were sufficient and scalable. The internet degraded editorial standards while enabling unprecedented distribution. None of these shifts reversed. They stabilized at a new equilibrium where high quality persisted only in niches where it was economically justified.

Yes, and that constraint shows up surprisingly early.

Even if you eliminate model latency and keep yourself fully in sync via a tight human-in-the-loop workflow, the shared mental model of the team still advances at human speed. Code review, design discussion, and trust-building are all bandwidth-limited in ways that do not benefit much from faster generation.

There is also an asymmetry: local flow can be optimized aggressively, but collaboration introduces checkpoints. Reviewers need time to reconstruct intent, not just verify correctness. If the rate of change exceeds the team’s ability to form that understanding, friction increases: longer reviews, more rework, or a tendency to rubber-stamp changes.

This suggests a practical ceiling where individual "power coding" outpaces team coherence. Past that point, gains need to come from improving shared artifacts rather than raw output: clearer commit structure, smaller diffs, stronger invariants, better automated tests, and more explicit design notes. In other words, the limiting factor shifts from generation speed to synchronization quality across humans.

I think the productivity question hinges on what you count as the language versus the ecosystem. Very few nontrivial games are written in "just C". They are written in C plus a large pile of bespoke libraries, code generators, asset pipelines, and domain-specific conventions. At that point C is basically a portable assembly language with a decent macro system, and the abstraction lives outside the language. That can work if you have strong architectural discipline and are willing to pay the upfront cost. Most teams are not.

I agree on C++ being the worst of both worlds for many people. You get abstraction, but also an enormous semantic surface area and footguns everywhere. Java is interesting because the core language is indeed small and boring in a good way, much closer to C than people admit. The productivity gains mostly come from the standard library, GC, and tooling rather than clever language features. For games, the real disagreement is usually about who controls allocation, lifetime, and performance cliffs, not syntax.

Terraform in combination with Claude Code is actually quiet managable. Yes it generates much code, but you have great detail of what is actually going on, there is no hidden abstraction layers on top.

I think that the current test suite is far too small. For the Claude Code codebase, a sensible next step would be to generate thousands of tests. Without that kind of coverage, regressions are likely, and the existing checks and review process do not appear sufficient to reliably prevent them. My request is that an entirely LLM-written feature should only be eligible for merge once all of those generated tests pass, so we have objective evidence that the change preserves existing behavior.

I’m experiencing a similar issue hosting MCP Server on Cloud Run with scale-to-zero for cost optimization. As far as I know, Cloud Functions v2 and Cloud Run both are container-based, and they tend to have noticeable startup times.

In contrast, AWS Lambdas, which run on Firecracker, have sub-second startup latency, often just a few hundred milliseconds.

Is there anything comparable on GCP that achieves similar low latency cold starts?

If tested various Posix FS projects over the years and everyone has their shortcomings in one way or the other.

Although the maintainers of these projects disagree, I mostly consider them as a workaround for smaller projects. For big data (PB range) and critical production workloads I recommend to bite the bullet and make your software nativley S3 compatible without going over a POSIX mounted S3 proxy.