alwillis

> Sure wish hg had won.

To me, it's more like GitHub won; Git came along for the ride.

Back in the day when companies evaluated Git and Mercurial (Facebook, Google, Microsoft), they decided Mercurial was better. Mozilla used Mercurial for a long time until switching to Git fairly recently.

But once GitHub took off and became the center of gravity for developers, it became the de facto standard.

It also explains why there have been several attempts (Sapling, JJ) to use Mercurial's semantics as a front-end for Git.

> Sapling and JJ can sort it out, the outside world will only care for one of them.

I was immediately intrigued when I learned that JJ has revsets [1], just like Mercurial.

[1]: https://docs.jj-vcs.dev/latest/revsets/

> I'm so glad git won the dvcs war. There was a solid decade where mercurial kept promoting itself as "faster than git".

It wasn't the Mercurial team saying it was faster than Git; that was Facebook after contributing a bunch of patches after testing Mercurial on their very large mono-repo in 2014 [1]:

For our repository, enabling Watchman integration has made Mercurial’s status command more than 5x faster than Git’s status command. Other commands that look for changed files–like diff, update, and commit—also became faster.

In fact they liked Mercurial so much they essentially cloned it to create their own dvcs, Sapling [2]. (An aside: Facebook did all of this because it was taking too long getting new engineers up to speed with Git. Shocker.)

Today, most of the core of Mercurial has been rewritten in Rust; when Facebook did their testing, Mercurial was nearly 100% Python. That's where the "Mercurial is slow" thing came from; launching a large Python 2.x app took a while back in the day.

I was messing with an old Mercurial repo recently… it was like a breath of fresh air. If I can push to GitHub using Mercurial… sign me up.

[1]: https://engineering.fb.com/2014/01/07/core-infra/scaling-mer...

[2]: https://sapling-scm.com/

Most modern terminals have a built-in multiplexing anyway. When you use tmux, you're essentially using a terminal emulator on top of a terminal emulator.

> While that paper praises the Apple advantage in SSD speed, which allows a decent performance for inference with huge models, nowadays SSD speeds equal or greater than that can be achieved in any desktop PC that has dual PCIe 5.0 SSDs, or even one PCIe 5.0 and one PCIe 4.0 SSDs.

Apple’s advantage is their unified memory architecture where the CPU, GPU and Neural Engine share the same memory and the SSD is directly connected to the SoC--less latency than PCIe. Memory bandwidth starts at 300+ GB/s.

> We still aren't going to be putting 200gb ram on a phone in a couple years to run those local models.

You can already buy an iPhone with 2 TB of storage. The CPU, GPU and Neural Engine all share the same pool of RAM and the SSD is directly connected to all of this. You won’t need 200 GB of RAM to run local models when you essentially have 500 GB of virtual memory.

Agreed. Apple is sells an iPhone Pro Max with 2 TB of storage.

> I’ve got many catholic relatives that describe themselves as vegetarians and eat fish

Those are pescatarians.

It's like how a tomato is a fruit, but it's used as a vegetable, meat has traditionally been the flesh of warm-blooded animals. Fish is the flesh of cold-blooded animals, making it meat but due to religious reasons it’s not considered meat.

Been on the Jekyll bandwagon for a long time now; it's my go-to static site generator.

AI is predicted to continue eating SaaS: https://www.bain.com/insights/why-saas-stocks-have-dropped-a...

> 1. We pay for saas, so we don't have to manage it. If you vibe-code or use these AI things, then you are managing it yourself.

> 2. Most Saas is like $20-$100/month/person for most Saas. For a software engineer, that maybe <1h of pay.

    |Segment                   |Median Enterprise Price                   |
    |--------------------------|------------------------------------------|
    |Mid-market                |~$175/user/month                          |
    |Enterprise (<100 seats)   |~$470/seat/month implied (~$47K ACV)      |
    |Enterprise (100-500 seats)|~$312–$1,560/seat/month range (~$156K ACV)|

Enterprise contracts almost always include a platform fee on top of per-seat costs (67% of contracts), plus professional services that add 12–18% of first-year revenue.

So for a lot of companies, it's worth using AI to create a replacement.

Cheaters: https://brettterpstra.com/projects/cheaters

> At this point perhaps a million person-years have been sacrificed to the semantically incoherent shit UX of git. I have loathed git from the beginning but there's effectively no other choice.

