The social landscape doesn't depend on anyone actually using it. However, 1.0 isn't a significant milestone like you suggest either. For a current example, Zig is relatively popular today despite not yet reaching 1.0.
Do you just forget the things you write in earlier comments?
> Rust is older than Go and it was already confusing people into thinking enums and sum types are the same thing
Of course the social landscape depends on people actually using it. None of the people who weren’t using Rust at the time were magically confused about enums and sum types by the mere existence of some new and experimental language.
Rust barely existed at the time Go was first being developed. And given the history of Go and the notoriety of its core team for flatly ignoring prior work in programming languages, it’s extremely unlikely that Pike et al gave more than a cursory glance to what nascent Rust was doing at the time.
But even if they had, to suggest that they intentionally replicated a dumb thing from C but gave it a different name to avoid users being confused by a different thing from a language that roughly nobody knew about at the time is bananas.
> Of course the social landscape depends on people actually using it.
That's nonsense. Brainfuck has shaped the social landscape despite effectively nobody using it, and absolutely nobody using it for any real work. The social landscape is not at all dependent on use.
> And given the history of Go and the notoriety of its core team for flatly ignoring prior work in programming languages
Huh? Go comes straight out of prior work. It is nearly indistinguishable from Alef. What the Go language flatly ignored was being innovative. Reasonably so, of course. It wasn't trying to innovate in programming languages so that we'd have another to throw on the heap of languages nobody uses. It was trying to solve a specific business problem using well-established methods.
The big differences are that the jj approach gives you a commit message for the staging change, and lets you jump to some other commit without extra steps.
jj has nothing I need, so it would be changes for the sake of changes. I’m not saying it’s bad, but people do need to realize that their struggles are theirs, not the whole world.
Not trying to tell you how to live your life, obviously, but I think “changes for the sake of changes” overstates it. For example, `jj undo` is a pure ergonomics win.
It’s been said a million times but it is really true that jujutsu’s appeal is something you feel (or don’t) after giving it a proper go. It doesn’t survive compression into the feature list.
Actually I think that property is a much bigger obstacle to adoption than what it does or doesn’t offer to the rare true git wizard.
I use magit on a daily basis. And I do use tig occasionally (I don't like lazygit). Most of my magit workflows only requires a handful of keys (most are only two keys). If you've not tried Magit before, it's like vim for a git repo. tig is more barebones, but I could quickly configure it to be able to do most of the magit tricks I need.
Git cli is tedious. But like all cli operations the goal is always to script your workflow or alias the most used commands in something shorter. I'm sure that jj may have an easier learning curve. But some people do know how git works and like the level of control over commits.
I’ve never used magit but my impression is that it’s similar to jj in the sense that it smooths out git’s rough edges in an elegant way and in the sense that it’s hard to properly appreciate without using it.
That being said, I also much prefer a UI layer (lazygit originally, now lazyjj), and personally I find the benefits of jj to be partly complementary to the UI ones.
That is, after getting used to jj, my problems with git are (1) the CLI ergonomics, and (2) the model is actually more complex than it needs to be, in a way that materially diminishes my experience. Only the first is addressed by lazygit (though maybe magit does both; not sure).
One other point: jj doesn’t actually impose a level-of-control tradeoff on the curation of commits. You can mimic the git workflow by modeling the working copy and staging area as commits (changes, in jj parlance), or you can experiment with any number of alternatives. What git gives you is the opinionated support for the working-copy-staging-area-commit approach.
Totally fair :) personally I used to be a git wizard and I am relieved at how much about it I’ve been able to forget since learning jj, but I understand not everyone has the same experience.
I assume you mean named branches (bookmarks in jj)? Because anonymous branches in jj are trivial: you just `jj new <parent_change_id>` and you have a new branch.
Bookmarks aren’t that bad either IMO, especially with the recent addition of `jj bookmark advance`. Curious if you can say more about the particular difficulties you found keeping them up to date?
I think I said named branches, but that is definitely what I mean. I find it strange that people want to work on anonymous branches, but to each their own. I don't so that has no appeal to me.
I often work on something and then switch away to something else. it might be a week before i get back to it, and the name of the branch is a clue as to what the heck I was doing.
Other people often need to check out a branch I'm working on to help. How does anonymous branching help anyone except a solo developer?
that doesn't make sense because when i am working on a feature, i create a branch, name the branch after the feature and then each commit has a description of what is in that commit. the feature has multiple commits, and while i carefully work out what goes in each commit i don't squash them.
so with jj i could use a bookmark, ok, but having to manually update that bookmark feels wrong.
When I'm working in git, I always start work by creating a new branch with a name. Sometimes the branch becomes something different as I work and then I might rename it or more often just keep a stale name around. But in git commit descriptions come later.
In jj, it's the opposite. I start with a change, and I often describe it right away. Branches (bookmarks) come at the end.
You could, in jj, tag a new empty change with a bookmark as soon as you create it. You don't have to advance the bookmark -- that the first change in a sequence of changes is tagged with a bookmark is probably as much information as you need?
> I think I said named branches, but that is definitely what I mean
I think I misread you, because you were talking about git vs svn in a way that made it sound like jj was a step backward from git as regards branching, and I got confused.
> I often work on something and then switch away to something else. it might be a week before i get back to it, and the name of the branch is a clue as to what the heck I was doing.
Right, but you can still name your branches with bookmarks, you’re just not required to. Personally, I tend to use commit descriptions more than bookmarks to keep track of what I’m working on, but this is a personal choice.
> Other people often need to check out a branch I'm working on to help. How does anonymous branching help anyone except a solo developer?
It’s just nicer as a local workflow, to me at least? I can create throwaway branches without having to come up with a name for them. I end up creating many, many more branches than I did in git as a result, which helps me keep my work better organized and my changes more focused when I submit them for others to review (which at least on GitHub, requires a bookmark of course). This is ultimately psychological because obviously I could just make up a name for the git branch, right? But it makes a big difference for me!
The biggest issue is my git knowledge is atrophying while my coworkers still know me as “the git wrangler” (mostly because most devs have never actually learned git, so any knowledge looks 10x more than theirs). So when a coworker comes to me with a problem like their local main now has 2000 commits that they’ve (or rather Claude Code has…) somehow accidentally re-signed locally and then the 20 commits that actually contain their work, I’m thinking this would be easy to fix with jj rebase but the best advice I can give them for git is to reset their local main to origin/main, create a new branch and then cherry pick their 20 commits to their new branch. Since that’s too time consuming they just checked out the repo again and copied their working copy over, which is the level of avoiding actually using git that the git CLI routinely inspires.
Some later googling revealed `git rebase --onto origin/main theirbranch main` was probably what they needed. Which I’m sure would have come to me quicker if I hadn’t dropped the git cli for jj 2+ years ago.
Are you me? I do feel like I'm starting to forget git as a result of my happy jj use. Thankfully some repos use git submodules, which keeps me at least a little connected
Yes, that describes me at both jobs I’ve had since learning jj. Hence why I asked for specifics: I’m genuinely curious what other people struggle with, partially because I’d like to help them if I can, and partially because it gives me a better understanding of common pitfalls which helps when teaching other people.
I use jj all the time for pull requests, in fact I don't use regular git at all anymore, and it's perfectly easy. Not only can I easily keep all my pull requests properly synced to their base branches, but I can easily and very quickly address review comments, keeping the commit stack clean without having to manually squash or amend or anything of that sort. Honestly it's a lot easier and more efficient than git for me because of how much naturally follows rather than requiring explicit imperative fixups.
I believe this is the most common scenario, yes. If you're used to actively pushing and pulling from the same branche as your colleagues, you need to learn how to manipulate diverging changes and conflicting bookmarks, but other than that all the jj magic is limited to your local activity.
Which, by analogy, would mean you could use subsided tokens for over 10 years and then, and only then, actually purchase your own hardware to do inference, with over a decade of technological advancements to compound.
I'll invest in inference hardware whenever the economics make sense, not because of my prediction that prices will get higher (also, because smaller models keep getting better and they might just suffice for most of my use cases in a few years time).
My biggest worries in terms of cost is in regards to training. Whenever that gets too expensive for Beijing to pay, we won't be getting new SOTA open small models to run on local hardware, which, again, reinforces the decision to use providers for AI inference for now.
> Whenever that gets too expensive for Beijing to pay, we won't be getting new SOTA open small models to run on local hardware, which, again, reinforces the decision to use providers for AI inference for now.
Valid takeaway.
"Invest" in the companies that release their models, because the alternative is to reward the people who will capture the market and jack up the prices to unreasonable level.
Unfortunately I think this is a bit like game theory, people will choose the local optimum despite the long term problems with doing so.
Rust originally came with a green thread library as part of its primary concurrency story but it was removed pre-1.0 because it imposed unacceptable constraints on code that didn’t use it (it’s very much not a zero cost abstraction).
As an Elixir + Erlang developer I agree it’s a great programming model for many applications, it just wasn’t right for the Rust stdlib.
Cloudflare didn't give them the option to quit hosting with CF and port their domains out. It held the domains hostage because the domains were registered through CF.
Sonarqube did not flag public fields as a security issue by default the last time I used it — however it has found several real vulnerabilities for me before.
It did by default for me, and there are a bunch of other poorly implemented analyses, such as it incorrectly flagging Dictionary keys in C# as mutable, or opinionated stuff like it disliking certain names and patterns, forcing me to make arbitrary changes that often cost performance, readability or API cleanliness.
Or insane stuff like it doing a blanket-ban on security related code in the app (but importing a third party lib that does the same is fine).
The analyses in general are low quality and you can see not a lot of effort or thought went into them.
They are not the product - compliance, and dashboards for boomers is.
I'm curious about what did it detect for you? In my experience it stops very obvious bad patterns like using string manipulation to submit SQL (which in certain circumstances might even be fine, even necessary), but it can't really trace non-obvious security issues (like tracing a value through the code, making sure its valid on every codepath), it just doesn't have the compiler machinery to do that.
reply