> Those of us building software factories must practice a deliberate naivete
This is a great way to put it, I've been saying "I wonder which sacred cows are going to need slaughtered" but for those that didn't grow up on a farm, maybe that metaphor isn't the best. I might steal yours.
This stuff is very interesting and I'm really interested to see how it goes for you, I'll eagerly read whatever you end up putting out about this. Good luck!
EDIT: oh also the re-implemented SaaS apps really recontextualizes some other stuff I’ve been doing too…
This was an experiment that Justin ran: one person fresh out of college, and another with a long, traditional career.
Even though all three of us have very different working styles, we all seem to be very happy with the arrangement.
You definitely need to keep an open mind, though, and be ready to unlearn some things. I guess I haven’t spent enough time in the industry yet to develop habits that might hinder adopting these tools.
Jay single-handedly developed the digital twin universe. Only one person commits to a codebase :-)
> Or perhaps write a complier for a new language that someone just invented, after writing a first draft of a spec for it.
Hello, this is what I did over my Christmas break. I've been taking some time to do other things, but plan on returning to it. But this absolutely works. Claude has written far more programs in my language than I have.
https://rue-lang.dev/ if you want to check it out. Spec and code are both linked there.
I used to answer security vulnerability emails to Rust. We'd regularly get "someone ran an automated tool and reports something that's not real." Like, complaints about CORS settings on rust-lang.org that would let people steal cookies. The website does not use cookies.
I wonder if it's gotten actively worse these days. But the newness would be the scale, not the quality itself.
Claude Code recently deprecated slash commands in favor of skills because they were so similar. Or another way of looking at it is, they added the ability to invoke a skill via /skill-name.
Yeah, I saw that announcement but still can't figure out what the actual impact is - doesn't change anything for me (my non-skill slash commands still work).
The actual impact is that there should be less confusion in the future about "what's the difference between these two" because there isn't really.
To overly programmer-brain it, a slash command is just a skill with a null frontmatter. This means that it doesn't participate in progressive disclosure, aka Claude won't consider invoking it automatically.
The problem with this is that at the limit, this means "run the precommit on every save of a file," which is not really usually how people think of precommit hooks.
Given jj's rebasing tooling, rewiring precommit into "prepush" feels like the right way forward. There's a bit of a phase transition between commits on your machine and commits that are out in the wild, after all.
For me it's mostly about doing as much of CI locally as feels reasonable to do quickly to save an iteration cycle. But I live in a world of badly configured text editors and the like so I usually have some silly formatting error
Pre commit hooks are complicated because jj just has a fundamentally different lifecycle than git does.
Tools that integrate with git specifically can be tough though, yeah. Some do Just Work, and some very much do not.
I’ve found a “we use jj not git for this project” in Claude.md makes falling back to git rare, but I also tend to incorporate version control into slash commands or skills directly rather than let Claude decide what to do.
I also prefer to manage version management myself directly, even with llm-gen'd CICD elements, so preferring jj hasn't been nearly as costly for me specifically :D
One obvious case where magit isn’t useful as opposed to jj is if you’re not an emacs user.
jj has some additional features over just a nicer UI that I believe magit can’t do, but given that I haven’t used magit yet I am not 100% sure of how that comparison is exactly.
It uses it when you use the git backend, but not when you don’t.
Right now, the only other backend is at Google, so it’s not practical for most people. But it’s not an inherent part of jj, and that’s really important, actually.
Yes, at the moment it does not. But a well factored system is important for gaining future benefits. For example, I work at a startup that is building jj related tooling, and that the git stuff is separated out cleanly is what enables us to build better things than if it were so tied to git.
To complete the analogy, given that we haven't launched, yes, this is a theoretical benefit for now. But that doesn't mean it's useless. jj is still pre-1.0 software, there's a lot more work to do, and more interesting things coming down the pipeline. That matters, even if it's not relevant to every potential user just yet.
Not working on it (yet), but I wish the jj <-> github story was a little more ergonomic.
Additionally, I am really missing support for stacked diffs, ie, easily pushing a number of commits into one PR on github each such that they all show their incremental diff.
ezyang's gh stack was pretty useful, if a little bit fragile [0]
and graphite.dev is also very nice, but paid software with a strong VC based motivation to become everyone's everything instead of a nice focused tool.
https://github.com/LucioFranco/jj-spr is one way to get stacked diffs on GitHub with jj, but also GitHub has at least claimed on X that native stacked diffs is coming so we'll see how that goes!
Rust tags every &mut T and every &T with the equivalent of restrict except for when the T transitively contains an UnsafeCell<T>. Types like Arc<T> and Rc<T> are built on top of UnsafeCell<T>.
Don’t use shared ownership? You get the semantics you want. It’s the norm for the vast majority of things.
Thanks for the answer, that sounds reassuring. I have another question, from what you said, it sounds like you remove restrict from the whol argument, but technically, afaict, the Rust borrow rules still prevent anything inside those structs getting aliased, with the exception of the stuff inside UnsafeCell<> (even with Rc<> the underlying value cannot be aliased, only the reference counter).
Does Rust/LLVM track aliasing to this degree, or is it all or nothing, like if you have a UnsafeCell anywhere, the whole type is excluded from restrict?
I am not sure off the top of my head, to be honest. https://news.ycombinator.com/item?id=46616616 was a thread where I was talking about this sort of thing previously, you could probably adapt those code examples and get an answer.
A few things. Shared identity is one of them. Another is that applications can understand each other's data and mix them together, if they wish, or keep them separate, if they wish. An instagram-like client can read the posts made by the microblogging client and re-use posts that include images, for example. Same goes with the social graph: re-use one from another application, or create your own.
> Those of us building software factories must practice a deliberate naivete
This is a great way to put it, I've been saying "I wonder which sacred cows are going to need slaughtered" but for those that didn't grow up on a farm, maybe that metaphor isn't the best. I might steal yours.
This stuff is very interesting and I'm really interested to see how it goes for you, I'll eagerly read whatever you end up putting out about this. Good luck!
EDIT: oh also the re-implemented SaaS apps really recontextualizes some other stuff I’ve been doing too…
reply