Yes! We mostly wouldn’t tolerate the complexity and the terrible UX of a tool we use everyday--but there's enough Stockholm Syndrome out there where most of us are willing to tolerate it.

> More than killer AI I'm afraid of Anthropic/OpenAI going into full rent-seeking mode so that everyone working in tech is forced to fork out loads of money just to stay competitive on the market.

You should be more concerned about killer AI than rent seeking by OpenAI and Anthropic. AI evolving to the point of losing control is what scientists and researchers have predicted for years; they didn’t think it would happen this quickly but here we are.

This market is hyper competitive; the models from China and other labs are just a level or two below the frontier labs.

> They should just say they'll never release a model of this caliber to the public at this point and say out loud we'll only get gimped versions.

That’s not going to happen. If you recall, OpenAI didn’t release a model a few years ago because they felt it was too dangerous.

Anthropic is giving the industry a heads up and time to patch their software.

They said there are exploitable vulnerabilities in every major operating system.

But in 6 months every frontier model will be able to do the same things. So Anthropic doesn’t have the luxury of not shipping their best models. But they also have to be responsible as well.

> I struggle to believe that a ton of seemingly intelligent software engineers are too dumb to figure out how to use Claude code to get reliable results.

They're not dumb, but I'm not surprised they're struggling.

A developer's mindset has to change when adding AI into the mix, and many developers either can’t or won’t do that. Developers whose commits that look something like "Fixed some bugs" probably aren’t going to take the time to write a decent prompt either.

Whenever there's a technology shift, there are always people who can't or won't adapt. And let's be honest, there are folks whose agenda (consciously or not) is to keep the status quo and "prove" that AI is a bad thing.

No wonder we're seeing wildly different stories about the effectiveness of coding agents.

They seem to know what they’re doing. Anthropic entered 2025 with a run rate of $1 billion; the run rate for March 2026 is estimated at $19 billion.

Internal projections show the company reaching cash-flow break-even in 2028, after stopping cash burn in 2027.

They’ve already implemented several of the features that put OpenClaw on the map.

I think the point the author is trying to make is dealing with environment variables was a solved problem 40+ years ago on FreeBSD and other Unix-like systems.

And that we shouldn't need to download something like dotenv to address something the operating system should handle.

> On your lan, you really want to be doing ".local" / ".lan" / ".home".

The "official" is home.arpa according to RFC 8375 [1]:

    Users and devices within a home network (hereafter referred to as
    "homenet") require devices and services to be identified by names
    that are unique within the boundaries of the homenet [RFC7368].  The
    naming mechanism needs to function without configuration from the
    user.  While it may be possible for a name to be delegated by an ISP,
    homenets must also function in the absence of such a delegation.
    This document reserves the name 'home.arpa.' to serve as the default
    name for this purpose, with a scope limited to each individual
    homenet.

[1]: https://datatracker.ietf.org/doc/html/rfc8375

Yes, I configured VS Code to use Monaspace a while ago.

Also terminal apps like Ghostty, Wezterm.

I’ve been using Monaspace with Neovim for at least a year.

"The file has no permissions model. No encryption. No audit trail. It is a sticky note on a monitor, formatted as UTF-8."

I’ll have to give this a shot.

One possibility: Claude Code subagents get their own 1 million token context window; should be better with large JSON files vs. having everything in the same context window.

Agreed.

AI is better at writing prompts than most humans. It requires work and lots of developers don’t think getting good at prompting actually matters.

At least half of the complaints I see on HN boil down to the person's prompts suck. Or the expectation that AI can read their mind.

Mushroom. Since when is a mushroom a buddy?

Sounds awesome! Looking forward to trying it out.

> but if there is a deterministic option, why would you choose something that might give you the wrong answer?

Claude Code can use jq if it's installed on your system. Also, the data transformation is usually part of a larger workflow where an LLM is being used. And honestly, Claude is going to know jq better than 95% of developers who use it. jq can do a lot of things but it’s not the most intuitive tool to learn.

An obvious best practice is to have the LLM use existing tools to confirm the correctness of its output.

Claude Code hooks are deterministic; the agent can’t bypass them [1].

For example you force a linter to run or for tests to run.

Claude Code defaults to running in a sandbox on macOS and Linux. Claude Cowork runs in a Linux VM.

[1]: https://code.claude.com/docs/en/hooks-guide