quacker

Admitting the status of his original shares is not a good look either way. Either he sold, and the additional shares aren't technically worth $1B because he'd have sold them too. Otherwise he held, and is another unsatisfied greedy billionaire in the world.

The idea is: the package maintainer pushes a final version of the old package that is a shim, and which has a deprecation notice. The shim imports the new package, and forwards all calls to the new package (and I suppose type aliases and variable aliases as well). The shim includes `//go:fix inline` annotations on all exported symbols, so that when users run `go fix` it rewrites their code to use the new package, by inlining their usages of the old package (which is now simply a shim that references the new package).

Not perfect. There is still a bit of a discoverability problem. Not all tooling warns on deprecated packages/functions (go toolchain doesn't, but gopls and staticcheck do). And users need to know to run `go fix`.

1: https://go.dev/blog/inliner#example-renaming-ioutilreadfile

What actually is it and what value do I get out of it?

Reading the linked blog posts: It's a layer on top of git for CRDT-based collaborative editing that captures addressable code deltas + agent conversations. I could have real-time collaborative humans + agents development and can resume any agent conversation from any point in history, because it is all stored (powered by DeltaDB). I guess?

I actually might want this, but wouldn't know it from the landing page.

I don’t need “a varied sense of taste” to budget and do simple math to determine the membership is worth it.

Babies don’t need “a varied sense of taste” to use diapers purchased from Costco in bulk at a great price.

Do I lack a “varied sense of taste” when I buy ingredients from Costco, like chicken thighs and rice and eggs and olive oil, and cook them at home?

And delisting a game from a store isn't a license pull. Delisting prevents new purchases of the game, but owners of a game prior to delisting can still download and play[2]

For example, even though Sony is closing the PS3 store to new purchases after 20 years, existing owners of digital games can still download their digital copies. So my entire PSN digital library for the past 20 years is still downloadable and playable. Same for Steam.

I love GOG, and prefer a DRM-free digital copy for PC that I can backup redundantly, as it is the most future-proof option, IMO. Physical media can get damaged or lost and digital storefronts won't last forever (even Steam could shut down one day). Even my hard drives can fail and lose data. But even so, when I purchase a digital license for a game, I have good confidence it will be playable for years and years to come.

---

1. Of course, many online multiplayer games have had their servers shut down, after which the game becomes effectively unplayable. But this is a separate problem that isn't solved by choosing physical over digital media.

2. As long as the digital storefront exists and as long the console hardware still works, if I purchased it for a console.

The revision must be an ancestor of one of the module repository’s branches or tags. This prevents attackers from referring to unapproved changes or pull requests.

1: https://go.dev/ref/mod

No, they are usually pinned to a git tag, which is usually a version string representing a released version. And the tag is locked to a hash to detect if the tag is later modified.

Reasons: The Python 2->3 transition, asyncio package, async/await function coloring, abysmal package management, the GIL and poor performance, breakage from version to version. I'm ambivalent on type hints. I regret nothing, especially after seeing how the GC and JIT projects have been handled.

Golang addresses all of my problems with Python. Native code, good performance, an exceptional toolchain, a built-in package solution, great concurrency support, and they prioritize compatibility across versions. AI is good at writing Golang (as good as any other language I've tried), and AI benefits a lot from static types.

Ballparking: 200 events/workflow, 200 workflows/per day and assuming 1 event = 1 cloud action[1], that is 1.2M or so actions per month. The $100/month plan includes 1M actions each month, and even the pay-as-you pricing when you exceed that is $50 per 1M actions[2].

Temporal Cloud seems extremely cheap for your use case, even if I'm off by a factor of 10. Is there a catch? You still need infra to run your Temporal workers, and I assume there are storage and other costs, but I assume action usage is the majority of it.

1. Not sure exactly what constitutes an "Action". At a glance, seems like most events have a corresponding action(?) and a subset of those actions are actually billable(?)

2. https://docs.temporal.io/cloud/pricing#payg-action-pricing

Same laptop, and my contrived test was having it fix 50 or so lint errors in a small vibe-coded C++ repo. I wanted it to be able to handle a bunch of small tasks without getting stuck too often.

GPT OSS 20B was usable but slow, and actually frequently made mistakes like adding or duplicating statements unnecessarily, listing things as fixed without editing the code, and so on.

Qwen 3.5 9B with Opencode was much faster and actually able to work through a majority of the lint warnings without getting stuck, even through compaction and it fixed every warning with a correct edit.

I tried 4bit MLX quants of Qwen 3.5 9B but it eventually would crash due to insufficient memory. I switched to GGUF, which I run with llama.cpp, and it runs without crashing.

It is absolutely not comparable to frontier models. It’s way slower and gets basic info wrong and really can’t handle non trivial tasks in one go. I asked it for an architecture summary of the project and it claimed use of a library that isn’t present anywhere in the repo. So YMMV, but it’s still nice to have and hopefully the local LLM story can get much better on modest hardware over time.

Doesn't mean it's not overpriced, but that's one reason and you can get a used TI-83/84 for like $30 or less. They pretty much never break.

-----

1. Okay, the Casio can QR-code-link you to a graph, but if I have internet/smartphone there are better graphing tools anyway, like Desmos.

Code may not be the bottleneck, but writing it absolutely does consume time.

Especially with solo game dev, I can prototype ideas, try them out, and then refine or scrap them at a rate I could never do without AI. This type of experimentation is a perfect use-case for AI. It’s actually super fun, and if I pay attention and give the AI decent instructions, I don’t really lose out on code quality.

“Good” bread according to the majority and bread that is specifically up to your standards are probably two very different things.

My grocery store’s bakery sells many types of fresh bread: sourdough, white, rye, croissants, ciabatta, buns, rolls, bagels, and so on. Many grocery stores in my city have a bakery section with a selection of fresh bread like this. (Even Walmart I think, but I don’t shop there).

It’s not the best bread I’ve ever eaten, but it’s fresh, good, tasty bread. It’s not “mushy garbage” and it’s not “cake” like you described in your original comment. It’s not “weird specialty hipster” bread. It’s just simple, real, fresh bread.

(Not actually sure about the price history of the family plan or when family was introduced. I was originally on the individual plan and it was $35 then, and switched to the family plan in 2022. I don’t think prices have changed though)

I like 1Password a lot. I've used it for 10 years. It's never lost a single thing, and I don't recall any downtime that impacted me. It's easy to setup and 99% hassle free. Works on my various device types (windows, mac, ios). It supports passkeys and 2FA codes. I like having shared and private vaults. I love the ability to share an auto-expiring, one-time-view link to a password. And the billing is a simple subscription fee.

I could do without some bloat. Watchtower feels like an enterprise need that is otherwise low-value and (by default) noisy for individuals/families. I obviously don't need "AI" forced into my password manager. I didn't love the version 7 to 8 transition that required a new app/extension to be installed. But all of that is really not so bad.

So yeah, I don't feel like I'm getting any additional value that justifies the price increase, but it's still more than worth it for me.

She has posted publicly about her condition.

He is 25 years old and trying to cope with a hard life event. Let’s not act like it doesn’t affect him. It affects everyone around her and the strong reaction from him is really a positive reflection on her, isn’t it?

His post is written and edited to garner sympathy and support. I don’t mind that for a naive but noble cause. And there is always a slim chance of success.

I’m not advocating for anything (certainly not optimizing for calories per dollar).

My point is just that the article has no data. It says a Japanese lunch is cheap and a US lunch is expensive and doesn’t consider what you actually get for the money. It assumes the US lunch is a worse deal, but I suspect it’s really not if you adjust the price for the amount of food.

Google’s model will reportedly run on Apple’s own servers, which in practice means that no user data will be shared with Google. Instead, they won’t leave Apple’s Private Cloud Compute structure.[1]

1: https://9to5mac.com/2025/11/05/google-gemini-1-billion-deal-...

A rice bowl at Chipotle, for example, is not unhealthy (rice, beans, meat, vegetables). Plenty of restaurant food in the US is perfectly healthy (or, you can look at nutrition facts to know if it is). And if I can take a single US portion size and split it into two lunches that are Japanese-sized portions, then maybe we're getting the same amount food per dollar.

And on the "healthy" point: The article doesn't discuss nutrition facts at all or refer to any specific meals or dishes.

They link to an article concerning the price of Japanese bowls, that mentions "a regular-sized bowl of rice with beef from Japanese fast food chain Yoshinoya, which costs around 468 yen (S$4.25)." I don't know Japanese so it's hard for me to find nutrition information about that particular dish, but I suspect that a beef bowl is high in saturated fat, cholesterol, and sodium (because most stir-fried beef is higher in these things). Is that healthy? Japan as a country has higher sodium intake than the US. Is that healthy? And so on. I suspect a big factor of the "health" of these lunches is that portion sizes are just smaller than in the US (but I have no data).

Yes, a bowl at chipotle in the US might be 2x the price (more, probably) of a Japanese bowl, but it matters if I am getting 2x the calories also.

And there are foods in the US that are technically as cost effective, although maybe not as nutritious, like pizza which they mention, that can be around $1-$3 per slice. (Not my first choice for a lunch, but I could pickup a large 3 topping dominos pizza for $10 and make 3-4 lunches out of it, for example)

Reading through git history should be my last resort to figure something out about the codebase. Important knowledge should be written somewhere current (comments, dev docs, etc). If there is a random value being appended to a url, at least a code comment explaining why so I don’t even have to git blame it. Yes, these sources of knowledge take some effort to maintain and sure, if I have a close-knit team on a smaller codebase, then git history could suffice. But larger, long-lived codebases with 100s of contributors over time? There’s just no possible way git history is good enough. I can’t ask new team members to read through thousands of commits to onboard and become proficient in the codebase (and certainly not 5x-10x that number of commits, if we are not squashing/rebasing feature branches into main. Although, maybe now an LLM can explain everything). So I really need good internal/dev documentation anyway, and I want useful git history but don’t care so much about preserving every tiny typo or formatting or other commit from every past feature branch.

Also iirc, with github, when I squash merge via the UI, I get a single squashed commit on main and I can rewrite the commit message with all the detail I like. The PR forever retains the commit history of the feature branch from before the squash, so I still have that feature branch history when I need it later (I rarely do) so I see no reason to clutter up history on main with the yucky feature branch history. And if I tend toward smaller PRs, which is so much nicer for dev velocity anyway, even squashed commits can be granular enough for things like bisect, blame, and so on.