Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Meilisearch 1.0 – Open-source search engine built in Rust

blog.meilisearch.com

Post reply on HN
Print view View original

61–70 of 186 posts

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#61

Post by groestl »

curquiza wrote: post #16
chimen wrote: post #10

Is Rust that important that you have to place "built in Rust" in the title? Is this like a cult following that we only bet on traffic and interest coming from other evangelists where Rust is the only feature that matter? 4 months ago: " Meilisearch, open-source alternative to Algolia in Rust lands a $15M Series A" It's not the first time I see, there are at least 2-3 daily submissions reaching the FP in this manner s…

Hello! For me, "built in Rust" can be a real marketing argument. Indeed, Rust is a language that has proved its safety in the past. Building a technical product in Rust guarantees stability and safety (no memory issues in general) and performance (no garbage collector issue), so it brings more trust to the users.

Safety yes, but stability? It's crash early model wrt stack overflows and out-of-memory errors seems to trade off availability for safety. Not proficient in Rust as a user nor as a developer, so an honest question.

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#62

Post by dureuill »

kristiandupont wrote: post #36

I am using the core (called "Milli") in a local indexer that I run on my repositories and Obsidian files. It works like a charm and I am very happy with it. Obviously that's a use case with very little traffic but just indexing my repositories folder is quite a bit of work and it does it surprisingly fast. The only real thing I am missing is a typeahead feature.

Hello from a Meilisearch team member,

wow your project looks very interesting. How do you handle things like the filesystem changing while your indexer is offline? Do you reindex from scratch at startup?

Regarding typeahead, is this what we call "query suggestions"[1]? At the moment, we think that this is something that frontends and SDK can provide rather than the engine, so that means you wouldn't find it at the Milli level. We think you could maybe build an ancillary suggestion index and make two queries instead of one when typing, so as to get both results and suggestions at once.

Here's a chat link[2] to our latest discussions on the topic; feel free to come and weigh in if you're interested!

[1]: https://roadmap.meilisearch.com/c/31-query-suggestions

[2]: https://discord.com/channels/1006923006964154428/10685073658...

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#63

Post by cies »

groestl wrote: post #61
curquiza wrote: post #16

Earlier quoted context omitted.

Hello! For me, "built in Rust" can be a real marketing argument. Indeed, Rust is a language that has proved its safety in the past. Building a technical product in Rust guarantees stability and safety (no memory issues in general) and performance (no garbage collector issue), so it brings more trust to the users.

Safety yes, but stability? It's crash early model wrt stack overflows and out-of-memory errors seems to trade off availability for safety. Not proficient in Rust as a user nor as a developer, so an honest question.

So Zig then?

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#65

Post by wejick »

spoiler wrote: post #40
chimen wrote: post #10

Is Rust that important that you have to place "built in Rust" in the title? Is this like a cult following that we only bet on traffic and interest coming from other evangelists where Rust is the only feature that matter? 4 months ago: " Meilisearch, open-source alternative to Algolia in Rust lands a $15M Series A" It's not the first time I see, there are at least 2-3 daily submissions reaching the FP in this manner s…

As some people mentioned: I generally expect a higher standard of software when I see "build in Rust". That expectation includes a few things such as stability and operational UX (ie how easy it is to run and maintain). And these (in my experience as a Rust developer) stems from the fact that it's much easier to get the MVP and business logic taken care of becau I'm not bogged down by the drudgery of menial tasks tha…

While I can agree on the argument that rust offer many ergonomics and keep us away on many classes of security and memory management related issues. The quality of UX/DX is more defined by product and design requirements, not much to do with language of choice. Similar like restful api, good or bad is on the designer hand most of the time, not because it's implemented on some esoteric language.

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#66

Post by manigandham »

naiv wrote: post #58
manigandham wrote: post #8

Congrats to the team, it's been interesting to watch the development of Meilisearch (and it's close competitor Typesense). Algolia has really paved the way here but it's nice to see the open-source options with more configurations and better default UX. There's also many search libraries if you want to embed search more deeply into your app. I have a list of modern search systems and libraries here: https://manigandh…

I will never understand who the target group of Algolia is besides a website where the number of records coincidentally is in the range of the number of queries. At least they got rid of the pricing per indexing transaction which made it even more absurd. If Algolia would offer an instance based pricing on cpu, ram and storage they would be the clear winner imho.

Why do the number of records and searches have to be similar? The current pricing is simple - you pay per "search unit" which scales in both dimensions.

The vast majority of small/medium customers would rather pay-as-you-go than maintain a fixed cost instance, and it allows Algolia to efficiently pack them into a multitenant architecture instead of wasting resource overhead.

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#68

Post by jabo »

traverseda wrote: post #51
jabo wrote: post #44

Earlier quoted context omitted.

I maintain that comparison page on the Typesense side. I just updated it as recently as yesterday, based on my observation. But let me know which ones need updating for Meilisearch. Happy to update. While we’re on the topic, reminder about some of the outdated information in your comparison pages: https://twitter.com/typesense/status/1620825236055932928?s=4...

I'd say that the bit where typesense can only work with data that fits in ram is actually a pretty big problem for a lot of use cases, as an aside. That feature alone would discount typesense for basically all of my personal projects. Might be a trade off I'd be willing to make on a professional project given the other features but it seems really wasteful. Personally I find the meilisearch comparison to be more usef…

Typesense follows a memory model similar to Redis - you need sufficient RAM to hold the entire dataset.

I don't want to speak for the Meilisearch team, but from observing user reports like this [1], it seems to me like you'd need at least X-2X RAM to run Meilisearch, if X is the size of your dataset, if you want it to not slow down as it swaps content from Disk to RAM.

[1] https://news.ycombinator.com/item?id=34708658

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#69

Post by adamnemecek »

dividedbyzero wrote: post #18
adamnemecek wrote: post #15

Earlier quoted context omitted.

It is important. Rust projects are infinitely easier to contribute to.

Compared to what?

Anything. Legit no language comes even close in terms of how easy it is to git clone something and get it to build.

Re: Meilisearch 1.0 – Open-source search engine built in Rust

#70

Post by nicoburns »

groestl wrote: post #61
curquiza wrote: post #16

Earlier quoted context omitted.

Hello! For me, "built in Rust" can be a real marketing argument. Indeed, Rust is a language that has proved its safety in the past. Building a technical product in Rust guarantees stability and safety (no memory issues in general) and performance (no garbage collector issue), so it brings more trust to the users.

Safety yes, but stability? It's crash early model wrt stack overflows and out-of-memory errors seems to trade off availability for safety. Not proficient in Rust as a user nor as a developer, so an honest question.

> It's crash early model wrt stack overflows and out-of-memory errors seems to trade off availability for safety

It's worth noting that while you can catch these kind of errors in C, very little software actually does so. The only software I'm aware of that does this is SQLite. Your C software will more than likely crash in OOM and StackOverflow situations too.

Post reply on HN