danappelxx

There is natural incentive for engineers working on a project to keep Claude skills up to date. I cannot say the same for general documentation.

GitHub API is actually quite tricky here because there is a different between “comment” and “review” and “review comment” (paraphrasing, I don’t remember the details). So it’s not as simple as one API call that grabs the markdown. Of course you can write a creative one-liner to extract what you need, though.

If the DNS resolution call blocks the thread, then you need N worker threads to perform N DNS calls. Threads aren’t free, so this is suboptimal. OTOH some thread pools e.g. libdispatch on Apple operating systems will spawn new threads on demand to prevent starvation, so this _can_ be viable. Though of course this can lead to thread explosion which may be even more problematic depending on the use case. In libcurl’s situation, spawning a million threads is probably even worse than a memory leak, which is worse than long timeouts.

In general, what you really want is for the API call to be nonblocking so you’re not forced to burn a thread.

Mirrors my experience. IPv6 issues are frustratingly hard to triage and reproduce, lots of “works on my machine” etc.

This is an interesting point. Hangs usually cost $ from user experience, with serverless they cost $ from compute. All the more reason to set strict deadlines on all API calls!

Took the same class at UCI (with Prof Anton Burtsev). Best class I ever took.

Yup, exactly. Phones change wifi networks, routers drop packets, load balancers get overloaded. Hard to fully eliminate tail latencies.

Unless your database is in the browser, you are always going to be at mercy of network latencies talking to the backend.

I think you always need loading states to account for slow network, or am I missing something?

“Cabin Noise during Acceleration with Ludicrous Enabled” was by far the most interesting

Generally stems from the philosophy that code is read more than written, and this helps readability.

What do you use instead?

Not that difficult, but it’s still a separate dependency (with python requirements). If the goal here is a Caddy competitor, then IMO it’s missing the mark in terms of “one stop shop”. What’s the killer feature?

Ah, good to know!

It’s becoming standard as a security measure. See: Kata containers, Firecracker VM

I’ll assume the worst case:

- lots of containers running on a single host

- containers are each isolated in a VM (aka virtualized)

- workloads are not homogenous and change often (your neighbor today may not be your neighbor tomorrow)

I believe these are fair assumptions if you’re running on generic infrastructure with kubernetes.

In this setup, my concerns are pretty much noisy neighbors + throttling. You may get latency spikes out of nowhere and the cause could be any of:

- your neighbor is hogging IO (disk or network)

- your database spawned too many threads and got throttled by CFS

- CFS scheduled your DBs threads on a different CPU and you lost your cache lines

In short, the DB does not have stable, predictable performance, which are exactly the characteristics you want it to have. If you ran the DB on a dedicated host you avoid this whole suite of issues.

You can alleviate most of this if you make sure the DB’s container gets the entire host’s resources and doesn’t have neighbors.

IMO if you’re concerned about performance and yet are deploying databases this way — mmap should not even be on the radar.

Who is deploying databases in containers?

Agreed, but if you’re asking for a solution that will generate a spec from your code, the more proven path is to generate code from a spec. Gives you more and costs less.

In my opinion the problem is that there’s some APIs that are impossible to represent with OpenAPI — that’s the real challenge they should be solving with this version, not reducing spec line count.

I suspect OpenAPI advocates would argue you should start with the spec and use it to generate both the client and server. This is already a common pattern in other RPC definition languages such as gRPC. You _could_ write a server to match the gRPC spec, but why would you?

does it add support for streams?

Right! Which is why we use (public) short-lived JWTs and (private) long-lived refresh tokens. What’s missing?

Interesting. You already don’t have to worry about revoking JWTs if they’re sufficiently short lived. This gives you the exact level of protection as a short-lived mTLS cert, because if that gets stolen the attacker can continue to establish connections until it expires, unless as you say you revoke the certificate. So clearly I am missing something.

How does this approach practically differ from using short-lived JWTs+TLS?

This is incorrect, value types are not referenced counted in Swift. If a value type contains a reference type member (usually an anti pattern!), then that member’s reference count is indeed incremented when the value type is copied. But it is not accurate to claim that value types themselves have reference counts.

There’s partial support which is under active development.

https://github.com/apple/swift/tree/main/docs/CppInteroperab...

https://forums.swift.org/t/swift-and-c-interoperability-work...

Unsurprisingly, this is out of touch. Juul has been dead among teenagers for years, basically immediately after the FDA banned flavors. Its now been replaced by, as far as I can tell, completely unregulated disposable e-cigarettes which have been growing in price, size, and strength. Ask your interns when the last time they saw a Juul at their college was.

To clarify:

- I was talking about ACID guarantees across databases (ie across users) - I was talking about aggregations across databases (ie across users)

Of course working inside one database works as you would expect it to. My point was that this pattern of database-per-user seems to be a totally different design than people have used with traditional n-tier designs.

Good point about NoSQL! But, wasn’t part of the reason MongoDB fell out of favor because it was lacking consistency?

Hold on, doesn’t one-database-per-user totally absolve all ACID guarantees? You can’t do cross-database transactions (to my knowledge), which means you can end up with corrupted data during aggregations. What am I missing?

Really cool work. My impression after reading the article is that it’s significantly inspired by SwiftUI, but without the magic annotations (@State, @Binding, @EnvironmentObject, @StateObject, etc.). It will be interesting to see how Rust handles the fully-statically-typed view tree, which has been really pushing the limits of the Swift compiler.

Question for the author: perhaps I missed it, but how do you plan to handle view trees that change based on state (ie SwiftUI’s IfElseView + viewbuilder)?