sunshowers

A very important thing about constraints is that they also liberate. TUIs automatically work over ssh, can be suspended with ctrl-z and such, and the keyboard focus has resulted in helpful conventions like ctrl-R that tend to not be as prominent in GUIs.

I'm not a professional, but to me it's clear that whether i and -i are "the same" or "different" is actually quite important.

I believe that countries and borders exist as a descriptive fact about the world. But I also believe that it's impossible to square immigration control regimes with any robust notion of freedom and liberty, and also that there isn't room for much disagreement on this specific point once you understand the intrinsic nature of such regimes. See Kukathas, Immigration and Freedom for more.

I know most people (of any nationality, not just Americans) don't understand this, but you and I are not most people. I believe things because it is correct to believe them, not because most people believe them (or not).

edit: to be clear, you can say "immigration control lessens freedom, but I'm willing to give up freedom—both yours and mine—because I value certain things more". That is a reasonable point, though I might as a follow-up probe into the motivation behind that. "I think the government gets to stop you from living with your spouse, but I'm okay with that because XYZ" better have a pretty robust XYZ behind it!

I need you to understand that immigration controls are fundamentally and inherently antithetical to freedom of speech, freedom of movement, and freedom of association. And this applies both to immigrants and to citizens.

Imagine if you needed government approval to live with the one you love! What a completely unreasonable intervention into the private lives of ordinary people. Oh wait, that's the actual reality immigrants live in.

Migrating to a place where people can contribute more to society is both a core tenet of individual liberty and one of the most positive-sum things any human being can do.

But given that you both feign concern over visa holders' working conditions [1], while at the same time advocating for policies that lead to worse working conditions [2], perhaps you just hate freedom and were never acting in good faith in the first place.

[1] https://news.ycombinator.com/item?id=45656527

[2] https://news.ycombinator.com/item?id=45323501

Ah yes, the inevitable future where the only way we'll know to interact with the machine is through persuading a capricious LLM. We'll spend our days reciting litanies to the machine spirits like in 40k.

I talk to one of my doctors over Signal.

Language-specific package managers are a natural outgrowth of wanting portability across platforms.

?

You have to turn rerere on, though, right? I've never done that. I've also never worked with long-running branches — tend to strongly prefer integrating into main and using feature flags if necessary. Jujutsu doesn't have anything like rerere as far as I know.

To be honest I've used rebase-heavy workflows for 15 years and never used rerere, so I can't comment on that (been a happy Jujutsu user for a few years — I've always wondered what the constituency for rerere is, and I'm curious if you could tell me!) I definitely agree in general that whenever you have a cache, you have to think about cache invalidation.

I have an early draft of a blog post about them :) as a source control expert who built both these systems and tooling on top of them for many years, I think they're the biggest and most fundamental reason rebases/linear history are better than merges.

> whether it’s better to rebase a work branch onto the main branch, or to pull the changes from the main branch to the work branch.

The problem with this is that the latter has an infinitely higher chance of resulting in criss-cross merges than the former (which is 0).

LLMs are pretty good at generating and maintaining error enums for you these days.

Do you know what criss-cross merges are and why they're bad?

> If you aren't instantiating a template, then it isn't used, so who cares if it has theoretical errors to be figured out later?

This seems like a very strange argument to me. For a pleasant experience you generally want to report errors as early as possible.

True but you lose out on much of the functionality of templates, right? Also you only get errors when instantiating concretely, rather than getting errors within the template definition.

Note that while C++ templates are more powerful than Rust generics at being able to express different patterns of code, Rust generics are better at producing useful error messages. To me, personally, good error messages are the most fundamental part of a compiler frontend.

It depends. I've been working on a series of large, gnarly refactors at work, and the process has involved writing a (fairly long), hand-crafted spec/policy document. The big advantage of Opus has been that the spec is now machine-executable -- I repeatedly fed it into the LLM and see what it did on some test cases. That sped up experimentation and prototyping tremendously, and it also found a lot of ambiguities in the policy document that were helpful to address.

The document is human-crafted and human-reviewed, and it primarily targets humans. The fact that it works for machines is a (pretty neat) secondary effect, but not really the point. And the document sped up the act of doing the refactors by around 5x.

The whole process was really fun! It's not really vibe coding at that point, really (I continue to be relatively unimpressed at vibe coding beyond a few hundred lines of code). It's closer to old-school waterfall-style development, though with much quicker iteration cycles.

True!

You sound like my teacher in school, after my friend submitted an assignment so good my teacher thought he was cheating.

> Rust should have done exactly one thing and do that as good as possible: be a C replacement and do that while sticking as close as possible to the C syntax.

The goal of Rust is to build reliable systems software like the kind I've worked on for the last many years, not to be a better C, the original goal of which was to be portable assembler for the PDP-11.

> Now we have something that is a halfway house between C, C++, JavaScript (Node.js, actually), Java and possibly even Ruby with a syntax that makes perl look good and with a bunch of instability thrown in for good measure.

I think Rust's syntax and semantics are both the best by some margin across any industrial language, and they are certainly much better than any of the ones you listed. Also, you missed Haskell.

I do actually have this setup going with a Cable Matters adapter [1] + a custom firmware I found [2] and

> chroma/RGB 4:4:4 + HDR + VRR/Freesync + 4k,120hz for their Linux PC on a TV

works great now on my LG C4 TV with Bazzite's gaming mode, though:

* 144Hz is unstable

* 12-bit color is unstable (10-bit works fine), and gamescope doesn't have a way to limit color depth (kwin does), so I had to put in place an EDID override

* in the EDID, limiting the FreeSync range to 60-120Hz (which should still allow frame doubling/tripling) seemed to be better -- the default 40Hz caused a bit of flickering because the AMD driver would drop the refresh rate down to 38.5Hz or so.

Should write about this in more detail.

[1] https://www.amazon.com/dp/B094XR43M5

[2] https://forum.level1techs.com/t/it-is-possible-to-4k-120-hdr...

JavaScript does not have a separation between & and &mut.

I didn't know about that incident before starting at Oxide, but if I'd known about it, it absolutely would have attracted me. I've written a large amount of technical content and not once in over a decade have I needed to use he/him pronouns in it. Bryan was 100% correct.

I'm not sure about research, but I've used LLMs for a few things here at Oxide with (what I hope is) appropriate judgment.

I'm currently trying out using Opus 4.5 to take care of a gnarly code reorganization that would take a human most of a week to do -- I spent a day writing a spec (by hand, with some editing advice from Claude Code), having it reviewed as a document for humans by humans, and feeding it into Opus 4.5 on some test cases. It seems to work well. The spec is, of course, in the form of an RFD, which I hope to make public soon.

I like to think of the spec is basically an extremely advanced sed script described in ~1000 English words.

Jujutsu is not a Git frontend, it is an independent VCS that is compatible with Git. This is important because it has concepts and ideas of its own. It is used entirely independent of Git within Google.

Editions can definitely be made to alter standard library APIs in principle, thought the machinery for that probably needs to be developed a bit. But that's why I qualified my proposal with "if a breaking change is going to happen".

No? Clearly outlining the pitfalls of a proposal is not a threat.

I have separate PCs for gaming and work. The former lives in the living room and the latter by my desk.

Acknowledging that panic safety is a real issue with data structures that mutex poisoning does not solve, I don't think we're going to agree on anything else here, unfortunately. We probably have entirely different experiences writing software -- mutex poisoning is very valuable in higher-level code.