Staff Engineer at GitHub. Founder of CommonJS, TurboGears and Paver. Previously worked as an architect at Khan Academy, Adobe (Brackets), and Mozilla on developer tools.
[ my public key: https://keybase.io/dangoor; my proof: https://keybase.io/dangoor/sigs/S70GBsa2K96S1xO_Z-3r_jHUL6cQ0dFjqQmMlJ6na0o ]
I was thinking the same. Especially now that Obsidian has a CLI to work with the vault.
The one thing I saw in the README is that lat has a format for source files to link back to the lat.md markdown, but I don't see why you couldn't just define an "// obs:wikilink" sort of format in your AGENTS.md
As a heavy Meetup user, I can say that Bending Spoons absolutely fixed some glaring, long-standing bugs. But their massive price increases have really driven people away, and some of their attempts to grab more money (Meetup+) really rankled a lot of people. Also, search still sucks.
Something interesting about your comment is that HN also has a post today (https://tigerbeetle.com/blog/2025-10-25-synadia-and-tigerbee...) about TigerBeetle's support for Zig and their reason for using Zig specifically talked about wanting something for a long time horizon:
> Investing in creating a database like TigerBeetle is a long term effort. Databases tend to have a long half life (e.g. Postgres is 30 years old). And so, while Zig being early in 2020 did give me pause, nevertheless Zig’s quality, philosophy and simplicity made sense for a multi-decade horizon.
> There are no plans to move the NATS server to Zig.
> Zig will become a Tier 1 NATS client, and Synadia will utilize Zig in resource constrained environments to bridge OT/IT for manufacturing, IIOT, connected cars, robotics and embodied AI.
> I wonder why folks who start with roughly the same skills, intelligence and opportunities (and bank account balance!) can nevertheless end up in very different places?
External factors (aka luck), perhaps? Someone gets their resume into a job just after they made the last hire for that position. Or the car they can't afford to fix breaks down on the way to the interview.
This is something I've wondered about. I started out in the green screen era and remember how amazingly quick those UIs were to navigate. I don't see any reason why we couldn't replicate much of that UX and development model, but deliver it to web browsers with graphical capabilities in the parts of the system that need it.
I feel like mouse+keyboard is a step down in speed of use for many tasks, but I do wonder about touch screens. For some things, touch screens can be plenty fast and the UI adapts to the task.
If you have a frontend that is entirely dependent on data from the backend to display something to the user, then you've already got high coupling between the two.
You probably wouldn't use this for a drawing app. But if you've got something where you're showing/updating database data, this model is likely fine.
My tip, which seems to be working for me so far: I upgraded from a 2015 to a 2018 a few months ago, and _immediately_ added a silicone keyboard cover that I got on Amazon for $8 or so.
It's really thin and doesn't bother me, but the key thing is that it keeps everything out of the keyboard. So far, my keys continue to all work just fine. It could be luck, but it could also be that no dust or anything is getting trapped in the butterfly switches.
I will give the disclaimer that much of the time I'm typing on a bluetooth keyboard, but I still get quite a bit of use out of the built-in keyboard as well.
[ my public key: https://keybase.io/dangoor; my proof: https://keybase.io/dangoor/sigs/S70GBsa2K96S1xO_Z-3r_jHUL6cQ0dFjqQmMlJ6na0o ]