Has anyone who's enjoying Jujutsu tried Meta's Sapling? I've been using it lately with the VS Code plugin, and it's been great. My understanding is that Jujutsu is pretty heavily inspired by Sapling and Google's patch-based git workflow?
I used to work on Sapling and Mercurial while at Facebook. I've been using Jujutsu full time for the last two years.
Jujutsu is in a sense the final form of that style of VCS, which I characterize as making commits first-class rather than branches, and providing powerful tools for managing long queues of stacked changes (git rebase -i is nice but has many limitations that don't exist in Jujutsu).
I’d second Rain’s reply, but having gone from git to sapling to jujutsu, I feel like the jump from sapling to jujutsu was as big as the jump from git to sapling, in terms of “oh, this is a way nicer workflow”. I really like and miss Sapling’s interactive smart log, but I found jj’s conceptual simplicity to be more compelling than ISL. That said, VisualJJ and Jujutsu Kaizen (both listed on https://jj-vcs.github.io/jj/latest/community_tools/) might give you the ISL-style experience you’re looking for.
I'm mostly git -> mercurial -> sapling -> jj. For me, Mercurial -> Sapling was a mostly lateral, slightly upward move. Sapling -> jj felt really good, though oddly not because anything felt horribly wrong or missing in Sapling. Things just feel nicer and lighter in jj. Once I know a couple of things, I can combine them to do lots and lots of other things without learning any new commands. In fact, the total command set is pretty small, yet covers about the same range as other systems (a little more here, a little less there). Also, improvements come in at understandable and predictable places: at its current stage of development, it's not growing brand new commands. It is instead slightly improving existing commands to enable significant new capabilities. It has the feel of a well-designed system with mostly orthogonal components. (Give it a decade, and perhaps it'll start crumbling under its own weight too...)
I've been using this for a few months now, and it's been an absolute joy to use.
One thing that's been a bit annoying: my org enforces signed commits, and when you merge a stack, they sometimes rebase commits internally and lose the code signing, so you end up with an error to merge the rest of the stack.
Aside from that, working with stacks has been great!
Thank you for using Graphite and your support.
This is something we're aware of and current thinking around.
Question, if we were to support this by signing commits:
Would you want the commit to be signed by the Graphite GitHub App?
Or would you prefer for it to be signed by Graphite on behalf of you?
Or some other option that we haven't considered?
I think letting me give you a gpg private key and you sign commits with that would be ideal. I'm not sure how the app signing commits would work, since it needs to be signed by a member of our org I believe?
It looks like Docker support is still a paid feature? That's disappointing. I had written a blog post outlining how important docker support was and explaining how little work it was to get working, and at the time the maintainers agreed it should be a free feature, but it seems they've changed their minds.
We've not changed our minds on docker becoming a free feature eventually. We just didn't update the pricing yet, but this is planned for the near future.
IHP is really easy to package with nix nowadays. In fact the official docker building also just uses `pkgs.dockerTools.buildImage` and calls nix-build :) Most people with nix experience can easily figure out how to do exactly the same thing as the "official" way.
What differentiates this from a more general solution like fly.io? It seems like what’s being provided is an auto-scaling docker deployment with fast cross region network links, and storage? Fly provides all of that, and isn’t focused on gaming. Why would I choose Hathora?
So you're competing with Azure Playfab... so are those services you mentioned just now available a-la-carte or is it an all-or-nothing approach? (as in, can you use your sessions/rooms without using your IdP / can we bring our own IdP (using OIDC? SAML?) - or is your room system built around your IdP?
Websockets are very different to BSD Sockets (TCP/UDP/etc) though (string messages vs. binary packets/datagrams) - if you're abstracting-away then that means devs are ceding a lot of control over the performance dials (TCP_NODELAY? Nagle?)
The example in the article using a Node.js-based game-server is fine, but what options do people needing to run a Quake-style game server (i.e. a ph-phat binary) have?
Hathora's auth story is basically bring your own JWT token. So you can implement your own custom auth as long as you end up with a JWT signed using your APP_SECRET in the end.
Websockets do actually support binary packets not just strings. But yes you lose control over the server side receiver part of the connection (we think most developers will be ok with this)
Hathora Cloud will be able to run anything that can be packaged into a Docker container and implement the Hathora Protocol (yet to be formally documented)
(I’m the author) It’s only slightly more work, but what you get in return is a reproducible dev shell, a reproducible build, and a final docker image with over 100 very granular, optimally ordered layers. That last bit makes the diff of consecutive images much smaller, which can be nice.
(Author here) Never expected something I wrote to be on the first page of HN begins sweating. I’ll be checkin this post throughout the day, so if anyone has any questions, feel free to ask.
(I’m the author) The only feature in the paid list that I’d agree with you on was support for building docker images. I thought it was silly to charge for <15 lines of nix code that do something so fundamental for a web framework, so I wrote this blog post and convinced the maintainers to make it a free feature.
Now I think the remaining stuff is fine, paying for a stripe integration and oauth libraries doesn’t trigger any alarms for me, personally.
(I’m the author) The issue isn’t nix builds in general, those work fine on MacOS, the issue is cross compiling a Linux docker image, which can be much trickier. I usually end up just relying on the github CI to build it, but nix has some nice remote builder functionality that might also be worth looking into.
Thanks for the post. I've been meaning to write up remote nix builders on macOS, especially now that going cross-OS (and cross-arch) is increasingly common, though still possible! Perhaps I'll try your tutorial with my builders and see how it goes.
Hey everyone! I wanted to play with Haskell (https://ihp.digitallyinduced.com/), and Rust (Cloudflare workers), so I decided to make a product with them. This is the MVP I’ve come up with. It supports teams, projects, environments, flag variations, scheduling and expiry, and a reasonably complete targeting system that support Boolean logic combining user ID targets, arbitrary metadata targeting, rollout targets, and default fallthrough variations.
Some of those are features that are in the most expensive tier of other offerings, but they're all in my free tier because restricting them to higher tiers seemed silly to me.
There’s a typescript and react SDK, and swagger API docs. The website runs on IHP, and the actual flag resolving API is deployed on cloudflare workers, so response times are generally 40-100ms (though that could be due to my internet, it might be faster for you).
Coming soon: reusable groupings of users, and a dashboard showing all the users that have been targeted, what flags they evaluated, and what they evaluated to.
Feel free to ask any questions, and let me know what you think!
