Exceptionally well is my takeaway. It’s the only harness I am using these days. I was previously using pi and codex mostly, but also the ones built into editors like zed, vscode, and the jetbrains IDEs.
On top of that, somewhat unrelated I’ll agree but still, it has support for vim keybindings
Oh thank you for mentioning it has vim mode that's been my only gripe and I had no idea it had it. don't know if it's new or not never noticed the setting.
Way to restrictive in terms of tokens provided. I am on their largest plan, and quickly run into their limits. And that is using it selectively in addition to codex.
I have been a long time subscriber to the economist for the same reason. The print edition is great and keeps me feeling informed. If only it wouldn’t include the digital edition too… Invariably, the more stressed I get in my everyday life by work and small children and lack of sleep, the more I get dragged towards the online edition of the economist, and BAM I’m back in the constant instant news cycle again, even though the site doesn’t update that often.
My latest life hack which I can recommend to anyone, at least in Germany: as part of my local library membership I get access to the PressReader app, which gives me access to the print edition of the economist! At 10 EUR a year it’s so affordable it nearly feels like it’s unethically so for what I get. I guess I’ll close with: May we forever be blessed with libraries, and may they never be „optimised away“ as an unnecessary social good.
Taking a peek at the repo and the local first data layer issue (https://github.com/bartblast/hologram/issues/940) I get the sense that you aren't (and not planning to) using any off-the-shelf CRDT or the like, am I right in that assumption?
How will conflict resolution be handled? Or is it a last-write-wins type setup? It would be amazing to have this build on top of automerge or something like that! It could compile to and use the automerge js libs in the browser, and deal with automerge through a NIF server side? Ok, not knowing your implementation and plans, I have to confess I am talking a bit out of my arse here...
We are working on our two site-search search engines Monocle Search [0] and SearchCue [1]. The former is squarely aimed at people using Squarespace, whereas our newer offering SearchCue is aimed at anyone with a site that wants to add search.
We used Meilisearch as the search backend in the beginning but have since replaced it with a quite sophisticated search stack built around Tantivy [2]. We now support crawling and indexing of pages, most common office documents and PDFs, run OCR and feature extraction of images you might have, offer typeahead search with the aim of giving you providing answers as fast as you can type, as well as more classic agentic/conversational ai search.
There have been quite a number of interesting optimization challenges to solve in case anyone is interested. We have search nodes distributed around the globe to provide the lowest possible latency regardless of where the end-user sits.
We are also working on some other smaller side projects, but they aren't quite ready to launch yet.
Long story short: Meilisearch is a very good search application for sure, but our needs drifted apart.
Longer version:
Our usecase isn't entirely aligned with how Meilisearch is meant to be used, I think. For one, we have a very high number of indices (at the time of using Meilisearch we had multiple per site that uses our service) and we wanted to have these replicated to edge nodes we have placed around the globe to keep latency down. In the end I was ending up spending an inordinate amount of time wrangling Meilisearch to get indices up and running across our different edge nodes. And, I am not sure if it was a regression in the last Meilisearch version we used, or user error, but at some point some index creations would just never get done, and would hold up our entire indexing pipeline. So long story short: the amount of effort needed to orchestrate and keep all the individual Meilisearch nodes up to date and in sync just turned out to be too much hassle.
The system I built afterwards works vastly better because it's actually bespoke and tailored to our use case. I can create the search indices on our crawler nodes entirely in isolation, run all sorts of preprocessing and optimizations once, and then just ship the final search indices to all the nodes that then serve them, and as a result I need wastly less computational resources on those edge nodes too, since no actual indexing work ever needs to be done on them.
It also means (double edges sword of course, because Meilisearch already gives you so much functionality out of the box) that I had to re-implement a whole lot of stuff around relevance tuning, snippet generation, ranking, etc, but as a result I have also been able to build interesting functionality than we didn't get out of the box before. And lastly, since the search index is now served as part of our main search node application things also get really fast, as I have no latency whatsoever to speak of going from app to Meilisearch.
Very interesting! I'm considering Meilisearch but have zero experience with it, so I appreciate your response, thanks. I've used Elastic in the past, but trying to avoid it now. I'm a ways from needing edge distribution, so hopefully Meili might be a decent choice until then. Isolated indexing shipped back to the core sounds pretty cool though.
On top of that, somewhat unrelated I’ll agree but still, it has support for vim keybindings