Plausible deniability - The line of attack is in their sessions/prompts data. Just make the prompt pointed enough that the search space is tractable and use your ginormous compute.
> "Of course we don’t know whether that is true"
Yep. Who is verifying these claims? We all know how trustworthy Altman & Co are.
I saw 'the results speak for themselves' but for me this article seemed to have less LLM-ese than some of the more recent obvious LLM prose posted to hackernews. As a reader I think its jarring because you just see a lot of articles purportedly written by different people using a very similar voice. I guess pre-LLM you might see this in a newspaper with very strong editorial oversight. So the phenomena is not completely new but it feels stranger when its not from a single source. It's also kind of sad to see a some people who have written a lot in the past about interesting technical topics in a way that was easy to read to give up their voice and outsource it to an LLM. But given this is basically free labour from the authors it feels a bit ungracious to complain.
My complaint is directed at the Rust Foundation, not the authors, to be clear. Yes, it's free labor, but the Foundation ought to have standards.
I showed Bryan the post while in a meeting room with him, left the room, and a few minutes later heard a very loud, very exasperated primal scream coming from the room!
A few advantages for me, even for the same 5 commands I use over and over:
- undo
- shuffling commits around with squash, split, and rebase is much better than git’s interactive rebase
- make commits without having to come up with a branch name (I might make three versions of the same change in parallel to see how they compare)
I see git is working on adding some of this under the history command. The revset language is really not esoteric: @ is head, @—- is two behind head. That’s about it.
Part of it is that the sorts of shuffling I used to avoid because they were a pain in git (so I didn’t feel I needed them improved) are so easy in jj that I do them all the time.
> - shuffling commits around with squash, split, and rebase is much better than git’s interactive rebase
Can you explain this to me? I feel like Git is pretty easy there.
- select oldest commit to modify
- move the commits around with a mouse or the cursor
- close the editor to apply
Sure, the first step can go away (which is what they do with git history), but the rest seems pretty optimal to me.
Alternatively I can add changes to older commits by recording them on top (--fixup) and tell git to auto apply them (--autosquash). I can also tell git to do the first thing automatically (git absorb, I believe it's inspired by jj).
It does take a few days to stop missing interactive rebase.
But say you’re in the middle of working on something and you wish you had a commit you made last week on an experimental branch on the current branch before the last commit you made. That’s jj rebase -r oldercommit --before @-, without interrupting your work. I don’t like to think about how I’d do that with git.
> say you’re in the middle of working on something and you wish you had a commit you made last week on an experimental branch on the current branch before the last commit you made. That’s jj rebase -r oldercommit --before @-, without interrupting your work. I don’t like to think about how I’d do that with git.
This is the best pitch for jj I have seen yet. This should practically be the first text on their website.
jj just makes lots of git operations go from "technically possible if you're creative enough" to "<= 3 solutions, one of them probably being obvious". jj lowers the skill ceiling of git, and raises the floor.
How many of those do you need? How do find the correct arguments and git checkouts to do before? Are you sure you remembered to do everything? What if there are merge commits?
Why would I do a checkout before? I don't want to modify the worktree? Maybe I in fact also want to alter the worktree, but that's unrelated.
> Are you sure you remembered to do everything?
Am I sure I have all my files ordered? No. Does it matter? Also no. Are you sure you have no bug in your commits in JJ?
If I want git to alter some set of commit chains, I can tell it to. Actually I never needed to do that, because I don't work on several thousand branches at the same time. I prefer it to not alter unrelated branches automatically, just because some earlier commit changed that is in both. Such things actually undermines the trust I have in a tool, because it does things I haven't told it to do, even if I'm aware it does these things.
> What if there are merge commits?
Then I resolve them. Merge conflicts occur, because there is some actual conflicting change and often it is also semantic. These don't go a way by changing the VCS. On a theoretic basis, these require outside information(=decisions) that is not there yet. There are more often semantic conflicts, that are not syntactic, then there are the other way around. If you are referring to doing the same merge conflicts again, I can tell Git to resolve them automatically too, but it actually occurred too often, that this is not actually what I want, so I actually dislike that feature now.
Separate git rebase commands. JJ manipulates the whole DAG in singular operations, where as with git you're working one ref at a time. And carefully managing where one ref intersects with another, to rebase those commits only once, reusing the rewritten commits from the previous git rebase. With jj you just say "that thing, over there" and all descendant commits and bookmarks are updated, no matter what the shape is.
I do, but I don't really get it, because you did learn the jj command. I mean you could have learned jj first, I would understand that, but I presume that is not the case.
that’s the first example I’ve seen these last year so that makes sense to me about jj having better commit management.
I rebase a lot using Fork (git gui) and it’s really easy to drag and drop reorder commits, rename, apply as fixups or squash in. I can see how jj makes sense if you’re in the command line, though. And splitting changes from commits in git is really annoying, but it only comes up once in a blue moon for me.
The ability to rebase, reorder, and squash like this only really makes sense with jj’s autorebasing IMO.
With git, if you do this, everything after is left orphaned. Even if you have a GUI that does this for you, now rebase conflicts become an enormous pain.
Along with the appropriate git stash and git stash pops or git commit -anm wip and git reset HEAD^ so long as you’re not using your staging area for anything, yeah.
But if the cherry pick doesn’t cleanly apply at the current HEAD, then you have to remember to either do the git rebase -i first and pause at the appropriate place to cherry pick it if that works (I think it should? though I also recall rebase only letting you pause before a commit so you lose your commit message, but that’s probably a me problem) or else maybe detach your head and start doing surgery because otherwise you’ll be resolving conflicts in two different directions as you cherry pick and then rebase, and at that point I’m usually going
back to git reflog to try to find the last point where history made sense. Or I guess you could just remember that you can introduce arbitrary existing commit refs into an interactive rebase like 1718627440 did. But I said I didn’t want to think about this anymore.
> Along with the appropriate git stash and git stash pops
If you don't want to do that, you can tell git to do it automatically too? I actually thought I would like that, so I used it for a week. I did not like it at all.
> But if the cherry pick doesn’t cleanly apply at the current HEAD
If the diff you want to commit isn't applicable to the tree you want to apply it to, it's not going to work, no matter the VCS you use.
> then you have to remember to either do the git rebase -i first and pause at the appropriate place to cherry pick
You say that like these would be separate operations, but for me these are very much not, I guess like the fact that you need to supply both '-r oldercommit' and '--before @-' are for you. I think this is the point where I actually don't understand your view. Like, we both need to supply two parameters, we need to because this is the operation we want to do. You write two parameters free form, I write one free and select the other from a list. There is a difference, I actually think selecting from a list can be more convenient in some cases, less in others. But I don't get why you write like it would be crazy work.
> though I also recall rebase only letting you pause before a commit so you lose your commit message, but that’s probably a me problem
It does only let you handle full commits, if that's what you mean, if you want to split a commit you need to provide information how. But that it doesn't sound like you mean that.
> so you lose your commit message
You can apply commit metadata independently of the tree you want to commit, so that definitely occurs never.
> maybe detach your head
I bet you don't have issues with detaching the head in JJ, so why do you in Git, it's just a normal state.
> start doing surgery because otherwise you’ll be resolving conflicts in two different directions as you cherry pick and then rebase
Yes, but that is not because you use Git, but because you wrote the change against some other commit first, which you don't do in your JJ example. You could do that in Git as well and then you only have one set of merges to resolve.
> I’m usually going back to git reflog to try to find the last point where history made sense
Which is git rebase --abort or git reset @{1}. The latter is always the same, this is as silly as saying I can't remember whether it's jj undo or jj revert.
> But I said I didn’t want to think about this anymore.
If I may ask, how much time have you spent trying to learn use jj? I ask because I've seen a strong tendency for people to who have never used it to argue against it. I see much less arguments against it from people who understand both Git and jj well. But that's just my impression; I may of course be wrong.
Because it interferes with my workflow. If there are non-committed changes when I want to do something else, they do represent actions I want to do. I don't just have random uncommitted changes there. Setting --autosquash as default results in my finding out I forgot something later.
I believe this to be the same with the index, that is praised as unnecessary and "overcomed" in JJ.
I love the index, and often have "uncommitted" stuff lying around. jj makes doing this easier because you represent the index as an unnamed commit, and everything just works, as opposed to needing to manage the index vs committed changes with separate tools.
What I mean is, you manage the index with the same commands that you manage commits with. The emphasis is on "with separate tools" not "manage the index".
I am super curious as to what you mean specifically, but I also know that getting into details can be annoying, so if you have some specifics I'd love to hear more about them. I loved git's index so this isn't coming from a place of "the index sucks and you shouldn't care about it" it's "I think jj executes the index better than git does actually". But also if you don't, that's fine by me too, if you like a tool you should continue to use it.
You're broadly right but I think you're dead wrong about the CFO statement — I think "July revenue alone exceeded all of Q2" is an extremely normal thing to say when revenue is going up at an insane rate. For example, if it was not true that June revenue exceeded March-May revenue, the point would be to show how their revenue growth has accelerated.
She, and we do not have the direct quote. It's a paraphrase, and the report can't seem to decide whether they're talking about revenue or growth. If she was talking about growth, "the ARR growth in July exceeded the ARR growth of Q2" is perfectly coherent.
Are you just speculating now? No source mentions growth.
The source you linked says: "Friar told staffers that annualized recurring revenue in July was higher than in the second quarter as a whole."
If we're charitable that means they annualized the quarter, i.e. multiplied by 4.
Which, if both measures are ARR, just means that a single month outperformed the average of three months, which is something that happens 50% of the time. Something you can opportunistically say whenever the coin flips the right way.
The less charitable reading is even worse, that one month's revenue times 12 is more than three months worth of revenue. Because duh.
The CNBC report I linked, which appears to be the primary source, mentions growth in the second paragraph. It is the main characterization of what Friar said.
“In an internal meeting with employees on Wednesday, finance chief Sarah Friar and board chair Bret Taylor touted OpenAI’s revenue growth and addressed competition with Anthropic, CNBC has learned.”
"July revenue alone exceeded all of Q2" would be a very normal thing to say, but you're skipping over some of the words. Unless revenue is sharply dropping, annualized recurring revenue in any month will exceed the revenue incurred in any quarter, because it's an annualized figure.
I think the most likely explanation is that the CFO misspoke and intended to say something more like your quote, or perhaps she spoke correctly and was misquoted. But without audited financial statements, all we have is speculation, and there have definitely been times in the past when executives of major companies made intentionally misleading statements about their revenue. (In fact, this thread began with a question about why you can't just look at the numbers, and here the answer is that nobody has reported the actual revenue numbers this comparison is based on.)
I didn't say I hate it. I've never seen any reason to doubt that Ed Zitron is a great guy who's working hard to tell the truth as he understands it.
My point is that any discussion of how a large, complex company is doing requires making judgment calls about which numbers are more or less reliable, do or don't matter, etc. This is especially so when it's a private company that has not yet any kind of meaningful disclosures. So if you don't think Ed Zitron's judgment is sound, there's no good way to adjust his commentary for that and "just look at the numbers", because the numbers have been filtered by his judgment even if they all came from accurate underlying sources.
No, you can't. The numbers are genuinely confusing, and Zitron actively works to make them more confusing rather than explaining what they mean because he needs them to sound as bad as possible. He also buries the numbers in thousands of words of prose!
Yes, and his post about the exact same data was noticeably more confusing and less illuminating than theirs because he was primarily concerned to point to whatever the biggest number was and go "Ooh, big number!"
Macrofinance expert Nathan Tankus has an excellent post on why the financing situation around the AI boom is just not big enough to mess up the financial system.
I agree that the specific amounts invested in AI aren't enough to cause a calamity directly.
The problem is you have the vise of a stock-market decline on one side (something basically everyone thinks is impossible), and AI-induced unemployment on the other side (something a lot of commentators, including Zitron sometimes, seem to think won't happen). Those two things in tandem would be worse than 2009 by a multiple. I doubt the US government will be able to bail it out.
It's not hard to sell a dollar for 50 cents. Imo, these businesses are pretty clearly not doing well financially (the revolving door of unvested C-levels is a good hint, the constant postponing of S-1s is another).
That graph looks a lot less impressive when not "annualized". Annualized revenue can be gamed in a number of ways, and is a big reason companies tend to compare YoY to investors once they're public.
Their quarterly revenue looks exactly the same. It's literally the same data. Annualized revenue can be gamed when it is fluctuating. It can't really be gamed when it is growing exponentially for three years straight. There's nothing to cherry-pick.
reply