I get your point and think in a similar way. The difference between AI and the coconuts is -> there is no way deaths by coconuts increase by 10000000x, but for AI it's possible.
The reasons we have not - and probably will not - remove obvious bad causes is, that a small group of people has huge monetary incentives to keep the status quo.
It would be so easy to e.g. reduce the amount of sugar (without banning it), or to have a preventive instead of a reactive healthcare system.
I’m not so sure that’s true. There are many examples of OpenAI putting in aggressive guardrails after learning how their product had been misused.
But the problem you surface is real. Companies like porn AI don’t care, and are building the equivalent of sugar laced products. I haven’t considered that and need to think more about it.
Wouldn't be the trick to let AI code the app on first requests and then let it run the code instead of have it always generate everything? This should combine the best of both worlds.
I still remember feeling like a badass using Git-SVN on my SVN-based team, and being the only guy who could actually correct bad merges and restore lost data without having to plead to our SVN admin.
And now I'm feeling like a badass using jj on my Git-based team :)
Having used git submodules, I see a lack of them as a feature. I honestly think that a script that checks out a specific commit from an external repository, combined with adding the path to the .gitignore is strictly better than submodules.
sure, but there are projects that use them already. If jj wants to replace git, it needs to work with people's existing projects without significant changes (ideally none at all)
Changing git hosts happens less frequently than changing clouds, which is infrequent. Changing VCS tools is even less frequent than either of those
The development world is much different and entrenched than it was when the move from svn -> git happened. Think of all the tooling, integrations, and automation we use these days. That was not happening 15+ years ago. I don't think svn as an analogy holds much water, tbh
Sounds like I still need git for much of this, so jj and the things it does is and additional thing to manage. I've been told intermixing them is not a good idea
At the same time, not everyone requires those features. All I mean to say is, the degree of support is varied out of the things mentioned, not just "no support for any of them."
The docs say "no" to support for all of those except tags, which is "partial" because jj can check it ou, but not create them, which hopefully is clear in my comment that "new tags" is still a "no"
I'm going to take the docs for what they say about support over an HN comment
You can trivially run `git tag` and create one, or in your forge and then pull it down. Creating one is not directly supported directly in jj's cli, but if you create a tag, it's in the repo just fine.
It’s not. It’s that there’s no inherent advantage to doing it natively when it works just fine via git. There’s more important things to do first, like many of the things on your list.
jj clicks almost for me. I still struggle to understand when do I switch to a "branch" using 'jj new' and when do I use 'jj edit'. Also the manual setting of bookmarks after 'jj git pull' seems strange.
Too bad that we still use text based shells in the year 2025. We should have come up with a graphical shell that is as powerful and flexible two decades ago.