I prefer modal editing. It feels the best to me, but that could be because I learned it.
I had to learn vim back when I was a basic system administrator so when it came time to start doing real coding it was an obvious choice. I also prefer properly open source software, and if possible, non-corporate backed. So it checks all my boxes especially now that I'm not "missing" anything from VSCode.
When people ask me though I recommend VSCode to most normies, I don't think vim is worth it nowadays.
> Using Jujutsu, “amending a commit” also produces a new commit object, as in Git, but the new commit has the same change ID as the original.
This is confusing to me, though to be fair I'm a "git expert" by trade. If you're amending a commit surely the "change" has changed so the change ID should also change? If the "change" isn't tracking the actual changes then what could it be tracking?
Overall I think this is just more confusing than using git but I think it's cool that people are building alternative clients. That's definitely the way to go if you want adoption.
Making history manipulation easier seems like a bit of a recipe for disaster given my experience training people. That old XKCD about git comes to mind and honestly that's where most people stay, if you bother to learn it then things like Jujitsu are probably harder to use for you. If you aren't interested in learning git to that level then I doubt you want / need something like Jujitsu.
For those curious the "multiple branches" at a time thing they're selling can be done with git, IMO easily, using worktrees: https://git-scm.com/docs/git-worktree
Whenever I see tools like this I always think "that wouldve been great at my old job where we didn't do post mortems"
But nowadays I think if I can automate a runbook can I not just make the system heal itself automatically? If you have repeated problems with known solutions you should invest in toil reduction to stop having those repeated problems.
What am I missing? I think I must be missing something because these kinds of things keep popping up.
For self-hosting I've found https://k3s.io to be really good from the SUSE people. Works on basically any Linux distro and makes self-hosting k8s not miserable.
For handling secrets we manage helm via Pulumi (previously Terraform) and pass in the secrets to values from Secrets Manager or whatever cloud provider.
I haven't found a good alternative to Helm. Pulumi is probably the best if you wanted to just create manifests their k8s provider is great, but we ultimately want to shift left the kubernetes manifests and helm is pretty ok for that.
The declarative DSL for defining user interfaces reminds of QML and I'm not sure why I would use this over QT really given that Slint seems to have a similarly weird licensing model.
While I can't contest that SCons is comprehensive, I would never recommend it as a source of learning "what to do".
SCons is not idiomatic Python and it abuses things like `eval` which gives it terrible performance.
Source: I used to work for MongoDB and my full time job was to make SCons faster, which I eventually did by making it a Ninja generator (which has now been upstreamed). But the code is still pretty bad.
Using SCons however is much nicer than using make / autoconf IMO, especially now that you can farm the builds out to Ninja.
While there is definitely a higher barrier to entry, once I got comfortable with Rust (and finally stole someones working cross-compile / publish github actions for it) it has surplanted Golang in this use case because it does spark joy for me.
Man I love Make. But recently started a new job and we decided to use Just* and it's been fantastic. I doubt I would use Make again unless I was planning to use it as a real build system (which has been the minority use case of my use cases in the last 5 or so years).
Definitely, it's also important to remember how salaries vs. infrastructure costs show up on a P&L sheet.
Salaries are going to be considered largely immovable and they won't "go down" or show as a lower number on the P&L as a result of your devs getting some time back. Whereas your infrastructure costs jumping up (even by a small amount, esp if you have any amount of scale) will set of alarms, rightly IMO, in the Finance department.
I had to learn vim back when I was a basic system administrator so when it came time to start doing real coding it was an obvious choice. I also prefer properly open source software, and if possible, non-corporate backed. So it checks all my boxes especially now that I'm not "missing" anything from VSCode.
When people ask me though I recommend VSCode to most normies, I don't think vim is worth it nowadays.