The social connectivity and discoverability in github is a big reason many people use it. Can't say how many, but it is.

Migrate/optimize later when you're actually reaching scale is a perfectly reasonable approach.

In fact, if you have a decent abstraction or standard in place (e.g. S3 API or repository pattern) you can swap it out in place.

It's 90% AI, but that 90% was almost entirely boilerplate and would have taken me a good chunk of time to do for little gain other than the fact I did it.

Even then, a solid validation/parsing library like Zod is a better choice than casting, it is much less error prone at ensuring you have the right type applied.

Beyond that boundary, casting with `as unknown` is a massive code smell and often introduces any further use of that data to invalid type errors. I'll refer to this as "force casting", because simply casting "x as T" with sufficient strictness configured will still fail type checking if x is not compatible with T, and that can be fine for certain cases like reducing a complex type or giving an inferred parser type a form that fits your domain types.

Developers that force cast too readily can end up creating hundreds or even thousands of type errors in the codebase over time, and they are pretty quickly revealed once you peel away the casting. The same is true when starting from an `any`, where every reference thereon is equivalent to a force cast.

There can be some complex typing scenarios that do require it, but even then a good type guard works better even if certain cases can be semantically equivalent, you can write tests around guards as they're just functions, ensuring some logical correctness to the typing.

The simplest but maybe odd way to judge whether a casting is used the wrong way is to ask "are you lying to the type system?". If so, how can you better portray that type correctly (validation that determines a correct type for you (e g. Zod) or type guards).

name: A name: Al name: Ale name: Alex

Which would suggest you are getting unfinished strings out in the stream.

Newline Delimited JSON

TIL

XDG may not be perfect but wiping related data for apps following it is straightforward. There are a few directories to delete instead of 1, but still consistently structured at least.

Their docker images were 11-35GB. Using the nix dockerTools approach would have resulted 100-300MB layers. These also may not even cache well between tags, though that's my intuition not knowledge. Especially if that's true, it wouldn't have improved the overall pull time issues they were having, which was 70-210s or image pull time on many new builds.

In their case they added a sidecar container which was actually an init container, which runs before the primary container of the pod runs. They did utilize root privileges to perform things like bind mounting of nix store paths into the running container which made it possible for the container to run software provided in the /nix/store available from those bind mounts. This also meant both the Kubernetes hosts and containers did not require the nix daemon, the nix-sidecar running within the pod orchestrated pulling derivations , binding them, and running garbage collection at low priority in the background to ensure host SSDs don't run out of storage, while still allowing referenced derivations in the cluster to persist, improving sync time where the SSD may already contain all necessary derivations for a new pod startup.

so, maybe SSHoQ or SoQ

soq reads better for the CLI I suppose.