Yes. I think one of the big advantages of SoA is that you only pay for the fields you're currently using.
If you need a field somewhere, you can add it and only pay the cost of iterating it where you need it.
foot also offers a client/server architecture.
If you start a foot server (e.g. with a systemd service), you can use `footclient -N`.
This may reduce the memory pressure of running many terminals.
This is similar to the `kitty --singleinstance` mentioned in another comment by amarshall.
I was once a bit of a Julia performance expert, but moved toward c++ for hobby projects even while still using Julia professionally.
I wrote a blog post at the time with exactly that punchline (not explicitly stated, but just look at the code!):
https://spmd.org/posts/multithreadedallocations/
The example was similar to a real production-critical hot path from work.
Maybe things changed since I left Julia, but that was December 2023, for years after this blog post.
I'm still working on it.
I'm currently working on a cache tile-size optimization algorithm that should (a) handle trees (a set of loops can be merged at some cache levels and split at others, e.g. in an MLP it may carry an output through the L3 cache, while doing sub-operations in the L2/L1/registers) (b) converge reasonably quickly so compile times are acceptable.
This is the last step before I move to code generation and then generating a ton of test cases/debugging.
My goal is some form of release by the end of the year.
Yeah, for now.
I'd like it to be open, but I also want to potentially be able to make money/a living off of it.
My dream would be that it can be open while hardware vendors pay me to optimize for their hardware.
For how, being closed gives me more options. It's a lot easier to open in the future than to close, so it's just keeping options open.
I've thought a lot more about the engineering than any sort of marketing or businesses plan, so I just want to defer those.
I'm just messing around with building agents, that's all. I'm not super interested in making ones that just sit in a terminal executing shell scripts because truth be told they're absolutely trivial to make and don't show any interesting parts of LLMs, whereas telling an agent that they are sitting in Kakoune is a whole lot more interesting and really shows a lot of what LLMs aren't great at, and how they'll have to fight their urge to spit out overwrought bash invocations or at the very least find a way to fit those into something new.
So far the only tools the agent has access to are `evaluate_commands(commands=["...", "..."])` and `get_buffer_contents()`, which really makes them have to work for doing things. I could make it super easy for them but then it wouldn't be an interesting experiment.
If I were to try to make something more useful out of this, I'd probably add the ability for LLMs to list buffers, probably give them an easier out for executing shell scripts in the way they prefer, give them an easier time to list docs and a few other things like that.
The tools and the interaction with Kakoune is really trivial to write; I already use this by having the agent write to the session FIFO (a very simple binary format) and I extract information via my own FIFO that Kakoune writes to (this is used for the buffer data only right now).
I think once you started using it more as a tool and not a pseudo-benchmark like I am you'd probably think of even more things to add but a lot of it comes down to just making Kakoune's state visible and making shell spam (which the LLMs love) easier.
In my experience, llms don't reason well about expected states, contracts, invariants, etc.
Partly because that don't have long term memory and are often forced to reason about code in isolation.
Maybe this means all invariants should go into AGENTS.md/CLAUDE.md files, or into doc strings so a new human reader will quickly understand assumptions.
Regardless, I think a habit of putting contracts to make pre- and post-conditions clear could help an AI reason about code.
Maybe instead of suggesting a patch to cover up a symptom, an AI may reason that a post-condition somewhere was violated, and will dig towards the root cause.
This applies just as well to asserts, too.
Contracts/asserts actually need to be added to tell a reader something.
I netted huge performance wins out of AVX512 on my Skylake-X chips all the time.
I'm excited about less downclocking and smarter throttling algorithms, but AVX512 was great even without them -- mostly just hampered by poor hardware availability, poor adoption in software, and some FUD.
I use niri and footclient -N, so builtin window and tab completion don't appeal to be.
Foot feels fast, but I've not actually measured the latency.
It also seems to use less CPU than GPU accelerated terminals (which it isn't) from just glancing at btop. So I'm not sold on GPU-acceleration as a feature unless I see benchmarks demonstrating the value in improved latency and reduced CPU use compared to foot
I love that foot's scrollback search, selection expansive, and copy can be entirely keyboard driven. Huge QoL feature for me that often seems neglected to me in other terminals.
I use kakoune, and don't understand why helix seems to be taking off while kakoune (which predated and inspired helix) remains niche.
Kakoune fully embraces the unix philosophy, even going so far as relying on OS (or terminal-multiplexer, e.g. kitty or tmux) for window management (via client/sever, so each kakoune instance can still share state like open buffers).
Sensible defaults and easy setup are a big deal. No one wants to fiddle with setting up their lsp and tree-sitter. There's probably more to their differences in popularity than just this, though.
I think the easy setup is exactly the reason Helix has taken off compared to Kakoune. It probably has the most simple onboarding experience I've had with any text editor. Things just make sense, and tools that should be built in are.
I think the philosophy of delaying the plugin system as long as possible is one of the reasons helix has achieved that.
With Helix I just have to learn selection first, and few different binds compared to vim. With Kakoune, I have to onboard into a more complex ecosystem, in addition to that. A lot of people already have vim/neovim config fatigue so that's not very compelling.
I genuinely don't like the concept of the keyboard interaction in helix and kakoune, selecting things to modify them. I don't know what it is, but it somehow just feels much less satisfactory to me personally compared to the vim way.
The biggest benefit is multiple cursors. The helix and kakoune multiple cursor implementation are probably the best in any editor. It just goes hand in hand with selection first.
The problem with that editing model for me is that it makes text objects much more cumbersome.
In Vim you can for example do "dap" to delete around a paragraph, but you cannot easily invert it ("pad") because 'p' is too common and is already bound.
You can also easily do the "select first" in Vim by first pressing 'v' to start a visual selection, so I just don't see the point.
This bugged me for reasons I can’t quite explain. I think it’s that I can write and edit the command before making the modification and the ease of going back and reusing a historic search and replace relatively easily.
I spent about a month trying to get used to Kakoune. It never clicked with me and I went back to vim.
My biggest beef with Kakoune’s editing philosophy is that it seems to emphasize “editing in the large” as its preferred mode of interaction. This is totally backwards to me. Editing in the large (making multiple identical edits throughout a buffer) is a rarity. Most edits in day to day use are single edits. So the fact that Kakoune likes to leave a bunch of extra cursors in your wake (like a trail of breadcrumbs) as you jump around a file to make single edits is extremely infuriating to me, like it’s trying too hard to be helpful.
The irony of Kakoune using a clippy-style contextual help window is not lost on me!
This is unfortunately exactly why I never used (neo)vim or kakoune (or tbh, sublime text whose lsp integration I have never successfully gotten working). Going from school (Java + NetBeans/C# + Visual Studio) to work (C#/JS + Visual Studio -> C#/TS Visual Studio Code) I had expectations for certain language features being available by default. Helix is the first editor of its ilk to get configuration out of my way so I can effectively write code the way I'm used to.
I don't have direct experience with either Helix or Kakoune but after only a few minutes tinkering around, I can see one big reason: In Helix, most of the basic commands seem to be the same as vi. Whereas I understand Kakoune inverts the action/movement paradigm of vi. Maybe that's a more sensible design, I don't know. I didn't check to see whether or not the key bindings were similar but at that point, it's rather moot.
I've been using vim for 25 years, my muscle memory isn't going to tolerate switching to a whole new text-editing "language" at this point. But I could perhaps learn to live with a new dialect.
https://github.com/Genivia/ugrep#aliases
Claude Code may ship with ugrep already.
reply