Hacker Newsnew | past | comments | ask | show | jobs | submit | thibran's commentslogin

Mozilla wasted probably hundreds of million dollars trying all those "features", but all we want is a stable browser.


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.


Right– write the application by using it. Pave the paths that work the way you want.


auto rebase, simple undo (jj undo), no staging area, easy splitting and merging


jj is so good, finally a tool to replace Git.

SVN -> Git -> jj


That's an excellent description.

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 :)


No LFS, submodules, hooks, or new tags means jj has some ways to go before it is a viable replacement for many organizations

https://jj-vcs.github.io/jj/latest/git-compatibility/


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


git doesn't do everything that SVN does, so I don't think that's true.


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


Tooling, integrations, and automation (Including CI) were all things we used at my work when we switched from CVS to SVN almost 20 years ago.


Some people were, yes, but the scale of this has changed in those 20 years as well


How do you record the specific commit of the external repository, that was used in a specific commit of your repository?


LFS sorta works and submodules are just managed by git, and you can create tags with the git CLI just fine.

Hooks are a bigger change, though, for sure.


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


Sure. Use the tools you like!

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."

It's still pre-1.0 software. We'll get there :)


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.


right, but then I'm using git, not jj, so why jj?

Why do people believe it's going to replace git if it won't do basic things we need. Why is it hard for jj to create a tag?


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.

It’ll get there! Early days.


The advantage is in not requiring multiple tools to do the job when one already does it fine by itself.

jj claims there are these really bad problems with git, which is not my experience. Git is not on my list of pains in dev work


30% of the productivity hacks can be archived in vanilla Nushell.


zoxoide, rg, fd, jj and Nushell are my command line favorites.


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.


No. I've done Java long time ago and now again in a new job. Java is still verbose and clumsy. Did not like it back then and don't like it now.

Would prefer to use Kotlin or Clojure.


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.


text is discrete, graphical is continuous. very different psychologically. i disagree with you wholeheartedly.


What's a graphical shell in your mind if you don't mind me asking?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: