Claims about “what comes after git” aside, I really like the idea of virtual branches. Worktrees have a pitfall IMO that they don’t allow you to test changes in a running local env, meaning I need to commit the changes, close the worktree, and checkout the branch on my primary workspace to verify.
Gitbutler virtual branches OTOH appear to provide branch independence for agents/commits, while simultaneously allowing me to locally verify all branches together in a single local env. This seems quite a bit nicer than checking out worktree branches in the primary workspace for verification, or trying to re-run local setup in each worktree.
I had a near identical approach for my blog but I recently moved to a headless CMS. The bugbear being that it wasn't easy to publish if I wasn't at my desktop. With a headless CMS, I auth through Github via my phone, which also serves as the draft/publish step since posts in the CMS manifest as pull requests. It's been working great so far, with the caveat that the writing experience isn't as nice as Obsidian.
FWIW the CMS is Decap CMS and I have it configured likewise with Cloudflare Pages (since Pages supports functions that are needed for the auth/callback cycle).
Emacs 29 made getting started a lot easier IMO, my from-scratch configuration is pretty minimal and I use it everyday. To plug my own project, I built a "kickstart" equivalent (https://github.com/mgmarlow/start-emacs) that sets up some recommended defaults and packages with lots of comments so you can easily extend it.
I don't think so. I just think right now Vercel is very good at marketing and lots of new programmers and hopping on the NextJS train. There are tons of materials out there for building apps quickly and it's very appealing for newer developers, particularly the bits where getting a site deployed is as easy as running a couple commands w/ the Vercel CLI.
For larger applications, I don't see meta-frameworks eating up a significant chunk of the world since they're very expensive to run in certain situations. Especially so if you use the default deployment options and rely entirely on serverless functions for your infrastructure or a database-as-a-service like Firebase/Supabase. I think it's inevitable that people will carve bits and pieces off of their meta-frameworks into different types of applications as they scale, just in the same way that people carve up their Rails applications of yore.
I generally think that the meta-framework obsession will also help propel backend SSR + HTMX, since thinking in server-side components is easier to translate to traditional backend SSR than SPA -> backend.
> database-as-a-service like Firebase/Supabase. I think it's inevitable that people will carve bits and pieces off of their meta-frameworks into different types of applications as they scale
(Supabase maintainer) Supabase is just postgres, so it’s actually designed like this. You can start using all the “auto generated” tooling, then evolve into a pure Postgres + middleware solution if you need/want to
> they're very expensive to run in certain situations.
In terms of pricing, it’s ~equivalent to RDS, at least the database component
I found this snippet in one of Mickey's earlier tree-sitter posts that works great. It does require searching through the tree-sitter repo to make sure your paths are correct:
Really happy to see this. I've been using Emacs 29+ for the past while and have enjoyed simplifying my configuration now that use-package is OOTB. I think now is a really excellent time to try Emacs if you haven't already.
I put together a simple tool to generate a starter Emacs config from a few configurable options, which I can now update to point at a proper release channel instead of a prerelease:
As someone learning Common Lisp for fun and planning to use it in the web, I’m a little disturbed by the “we manually force garbage collection periodically” part of that article. I haven’t fully digested the commentary, so maybe I’m more concerned than necessary…
Looks like they wanted to configure a much larger heap than they needed just in case, but then to have the system pretend it doesn't exist, and do GC cycles at a much lower threshold. I'm surprised SBCL doesn't have parameters to be just tuned that way; if not, that could be upstreamed.
Going longer between garbage collection cycles could be worse in terms of caching and paging. Marking the live objects allocated in that generation is about the same, since that doesn't grow, but there is more garbage to visit and sweep. Sweeping a smaller memory area more frequently is going to be faster than sweeping a larger area less frequently, from the point or view of caches and TLB.
(Regarding my remark about live objects; with larger collection cycles, they could be spread in a wider VM footprint, even if their quantity doesn't grow. The image has a kind of "GC working set"; longer intervals mean that there is a longer working set. The data being transformed cycles through more memory locations.)
I would say so, specially when you plan to use it for web dev (welcome!). Shinmera has released a game in CL heavily depending on CLOS (object system), and he says the GC is barely a matter.
I recognize your user name. Great work on the Lisp Journey site! Several times I’ve had a question and then found the exact same thought expressed on your site (along with an answer).
That's nice to hear, thanks for the feedback. I've been puzzled many times when starting out (or taking a not-so crowded path), so I'm glad the ones after me are having a better time.
Now, your time to build cool things and share in the process ;)
I use web-mode + typescript-language-server for React+TSX. Whether or not you choose to use eglot or lsp-mode, I'd still recommend following the lsp-mode performance guide: https://emacs-lsp.github.io/lsp-mode/page/performance/. Those tips are useful for all setups.
Gitbutler virtual branches OTOH appear to provide branch independence for agents/commits, while simultaneously allowing me to locally verify all branches together in a single local env. This seems quite a bit nicer than checking out worktree branches in the primary workspace for verification, or trying to re-run local setup in each worktree.