Woah that's actually huge. I've been very interested in tangled from an atproto perspective but I had no idea it had that as well. Wonder why that isn't talked about more. Seems like an amazing feature to potentially pull some people away from GitHub/GitLab after they've have been asking for years for a better stacking workflow.
I've been going through a lot of different git stacking tools recently and am currently quite liking git-branchless[1] with GitHub and mergify[2] for the merge queue, but it all definitely feels quite rough around the edges without first-party support. Especially when it comes to collaboration.
Jujutsu has also always just seemed a bit daunting to me, but this might be the push I needed to finally give both jj and tangled a proper try and likely move stuff over.
hey there! blacksmith solutions engineer here :) love to hear we've helped speed up your tests and docker builds!!
could you shoot me your GH org so I can apply your startup discount? feel free to reach out to support@blacksmith.sh and I'll get back to you asap.
thanks for using blacksmith!
Fragile against upgrades, tons of unmaintained plugins, admin panel UX is a mess where you struggle to find the stuff your are looking for, half backed transition to nicer UI (Blue Ocean) that has been ongoing for years, too many ways to setup jobs and integrates with repos, poor resource management (disk space, CPU, RAM), sketchy security patterns inadvertently encouraged.
This stuff is a nightmare to manage, and with large code bases/products, you need a dedicated "devops" just to babysit the thing and avoid it becoming a liability for your devs.
I'm actually looking forward our migration to GHEC from on-prem just because Github Actions, as shitty as they are, are far less of an headache than Jenkins.
Thank you for the kind shout out! Always happy to see comments like this. If anyone is looking for a better GitHub or GitHub Actions experience, feel free to reach out anytime.
Founder of Depot here. We provide faster and more reliable GitHub Actions runners (as well as other build performance services) at half the cost of GitHub [0]
Is there a write up on the security of actions or equivalent that explains how they are secure both with direct and transitive dependencies? If this applies to Depot.
Once it's available in even one browser not behind a flag, sure, but while it's still entirely undocumented and only available to people who both use Chrome Canary and know to go turn on a specific flag?
In terms of task running specifically it does generally stay that simple for the likes of just.
The only complexity there is getting it installed on everyone's machine, but that's true of most tooling, even the common stuff given versions won't match. I solve that with Nix.
I agree that the documentation story could be better. I also think it's a great shame that the language isn't statically-typed, so to understand how to use something I have to inspect its source code.
I've found it to be quite flexible though. For example, here's a commit in which I apply a patch to a tool to solve a problem that the derivation hadn't taken into account (and absent a home-manager solution): https://github.com/samhh/dotfiles/commit/867dd3b4d4b3942a0aa...
Static types are documentative, and language servers often also show you things like JSDoc alongside the type signature. Nix has neither of these, hence I have to check the source code or run a build and see what happens.
I really like Nix but in this particular way it feels like taking a big step backwards from the other languages I frequently use, particularly for a language in which you'll necessarily be constantly interacting with bespoke interfaces.
Informative function signatures, allowing programmers to add per-function documentation, and tooling that displays those things are by no means limited to staticly typed languages.
I guess knowing allowed types for each parameter is informative (more if very specific types are used rather than string or integer), but documentation usually specifies that anyway. And even knowing all the types isn't usually enough without documentation.
My point is just that I've used plenty of libraries in dynamically typed languages without needing to read the source. And conversely, I've occasionally needed to look at the source of a function in a staticly typed language, to answer some question not answered by the types and documentation.
Being able to see a function's entire type signature at a glance is the single most useful way of documenting code I've ever come across. No alt-tabbing to docs or relying on an IDE to pop up hints, etc., it's just right there.
Haskell is the ideal here, since it separates the type signature into its own separate line at the top of the function declaration. That confers readability and reduces cognitive overhead more than any other language I've used.
It also changes the programming thought process. You can pseudo-code an entire program just with function type definitions. Then test that the type defs compile without error, and go back and implement the function definitions. As long as the function definitions adhere to their type signature, the program almost always works (barring some I/O errors).
Not all statically typed languages are created equal. The ones fundamentally oriented around function type signatures, rather than variable types, are the ones I think parent had in mind in his comment.
Yeah, Arcade's selection is very lackluster. I have it as part of my Apple One subscription and I personally enjoy it, but I'm not much of a gamer and I'm pretty sure most serious players would rather have Game Pass.
This is something GitHub should be investing time in, it’s so frustrating.